Starting with Inbox Zero

As part of joining Cornell I have had a shiny new Cornell email address for a few weeks now. Cornell uses Gmail for its email service (along with Calendar, Docs, Sites, Groups and a few more). I’m not sure if I entirely approve with Universities and large organizations using Gmail for their mail, I do love Gmail as a mail client and interface.

Previously, Lafayette used Zimbra and I would forward all my Lafayette email to my personal Gmail accont so that I could use the Gmail interface. While it meant that all my email was in one place, it also meant that it was a bit of a mess. I’d regularly end up sending relatives email from my school account and professors email from my personal account even though I wanted to keep them separate.

Since my Cornell account gets sa Gmail interface, I’m going to keep it separate from my personal email completely. And since it’s a brand new, empty inbox I’m going to try to keep it to Inbox Zero. The basic of idea of Inbox Zero is that you use a combination of automated filtering and quick, decisive action to stay on top of email. By having all email get sorted automatically and manually processing only the things that need human intervention you can end each day with a clean inbox (a state of Inbox Zero).

I don’t really have a problem with email because I barely get a dozen emails a day (even on the busiest of days). However I do have problems replying to emails. Sometimes I’ll let things sit for days on end, lose them in the pile of things sitting (even though everything else has been read) and eventually follow up days later much to the annoyance of the sender.

The tenets of my Inbox Zero mission for my new inbox are simple. For starters, my email address is precious. It only goes out for reasons that are directly related to me being a graduate student at Cornell. As much as I can, I’m going to avoid using it to sign up for services. I’m not going to provide it as an alternate for any of my existing email accounts. How much will this work? I don’t know, but I’m hoping it’ll keep out at least some of the useless not-quite-but-almost spam that I get for my personal account.

Next step is automated processing. Whatever can be automatically filed away using Gmail’s filters and labels gets filed away, within limits. I already have labels for 2 project mailing lists and one for automated mail from the University. What I keep in mind while I set up these filters is that I don’t want to splinter my inbox into a dozen different places. Whatever doesn’t get into my inbox I can deal with later. Later here is defined as: I’ll look at it at some point in the next 24 hours and respond to it if necessary. The email that does make it to my inbox is stuff that requires my attention quickly or needs to spawn a filter so that similar stuff doesn’t come back to my inbox. Once I have read and responded to (or filtered) all incoming email, everything gets archived. Since everything is labeled I can use the labels to come back to something later (or just use the powerful search tools).

The final piece of the puzzle uses Gmail’s support for multiple inboxes. Besides the normal inbox I have two more. One is for high priority mail that hasn’t been filed away (using Gmail’s automated Important tag which seems to work pretty well for me). The other is for email that I have to respond to, marked with a blue star. This leaves the normal inbox to contain only unread email that is not high-priority. This way I can see important things that I should look at right now, things that I need to respond to as well as unread, probably unimportant things that might need to be filtered.

This is the same organizational system I’ve been using with my personal inbox which I wrote about a few months ago. However, the fatal flaw was that I didn’t actually clear out my inbox, I just made sure I read and marked everthing with some label. Unfortunately a “clean” inbox doesn’t have the same psychological effect as Inbox Zero. It’s easy to lose stuff in a sea of “read”. So this time around no compromises: Zero or bust.

The real test of my resolve (and system) won’t come until things start gearing up again in late August. The one tweak that I will need to make is when I check my mail. Right now I leave the tab open all day, but I think that’ll be far too distracting if I’m going to get email every few minutes. Ill probably adopt some kind of “check every few hours” policy, but what hours remain to be seen.

As I’ve been writing this I’ve been thinking that I should go back and revisit the system I use for my personal mail. I need to clear the inbox all the way down to zero for it to work, but that pile of 11000+ mostly answered email doesn’t look too appealing. Maybe someday in the not too distant future. But I’ve learned some lessons (I think) and it’s good to be able to make a clean start.

My Gmail power user workflow

My email has started to consume me. The amount I get has slowly risen over the last few years and a lot of what I get s not spam, but not important either. This means that I’ve been devoting increasing amounts of time to processing my email or letting things pile up and hence mixing the important and the unimportant It makes it harder to see at a glance and later find what the actually useful things. Psychologically I also worry about the number of unread emails in my inbox, even though most are relatively unimportant. I’ve also become rather attached to my email — leaving it open all the time and compulsively checking it whenever anything comes up.

A few days ago I decided that enough was enough and I was going to do something about the emotional and intellectual energy and time sink that my email was becoming. Looking around the internet I came across both Inbox Zero my Merlin Mann as well as an article by Christine Moran about her Gmail power user workflow. I’ve modeled my workflow on Christine’s with a few additions and tweaks.

The Concepts

I’ve come up with a few guiding concepts that help shape how my system is implemented and maintained.

  1. I want to focus on “important” email — things that I need to respond to or that contain vital information.
  2. Anything that is not “important” by the above definition must get filtered away and sorted automatically for possible future reference.
  3. At any moment I should be able to easily lookup email that I need to respond to without always performing searches.
  4. I should be able to check email only a few times a day, ideally once in the morning, afternoon, evening and night. An exception is made for my iPod which I can use to keep tabs on things that are really important but not for anything else.

The Workflow

Gmail is my mail client of choice, mainly because I change computers a lot and would like to get to my email from any machine connected to the Web. I make use of Gmail’s filters, labels and multiple inboxes to automatically sort email and present only the most important ones.

Filters and labels make up the “backend” of my system. Filters attach subject-specific labels to most of my incoming email. I can generally sort by sender, though sometimes I need to filter by content. I call these my importance filters. The labels are fairly fine-tuned and with one level of nesting (for now). As I get involved in more things I add more labels and the old ones get hidden and stay out of sight. I also use Gmail’s “Important” tag for the priority inbox, though not by itself.

The filters are designed to make sure that the only email that actually makes it to my inbox is stuff I need to read or respond to. Anything that gets past the filters but is not important enough generates a new one for that and similar cases. Everything else is labeled and sent to the Archive. Some of them I will just ignore completely (Netflix sent/received notifications) and some I go through on a weekly basis to see if there is anything interesting (ACM and IEEE newsletters).

While the labeling is mostly automatic, I use stars to manually mark emails that I need to respond to. This is done once I’ve actually read the email. I don’t have any plans for making this automatic anytime soon. This could be done with labels, but the stars are easier to see in the Gmail interface.

The frontend of the system makes use of Gmail’s multiple inboxes. Besides the default inbox I have two more. The first one shows me unread email that has successfully gotten through my importance filters. The second inbox is for starred mail that I need to respond to. The default inbox for now captures stuff that isn’t of high importance but isn’t getting filtered out automatically. As my filtering and labeling improves, it should become an “already read” section. This is different from Merlin Mann’s Inbox Zero in that the inbox is a generic holding area for read items. The actual “inbox” for all intents and purposes is the filtered unread-important list.

Ending thoughts

I’ve only been using the system for a few days, but it’s already making a good dent in the number of things that pile up. The greatest success in removing the not-spam but not-important stuff that I get a lot of every day. The final piece of the puzzle is just checking less often and not leaving Gmail open all the time. That’s something I’ll be working over the next few weeks. That’s more habitual but the fact that I’m getting fewer pings for inessential incoming stuff should help.

Though I’ve used Gmail it should be possible to implement a similar system on any client that supports filtering, tagging and custom views. I’d love to hear what measures you take to manage your influx of mail.

The Web is for Documents: Part I

I’ve always had something of a love-hate relationship when it comes to webapps. I use a lot of them and by and large I like them. But there was always something about them that seemed just a tad bit … unnatural. I could never quite put my finger on it and over the years as I started to using them more and more I put my uneasiness down to just the newness of the whole thing. By and large, I managed to put it out of my mind or learn to just live with it.

It only came back to me a few weeks ago as I was making plans for an independent study. See, one of the larger gaps in my knowledge of computer technology is networking in general and the Web in particular. I wanted to change that to some extent before I left college and since I had just one semester left I decided to spend my last semester building a webapp of some sort. But when I did that the uneasiness I had felt all along came flooding back. Though I knew that very powerful applications were being built using the current set of Web technologies (mainly HTML, CSS and JavaScript) as I read more and more about web programming something felt wrong. People were writing these huge frameworks and JavaScript libraries in order to build these great programs that ran essentially the same no matter where in the world you were as long as you were running a modern browser. Though it was a great idea and I’m sure lots of hard work had gone into it all, something felt out of place. After exploring the world of JavaScript frameworks and CSS generation tools, I think I’ve stumbled upon the answer.

The thing is, the Web was never built to be a host for dynamic applications. The World Wide Web was (and is) a platform for sharing and displaying documents and it’s only recently that we’ve been trying to hack that document-based framework to enable everything we’re seeing now. Even as the web evolves, the basic standards are still very much true to the Web’s document-based roots. The newest HTML5 specification actually adds a number of semantic elements such as headers, footers, asides and section tags that will help us create better, more meaningful documents. HyperText is ultimately a semantic markup language, no matter how much we try to hack it to be a GUI layout language. JavaScript ultimately manipulates a Document Object Model (the DOM). The inherent document nature of the Web and everything built on it isn’t something that can be ignored and it’s certainly not something that is going away any time soon.

So does this mean that webapps are bad or doomed to failure? Not at all. But it does mean that there are some things that we need to keep in mind as we build and use them. JavaScript does provide a very powerful (and increasingly fast) tool for manipulating our documents in real time and CSS is a good approach for styling and changing presentation (though the language itself could use some work). In order to build webapps that are both useful and feel natural in the context of the web, we should always have the web’s document basis in mind. Webapps that acknowledge and embrace this will have a better time than those that want to only recreate desktop-interfaces on top of HTML5 technologies.

Even today, the most elegant webapps are the ones that have embraced the document idea: Gmail and Simplenote make no pretense to be or mimic desktop apps. The reason that Gmail quickly became more popular than almost any other webmail client out there is that they took a different approach from everyone else: Gmail didn’t try to look or feel like a full desktop app, but it wasn’t just a webpage with links to your messages either. There was a very delicate balance of dynamism and static presentation that makes Gmail so great for the web (as well as no annoying banner ads).

I think the rise of the mobile web and the app store model for mobile devices is helping this new model of webapp become more popular. We’re seeing the rise of cloudtop services — services where the web interface is just one of a group of ways of interacting with the service. Take for example Simplenote and Dropbox. Both have a decent web interface, but also have mobile and desktop apps for the popular platforms and an API allowing others to build inventive applications on top of their services. This means that the webapp doesn’t have to be the be-all and end-all of the user interface. There are many interfaces, each playing to the strengths of their respective platforms.

Of course not all services are going this route. 37signals makes some great web software (or so I’ve heard, I’m not a customer myselft). They’re going all out Web, at least for their Basecamp product. Will it work? Maybe. They claim it’s because they don’t want to have specialized apps for each platform. But the web itself is a platform and the fact that they say that you need a WebKit mobile browser makes it sound like they’re just choosing the web platform instead of native mobile platforms. I personally don’t agree with their direction (and their stated reasons for it), but it will be interesting to see what happens.

I think we’re living in a very exciting time with our technology going in numerous interesting directions. As the idea of cloudtop services becomes more popular, we’re going to see a plethora of native applications that play to the strengths of their native platforms. The ones that are successful on the web will embrace it’s document nature instead of trying to ape desktop apps. And it’s not just apps that we should be looking at, the meaning and scope of documents themselves will change and become better as the Web evolves and its technologies evolves. Stay tuned for part II where I look at some novel types of documents that the web is enabling.

Software is Forever Beta

Word on the web is that Google just pulled the Beta label off it’s Chrome browser. As Google Operating System has noted, it’s not that Chrome is fully ready for mass consumption but rather that it’s just good enough to enter the fray with Firefox and Internet Explorer and that Google is in the process of sealing bundling deals with some OEMs. There is still work to be done, there are still bugs and their  are important features in the works (including an extension system). But the event raises a question that I don’t think has ever been convincingly answered: when is the right time to take the Beta label off a piece of software?

Wikipedia says that a beta version of a software product is one that has been released to a limited number of users for testing and feedback, mostly to discover potential bugs. Though this definition is mostly accurate, it’s certainly not the complete definition. Take for example Gmail which is open to anyone and everyone, isn’t really out there for testing, but is still labeled beta years after it was first released. You could say that in some ways Gmail changed the software culture by being ‘forever beta’. On the other hand Apple and Microsoft regularly send beta versions of their new products to developers expressly for the purpose of testing.

Corporate branding aside, everyone probably agrees that a piece of software is ready for public release if it generally does what it claims to do and doesn’t have any show-stopping bugs. Unfortunately this definition isn’t as clear cut as it seems. It’s hard to cover all the use cases of a software product until it is out in the real world being actively used. After all, rigorous testing can only prove the presence of bugs, not their absence. It’s hard to tell what a showstopping bug is until the show is well under way. Also, going by the definition, should the early versions of Windows have been labeled beta versions because they crashed so much? With exam week I’ve seen college library iMacs choke and grind to a halt (spinning beachball of doom) as student after student piles on their resource intensive multimedia. Is it fair to call these systems beta because they crack under intense pressure?

Perhaps the truth is that any non-trivial piece of software is destined to be always in beta stage. The state of software engineering today means that it is practically impossible to guarantee that software is bug-free or will not crash fatally if pushed hard enough. As any software developer on a decent sized project knows, there’s always that one obscure that needs to be fixed, but fixing it potentially introduces a few more. However, that being said, the reality of life is that you still have to draw the line somewhere and actually release your software at some point. There’s no hard and fast rule that says when your software is ready for public use. It generally depends on a number of factors: what does your software do? Who is your target audience? How often will you release updates and how long will you support a major release? Obviously the cut-off point for a game for grade-schoolers is very different from that for air traffic control software. Often it’s a complicated mix of market and customer demands, the state of your project and the abilities of your developers.

But Gmail did more than bring about the concept of ‘forever beta’. It introduced the much more powerful idea that if you don’t actually ‘ship’ your software, but just run it off your own servers, the release schedule can be much less demanding and much more conducive to innovation. Contast Windows Vista with it’s delayed releases, cut features, hardware issues and general negative reaction after release, with Gmail and it’s slow but continuous rollout of new features. Looking at this situation shows  that Gmail can afford to be forever beta whereas Windows (or OS X for that matter) simply cannot. The centralized nature of online services means that Google doesn’t need to have a rigid schedule with all or nothing release dates. It’s perfectly alright to release a bare-bones product and then gradually add new features. Since Google automatically does all updates, that means that early adopters don’t have to worry about upgrading on their own later. People can jump on the bandwagon at any time and if it’s free, more people will do so earlier, in turn generating valuable feedback. It also means that features or services that are disliked can be cut off (Google Answers and Browser Sync). That in turn means that you don’t have to waste valuable developer time and effort in places where they won’t pay off.

In many ways the Internet has allowed developers to embrace the ‘forever beta’ nature of software instead of fighting it. However even if you’re not a web developer, you can still take measures to prevent being burned by the endless cycle of test-release-bugfix-test. It’s important to understand that your software will change in the future and might grow in unexpected directions. All developers can be saved a lot of hardship by taking this fact into account. Software should be made as modular as possible so that new features can be added or old ones taken out without need for drastic rewrites. Extensive testing before release can catch and stop a large number of possible bugs. Use dependency injection to make your software easier to test (more on that in a later post).  Most importantly however, listen to your users. Let your customers guide the development of your products and don’t be afraid to cut back on features if that is what will make your software better. After all, it isn’t important what you label your software, it matters what your users think of it. People will use Gmail even if it stays beta forever because it has already proved itself as a reliable, efficient and innovative product. Make sure your the same can be said of your software.