Dubroy.com/blog

A couple weeks ago, I trekked through another Toronto snowstorm all the way up to the Canadian Film Centre. Normally I’m a downtown snob and don’t go north of Bloor, but I made an exception this time because my friend Geneviève was demoing a project at the CFC Media Lab.

A Hierarchy of Needs for Design

While I was there, I happened across a copy of Universal Principles of Design. It’s a really cool book which describes 100 design principles: from general-purpose concepts like Ockham’s Razor and the 80/20 rule, to specific techniques like Iconic Representation (”the use of pictorial to improve the recognition and recall of signs and controls”). It’s kind of like a universal set of design patterns.

I only had a chance to flip through the book for a few minutes, but I really liked what I read. And Donald Norman recommends it, for what it’s worth.

One of the principles that I really liked was Hierarchy of Needs. Inspired by Abraham Maslow’s famous psychology theory, the authors proposed a Hierarchy of Needs for design:

A design must serve the low-level needs (e.g., it must function), before the higher-level needs, such as creativity, can begin to be addressed. Good designs follow the hierarchy of needs principle, whereas poor designs may attempt to meet needs from the various levels without building on the lower levels of the hierarchy first.

What about the code?

This got me thinking about coding. As a programmer, you are designing not only the product itself, but also the code. For the end product (the software that you are producing) the Design Hierarchy of Needs can be applied. But what about the code? What would a hierarchy of needs for code look like? Here’s what I came up with, but I’d like to hear what everbody else thinks.

Keep in mind that this is a hierarchy of importance, with the lower levels being more important. It’s most definitely not a sequence of steps.

• Functionality: If your code doesn’t work, there’s no point making it in optimizing that inner loop, or refactoring it to be infinitely flexible.
• Reliability: Any software developer worth his salt knows that there’s a big difference between code that “works”, and code that is ready to be shipped. After your code is functional, you need to make sure that it is reliable. Run it through your unit tests, run it overnight, run it on grandma’s computer.
• Maintainability: Can other people understand the code? Can you understand the code? When bugs are discovered, you need to be able to fix a bug and be confident that you won’t be causing more bugs in the process.
• Extensibility: Is your code adaptable to meet new requirements? If your code is extensible, you will be able to grow and adapt your software to meet the changing needs of your customers. If not, you might have to throw it out and start from scratch.
• Elegance & Efficiency: If you are sure you are meeting the other levels of need, then and only then should you worry about making your code fast and beautiful. Unfortunately, many people get hung up on this level instead of focusing on the more basic needs.

What do you guys think? Anything you’d change about it?

Related: Andrew McKinlay wrote about A Programming Hierarchy of Needs, and Oliver Steele proposed The Programmer’s Food Pyramid. Kathy Sierra, whose blog Creating Passionate Users I sadly miss, also tackled the user hierarchy of needs, and asked What comes after usability?

I’ve been taking a break from my RSS reader for the last couple of weeks, so I didn’t hear about Scribd’s iPaper until yesterday. If you also need to be filled in: Scribd is a Y Combinator startup who writes software “that makes it easy to share documents online.” They want to be the YouTube of documents. iPaper is their new Flash-based platform for document sharing:

iPaper is a document format built for the Internet. Like a YouTube video, iPaper documents are Flash widgets which you embed in your existing web pages. PDF, Word, PowerPoint, and many other document formats can all be displayed on the web using iPaper.

iPaper is designed to be fast, light, and simple. Because it’s integrated into your site, iPaper offers a fluid browsing experience, keeping visitors on your site. It has a small footprint, doesn’t require the installation of additional software, and it’s not loaded with superfluous features.

Now I would be the last guy to defend PDF. I’ve invented entirely new swear words just for Acrobat. And I’ve written before about how downloading documents is a seam in the web experience. iPaper seems like it could be an improvement — but it remains to be seen.

But what worries me a bit about iPaper is that if it becomes popular, it’s another step towards a centralized web. One of the greatest things about the internet is that it’s mostly decentralized — a single point of failure can only have a limited impact. If a single email provider like Yahoo! goes down, then only Yahoo! users are affected. The same with my web site: if CNN goes down, it doesn’t have an impact on me. But if your site relies on YouTube and Scribd to serve your content, then you are screwed if one of those sites goes down. (Or goes bankrupt, or gets shut down by the feds, or …)

As we move towards the vision of “utility computing” — where CPU cycles and software are delivered like gas and electricity — centralization is becoming more and more of a problem. The Amazon S3 outage last week brought down quite a few sites. Think about all the sites that rely on Amazon S3 and EC2, Google Maps, YouTube, and maybe soon Scribd.

The web is becoming fragile.

A few years ago, we were told that desktop search applications were going to change the face personal information management. Google Desktop was released in late 2004, only a few months before Apple introduced Spotlight as a key feature of the new version of OS X. When Windows Vista finally shipped, it included a similar feature called Instant Search. As Google brings order to the billions of pages on the web, desktop search was supposed to bring order to your files, emails, and photos.

Now, more than 3 years later, have things really changed?

I’ve been focusing on desktop search in my master’s research, and I’ve noticed that not many people are actually using these tools. Even though I am doing research in the area, I often find myself resorting to the tried-and-true hierarchical file system.

Part of the problem is that the search algorithms pretty much suck. Remember web search before Google? When the highest-ranked page was the one that contained the most repetitions of your keywords? Desktop search apps suffer from similar problems. The algorithm doesn’t know that a file I created should rank higher than some sample code that came with Python. It doesn’t realize that a message I received from a mailing list is less relevant than the email from my supervisor. We don’t yet have the equivalent of PageRank on the desktop.

Another reason desktop search hasn’t taken over is that the problem has changed. Really, it’s not about desktop search. It’s about personal information search. I mean personal information in the sense of personal information management — the information items (files, emails, IM conversations, bookmarks, etc.) that we use in our day-to-day tasks. What has changed in the past few years is that more and more of this information is stored in web applications. This presents a challenge for desktop search applications. Google Desktop can search GMail, but that’s an exception — most desktop search applications are restricted to searching things on your computer. I need something that will search GMail, my Facebook inbox, my Flickr and Facebook photos, wiki pages, Backpack, etc.

But while web applications are the downfall of desktop search, they are also the reason why we need personal information search. With our important data being stored in so many different places, each with its own particular organization methods, we don’t really have another alternative.

What do you think? Are you using desktop search? What’s your preferred application, and what do you love and hate about it?