Designed for the Canadian Winter

January 28, 2008 under design

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.

Skaters on the Rideau Canal, Ottawa

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


Technorati Tags: , , ,

Multiple-Monitor Productivity: Fact or Fiction?

January 25, 2008 under usability, programming, hci

It seems to be accepted wisdom, especially in programming circles, that more screen real estate makes you more productive. I’ve heard claims that you can increase your productivity by up to 50% just by adding a second display. After four months of using a big-ass LCD for development, I recently switched back to a 14″ laptop screen. And you know what? I don’t feel like I’ve missed a stride. So I decided to take at the facts behind the claim that more screen real estate makes you more productive.

The Claims

Jeff Atwood writes an excellent blog on programming and human factors, and he is an unabashed fan of multiple monitors. In his post Multiple Monitors and Productivity, he writes that using multiple monitors “is really a no-brainer for any developer who values his or her time.” He stresses the fact that it’s not purely about screen real estate — he recommends using two or three smaller displays rather than one huge one. The reason is that with bigger displays, the window management actually gets more complicated. This is what Jeff calls The Large Display Paradox.

Joel Spolsky is another well-known champion of a multiple-monitor setup for programmers. In The Joel Test: 12 Steps to Better Code, he advocates giving your programmers the best tools money can buy. And according to Joel, this means multiple monitors:

Debugging GUI code with a single monitor system is painful if not impossible. If you’re writing GUI code, two monitors will make things much easier.

It’s not just Jeff and Joel. Take a look at the discussion thread on the Slashdot article Multiple Monitors and Productivity, or Ask Metafilter: Where can I find case studies on productivity gains from dual monitors for developers?. Even the New York Times published an article on The Virtues of a Second Screen:

Survey after survey shows that whether you measure your productivity in facts researched, alien spaceships vaporized, or articles written, adding an extra monitor will give your output a considerable boost — 20 percent to 30 percent, according to a survey by Jon Peddie Research.

My Doubts

I definitely agree that for some tasks, it’s really helpful to have some extra screen real estate. If you’re a graphic designer, you probably don’t want to be peering at your poster layout through a 13″ keyhole. But for programmers, how many tasks actually benefit from more screen space? If I need to look at API documentation while I’m coding, I have no problem switching to another window to start writing my code. And on my 14″ widescreen laptop screen, there’s more than enough room to compare two pieces of code side-by-side:

Side by side code

In the end, I think it’s a case of micro-optimization. There are lots of small tasks that can be made slightly more efficient if you have a second monitor. But these tasks are not the real bottlenecks to programmer productivity. If you were a writer, would you expect to increase your productivity if you could avoid changing sheets of paper in your typewriter?

The Evidence

So what about the actual hard evidence? Let’s take a look at the studies that supposedly show this increase in productivity.

An article on the Microsoft Research site entitled Two Screens Are Better Than One claims that researchers “found a tool that can increase your productivity by 9 to 50 percent and make your work day easier.” Since the article didn’t actually cite the studies, I had to do a little digging. I found a paper called Toward Characterizing the Productivity Benefits of Very Large Displays which found a 9% improvement in a series of tasks that involved cutting-and-pasting and scanning a document for information.

Not bad, actually. A 9% improvement in tasks that are highly applicable to programming. But on the other hand, how much time do you actually spend in a typical day doing these kinds of tasks? And how much time do you spend typing, whiteboarding, talking to your co-workers, and just staring into the distance and thinking about a problem? Let’s be generous and assume that you spend a quarter of your day performing tasks like in the study. So by using a bigger display, you might be able to improve your productivity by about 2.5%. Remember, studies have shown more that a rock-star coder can be an order of magnitude more productive than your average joe 1. Do you think these guys are more productive because they can cut and paste faster?

Okay, so we know where they got the 9%. What about the 50%? “Further studies showed even greater increases - at times up to 50 percent for tasks such as cutting and pasting.” Aha, there it is again. Cutting and pasting. Well, if your job includes 7.5 hours a day of cutting and pasting, then maybe you can cut that down to 5. You might make it a bit longer before you stab yourself in the eye due to the mind-numbing boredom.

Another study I’ve seen cited a few times is the The 30 inch Apple Cinema HD display productivity benchmark by Pfeiffer Consulting. This study showed that a 30″ display made users significantly more productive than a 17″ display. But the tasks were mostly designer centric, except for a task that involved manipulating a large spreadsheet, and one of combining several Word documents into another document (cutting and pasting again!).

Conclusion

After looking at the studies, I think it’s fair to say that some tasks can be made significantly faster if you have more screen real estate. On the other hand, I think it’s clear that most programmers are not going to be 50% more productive over the course of a day just by getting a second monitor. The tasks that can be improved are not the bottleneck to programmer productivity.

On the other hand, if you just can’t live without your dual- or triple-monitor setup, fine! I definitely agree that it can be nice sometimes. I personally find it difficult to manage the extra screen real estate, but that’s just me. If you’re a developer and you want a dual-monitor setup, then that should be reason enough for your boss to buy one. As Joel says:

Top notch development teams don’t torture their programmers. Even minor frustrations caused by using underpowered tools add up, making programmers grumpy and unhappy. And a grumpy programmer is an unproductive programmer.

Just don’t think that by adding a second monitor, you’ll start coding circles around the guy on his ThinkPad.


[1]: The fabled “10 fold difference” in programmer productivity is a discussion for another day. If you want to dive in, you could start with Jeff Atwood’s post on Skill Disparities in Programming.


What interaction programming is, and why it matters

January 18, 2008 under design, usability, programming, hci

Cover of "Press On: Principles of Interaction Programming"

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.


Links for January 15th

January 15, 2008 under links

The innovative interface of the OLPC laptop

January 10, 2008 under design, usability, hci, olpc

The One Laptop Per Child XO laptop

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:

Sugar user interface

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.

Sugar user interface - activity ring

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.

Sugar user interface - journal activity

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.