Sometimes it happens via dialog, sometimes it happens via notification bubble, but either way my computer can be quite chatty.
I’m wondering if there are any guidelines for designing programs to be good citizens in their chattiness. Some questions that I have that maybe could be used to come up with a set of guidelines if there aren’t any:
- Classify the message you’re sending out. Is it a critical message, a warning, or simple information? Is it hardware-related, security-related, long-running task related (task failed or task succeeded), do I need to take any action from it or is it not possible to take action from it?
- What should the user do to address the issue, if there is any action to be taken? Can you allow the user to say, “always treat this type of action this way without bugging me?”
- For each message classification, what is the most appropriate iconography needed for the message? Is there any special wording needed? Should it be displayed on a frequent basis? What basis? Or should it be displayed just once?
- Allow users to ‘unsubscribe’ from particular types of notification. But perhaps don’t make it all or none (although I may want to opt-out of all messages from a particular app, I should be able to turn it off at a more fine-grained level.) In each alert dialog/notification bubble, allow users to one-click visit the notification preferences for that (or all?) applications so they can quiet it. Also, should there be both ‘shut up now’ and ‘shut up forever’ buttons? If not which should be more prominent?
- Alerts are going to the desktop, to the currently-logged in user. Are there users of the system who aren’t logged in who would want to be kept notified of the alerts? Are there users logged in remotely who might want an alert on the shell? How do desktop notifications/alerts translate?
- How do you enable users to take action on alerts? What if there are many alerts from the same application? How do you consolidate them so that users can perform the same action on multiple alerts at once but in a well-informed manner (or at least as informed as the user wants to be)?
- When do you decide to alert a user vs. take action on their behalf without bugging them? To what level should the user be allowed to dictate this if they want more or less notification/control than provided by default?
Just some half-formed thoughts anyway. I would be curious to see if anyone is familiar with guidelines on these. I’ve looked in a few UI books and guidelines (GNOME HIG, Apple UI guidelines, MS UI guidelines) and haven’t found any yet but maybe I’m not looking in the right spots.
notification interface
of course, there are these people's ideas
Re: notification interface
Wake me up when Canonical writes actual code then.
Re: notification interface
I'm just curious, why did you highlight the word "ideas" ?
thanks for the link.
Re: notification interface
(They probably didn’t. You have your LiveJournal configured to convert clickable links into non-clickable highlighted text. The same happened to all the links in my other comment in this thread.)
Re: notification interface
So I sat down and looked at this very carefully. I do take issue with some of the points:
"There should be no actions on notifications." "no buttons, sliders, links, or even a dismissal [x]."
I don't understand the rationale for this. The given rationale does not make sense to me.
Many notifications include messages that talk about bad/critical things happening. E.g., popping up a bubble that says, "An unauthorized user just logged into your computer" without suggestion to the user what action to take or waht to do is rather irresponsible. Okay, great, computer! what do I do? Should I shut down? Should I disconnect the network? Just as I sometimes get annoyed with people who come to me complaining aboutproblems and no ideas on a solution to fix them, I am annoyed by software that spreads gloom and doom without just fixing it for me or giving me options on how to deal with it. Error condition notifications without suggested remedies are really bad for usability I think, because you're making your user feel bad AND powerless.
"Notifications should not be displayed synchronously, but may be queued. Our implementation of the notification display daemon will display only one notification at a time, others may do it differently."
This is an interesting idea. I think there are some types of messages that shouldn't be queued though. It's dumb for rhythmbox to notify me of what song I am listening to when it's already half over. It's really bad for me to get a "someone is hacking your computer right now!" message at a delayed rate. It is also annoying to have the right half of my screen turn into something not unlike the bottom news scroller of CNN news. Movement on the screen is highly distracting with things sliding up and out I would think is more distracting than a bubble appearing and disappearing, although I do like that the bubbles in the mockup are dark in color and less contrasty than a white bubble would be.
"We think there should be persistent panel indicators for things which you really need to know about, even if you missed the notification because you urgently wanted that coffee. So we are making a list of those things, and plan to implement them."
I would be very interested to see that list. I would think error messages and security issues should be on it.
"Everything else should be dealt with by having a window call for attention, while staying in the background, unless it’s critical in which case that window could come to the foreground."
What if the message is not associated with an application that doesn't currently have a window displayed? (E.g., se linux error, firewall issue, vpn issue, or hidden application such as pidgin out of the task bar and only in the system tray area, a blinking system tray of doom is not something I remember fondly about Windows.)
Overall some interesting ideas on visual implementation, but not a lot of ideas on categorization and data types and policies which is more the type of meat I'm after.
Ah yes important subject
In a language comp.sci people grok (that includes me). Context switches for humans are EXTREMELY slow. It even introduces errors, since humans have to restart a number of operations earlier when switching back.
Basicly, if you model human thinking as a stream of thoughts (many metaphors work surprisingly well), imagine the harm done when something requires attention and interrupts the stream.
Bascily – anything moving or animating requires a context switch. If it requires interaction you just at least 1 min.
Re: Ah yes important subject
It's true. But maybe you're open to interruption. If you're just chilling out chatting with your friends I don't think you'd mind say a notification from identi.ca that one of your friends just made a post because you're already in the task of socializing.
But if you're working on a deadline at work or trying to get your taxes done, you probably do not want to get interrupted by that sort of thing. 🙂
I really like Paul's idea of having a slider to increase-decrease the number of messages you get, if it's tuned down to low you only get very critical security messages (e.g., SOMEONE IS HACKING YOU RIGHT NOW, that you'd be interrupted by if someone tried to break into your house when you were doing work on paper) and if it's tuned up you get rhythmbox track identification notices and identi.ca and IM posts, etc. The slider being turned low could also change the method of notification, eg, less data, no animation, etc.
What your post made me think of, is maybe this slider isn't a permanent user setting but is something people could set based on the mode of work they are in. Kind of like how I always have the volume control applet in the upper right corner of my desktop all the time, and I can turn the volume down when I'm at work and turn it up if I want to play music and let other people hear.
Also… some actual pointers
This guy has a lot material <a href="http://research.microsoft.com/en-us/um/people/horvitz/http://research.microsoft.com/en-us/um/people/hor… />
especially at <a href="http://research.microsoft.com/en-us/um/people/horvitz/interrupt.htmhttp://research.microsoft.com/en-us/um/people/hor… />
I have not read it ;)… some of it seems to be reviewing dialogs centered on the screen (eek!).
I found the above via this paper (reference 8). http://kasperhornbaek.dk/evaluating-user-interfac… Which I found quite nice…. but written by they the teacher of the course i followed, so huge bias there.
Re: Also… some actual pointers
Any basic introduction to cognitive psychology is useful. After getting the basics of that you will already notice dozens of fatal flaws in the present chatty desktops. Shuttleworth's idea was btw a brainfart at best – tending to the symptoms instead of the real problems.
Re: Also… some actual pointers
Thank you so much! I will definitely take a look at these!
Am home sick, and a little brain-fuzzy, so thoughts may be less coherent than possible, but:
I recall a white paper circulating at MS regarding notification bubbles and when to use them, at least in official MS apps (the thought here being, the mechanism is kinda broken, but we can at least make sure apps like MS Office and the OS components are good notification citizens, so we can talk coherently to third-party developers about how best to use notifications).
There were basically bullet-points in it for "should I pop a notification-bubble for this?" and I recall a few of them.
Actionability – If you're giving the user a choice to make, pop a bubble. (So, pop a bubble for "There's mail!" or "Plug in or die!" – the user needs to do something for those, either read the mail, or plug the computer in. Don't pop a bubble for "Couldn't contact the mail server!" – there's nothing the user can do for that in the vast majority of cases. That's more appropriate to show as a warning in a status area, like the bottom-of-window status bar many apps have. Some messages, like the "Document sent to printer" one that the print spooler does, simply shouldn't happen at all – what use is that message, really?)
Messaging Rate – How often is this bubble going to show up? If it's all the time, why does the user want it? Can you make it more informational by making it less frequent? (Outlook violates this one pretty badly.)
There was some stuff about opting and control, but I don't recall exactly what they said. None of it was groundbreaking. The really interesting bit to my readthrough was the idea that there's not much point in using the interrupting "bubble" UI, which is very prominent, for something that the user doesn't want to act on when it happens. The notion is fairly intuitive, but I hadn't seen it put so clearly elsewhere.
Bubbles and actions
There was some stuff about opting and control, but I don't recall exactly what they said. None of it was groundbreaking. The really interesting bit to my readthrough was the idea that there's not much point in using the interrupting "bubble" UI, which is very prominent, for something that the user doesn't want to act on when it happens. The notion is fairly intuitive, but I hadn't seen it put so clearly elsewhere.
This seems intuitive to me too. Not to get too off course here, but it seems to me that relocating the interface elements by which the user does act to some other location, when the user's attention is already (supposedly) on the bubble, is completely counter-intuitive.
Mairin, I like the idea of a very simple, global "more chatty / less chatty" setting that affects whether the user sees only critical messages ("Plug in or die!"), as opposed to info-level messages ("You're now hearing 'Georgia' by Ray Charles"). Rather than having the user set message levels by selecting one of those levels, one could have a slider or radio button that essentially goes from no filtering to filtering everything but critical messages.
Hmm
The user "needs" to do something about "There's mail!" ?
Am I the only one who treat email differently from IM, and who considers the main BENEFIT of email over synchronous forms of communication that you DONT need to drop what you're holding and get at it right-away, but instead can read and respond to your email at *your* convenience ?
Re: Hmm
Actually, that's exactly the reason I put mail in the examples. Unlike "Plug in now!" which is both actionable and immediate, "You've got mail!" is actionable, but not necessarily immediate. The action is "Go read it, or not. Your call, user." Notifications like "Hey, you just came into WiFi service" are similar – there's an action the user can take, enabled through the bubble, but there's nothing pushing the user to take that action.
Hey thanks! I was kind of thinking along those lines too, where actionable = bubble and information thats not actionable living in the application itself in a dialog maybe. It is good to know that I wasn't alone in that thinking. 🙂
I do think that a high bar needs to be set on whether or not a notification is made at all. Because nobody wants their desktop to be a jungle 🙂
Take a look at Growl
I think that Growl for Mac OS X gets things more or less right, with a global preference panel which allows you to configure defaults for notifications, but then override them for specific applications.
That way you can make an announcement that someone has sent you an IM prominent, but the message about having unplugged your laptop much less so.
It also allows notifications to be sent and received over the network, which seems like a decent solution to notifying other people of things at the same time.
Re: Take a look at Growl
Very nice tip, thank you! There are a lot of good ideas in the growl preferences dialogs: <a href="http://growl.info/documentation/exploring-preferences.php” target=”_blank”>http://growl.info/documentation/exploring-preferences.php
I like how you can turn them off for an entire application, or turn off only particular notifications for that app…. I really like how you can log too, and you can log only without notices if you want.
Working out sane defaults I think will be quite some work but pretty do-able.
Very, very nice food for thought, thanks again for the tip!
OpenTTD messaging system
I think one game got this notification thing pretty well done, Transport tycoon (OpenTTD nowadays) to be exact. In Transport tycoon new messages scroll in the statusbar and if you click them, they open up and show full content of the message. You can also control which kind of messages pop up automatically and which don't. There's also a message history. I put few screenshots to picasaweb if you're interested. Although a game of OpenTTD would tell much more. 😉
http://picasaweb.google.com/corecrystal/OpenTTDMessagingSystem?feat=directlink
Does anyone of you know a program(like a gnome panel applet) that would mimic that kind of behavior?
cheers,
corec
Sounds familiar
Per-application and per-message-type filtering … sounds a lot like syslog's facility and level mechanism. Good ideas never die, they just get reimplemented 🙂
Re: Sounds familiar
Well, reimplemented…. or GUI-ified right 🙂
Butler
Not guidelines exactly, but I always like Ellen Isaac's approach (which she expands upon in her book, "Designing from Both Sides of the Screen") of designing applications to behave like a "helpful, efficient, but unobtrusive butler". Most of the time you just want your butler to shut up, keep out of your way and deal with things– if they kept telling you what they were doing, or asked you what to do every time they had a choice to make, you'd soon fire them and find a better one.
Notify OSD and notification design guidelines
Together with the appearance of Notify OSD in Ubuntu Jaunty this week, we’ve published some notification design guidelines. The guidelines cover the various notification mechanisms, and when developers of software running on Ubuntu should use each one.
Microsoft also has guidelines on the use of notification balloons in Windows. Their design differs — and therefore their guidelines differ — from ours in two major respects. First, their notification balloons are interactive, whereas our notification bubbles are deliberately non-interactive. And second, their balloons almost always point at an icon in the “notification area”, whereas we think that pattern is fundamentally broken.
You wondered about the non-interactivity: “I don't understand the rationale for this. The given rationale does not make sense to me.” Fair enough (Mark’s a CEO, not a tech writer), so let me clarify. There are three main reasons we think notification bubbles should be non-interactive. First, they appear without warning and float on top of everything else, so if they were interactive they would risk accidental clicks. Second, bubbles should always go away after a timeout (because if they didn’t, they’d either overlap with later bubbles or cause a queue of bubbles to back up indefinitely); therefore, it would be unpleasant to have controls in them that you might aim for but not quite reach in time. (notification-daemon tries to counteract this by showing a pie chart of time remaining, but that chart is counterproductive because it draws your eyes away from the message itself.) And third, we fade away bubbles when you mouse over them so that they don’t prevent you from clicking something underneath; that wouldn’t work if the bubbles themselves were interactive.
Sure, so that’s the sort of thing that shouldn’t use a notification bubble in the first place — it should use an alert box, or even a morphing alert box if it’s really time-critical.
In Ubuntu, if it is a messaging application (e-mail, IM, IRC, Twitter, etc), it should integrate with our new messaging menu. Otherwise, if there is a relevant window at all, it should open that window unfocused, and highlight the relevant section appropriately. If there isn’t a relevant window at all, it should use an alert box, again unfocused.
You and others in this discussion also mentioned the idea of configuring the amount of “chattiness” based on how busy you are. We haven’t gone far with that idea in Notify OSD yet, but we will have a “do-not-disturb” mode in which only critical notification bubbles will be shown.
Re: Notify OSD and notification design guidelines
So it seems your notion of notification bubbles is quite limited compard to mine. I'm almost thinking of something like a syslog (okay not that chatty) and there aren't worries about missing a message (one of the rationales for not including action buttons) because there is an associated application that you can use to view previously-shown alerts. In SELinux's case this is the SETroubleshoot alert browser, which is kind of laid out like an email client.