Sugar leaves the One Laptop per Child nest

May 16, 2008 under usability, hci, olpc

Sugar Labs logo

It’s been an interesting 24 hours for anyone who follows the One Laptop per Child project. Yesterday, OLPC announced that they have teamed up with Microsoft to make Windows XP available on the XO. Then it was announced that Walter Bender, OLPC’s former president of software and content, is forming a new organization called Sugar Labs to spearhead development of the Sugar user interface.

This is an interesting development. I started working on OLPC-related projects a few months ago, doing some work on the user interface for the built-in graphics tablet. Back in January, I wrote about how cool I think the Sugar UI is. I really hope that Sugar can gain some momentum on its own, instead of constantly being overshadowed by the political and ethical issues of the One Laptop per Child project as a whole.

I’ve been thinking about buying myself some kind of ultra-portable laptop, and since I find it almost impossible to type on the XO keyboard, I’m currently eying the Asus Eee PC. I don’t think it makes sense to use a conventional desktop environment on that kind of machine, and I think that the current Sugar UI is a really promising alternative. Now that Sugar is being developed separately from the OLPC project, it will be interesting to see if it can develop into a useful general-purpose desktop shell.


Firefox’s awesomebar: a command-line for web apps

April 23, 2008 under usability, hci

Mozilla Firefox logo

One of the cooler features of Firefox 3 (which is currently in beta) is the awesomebar, which is the nickname for the URL bar and its new autocomplete features. Madhava, one of Mozilla’s talented interacticians, noticed something neat: this means that the URL bar can be used as a shortcut to perform commands in web apps like Google Docs.

Here’s how it works: instead of navigating to Google Docs and clicking the “new document” button, you can just type the words “new document” into your awesomebar. These search terms will match part of the query string of a Google Docs URL, and visiting that URL will pop you right into a new document.

This reason this works in Firefox 3 is because the awesomebar autocompletes anywhere in the URL or page title, not just at the beginning of the URL like older versions of Firefox. For more information about the awesomebar, check out Deb Richardson’s post, or see some of my older posts: Firefox 3 Awesomeness and Firefox 3 Beta 1: Usability impressions.

I just tried something similar when I went to write this post: instead of navigating to my blog’s admin page and then clicking “New post”, I just typed “new post” into the URL bar. The first hit was on the title of the Wordpress “Create New Post” page. Sweet!

I think this is pretty cool. It means that Firefox’s URL bar is now a command-line for web apps. Of course, this is just more evidence of the command-line comeback and the URL as a user interface.


What I’ve been up to: freehand drawing on the OLPC laptop

April 17, 2008 under design, usability, hci, olpc

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.


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.


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.


5 ways to radically change computers (for the better)

December 31, 2007 under usability, hci

In his seminal paper No Silver Bullet, Fred Brooks draws a distinction between “essential complexity”, which is complexity that is directly caused by the problem we are trying to solve, and “accidental complexity”, which is just part of a particular solution. I’ve noticed that a lot of the usability problems I run into are caused by accidental complexity. Some of this complexity is so old and so pervasive that we’ve forgotten what caused it in the first place, and now we just accept it as “the way things are.”

Here are my suggestions for five ways that we could radically change computers for the better. All these problems are caused by accidental complexity. Some people might give reasons why these ideas can’t be implemented, but the truth is that nobody has ever demanded that these things be changed, because “that’s just the way things are.” But what the hell — it’s a new year, time for some new ideas time to make some changes!

  1. Instant on and off

    When you turn on your oven, microwave, or television, you don’t have to wait 30 seconds before it’s usable. But with computers, it’s something we just accept. And then when it’s time to turn the thing off, there’s a confusing array of choices: should I shut down, or just put it to sleep? Or maybe I should hibernate.

    For a good example of how computers should work, look at the iPod. It doesn’t even have an on or off button. When you press any of the buttons, it turns on. After it’s been idle for a few minutes, it turns off. Sometimes — rarely — when you turn it on, it takes a second or two to boot up. A second or two is fine; almost a minute is not.

  2. Automatic save

    At one time or another, I’m sure everybody who’s used a computer has gotten burned by not saving often enough. You know, you hit the zone working on the last few pages of that essay, and whoops, you stretch your legs out and flip the switch on the power bar.

    Did you ever wonder why you have to save your progress every few seconds? Wouldn’t it be better if you could just concentrate on doing your work, and let the computer worry about saving it? I’m not talking the half-baked “document recovery” that Microsoft Word offers — every single character you type should be saved as you type it.

  3. Getting rid of filenames

    Does every page in your notebook have a title? Probably not. Then why is it that anytime you want to write down even the most trivial note on the computer, you have to give it a name? It gets in the way of what you’re really trying to accomplish.

    And in the end, don’t we just up with next-to-useless names like “resume6-modified-pld-edit.pdf”? Instead of forcing you to choose a filename, the computer should just automatically save whatever you type. When you need to access it later, you’ll be able to find it by looking at a list of recent documents, or by using keyword search. Later, you might want to give it a title and a description, but that should be optional.

  4. Ubiquitous access to information

    Here I am, working away on a computer with a 5 Mbps always-on internet connection, and the best way to make sure I have access to my documents is to email them to myself. Despite the massive amounts of bandwidth that I have available, a lot of my important data is still trapped on a tiny, fragile, spinning platter on my desk.

    Sure, I could (and do) use web applications to be able to access my information from almost anywhere, but there are still some significant problems with doing that. If the site goes down, or I lose connectivity, I’m screwed. And many applications simply don’t have a good web-based alternative.

    What I really want is for all my important documents to be silently synchronized to the internet while I’m working. If I lose connectivity, I can keep working away, and my work will be synchronized later.

  5. Eliminating applications

    Sometimes when I use my computer, I feel like a janitor. When I’m really focused on a task, I find that my desktop starts to accumulate cruft. So I take a break from whatever I’m doing, and go and clean up after myself, closing windows and applications that I’m not using anymore.

    I really wish that I never had to do that. And why should I? The computer is already going to swap out inactive applications, so why do I need to bother closing them? It can open applications on an as-needed basis, so why can’t it close them too?

    I think the real answer is that we need to eliminate the concept of “applications” as we know it. Think of web applications — you don’t ever have to worry about “opening” or “closing” them. I’d like to see this kind of model applied to desktop applications as well.


Well, what do you think? I’m interested to hear people’s thoughts on these ideas, and to hear if you’ve got any others to add to this list. My friend Mike pointed me to a cool post by Matthew P. Thomas in the same vein as this. His old blog is offline now, but you can still find it in the Wayback Machine: When good interfaces go crufty.

Update (Jan 3): I didn’t mean to say that these are MY ideas, or that they are necessarily new. As MH pointed out in the comments, some (or maybe all) of these ideas are mentioned in Jef Raskin’s The Humane Interface, which I can’t recommend highly enough.


Design *for* our brains, not *like* our brains

November 29, 2007 under design, information management, the brain, hci

Human brain 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)


Firefox 3 Beta 1: Usability impressions

November 20, 2007 under usability, hci

My posts have been pretty Mozilla-centric for the last couple of weeks, and with Firefox 3 Beta 1 having dropped today, I see no reason to change that.

I’ve been running it for a couple of hours now, and here are some of my first impressions of the UI changes. For a more thorough review, check out Ars Technica.

First off, based on the concepts Alex posted about last week, the look and feel is going to change a lot before the final release. So, from a UI perspective, Beta 1 might be more properly considered to be an alpha.

The Good

No more lost edits

I’m happy to report that they’ve fixed the problem I wrote about last time. Previously, when a user selected to open (rather than save) a downloaded file, it was possible to save changes to the open document. That was a Bad Thing, because it the file was actually in a temp directory, and it meant that you could easily lose the changes that you’ve made. Now they’ve made downloaded files read-only, so when you try to save your changes, you will be prompted to save them to a different file in a more permanent location.

Password Manager

One of my long-time annoyances with previous versions of Firefox is that every time you log into a site, you’re presented with a modal dialog asking, “Do you want Firefox to remember the password for this site?” The modal dialog has been replaced with a nice, unobtrusive question in the notification area. Better still, if you ignore the message, it disappears after a few seconds. Slick. Jef Raskin would be proud.

Passive password dialog

Seeing Stars

One of the major new features of Firefox 3 (which I wrote about previously) is Places, which is unified system for dealing with bookmarks and your browsing history. In support of this, Firefox 3 introduces the concept of “starring” pages, much like in GMail. In theory, this is a very lightweight way of bookmarking pages. When you star a page, it you will see a star beside it when it appears in the autocomplete list, just like this:

Starring a web page

I had hoped that the history sidebar would also show the star for pages that you have previously visited, but that doesn’t seem to be the case (yet).

Awesomebar

I mentioned the new “awesomebar” in a previous post. In short, it’s a modified autocomplete mechanism for the location bar. When you start typing, it tries to match the URL or title of previously visited pages. It’s also adaptive, based on the previous selections you have made.

So far it has worked nicely for me. I’ll have to use it for a bit longer before I can declare it to be “awesome”; for now it’s just the not-too-shabby-bar.

The Not-so-good, aka the Don’t-forget-it’s-just-a-beta

Lost in Places

Unifying bookmarks and history seems like a good idea, but I think that the front-end for the Places functionality needs some work. First of all, the star control is way off on the end of the location bar, in an area I’ve heard referred to as “the lucky charms”:

Firefox lucky charms area

Personally I think it would be better to put this control immediately to the left of the location bar, similar to how it’s placed in GMail. To me, it is sort of lost where it currently is; but maybe that’s because I never use the RSS and Go buttons.

After you star a page, if you click on the star again, you’re presented with the following dialog:

Star menu

I had a few problems with this. First of all, there’s no indication that the tags field accepts comma-separated tags. Second, it was not really clear to me what the “Delete” button meant. It might be clearer if it were labeled “Unstar”. Finally, it feels weird to me that the star is not a toggle. It has two completely separate behaviours, depending on what state it’s in.

Overall I find the new UI for bookmarks to be very confusing. There are now at least three different ways to bookmark a page: starring it, dragging the icon to the bookmark toolbar, and the old standby, Ctrl-D. When you press Ctrl-D, it actually brings up the star menu, as if you had clicked once to star the page and then clicked again to bring up the menu. So, at least that clarifies that bookmarking a page is the same as starring it. But I really think it would be better if they didn’t use two different terms to refer to the same thing. In fact, make that three — starred pages are accessed through an item named “Places” in the bookmarks menu:

Bookmarks menu

Conclusion

Overall, I’m pretty happy with the beta. Firefox 3 has got quite a few nice, new features, and the guys at Mozilla are working hard to make the user experience second-to-none. I think the Places UI still needs a lot of work — one of the great things about Firefox has always been its simplicity, and I wouldn’t want them to lose that. But I’m confident that Mike, Alex, and the rest of the user experience team will be able to address these problems in time for the release.


Usability problems downloading from web apps

November 7, 2007 under usability, hci

My post yesterday on the upcoming changes in the Firefox download manager reminded me of a little story I wanted to tell. A few weeks ago, I said that uploading and downloading are seams in the web experience, and this story provides a good example of what I mean by that.

A few weeks ago, I was sitting in my room (probably at my computer), when I heard my roommate call me nervously from upstairs.

“Pat….?? Can you help me?”

I’d heard that tone of voice before.

“Is it about about your computer?”

“Um, yeah.”

So I went upstairs to help. Here was the problem: last night, she opened a Microsoft Word attachment from GMail, spent an hour or two editing it, saved it, and closed Word. Now, she was looking for the file, and it was nowhere to be found.

This has happened to me before, and I’ll bet that it’s happened to most people. When you download a file from GMail, you are prompted to either save or open the file. If you choose to save, the file will be downloaded to the desktop or your downloads folder (assuming you’re using Firefox). If you choose to open, the file will be downloaded to a temporary folder and opened from there. The problem is, if you choose to open the file, there’s nothing stopping you from merrily making all the changes you want and saving them back to the temporary file. Which is almost certainly not what you want to do.

It’s a tough problem, and probably not something that can be fixed in the web browser alone. But as we start relying more and more on web applications, I think it’s becoming an important problem to solve.

So what’s the right answer? First of all, I wonder if you should even be asked to choose between saving or opening the file. If you’ve clicked on it, don’t you probably want to open it? Once you’ve opened it, if you want to save it somewhere, then you can make the decision. This is the way that it works with PDFs if you’ve got Acrobat Reader installed.

Second, you shouldn’t be allowed to make changes to temporary files. If you are viewing a Microsoft Word document and then you try to save changes to it, it should then prompt you for a place to save the file, instead of silently saving the file to a temporary location.

Those are two possibilities that I can think of off the top of my head that might help fix this problem. Comments? Thoughts?

Oh, and just so I don’t leave you hanging — I helped my roommate rescue her changes from temp directory.


Next Page »