Yesterday, Apple donated the source code for MacPaint into the Computer History Museum. MacPaint was a bit before my time, but learning more about it, it’s amazing the influence it’s had on every graphics program since.

When Bill Atkinson was writing MacPaint, he had to figure out how to do rectangular selection. The solution he came up¹ with was the—now standard—animating dashed border rectangle, which his colleague dubbed “Marching Ants”. The rectangular selection tool looks and works exactly the same today. In fact, if you look at the entire user interface for MacPaint (1984) compared to Fireworks CS5 (2010), they’re really not much different.

The lasso, the paint bucket tool, the rectangular selection tool, and floating tool palette all first appeared in MacPaint. Incredible, 26 years later and the same exact solutions are in place today. For all intents and purposes, Bill Atkinson solved most of the problems around creating a graphics program in 1984, and it’s just be refined ever since.

I feel like most programmers today don’t really solve problems. We just find existing solutions and put them into place. In many ways, this is good. We don’t want to reinvent the wheel for every project as we should focus on the unique challenges in each app. But at some point, the wheel needs to be reinvented because its design was limited by the constraints of its time. Marching ants is a simple and elegant solution to the rectangular selection problem, but if Bill Atkinson had 2GB of memory, instead of the 128K he was working with, would he arrived at the same solution? Maybe he would have done some sort of semi-transparent overlay that wasn’t possible on that hardware. Maybe not, it’s probably still the best solution, but it’s worth thinking about.

¹ You should read all the stories of the creation of the original Macintosh on Folklore.org, they’re great

For the next version of Gmail, one of Google’s goals is to get it to load in under a second. They stated that for them, “Speed is a feature”. I couldn’t agree more. It’s something that Google seems to take seriously in most of their applications. Their user interfaces are pretty minimal, but they’re fast. Sure, they could focus on adding other features, improving the design, making it look like a desktop version, but instead they focus on speed. I’m a bit torn here, as I love a beautiful interface. I’ve tried Mobile Me, and it’s really nice looking, has all the little details that Apple gets right, but damn it feels slow after using Gmail. If I had to make a choice, I would choose Gmail every time.

I think that’s the heart of the matter. Speed is a feature that is often overlooked in most applications - both native and web. Everyone tries to build the most beautiful and fancy user interface, but improving speed and responsiveness is one of the best ways to improve the user experience. I think few developers really make it a priority. If your web app is slow, you’ll probably enable gzip, combine and minify JavaScript, reduce HTTP requests, etc. But would you change your interface to make it faster? Would you make it a little less pretty, a little simpler, get rid of some images, use a solid background color instead of a gradient to see an increase in performance? Probably not.

For the next release of your app, I’d suggest try to make increasing speed the top priority. I for one would love to see the release notes for a new version that just said “Improved performance by 2x all around”. I know it’s something I’m going to start focusing on in my apps.

I’ve been really digging the status pages for various web apps/services lately. As these services grow larger, and we grow more dependent on them, it’s critical that we know how they’re operating. They’re typically one page sites with a single purpose - to report the status of the system. Usually, that is broken down into current status and recent status history, in which the primary focus should be the current status, and the history secondary. Often, they’re completely separate from the rest of the site/service, so they can have their own identity as well. I love to see the results that come from those types of minimal requirements.

From what I’ve found so far, my favorite is the recently launched Github status page. It’s a nice, clean design and the large, color coded header immediately conveys the current system status. The recent history is listed below, and makes it easy to scan for any recent issues. Also, it’s hosted on Heroku, so it’s external from their site, which is a necessary ingredient for it to be of use to anyone. Bonus points for auto-updating the status page via AJAX.

OpenDNS is pretty good as well. I like the big green button for “System is currently online”. It would be much better though if they just swapped the Current Status and top section. My eye is drawn to the total activity chart which is not really that important. They also provide an IP address link for the status page since if their service is down, and you use them, you couldn’t resolve the site’s domain anyway.

Google’s app engine status page is not bad, but like most Google creations, a bit heavy on data and light on design. At least you can easily see the current status. I like the use of friendly words like Now/Today/Yesterday so I don’t have to think about what today’s date is. I would prefer if the table went from most recent to least recent though.

I’ve posted some screenshots of other ones I’ve found in this flickr set. Let me know if you know of any other good ones, and I’ll add them.