Dubroy.com/blog

Some of you might remember my post from January where I talked about the innovative interface of the OLPC laptop. I wrote that post after talking to Mike Fletcher about doing an OLPC-related project for a course I was taking with Greg Wilson. It turned out to be a really fun and cool project, and now that I’m finally finished the course, I thought I’d post about it here.

So, you’ve probably all heard of One Laptop per Child. They recently started shipping their first laptop, which is called the XO. One of the unique things about the XO is that it comes with a built-in graphics tablet. Unfortunately, the system software doesn’t come with tablet support built-in. My project for the semester was to work on improving the tablet support — specifically, the API for activity developers, and the user interface for drawing.

The user interface ended up being the most challenging part of the problem, because the XO tablet is not quite like a standard graphics tablet. It has no hover mode, and it has an aspect ratio that’s completely different from the XO’s screen. In this video, where I explain some of the ways I’ve come up with to deal with these problems.

For more information about the project, check out the Pen Tablet Support and Pen Tablet UI pages on the OLPC wiki.

I’m planning on continuing with this work this summer, so if you’ve got a comment or any other ideas, I’d love to hear them. Leave ‘em here, or send me an email.

Apparently someone from Rogers Wireless remembered the old adage “if you can’t say anything nice, don’t say anything at all.”

I was taking a look at the phones they offer for prepaid, and got a laugh out of the description for the Motorola W370:

The features for the Nokia 6080: “Great value!”, “Pocket sized”, “Sleek design”, and “Embedded camera.” For the Motorola W370: “Flip phone”, “Affordable”, and then a blank bullet. Like the sales guy just gave up: “Meh…I got nothing.”

If that doesn’t convince you to grab one of these babies while you still can, I don’t know what will.

My friend (and recent DGP graduate) Gerry Chu has started a cool blog on interaction design called Design Transformations. It looks at how existing designs can be transformed into new ideas by applying certain “design transformations.” For example, his first post is about how a mouse is just a trackball turned upside down. Eventually, the goal is to come up with a kind of cookbook of transformations that designers can use for brainstorming.

The concept reminds me a bit of Roger von Oech’s Creative Whack Pack, which I got at a Christmas gift exchange a few years ago. It’s a set of 64 cards, each one with a different “creativity strategy.” Some examples: “Try a Random Idea”, “Imagine How Others Would Do It”, and “Slay a Sacred Cow.” It may sound a bit cheesy, but they’re actually pretty useful. See also Brian Eno’s Oblique Strategies.

(Photo by tanakawho)

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?

Over at Pie Palace, the esteemed Erigami Scholey-Fuller asks why we don’t have more things designed for the realities of the Canadian climate:

Winter plays a huge part of our identity. Canadians snowshow, snowboard, ski, skate, and skidoo. We invented hockey. We dominate the sport of curling. We essentially invented the modern ski resort. In the temperate south of the country, we endure subzero temperatures five to six months of the year.

But our consumer goods, our clothing styles, architectural styles, and fetish objects are designed elsewhere. We use stuff designed in climates where zero is considered cold, and a light dusting of snow will close a city.

I can think of a few exceptions, like the ubiquitous Uggs and fur-hooded parkas, but for the most part, he’s right. On the other hand, when have electronics, fashion, and architecture ever emphasized practicality first? Design in these disciplines tends to favour style over substance.

What do you guys think? Do we need more products designed for the Canadian realities? Or will we be prying your iPod Touch out of your cold, frost-bitten fingers?

If you’re interested in Canadian design, you should take a look at The Canadian Design Resource, which I’ve been enjoying immensely over the past few months. It features a daily post on a diverse mixture of things designed in Canada.

Photo of the Rideau Canal by Flickr user Robbie1

I’ve just started reading Harold Thimbleby’s Press On: Principles of Interaction Programming, kindly lent to me by Greg Wilson. I’ve just finished reading the introduction, but one thing stands out to me already. Maybe you noticed it already: the subtitle of the book is Principles of Interaction Programming.

What the hell is Interaction Programming?

I don’t know about you, but until I picked up this book, I’d never heard the term interaction programming. As far as I can tell, it’s a term that Thimbleby made up. According to him:

Interaction programmers are computer scientists using their specialist skills to design, analyze and program interactive devices used by people.

I really like this term because it captures the fact that the interaction is inextricably linked with the internals of the system. We already have lots of terms to describe the study of the interaction between people and computers (human-computer interaction, usability, interaction design, and user experience, just to name a few). But these terms all seem to imply that you have a system and you have a user, and all you need to do is design the interaction between the two. Thimbleby’s view is that these terms are primarily concerned with “what things look and feel like, rather than how they work inside.” Using the term interaction programming challenges the view that the interface is created by designers and the functionality is implemented by programmers.

Why interaction programming matters

I’m definitely not arguing that there is anything wrong with interaction design, user experience, or choose-your-preferred term. There are certainly lots of talented people out there who play a very important part in developing usable interactive sytems without have intimate knowledge of the implementation details. But there are also many programmers who have the skills and desire to make the interaction a concern in every step of the development (see Jeff Atwood, 37 Signals, etc.).

It seems to be well accepted now that we should consider usability during all phases of a product’s development, but Thimbleby stresses that interaction programming should also be an integral part of the process:

Much of the initiative for better design can come from clear engineering creativity, knowledge, and perspectives based on sound computer science principles. […] Programmers can come up with solutions that would have escaped users or designers with limited technical knowledge; programmers can be more creative and more central in all areas of interaction design than anyone suspected.

Ich bin ein Interaction Programmer

I’ve always found it hard to describe what I’m interested in. I love coding, but I also care a lot about how people interact with computers. Yet I wouldn’t consider myself to be designer, since I don’t have the background or experience. Thanks to Harold Thimbleby, now I can express it pretty well: I’m an interaction programmer.

Last night I had the chance to see the One Laptop Per Child (OLPC) laptop in person for the first time. Everybody has their opinions about the project; but putting aside the political discussion, OLPC laptop (aka the XO) is undeniably cool from a technology standpoint. The hardware design is impressive — and I can confirm that it looks just as good in real life as in the publicity photos — but to me, the most interesting part is the user interface. From the ground up, the OLPC interface is like no computer you’ve ever used before.

The OLPC user interface is called Sugar. I won’t give a comprehensive description; for the full run-down, see the Getting Started guide, or the Sugar page in the OLPC wiki. Instead, I’ll just cover my two favourite parts: the focus on activities rather than applications, and the journal, which replaces the hierarchical file system. Coincidentally, these two ideas both relate to points on my wishlist of 5 ways to radically change computers (for the better).

Here’s a shot of the Sugar user interface in the “home” view, which is roughly equivalent to the desktop view in the desktop metaphor:

Activities

As you may remember, in the traditional desktop metaphor, we do most of our work in applications, which are specialized programs that manipulate files. First you start an application, then you use that application to do things to files: create, open, modify, and save. If you’ve never used a computer, these concepts might seem a bit weird. What exactly is an application? What’s the difference between opening a file and opening an application? And why do you have to save?

Instead of applications, the OLPC interface is centered around activities. It’s largely just a terminology thing, but the concept of an “activity” is easy to understand even if you’ve never seen a computer before. You can start a new activity (implicitly creating a new file), or resume an old activity (i.e., open an existing file). From the OLPC developers’ wiki:

Based on the Object model associated with files, each kept Object is, technically speaking, a separate instance of the activity which created it. This eliminates the need to “open” a file from within an activity, replacing the act of opening with the act of resuming a previous activity instance. Of course, a child will have the option to resume a drawing with a different set of brushes, or resume an essay with a different pen, providing “open with” style functionality, but no substitute for an “open” command will exist within an activity’s interface.

One part which I love is that saving happens automatically:

We believe that the traditional “open” and “save” model commonly used for files today will fade away, and with it the familiar floppy disk icon. The laptops do not have floppy drives, and the children who use them will probably never see one of these obsolete devices. Instead, a more general notion of what it means to “keep” things will prevail. Generally speaking, we keep things which offer value, allowing the rest to disappear over time.

[…]

Most of us heard the “save early, save often” mantra, largely ignored it, and incurred the consequences. The laptops aim to eliminate this concern by making automatic backups. This lets the children focus on the activity itself.

Unfortunately, activities still need to be managed just like applications — you have to explicitly stop them in order to free up resources. The XO has no swap space, so you can only run a limited number of activities at once. This is communicated to the user through the clever “activity ring” which acts kind of like the Windows task bar, and the amount of space that an activity takes up in the ring corresponds to the amount of RAM it is using.

In the activity ring above, you can see that there are Browse, Journal, and Paint activities active.

The Journal

If you’ve been reading this blog for very long, you probably know that I’ve got some serious beefs with the old hierarchical file system, so I was happy to see that Sugar does away with that. The Journal provides a time-based way of tracking activities (and thus files). From the OLPC Human Interface Guidelines:

The laptops will drastically minimize the hierarchical filesystem as a means for organization, replacing it with a temporally organized list of activities and events, furthering the Journal metaphor. This drastically simplifies the auto-keeping behavior, since it eliminates the need to specify a location in which a newly started activity should be kept; naturally, the newly started activity will appear as the most recent entry in the journal.

Obviously, the time-based view might get cluttered; but there is support for tagging, and sophisticated searching and filtering:

Temporal organization functions naturally in the absence of explicit or hierarchical methods, since humankind’s intrinsic relationship to time gives them, at the very least, a relative notion of “how long ago” something happened. By moving back through the Journal, a child can simply locate the period in time within which she knows she made something, and then employ additional use of searching, filtering, and sorting to pinpoint exactly what she’s looking for.

Basically, it sounds like they have implemented Lifestreams. It sounds like a great idea, but I’m interested to see how it works out in practice. I would think it’s pretty easy to use, especially for someone who has never used a computer before, but I wonder how well it will scale to lots of activities over a long period of time.

I’m really excited about Sugar. It would be interesting to see how it works in day-to-day use — not just for children in developing countries, but for experienced adult users as well. I may actually have the chance to play with one of the XOs for a course project this semester. If I do, you can be sure you’ll hear about it here!

If you’re interested in more details on the OLPC laptop, check out Bunnie’s post on disassembling the XO-1, or browse the copious amounts of information in the OLPC wiki.

A few days ago, I came across an article called The Second Coming — A Manifesto by David Gelernter. Gelernter is famous for being a co-inventor of LifeStreams, which was a really cool PIM system based on time-order streams of documents.

In The Second Coming, written in 2000, Gelernter writes about a coming revolution in computing:

Computing will be transformed. It’s not just that our problems are big, they are big and obvious. It’s not just that the solutions are simple, they are simple and right under our noses. It’s not just that hardware is more advanced than software; the last big operating-systems breakthrough was the Macintosh, sixteen years ago, and today’s hottest item is Linux, which is a version of Unix, which was new in 1976. Users react to the hard truth that commerical software applications tend to be badly-designed, badly-made, incomprehensible and obsolete by blaming themselves.

He dedicates an entire section of the essay to the problems he sees with the current file-and-folder organizational model:

27. Modern computing is based on an analogy between computers and file cabinets that is fundamentally wrong and affects nearly every move we make. (We store “files” on disks, write “records,” organize files into “folders” — file-cabinet language.) Computers are fundamentally unlike file cabinets because they can take action.

[…]

30. If you have three pet dogs, give them names. If you have 10,000 head of cattle, don’t bother. Nowadays the idea of giving a name to every file on your computer is ridiculous.

31. Our standard policy on file names has far-reaching consequences: doesn’t merely force us to make up names where no name is called for; also imposes strong limits on our handling of an important class of documents — ones that arrive from the outside world. A newly-arrived email message (for example) can’t stand on its own as a separate document — can’t show up alongside other files in searches, sit by itself on the desktop, be opened or printed independently; it has no name, so it must be buried on arrival inside some existing file (the mail file) that does have a name.

I totally agree with the points he makes. These are things I’ve been complaining about for years, too.

Gelernter then goes on to describe (at a very high level) the organizational model that we should be using on computers:

36. File cabinets and human minds are information-storage systems. We could model computerized information-storage on the mind instead of the file cabinet if we wanted to.

37. Elements stored in a mind do not have names and are not organized into folders; are retrieved not by name or folder but by contents. (Hear a voice, think of a face: you’ve retrieved a memory that contains the voice as one component.) You can see everything in your memory from the standpoint of past, present and future. Using a file cabinet, you classify information when you put it in; minds classify information when it is taken out. (Yesterday afternoon at four you stood with Natasha on Fifth Avenue in the rain — as you might recall when you are thinking about “Fifth Avenue,” “rain,” “Natasha” or many other things. But you attached no such labels to the memory when you acquired it. The classification happened retrospectively.)

Our minds are extraordinarily complicated things. Should we really be building software that is modeled on that kind of complexity?

Modeling machines after nature is rarely the best approach. Our airplanes don’t have flapping wings, and cars and bicycles are not “running machines.” You can also think of spoken and written languages as “tools”, ones that have an intimate connection with our thought processes. If languages were modeled on the way the mind works, we would be speaking in sentence fragments, and constantly making up new words to easily refer to concepts and past events. Would anyone argue that languages could be made better by making them more flexible, more malleable, and a better match for our internal thought processes?

To me, modeling computers on our minds is just as much of a red herring as modeling them on file cabinets. Let’s build software for how our brains work, not like how our brains work. The best tools are the ones that support and compliment our natural abilities. My brain doesn’t have an internal calendar or to-do list, but those turn out to be remarkably simple and effective constructs that support my goals of accomplishing certain tasks. They are effective because of how simple and straightforward they are, and because they allow my brain to focus on what it does best (which is not remembering absolute times or lists of items).

(Brain photo by Gaetan Lee on Flickr)

Via Mike Beltzner, I see that there are some cool new UI enhancements in the upcoming beta of Firefox 3.

First, the download manager has been completely re-written. A few weeks ago, I complained that uploading and downloading are seams in the web experience. One of the things I suggested was that the download window should allow drag-and-drop. Lo and behold, the new Firefox 3 download manager does! Check out the mockup, or bug 397655 for more details.

Second, Firefox 3 is introducing a new scheme called Places which is “a new system for storing bookmarks, history, and other information about pages.” One of the cool new UI enhancements related to Places is what’s being called the “awesome bar“. In Firefox 2 (as well as most other web browsers), when you type into the location bar, it autocompletes using pages from your history. When you get accustomed to it, it’s a great feature, because going to one of your commonly-visited sites is as quick as typing a few characters and then hitting tab. The awesome bar basically takes this functionality to the next level: it autocompletes from your history and your bookmarks, it searches all through the URL and the title (as opposed to just the start of the URL), and it’s adaptive. Edward Lee’s got a full description.

Overall, I’m really glad to see Firefox again taking the lead in the user experience side of things. Alex Faaborg has a list of some other user-facing changes planned for Firefox 3. That post is few months old though, so plans may have changed substantially since then.

Beta 1 should be dropping soon; I can’t wait to try it out.

In a great post at Signal vs. Noise, Jason Fried answers the question, “Is it really the number of features that matter?”

What matters is the editing. Software needs an editor like a writer needs an editor or a museum needs a curator. Someone with a critical eye and the ability to say “No, that doesn’t belong” or “There’s a better way to say this.” Physical constraints create natural limits for books and museums. Books have pages and museums have wall space. Software, on the other hand, is virtual, boundless. Anything is possible. When anything is possible someone inevitably tries to make something do everything. And the more something does the harder it becomes to understand, grasp, and use. So the key is deciding what makes it and what doesn’t.

What Jason’s talking about here is really the core of design. It’s about making tradeoffs, and finding balance:

So remember: Good software is about balancing value and screen real estate and understanding and outcome. If it takes 20 good features to get there, then great. If it only takes eight, even better. It’s not the number that counts, it’s the balance.

Joshua Porter thinks it’s important that the designer be someone different than the creator:

You need someone pushing back as much as you need someone pushing forward. You need, not necessarily a critical eye, but a concerned eye that isn’t colored with the effort of creation. A creator is almost never equipped to be objective about their creation. (nor should they be)

The analogy to writing — that software needs an editor — is a good one. But there’s a key different with software: it’s about solving a specific problem. When choosing which features to include, you need to always keep in mind the problem that you’re trying to solve. As Charles Eames, one of the most famous designers of the 20th century, said: “Recognizing the need is the primary condition for design.”