LWN.net Logo

Ubuntu debates usability changes

March 4, 2009

This article was contributed by Bruce Byfield

Ever since last July, when Mark Shuttleworth called on Ubuntu to surpass Mac OS X in desktop design within two years, Ubuntu mailing lists and blogs have become one of the main places to go for detailed discussions about GNU/Linux usability. However, the discussions can become convoluted and acrimonious, as developers argue the logic of design principles. A case in point is the discussion of Ubuntu's new notification guidelines on the ubuntu-devel list over the past two weeks, which quickly turned into a discussion of whether notifications should be used at all.

The discussion centers around the new guidelines for notification messages, which typically appear by the notification tray in GNOME. These guidelines were announced in Mark Shuttleworth's blog entry for February 21. Both the blog and the guidelines include screen shots to illustrate what they are describing.

The problem is that the now-standard notification bubbles (so-called for their shape) are easily missed because they disappear after a few seconds, and they often point to icons in the system tray, which users may find hard to [Bubble notification] click. For these reasons, the guidelines call for a reduction in their use, although acknowledging the possibility that they might still be useful in unspecified circumstances.

Whenever possible, notification bubbles will, in the next Ubuntu release, be replaced with a notification in an existing window; for instance, when a web browser has blocked up a popup, the notification could display in a dialog above the web page, using the browser's built-in notification system. More radically, when a notification needs user input, but doesn't need an immediate response — for instance, when a printer is detected, but the necessary driver is missing — it will be displayed in an alert box that opens beside the system tray without taking the focus away from the user's current window.

In cases such as a low battery reading, when a quick response is needed, the window or alert box will display the basic message, followed by, when the user clicks it, a dialog, possibly with a different color background. The guidelines refer to this arrangement as "morphing," and suggest that it will help prevent the accidental selection of a button when the cursor moves to the dialog. Why accidental selection is perceived as a problem, though, is unspecified.

The advantages of the proposed alert boxes is that, unlike notification bubbles, they remain on the desktop, and provide dialogs that are easier to click than a system tray icon.

Discussion of these new guidelines quickly followed Shuttleworth's blog entry, wandering across several threads in ubuntu-devel in February and March. Some of the discussion called for citations to support a usability assertion, as when Jordan Mantha told Mat Tomaszewski of the Canonical design team, the group responsible for the guidelines, that "'trust us, we have our reasons' is not going to very convincing to many people."

As discussion continued, it soon became apparent that at least some Ubuntu designers outside Canonical distrust those employed by the company. For instance, Scott Kitterman remarked:

The feeling I get from many email and IRC discussions with people involved in the Canonical [Desktop Experience team] is that they are so convinced of the correctness of their design that any disagreement with it must stem from a lack of understanding from the community.

Similarly, Martin Owens complained that "It's as if the people at Canonical had taken a politics course and decided to deliberately alienate those people who are not inside of Canonical."

To such comments, Mat Tomaszewski replied several times, with patience and enthusiasm for the tasks at hand, while Matthew Paul Thomas, another Canonical employee, explained in a similar tone that usability efforts were just getting started, and were expensive enough that "much of the time we will have to rely on common sense".

At one point, the language became so heated that Mark Shuttleworth intervened to call one developer's comments "not constructive" — a rare occurrence on Ubuntu lists compared to those of some projects, due to the code of conduct by which developers agree to abide.

However, for the most part, discussion remained civil. Matthew Paul Thomas defended the new guidelines, pointing out that:

[A] 22*22-pixel icon in the "notification area" could never convey the idea that there are software updates available to a usefully large proportion of our users, no matter how good the icon designer was. An actual sentence saying, 'Software updates are available for this computer' can do a much better job.

Thomas also summarized potential problems with notice bubbles: either they disappear after a few seconds and can disappear before users notice them, or else they persist and distract users. In addition, alerts and windows are easier to use than small, often indistinguishable icons.

By contrast, Lars Wirzenius presented a case against all notifications, saying flatly that:

Notifications are always interruptions. When something new popups up on the screen, it interrupts my thought and my work, and if I'm 'in the zone' (also known as 'in hack mode,' that interruption may cost about fifteen minutes of effective work time.

All Wirzenius wanted was essential notifications, suggesting that "All applications should, in my opinion, strive to interrupt the user as little as possible, especially by default."

Wirzenius' position was soon challenged by other developers in ways that show some of the considerations necessary in usability design. Chow Loong Jin questioned Wirzenius' assertion that default settings should be designed for those who use their computer as a "tool" rather than a "toy," arguing that the tool users would know how to change the defaults while the toy users would not.

Similarly, Ted Gould contended that, since toy users are probably a majority, the defaults should be settings that they want. In the same post, he also suggests that:

The reality is that you want different levels of notifications at different times. Sometimes an interruption is okay and sometimes it certainly is not. For instance, someone IMing you 'wanna take a long lunch?' while you're giving a presentation to your boss. The problem is that it's hard to detect what people's intentions are.

However, Tomaszewski indicated that some ability to change levels of notifications would be available via a "Do not disturb" mode that would block at least some standard notifications.

What made this discussion especially interesting was how it brought out both the general and specific issues that arise in usability. For instance, Mathew Paul Thomas responded to the suggestion that using an application at full-screen size should disable notifications by pointing out that:

If you're using Ubuntu on a netbook, for example, you're quite likely to make the current application full-screen whenever you can — but that doesn't have anything to do with which notification bubbles you want to see.

Thomas also warned that:

Developers often think their software is more fascinating to people than it actually is, which leads them to make the software more 'chatty' than it should be. (The pathological extreme of this can be found in the Windows Vista User Experience Guidelines, which seriously recommend that a 'non-critical system event' should display a notification balloon 'once every 10 minutes if users must resolve within an hour, once every hour if users must resolve within a day.').

In much the same way, Tomaszewski stated:

[W]e have good reason to believe that persistent indicators only work for some very specific cases (examples being network connection, volume, etc.). We are now going through the long and painful process of carefully defining these cases.

Yet another post, this time by Bruce Cowan, summarized the problems with any sort of dialog. The sudden appearance of windows and alerts, Cowan suggested, is confusing, and could make users worry that a piece of malware has started an application. In addition, too many dialogs could frustrate users, to the point that some disable them altogether, so that over-use of the system could defeat the entire purpose of providing timely warnings. As for the changes in the new guidelines, Cowan suggested that they may annoy experienced users who see little wrong with notification bubbles.

Whether these discussions will have any effect on the Ubuntu Design or Desktop Experience Team seems uncertain, since the guidelines are already being used in alpha versions of the upcoming Jaunty release. All the same, they are the sort of discussions that Ubuntu developers are likely to be having for the next eighteen months as they try to realize Shuttleworth's goal of increased usability, especially in the absence of hard data to show what designs are most usable. They are likely, too, to have them again, as they attempt to have their changes accepted upstream by projects like GNOME. However, for others, they show the punctilious but necessary considerations that usability generally involve — considerations that many free and open source software projects are only just starting to face.


(Log in to post comments)

Ubuntu debates usability changes

Posted Mar 5, 2009 1:27 UTC (Thu) by ctwise (subscriber, #10952) [Link]

Coherent design requires coherent vision. Committees are lousy at it. Engineers want black-and-
white guidelines but design is opinion. And good luck getting the open source community to agree
on something as vague as an opinion. Linux has been lucky to have a "benevolent dictator". I don't
see Gnome agreeing to the same thing.

Ubuntu debates usability changes

Posted Mar 5, 2009 4:35 UTC (Thu) by jordanb (guest, #45668) [Link]

Perhaps the Gnome project should adopt the process used in architecture.

There are a huge number of stakeholders in a significant building (the client, neighborhood, city government, tenants, etc) and they all want a say in the building's design. But if the building was actually designed by comittee, it'd be atrocious. So instead a single architect (or a small team) is hired to produce the best design for everyone.

Meetings are held with all the stakeholders and they provide their input, and the requirements are then turned over to the architect who tries to fulfill as many as possible while maintaining a unified design. During the process, designs are produced and shown to the stakeholders, who provide more feedback.

For very large or high-profile projects the architect is chosen through a design competition.

The idea is that even if everyone is not completely satisfied, they all had the opportunity to provide their input (assuming the process isn't railroaded, which doesn't always happen, of course) and therefore have some ownership, but the design-by-committee problem is avoided.

Ubuntu debates usability changes

Posted Mar 5, 2009 21:39 UTC (Thu) by lab (subscriber, #51153) [Link]

Very smart observation, and I think you are absolutely right. I suspect the ideal designteam consists of 1 (one) person, up to a maximum of 3.

Ubuntu debates usability changes

Posted Mar 7, 2009 12:10 UTC (Sat) by rwmj (subscriber, #5474) [Link]

This is about usability, and usability is definitely not an opinion. You can measure it - it's tedious and can be expensive, but you can measure it, you can compare different choices objectively, there are even formulae based on human perception and abilities that you can apply.

Ubuntu debates usability changes

Posted Mar 12, 2009 13:42 UTC (Thu) by renox (subscriber, #23785) [Link]

[[ This is about usability, and usability is definitely not an opinion. You can measure it ]]

This is a gross over-simplification: you can measure it on a certain population okay, but I doubt that all the participants in the discussion prioritize in the same order the needs of different target population..

Ubuntu debates usability changes

Posted Mar 13, 2009 10:07 UTC (Fri) by linuxrocks123 (guest, #34648) [Link]

<Cue my standard rant about HCI>

Usability most certainly /is/ an opinion. Yes, you can have people in white coats in a lab stand over people while they try to use whatever new interface you came up with and you can time how long it took them to figure out what to do. That tells you approximately zero about how good your user interface is.

Why? Because a person has to learn how to use your interface exactly once. A person usually has to use your interface much more than once. So, you should optimize a user interface for speed, not intuitiveness. Once people have figured out how to use your interface, they won't have to do so again, and they'll want to use your interface to interact with the program as quickly as possible. This is why vi is, in my view, one of the most usable programs ever written.

"But wait!", you say. "Nontechnical users might never figure out how to use your program in the first place if it's not intuitive!" That's absolutely right, which is why so many nontechnical users use text editors other than vi. So, you have to trade off between intuitiveness and literal "usability" in your UI design.

What's the appropriate weight of each of these factors in the tradeoff? Well, uh ... it's an OPINION! My opinion is that I want the programs I use to have intuitiveness weighted at 0 and usability at 100%, because I'm smart enough to learn from and patient enough to read a manual when I encounter a new program, and I don't want the speed at which I am able to use that program to be negatively affected by those who lack my intelligence or patience. I do not suffer fools gladly.

An emphasis on usability as opposed to intuitiveness was part of what attracted me to Linux in the first place. I had experience with DOS and wondered, "Why does Linux use 'cp' instead of 'copy'? 'copy' is more intuitive!", and was then able to answer myself, "because 'cp' is fewer characters, of course!" Open source developers tend to write software that they wish to use; since they are intimately familiar with their own software, this promotes the development of usable and not intuitive interfaces. I like that.

However, I am exactly one user, and I have no more moral right to dictate the design of software I am (generally) not paying for than the fools I do not wish to suffer. Interface design is a judgment call that each individual project will have to make based on the type of user the project wishes to attract.

They should remember I'll probably give more informative bug reports :p

</end rant>

Universal notification icon in system tray?

Posted Mar 5, 2009 3:01 UTC (Thu) by fmyhr (subscriber, #14803) [Link]

This may be hopelessly naive, as I've not followed any of the Ubuntu discussion except for the succinct summary in this article. BUT, how about having a single notification icon in the system tray. It would normally be grey, very easy to ignore. If an application had reason to notify the user, it would tell the daemon behind the systray icon. At the point the systray icon would turn red (or some user-configurable color / shape) to indicate that there is at least one notification awaiting user input. The user can choose to ignore it or not, depending on how they are using the system at the moment. If the user clicks on (or hovers above? -- perhaps again user-configurable) the notification icon, they get a menu listing the applications that are currently attempting to notify them. They select which app (maybe including "all") and all of that app's notifications are displayed. The user responds to each in turn, and they disappear from the universal notification icon menu. When there are none left, the systray icon turns back gray.

This seems to me to have the following benefits:
1) All notifications appear in the same place, no need to go hunting for them.
2) Notifications are easy to ignore (or not) depending on how you're using the system at the moment.

Maybe this completely misses the mark, I don't know. It just occurred to me as I was reading this article.

Extension of kde adept-notifier

Posted Mar 5, 2009 3:14 UTC (Thu) by fmyhr (subscriber, #14803) [Link]

I knew that "idea" seemed awfully familiar. It amounts to a ripoff/extension of adept-notifier or I suppose now update-notifier-kde. Just using it for *all* notifications, not only system updates.

Extension of kde adept-notifier

Posted Mar 5, 2009 8:34 UTC (Thu) by michaeljt (subscriber, #39183) [Link]

Just thinking back to another recent thread, having a single application there for notifications, which just remembers the messages and what to start when they are clicked on, might save a lot of valuable RAM. It seemed that some of the applications sitting there just to notify the user of something (sometimes even just waiting in case they need to notify and not actually displaying something) can take as much as 20Mb of RAM each, with update-notifier being a case in point.

Notification firewall

Posted Mar 5, 2009 12:42 UTC (Thu) by fmyhr (subscriber, #14803) [Link]

Reading other comments below, where some people want to see confirmation that a USB device has been attached and recognized and others never want to see such a message, it occurs to me that having a universal notification daemon has another advantage:

3) It can act as a firewall between notifications and the user. In other words, the notification daemon could include user-configurable filters on notifying application, message, urgency level, etc. When a message like "USB device attached" comes along and a user never wants to see that again, they could right-click on that notification window and select an option "Don't show me such notification again" which would open a notification filter configuration window:
Hide future notifications from:
* select: this application / all applications
* select: this message / all messages
* select: urgency level below: (numerical value)

When the notification daemon receives another message that matches an existing filter, it puts that notification in a submenu of the systray icon marked "Hidden Notifications". It does not turn the icon itself red/active. But if the user clicks on the systray icon and selects "Hidden Notifications" they can see the notifications that have been hidden and respond to them or re-enable them if they so desire. After a configurable message lifetime, hidden messages would be automatically removed from the "Hidden Notifications" sub-menu.

To really gild the lily, the notification daemon could allow setting up multiple notification profiles, so that a user could build up different sets of notification filters for different use cases and easily switch among them.

Analogous to iptables firewall, with
ip packet -> notification message
destination -> human user

Speaking of gilding lilies, the analogy could even be extended such that a notification daemon running in one session would *forward* matching notifications to a notification daemon running in another session / user / machine. Not sure that'd really be useful, though, and it gets complex in a hurry.

Notification firewall

Posted Mar 5, 2009 23:21 UTC (Thu) by spitzak (guest, #4593) [Link]

I like the sound of this.

I think this can be extended to cover *all* of Linux logging. All those messages that get written to /var/logs can also go to this program. By default they are hidden messages.

I agree with others that one of the rules will have to be "make this other icon do something" so that you can still have the wireless indicator and others that people are used to.

Universal notification icon in system tray?

Posted Mar 5, 2009 14:49 UTC (Thu) by sergey (guest, #31763) [Link]

How would this work with separate icons for battery and wireless link that are usually present in
a notification area? If they "delegate" their notification to yet another icon it'd probably be
confusing.

Universal notification icon in system tray?

Posted Mar 5, 2009 15:14 UTC (Thu) by fmyhr (subscriber, #14803) [Link]

Good point -- there are notifications the user wants to see at a glance, without having to click an icon and navigate its sub-menus.

One way this could be handled is to add another option that appears when you right-click on a notification: "add icon to systray". That would bring up a configuration window with:
- name of app/driver sending the notification
- icon to be added to systray, with button to select a different one
- radio buttons:
x pop up message windows above systray icon
x click systray icon to see messages

Right-clicking on the new app/driver-specific systray notification icon would give you an option "move to universal notification icon" that would undo the steps above.

Probably most distros would ship with a standard configuration that would have separate icons for things like battery and wireless. And if the user didn't like those they could easily get them out of their systray and into the universal notification icon.

Universal notification icon in system tray?

Posted Mar 7, 2009 10:48 UTC (Sat) by jospoortvliet (subscriber, #33164) [Link]

Well, basically this is what plasma is doing already. All notifications go
through the central notification system (embedded in the systemtray but
can be had separately as well, yay for modularity). There are no daemons
or apps in the systemtray for battery usage or network management, even
though you can have a plasmoid taking care of those. Even if you use these
plasmoids (be it on a panel or desktop), notifications go through the
notification plasmoid.

Universal notification icon in system tray?

Posted Mar 6, 2009 16:29 UTC (Fri) by bfields (subscriber, #19510) [Link]

Yes, it would be helpful to have the notifications combined with some kind of easy-to-find log; the main anxiety notifications give me as a user is "what if I ignore one and it turns out it was important?" It'd be reassuring to know I could always go back through the most recent ones....

Ubuntu debates usability changes

Posted Mar 5, 2009 3:18 UTC (Thu) by jwb (guest, #15467) [Link]

The screenshot accompanying the article is a singularly good example of a useless notification. I don't need the computer to tell me a USB device has been attached. I, the user of the computer, am the guy who plugged the USB device in.

Ubuntu debates usability changes

Posted Mar 5, 2009 5:29 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

Users often need confirmation from the system that it has recognized and is responding to the operation they are performing. Talk to non-technical users more.

Ubuntu debates usability changes

Posted Mar 5, 2009 5:36 UTC (Thu) by jwb (guest, #15467) [Link]

That's just BS. My Mac doesn't do anything when a USB device is attached, and that's the most non-technical user population in existence.

If there's any uncertainty that the computer has recognized the peripheral, then THAT is a major bug in the operating system. You only need confirmations when you have to constantly worry that the computer has failed.

A better notification would be "A USB device was attached, but the computer doesn't recognize it. Sorry." But to pop up a notification for success of peripheral attachment is just dumb.

Ubuntu debates usability changes

Posted Mar 5, 2009 6:43 UTC (Thu) by bronson (subscriber, #4806) [Link]

This is 100% correct. It not very unix-like to output needless messages: http://www.faqs.org/docs/artu/ch01s06.html#id2878450

It's going to take a big change in mindset but I do hope it happens. One day Linux developers are no longer going to be surprised when a hardware device just works like it should. :)

Ubuntu debates usability changes

Posted Mar 5, 2009 10:45 UTC (Thu) by NAR (subscriber, #1313) [Link]

If there's any uncertainty that the computer has recognized the peripheral, then THAT is a major bug in the operating system.

That's wrong. There can be many problems in attaching an USB device (broken cable, not working USB connector, turned off device or simply someone forgot to plug the cable), so it's useful to have some feedback even on success.

Ubuntu debates usability changes

Posted Mar 5, 2009 11:11 UTC (Thu) by tialaramex (subscriber, #21167) [Link]

I'm dubious about this in principle, but even if we accept for a moment that notifications are an appropriate solution, the example provided is terrible because it's so vague, particularly when you realise that an ExpressCard can appear to the kernel as USB, so the user's experience is "I plugged in my FooBaz card, and Linux said I'd connected a USB device - but the FooBaz is a modem not a USB device".

If someone's excited about notifications for USB devices, let them first go solve the case that's agreed to be a problem, which is when a user plugs in their USB Foobaz, and Linux doesn't have a suitable driver. udev (with perhaps a small tweak to the kernel) can figure out that nothing uses this device and /that/ is worth telling the user about. "Vender Inc Foobaz connected but you don't have a driver for it [Don't show me this again]".

Once /that/ works, it is extensible in a good way ("Connected device needs firmware file FooBaz-1.28.bin. Please install firmware and re-connect" and "The FooBaz webcam you've connected has an unsupported Baz controller") which tell a technical user what they need to know, and provide the non-technical user something useful to report to their tech support.

Ubuntu debates usability changes

Posted Mar 6, 2009 0:27 UTC (Fri) by maney (subscriber, #12630) [Link]

+1, with bells on.

Ubuntu debates usability changes

Posted Mar 6, 2009 6:46 UTC (Fri) by cpeterso (guest, #305) [Link]

Windows does this, but it rarely works. If Windows does have a generic driver for a device, I've never seen it successfully find a new driver from Windows Update when I plug in a new device.

Fortunately, I could imagine a Linux notification system using (something like) apt-get to download new drivers might actually work correctly. :)

Ubuntu debates usability changes

Posted Mar 6, 2009 6:48 UTC (Fri) by jwb (guest, #15467) [Link]

Probably the only reasonably accurate message would be "USB device not recognized. Wait a year and try again."

Ubuntu debates usability changes

Posted Mar 5, 2009 12:06 UTC (Thu) by ctwise (subscriber, #10952) [Link]

It's ironic you mention the Mac since this particular notification and this particular implementation
are lifted directly from Growl on the Mac. You're correct. Mac's don't natively show any notification
for hardware changes. If you install Growl and the Hardware Growler on the Mac then you'll get
notifications for hardware changes. It's actually quite useful. It tells you when the wireless drops
signal, when you have a network drive disconnect unexpectedly and so forth.

Ubuntu debates usability changes

Posted Mar 6, 2009 6:51 UTC (Fri) by cpeterso (guest, #305) [Link]

Growl solves some of the qualms have with Canonical's design:

* Growl is a single application, reducing memory usage
* Growl has an extensible notification API, so application developers can write new application-specific notifications
* Growl is a one-stop-shop for the user to control all (system and application) notifications. Each notification can be independently disabled, made sticky, or a timed message.

Ubuntu debates usability changes

Posted Mar 7, 2009 0:48 UTC (Sat) by dmag (subscriber, #17775) [Link]

The grandparent is pointing out that the message in the screenshot is not specific enough. It *might* be useful to say "new USB drive found", but then again, putting an icon on the desktop might be enough (that's what the mac does).

I want to route all the silly pop-ups to my IM program. That way I can scroll thru them, etc.

Ubuntu debates usability changes

Posted Mar 5, 2009 7:25 UTC (Thu) by bronson (subscriber, #4806) [Link]

This is starting to feel like the spatial disaster... a few developers suddenly think that they found the one true way of doing something and drive it through to completion, dismissing a lot of discussion along the way.

Then they discover that, while they solved their own problems perfectly, they have made life worse for most other Linux users. Then everything goes back to the way it was.

Betcha something similar happens here. I'm not worried though. Ubuntu is just over-correcting for Gnome's hideous notification system. They'll loosen up the design when they watch regular people trying to use it.

Ubuntu *implements* usability changes

Posted Mar 5, 2009 8:07 UTC (Thu) by DeletedUser32991 ((unknown), #32991) [Link]

I think that it is way cool to see Ubuntu experimenting to improve usability in this way. As much as the initial implementation might not be optimal, discussion without end will not lead to any improvements, either. It is really neat to see them pulling this off across the system and Ubuntu deserves credit for pioneering changes on this scale.

Ubuntu *implements* usability changes

Posted Mar 7, 2009 12:15 UTC (Sat) by rwmj (subscriber, #5474) [Link]

This isn't "experimenting to improve usability", this is people gabbing away their opinions on a
mailing list. You can perform real experiments on users - it's somewhat costly and can't be done
over the internet, but it can be done, and can be objectively measured.

Ubuntu *implements* usability changes

Posted Mar 7, 2009 19:08 UTC (Sat) by dlang (✭ supporter ✭, #313) [Link]

theis is at least the second comment saying that you can prove usability.

yes you can, but you are only proving usability for the users skill set that you test with.

you can get _very_ different answers to usability questions from users that have never seen a computer before (but you can't repeat the test with those users, because they now have the experiance of your first test) then if you test with people who have used windows for years then if you test with people who have used Macs for years.

which set of results is 'more valid' is definantly arguable.

Ubuntu *implements* usability changes

Posted Mar 7, 2009 22:58 UTC (Sat) by rwmj (subscriber, #5474) [Link]

And also by testing monkeys and cats. What's your point? Test the target group of people you want to sell your OS to.

Ubuntu *implements* usability changes

Posted Mar 8, 2009 1:33 UTC (Sun) by dlang (✭ supporter ✭, #313) [Link]

but the target audience for Linux distros is all of the above. so which answer is 'right'?

Ubuntu *implements* usability changes

Posted Mar 8, 2009 9:19 UTC (Sun) by rwmj (subscriber, #5474) [Link]

No answer is right. You test all the groups of people that you want to be able to successfully use the UI. This makes the whole thing much more expensive, but that's what you get when you want a UI which is useful for grandmas, astronauts and monkeys. Back in the real world, businesses decide narrow segments where they want to market and sell their software, and test only those, trading off the cost of developing for each segment with potential return.

Ubuntu debates usability changes

Posted Mar 5, 2009 9:57 UTC (Thu) by k3ninho (subscriber, #50375) [Link]

I wonder if the real issue is how people learn to use the interface they're given. If there's a steep ramp (notification that says "Something happened. RTFM!"), then no-one will like the contribution made. If there's a walk-through, or guided example use of the notification system, then the adoption will be much higher.

Consider the portal gun in Portal: the first few levels are entirely about learning what the portal gun can do and how to do it. And the story is also structured to ensure that this happens. Therefore there is a need that the user experience teaches the user how to do things. Perhaps a tech demo (possibly of the widgets in the desktop environment toolkit) would be the right place to build a tutorial.

Ubuntu debates usability changes

Posted Mar 5, 2009 14:50 UTC (Thu) by Frej (subscriber, #4165) [Link]

Games are single mission usage. You are actually playing a game, so whatever it does is feedback.

Notification from you OS while playing a game (or writing email) is annoying.

Ubuntu debates usability changes

Posted Mar 12, 2009 4:16 UTC (Thu) by thedevil (subscriber, #32913) [Link]

Apropos email: what's wrong with firing an email to root as a form of notification in cases like new updates?

Ubuntu debates usability changes

Posted Mar 12, 2009 6:59 UTC (Thu) by muwlgr (guest, #35359) [Link]

Oh, email is just so old-fashioned. The newly-invented wheel should indeed be square :>

Ubuntu debates usability changes

Posted Mar 5, 2009 14:45 UTC (Thu) by kitterma (guest, #4448) [Link]

I'm the Scott Kitterman quoted in the article and I want to clarify something. Here's
the email from which the quote was taken: https://lists.ubuntu.com/archives/ubuntu-

Both the comments of the author of this article and the way that the quote was
adjusted to provide context appear to me to misconstrue what I was trying to
communicate. In the original email I was talking about "people involved in
Canonical Dx", which is one specific group within Canonical. As a community
developer I work with Canonical developers regularly and we work quite well
together. My point about not being open to feedback was narrowly focused at one
small group in a company that is otherwise quite easy to work with.

As a follow-up I've learned that there are really two teams, a design team and the
mentioned desktop experience team involved in this new effort, so my initial
characterization was a bit too narrow.

Ubuntu debates usability changes

Posted Mar 5, 2009 14:47 UTC (Thu) by Frej (subscriber, #4165) [Link]

A bit late to the debate but,
Take this if from a comp.sci student (I don't do HCI, but it's more important than my expected profession)....Respect the work of others, especially from outside your profession. You might be smart, but subject knowledge often matters more. Secondly I enjoy software and computers - so if it talks to me. Yay!. But really most people don't.

I've posted this before as comment on Marin Duffy's blog. Same subject. Don't disturb the user!
http://mairin.wordpress.com/2009/01/05/chatty-applications/

In a language comp.sci people grok.

Context switches for humans are _extremely_ slow and can cause _errors_!. Humans have to rethink some number of 'instructions' earlier when switching back.

Abstractions and models are everywhere in programming, the same goes for reasoning about human thinking. If you model human thinking as a continuous stream of thoughts (many other metaphors work surprisingly well), imagine the harm done when something requires attention and interrupts the stream.

Anything moving or changing requires a context switch, if noticed. If it requires interaction you just lost at least 1 min. And the point of notifications is, well being noticed ;).

And! some actual research to back this up.

This guy has a lot material
http://research.microsoft.com/en-us/um/people/horvitz/
especially at
http://research.microsoft.com/en-us/um/people/horvitz/int...
I have not read it ;) … some of it seems to be reviewing non-modal dialogs centered on the screen (eek!). But the point is the same.

I found the above via this paper (reference 8). http://kasperhornbaek.dk/evaluating-user-interfaces-metap... Which I found quite nice…. but written by they the lecturer of a course i followed, so huge bias there.

Errata

Posted Mar 5, 2009 19:08 UTC (Thu) by mpt (guest, #53303) [Link]

For these reasons, the guidelines call for a reduction in [notification bubble] use, although acknowledging the possibility that they might still be useful in unspecified circumstances.

The guidelines say to use a notification bubble “When a notification doesn’t need an input response, and either it is best read as soon as possible or there is no relevant window (whether open or closed) to display it in”. Perhaps that’s not the clearest possible way of wording it, but it’s not accurate to call it “unspecified”.

Whether these discussions will have any effect on the Ubuntu Design or Desktop Experience Team seems uncertain, since the guidelines are already being used in alpha versions of the upcoming Jaunty release.

We have already made several changes to Update Manager’s behavior as a direct result of the discussions, so we’re grateful for the feedback.

designated notification queue widget

Posted Mar 12, 2009 5:51 UTC (Thu) by jabby (guest, #2648) [Link]

I think one solution that deserves a usability study would be a "designated notification queue widget." This would alleviate some of the concern that users will suspect malware activity because it will clearly be an integral part of the desktop. It will be a stack or queue that remembers the last 'n' notifications (complete with dialogs, if possible) and allows the user to scroll back through any that were missed. It would be minimal and unobtrusive by integrating into the taskbar or desktop and could change color to indicate new notifications since the last time the user checked the widget. And best of all, it could contain an obvious toggle button for "Do Not Disturb" mode!

I do not know if anyone else has ever proposed this, but feel free to take this idea and run with it.

:)

Copyright © 2009, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds