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.

Sunday Selection 2011-02-20

Reading

Is Scheme faster than C? The cheapest way to make your code faster is to throw more hardware at it. But for a cash-stripped college student reworking the algorithm is probably a better idea. Here’s a suspense-filled story of how  superior algorithm devised in Scheme and ported to C turned out to be faster than a naive C implementation.

On Writing Books for Programmers I think writing is an important skill, especially for programmers. Putting your thoughts in writing helps with the thinking process. But this piece looks at writing from another perspective — namely writing for (as well as by) programmers. It’s worth reading if you’re writing for programmers, even if it’s not a book.

Media

Parallelism and Concurrency in Programming Languages Rob Pike is certainly a person worth listening to when it comes to programming languages. And of course concurrency and parallelism is all the rage nowadays. Put the two together and you have a lot to learn from this talk.

Software

Firefox 4 beta Google Chrome might be giving Firefox some stiff competition, but the folks at Mozilla are definitely holding their own. Firefox 4 is getting an impressive set of improvements and features. I think their user interface model is better than Chrome’s in some ways (especially with Panorama). There are still rough edges and most extensions will probably not work, but it’s stable enough for people to check out and use on a daily basis.

Governments and Their People

The intertubes are full of the news of the revolution in Egypt and while I’m glad to see millions of people embracing their freedom and responsibilities as citzens, their is one trend I find a bit worrying. I’ve seen the thought “People should not be afraid of their governments, governments should be afraid of their people” and I find that a bit disconcerting.

V for Vendetta

The line is from V for Vendetta. I think it’s an awesome movie that everyone should watch at least once. V is a very interesting character but it’s worth remembering that he is ultimately a character in a book (and movie). “Governments should be afraid of their people” is something that you would expect from someone in his position, with his past and his mission. But it is not something that should be taken as the working principle for concerned citizens.

 

Dictatorships and totalitarian regimes are bad, sure. But in a properly functioning democracy the government and the people are one and the same. Let’s not forget that the point of democracy is to have a government of the people, by the people, for the people. Government officers are stewards entrusted with protecting the interests and rights of their fellows. Their duty is to listen to their people and execute their will. They provide security, direction and cohesion, but not at the cost of liberty.

People should not be afraid of their governments, but governments should not be afraid of their people either. Fear is a primitive emotion from a time when we getting chased down and eaten by a bigger, meaner animal was a clear and present danger. Fear’s main purpose is to override everything else: including both other emotions and logic. You cannot establish a working, sustainable government on the basis of fear on any side. There must be balances and checks on the power of the government, but the atmosphere and general feelings must be of respect and cooperation, not fear and suspicion.

Democracy is based on the idea of “We, the people” not on the basis of “rulers vs. the ruled”. As citizens of the free nations of Earth, let’s keep that in mind. Freedom, Forever!

The Bytebaker is changing

The Bytebaker is a good few years old now and through most of that time it’s been a purely technology oriented blog. The readership has grown steadily, but I don’t take tons of readers and the ones that I do get are generally concentrated on a few posts (which are mostly Python related). Of late I’ve been giving some thought to what direction I want to take this blog in the near future.

There is a part of me that wants to keep The Bytebaker purely technology related. On one level it makes sense: it’s one website and it should have a concrete theme so that people who come here regularly know what to expect and find. But on the other hand, it’s written by one person — me, and I have more than one interest. I love music and movies and I’m trying to get back into reading regularly and I have thoughts about them that I would really like to share sometimes. But a lot of the time I either don’t share at all or it gets fragmented between here, my Tumblr blog or my static website. I’ve come to learn that maintaining multiple websites, like maintaining multiple computers, is hard and not something to be taken lightly.

With that in mind I thought it was a good idea to take a few steps and think about what I wanted to do with the Bytebaker and my other blogs and websites. In some ways I’ve been thinking about the path taken by Marco Arment and John Gruber. Their websites are technology-oriented, but also reflects their own personalities too. I think it’s a good format and something that would work well for me, because as I said, I think a lot about tech but it’s not all I think about.

However, I don’t want to just have a blog, at least not right now. I want to keep a plain static website for a number of reasons. I want a place where I can point people to if they want to know just about me, not my writing or thoughts. It’s a place to show off my projects and my writing which don’t fall nicely into a blog format. This involves papers I write for classes and things like short stories and poems that I’ve written. The blog is a great format, but it doesn’t fit everything. Since I plan on being an academic for a few more years, I also want someplace to put papers I’ve publish and things (like a resume) that would only be of interest to a small audience. I also want to keep experimenting with CSS and HTML5 without breaking my blog and a static site is the easiest way to do that.

Luckily I don’t have to decide between the two: I can have both. I already have a blog with a decent readership right here and I have a static site which is already a showcase of my projects and other writing. And the tumblelog I won’t miss much. For the time being I’m happy with just merging the Bytebaker with my tumblelog and getting a bit looser in the type of things I allow here. I’m going to rethink the categories here to reflect that. I’m changing the theme to the brighter, spacier DePo Square which is very well suited to the things I have in mind. No I’m not actually moving anything over because I don’t think there is anything really of that importance there right now. As for the website, I’m keeping it the way it is since I don’t have the time to rethink it right now. But in the end I want to be something like Professor Karl Stolley or Scott Chacon’s website: an overview of who I am with excerpts of my online activities.

I’m hoping that this change will bring with it shorter, more rapid posts offer a wider range of subjects (though probably still dealing with tech). Personally I hope it’ll remove the blocks I feel when I want to post something but don’t know where. It’s been a while since I’ve had a single unified blog and I’m rather excited to see how things turn out.

The Web is for Documents: Part II

In my last post I talked about my dilemma regarding webapps: they’re wonderful and they’re letting us do amazing things, but in the effort to become a general-purpose app platform webapps seem to be struggling against the basic document-oriented nature of the web. However, there are some applications that I think are successfully embracing the idea that web is a sequence of connected documents. I mentioned Simplenotes and Dropbox in my last post and they’re both awesome apps that you should check out. However, the document nature of the web has given rise to some new uses that aren’t applications in the conventional sense of the term.

When we hear the term “document” we generally think of something along the lines of a traditional paper document. Perhaps we can blame “word processors” for that. But in this brave new age of Web 2.0 documents aren’t just flat sheets of text. The best demonstration that I’ve seen of this new potential is the HTML5 Slideshow. It’s an HTML web page, but thanks to the the tools of JavaScript and new semantic elements it’s a great presentation too. It probably took a good amount of time and effort to put together and I don’t think you want to put this much of effort into each document. Right now, it’s a great showcase but I’m hoping that eventually there will be tools that make it easier to generate these kind of HTML5 documents with minimal effort, the same way we have great CMSs for building web pages today. There are already HTML presentation tools out there, but right now I think too many of them are trying to hard to clone desktop apps.

Moving on from presentations, another really nice example of innovative documents is the the Google book/website entitled “20 things I learned about browsers and the web”. This is almost certainly not the type of thing you think about when you hear “document” or web-page. Personally I think the pageturn effects are overdoing it a bit, but it presents a large amount of information presented in a very attractive format. I also like that the format they used is quite innovative. It’s not like anything you’d expect to see on a desktop for the simple reason that it’s not a program, it’s a document. Well, that’s not technically true: there’s a significant amount of JavaScript code being executed while you’re viewing it. But would you download and install a program whose sole purpose was to tell you 20 things about browsers and the web? We expect documents to work differently than programs (irrespective of what’s going on in the background): we don’t want to run them or interact with them to perform complex tasks, we just want information. And this book makes access to that information quick, easy and obvious.

Presenting information effectively doesn’t need to have great design and cool animations. In fact, perhaps the easiest way to present information is to get the design elements out of the way and let the content speak for itself. This isn’t a call to ignore design or to consider it as unnecessary frills. Quite the opposite: creating design that doesn’t clutter up the data is a hard job that we’re only just starting to get right. Two services that are leading the pack in this regard are Instapaper and Readability.

Instapaper has the goal of letting you save long form text you find on the web for later reading. The website itself is really simple and behaves mostly as a lightweight bookmarking service; you just save links to things you want to read when you have the time. But it really shines when paired with the iPhone or iPad apps. Instapaper strips websites of all their clutter and presents just the text on a simple background in a good font. It’s goal is simple: putting the focus back on the content and letting you read without distractions. I’ve only used the iPhone app so far, but the iPad app looks really good too. If I had an iPad it would probably be my one of favorites. Instapaper lets you read web-based content without having to be in front of a computer (or even connected).

Next up is Readability. It’s a brand new service who’s mission is similar to Instapaper: make reading easier. But Readability is focused on the web. It’s a browser plugin that will take text-rich web pages and present them in a cleaner, simpler design. There are a number of themes to choose from (I like Inverse myself). There will be Instapaper-like iOS apps soon, but that’s not the real point of Readability. It’s for people who will spend time reading in front of their computers instead of on the move (such as me). I’ve only been using it for a few days, but I’m already hooked. Whenever I see a webpage with a lot of text I want to read, but the design isn’t to my liking I hit the Readability button (or just the backtick key). I get the whole article in a nice serif font on an easy-on-the-eyes dark background as well as a list of things I’ve read recently. You can see that list here. I have some more things to say about Instapaper and Readability, but that deserves to be in a post all by itself.

I think we’re only just seeing a resurgence of the web as a document platform. These are still early days no doubt: creating HTML5 slideshows or flip-page books is not something you can do at the push of a button, but I think we’ll get there. Tools like Instapaper and Readability are helping us take back the web, so to speak. There’s still a lot of to do and I’m pretty sure we haven’t even come close to how far we can push the document-based nature of the Web. I’m certainly looking forward to seeing the new formats and services that get built in the years to come (and maybe build a few myself). While webapps won’t go away, we’ll also gain a lot from the web staying true to its document-based roots.

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.