GUI design techniques to enhance user experience [closed] - user-interface

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
What techniques do you know\use to create user-friendly GUI ?
I can name following techniques that I find especially useful:
Non-blocking notifications (floating dialogs like in Firefox3 or Vista's pop-up messages in tray area)
Absence of "Save" button
MS OneNote as an example.
IM clients can save conversation history automatically
Integrated search
Search not only through help files but rather make UI elements searchable.
Vista made a good step toward such GUI.
Scout addin Microsoft Office was a really great idea.
Context oriented UI (Ribbon bar in MS Office 2007)
Do you implement something like listed techniques in your software?
Edit:
As Ryan P mentioned, one of the best way to create usable app is to put yourself in user's place. I totally agree with it, but what I want to see in this topic is specific techniques (like those I mentioned above) rather than general recommendations.

If you do give the user a question, don't make it a yes/no question. Take the time to make a new form and put the verbs as choices like in mac.
For example:
Would you like to save?
Yes No
Should Be:
Would you like to save?
Save Don't Save
There is a more detailed explanation here.

Check out the great book Don't make me think by Steve Krug.
It's web focused but many of the conepts can apply to anything from blenders to car dashboards.
Topics covered:
User patterns
Designing for scanning
Wise use of copy
Navigation design
Home page layout
Usability testing
He also has a blog called Advanced Common Sense
And some random UI related links:
- User Interface Design for Programmers by Joel Spolsky
- 10 Usability Nightmares You Should Be Aware Of

First Principles: Wilfred James Hansen
Know the User
Minimize Memorization
Optimize Operations
Engineer for Errors
Subsequent Expansions: Dr. Theo Mandel
Place Users in Control
Use Modes Judiciously (modeless)
Allow Users to use either the Keyboard or Mouse (flexible)
Allow Users to Change Focus (interruptible)
Display Descriptive Messages and Text (helpful)
Provide Immediate and Reversible Actions, and Feedback (forgiving)
Provide meaningful Paths and Exits (navigable)
Accommodate Users with Different Skill Levels (accessible)
Make the User Interface Transparent (facilitative)
Allow Users to Customize the Interface (preferences)
Allow Users to Directly Manipulate Interface Objects (interactive)
Reduce Users' Memory Load
Relieve Short-term Memory (remember)
Rely on Recognition, not Recall (recognition)
Provide Visual Cues (inform)
Provide Defaults, Undo, and Redo (forgiving)
Provide Interface Shortcuts (frequency)
Promote an Object-action Syntax (intuitive)
Use Real-world Metaphors (transfer)
User Progressive Disclosure (context)
Promote Visual Clarity (organize)
Make the Interface Consistent
Sustain the Context of Users’ Tasks (continuity)
Maintain Consistency within and across Products (experience)
Keep Interaction Results the Same (expectations)
Provide Aesthetic Appeal and Integrity (attitude)
Encourage Exploration (predictable)

To add to your list, aku, I would put explorability as one of my highest priorities. Basically, I want the user to feel safe trying out the features. They should never back away from using something for fear that their action might be irreversible. Most commonly, this is implemented using undo/redo commands, but other options are no doubt available e.g. automatic backups.
Also, for applications that are more process-oriented (rather than data-entry applications), I would consider implementing an interface that guide the user a bit more. Microsoft's Inductive User Interface guidelines can help here, although you need to be very careful not to overdo it, as you can easily slow the user down too much.
Finally, as with anything that includes text, make the user interface as scannable as possible. For example, if you have headings under which commands/options appear, consider putting the action word at the start, rather than a question word. The point that Maudite makes is a good example of scannability too, as the "Don't Save" button text doesn't rely on the context of the preceding paragraph.

A useful technique which I never see anyone use is to add a tooltip for a disabled UI control explaining why the control is disabled. So if there's a listbox which is disabled and it's not clear why it is disabled, I want to hover over it and it tells me why it's disabled. I want to see something like "It's disabled because two textboxes on the screen were left blank or because I didn't enter enough characters in some field or because I didn't make a certain action.".
I get into sooooo many such situations and it's frustrating. Sometimes I end up posting in the software's forum asking why a control is greyed out when a tooltip could have helped me in a second! Most of these software have help files which are useless in these kinds of scenarios.
Try to pretend you know nothing about your software and try using it. However this is not practical because you already have a certain mind set towards the app. So watch fellow developers or friends use the app and look out for the pain points and ask for feedback.

One of the classic books to help you think about design is "The Design of Everyday Things" by Donald Norman. He gives great real-world examples. For example, if you design a door well, you should never have to add labels that say "push" and "pull." If you want them to pull, put a handle; if you want them to push, put a flat plate. There's no way to do it wrong, and they don't even have to think about it.
This is a good goal: make things obvious. So obvious that it never occurs to the user to do the wrong thing. If there are four knobs on a stove, each one next to an eye, it's obvious that each knob controls the eye it's next to. If the knobs are in a straight line, all on the left side, you have to label them and the user has to stop and think. Bad design. Don't make them think.
Another principle: if the user does make a mistake, it should be very easy to undo. Google's image software, Picasa, is a good example. You can crop, recolor, and touch up your photos all you like, and if you ever change your mind - even a month later - you can undo your changes. Even if you explicitly save your changes, Picasa makes a backup. This frees up the user to play and explore, because you're not going to hurt anything.

I've found UI Patterns to be a useful reference for this sort of thing. It's arranged much like the classic GoF Design Patterns book, with each pattern description containing:
The problem the pattern solves
An example of the pattern in action
Sample use cases for the pattern
The solution to implement the pattern
Rationale for the solution

If you implement a search, make it a live search like what Locate32 and Google Suggest does now. I am so used to not pressing "Enter" at the search box now.

Well, one thing that may be obvious: don't change (even slightly) the position, color, font size, etc. of buttons, menus, links, etc. between screens if they do the same type of action.

Really good feedback is extremely important. Even simple things like making it obvious what can and cannot be clicked can be overlooked or too subtle. Feedback when something might happen in the background is great. In gmail, it's great that there's a status ribbon appearing at the top that let's you know if something is sending or loading, but it's even better that it lets you know that something has sent successfully or is still loading.
The "yellow fade" technique is something else made popular amongst the RoR crowd that accomplishes something similar. You never want the user to ask the question, "What just happened?" or "What will happen when I do this?".
Another trick that has become more popular lately that I've been using a lot is editing in place. Instead of having a view of some data with a separate "edit" screen (or skipping the view and only having an edit screen), it can often be more user friendly to have a nicely laid out view of some data and just click to edit parts of it. This technique is really only appropriate when reading the data happens more often than editing, and is not appropriate for serious data-entry.

If you are doing enterprise software, a lot of users will have small monitors at low resolution. Or if they are old they will have it at a low res so they can see giant buttons ( I have seen an 800x600 on a 24"ish monitor). I have an old 15" monitor at a low resolution (800 x 600) so i can see what the program will look likes in less than idle conditions every now and then. I know that enterprise users pretty much have to accept what they are given but if you design a winform that doesn't fit into an 800x600 screen, it's not helping anyone.

Try to think about your user's end goals first before deciding what individual tasks they would carry out when using your software. The book About Face has excellent discussions on this sort of thing and though quite long is very interesting and insightful. It's interesting to note how many of their suggestions about improving software design seem to used in google docs...
One other thing, keep your user interface as simple and clean as possible.

Here is a great DotNetRocks podcast episode where Mark Miller talks about how to create Good UI; Even though the show title is .NET rocks, this episode talks about a general rule of thumbs on how to create a UI to increase program user's productivity.
Here is an episode exerpt
Good user interface design can be done by sticking to some good rules and avoiding common mistakes. You don't need to be a latte-sippin tattoo-wearin macbook-carrying designer to create user interfaces that work.

I like to follow these 3 guidelines:
Standard - follow known standards/patterns, reuse ideas from all products you respect
Simple - keep your solutions simple and easy to change (if needed)
Elegant - use less to accomplish more

The best technique I found is to put your self in the users shoes. What would you like to see from the GUI and put that in front. This also gives you the ability to prioritize as those things should be done first then work from there.
To do this I try to find "layers of usefulness" and add / subtract from the layers until it seems clean. Basically to find the layers I make a list of all the functions the GUI needs to have, all the functions it should have, and all the functions it would be neat to have. Then I group those so that every thing has logical ordering and the groupings become the "layers". From the layers I then add the most important functionality (or what would be used for Day to Day operation) and that becomes the most prominent part, and I work things into the feature around those items.
One of the toughest things is navigation as you have so much to give the use how do you make it helpful and this is where the layers really help. It makes it easy to see how to layout menus, how other pieces interact, what pieces can be hidden, etc.
I have found the easiest way to do this is to start by see what and how your users function on a day to day basis this which will make it easier to get in their shoes (even better is to do their job for a few days). Then make some demonstrations and put them in front of users even if they are Paper Prototypes (there is a book on this process called Paper Prototyping by Carolyn Snyder). Then begin building it and put it in front of users as it is built often.
I will also recommended the book Designing Interfaces by Jenifer Tidwell published by O'Reilly

The items in the list you presented are really situation dependent - they will vary from application to application. Some applications will need a save button, some won't. Some conditions will warrant a modal dialog box, some won't.
My top rule for designing a usable interface: Follow existing UI conventions. Nothing confuses a user more than a UI that doesn't work like anything they've ever used. Lotus Notes has one of the worst user interfaces ever created, and it is almost entirely because they went against common UI conventions with just about everything that they did.
If you're questioning how you should design a certain piece of your UI, think of a few standard/well-known applications that provide similar functionality and see how they do it.

If your UI involves data entry or manipulation (typical of business apps) then I recommend affording your users the ability to act on sets of data items as much as possible. Also try to design in such a way that experienced users can interact with the UI in a very random, as opposed to sequential way (accelerator keys, hyperlinks, etc).

Sung Meister mentioned Mark Miller. You can find some of his blog posts regarding great UI on the Developer express blog. Here's a screencast of his Science of great UI presentation: part1 and part2. (both require Veoh player).
You can also find him on dnrTV: Science of great user experience: part1 and part2.
Here's a google techtalks about user experience by Jen Fitzpatrick.
Cheers

When using a dropdown, the default dropdown height is usually too low (default is 8 items for winforms, for example).
Increasing it will either save the user a click if the number of items is low or make it easier to search the dropdown if there are a lot of items.
In fact, I see little point in not using all the available space !
This is so obvious to me now, but for example, it seems even VisualStudio designers haven't figured it out (btw, if you manually increase Intellisense's height, it will stay this way, but that's offtopic:))

I'll give one of my personal favorites: avoid dialog boxes at all costs. A truly good U I should almost never need to pop up a dialog box. Add them to your program only as a truly last resort.
For more, you might want to check out easily digestible ui tips for developers.

The Coding Horror Blog regularly gives great ideas. Just some examples:
Exploratory and incremental learning
Self-documenting user interface
Incremental search of features/Smart keyboard access
Task-oriented design (ribbon instead of menus and toolbars)
Providing undo instead of constant confirmation
Another aspect: use scalable icons to solve the problem of multiple user screen resolutions without maintaining different resolution bitmaps.

Related

What is the Difference between User Interface and User Experience?

I see this term been thrown around a lot. Wish someone can explain it in simple terms. What is the difference and relationship between UI and UX?
Simply put, UI != UX although there's an overlap.
The UI designer is responsible for designing screens which users will
interact with. UX designer makes sure the interaction is a
pleasurable one
UX designer usually work for macro-interactions ie. how will the user journey play out from start to end. They perform research on personas, perform usability testing, etc. On the other hand, UI designers have A+ sense in developing an interface in accordance with user stories i.e UX designer's storyboard.They work on how the interactions would work out for the entire User Journey. Tenter image description here Read more on this blog Web Design Vs UI Vs UX ..Why You Don’t Get It Right?
The user interface design is the layout or the structure of the elements on the screen as well as the functional behaviour of such elements when manipulated by the user. The user interface design should be user-friendly.
On the other hand, the user experience has to do with the ability of a user to effectively and successfully manipulate a software. Some software demand that users rate them according to appearance, functionality, interactivity among others.
Put very simply, a user interface (UI) is the thing (website/touchscreen application) users interact with to complete some task. User experience (UX) is a user's rating of how well the interface suited their needs to complete that task.
UI stands for User Interface while UX stands for User Experience
To make it really simple:
Layman example:
When you see a car, how it looks that is UI.
However, the feeling that you have while driving a car that's UX.
Technically speaking:
UI is just a part of UX, so a good UI contributes to a better UX. For example, imagine you visit a University's website to find admissions information. Imagine the website has weird graphics, ugly fonts and you can't figure out which link to click to get the information.
That is an example of bad UI which also ruins your UX (user experience) when you try to perform any operation. On the contrary, if the website has appealing graphics, nice big fonts and you spot your desired information easily. That could be an example of good UI leading to good UX.
UX itself is dependent on many factors including UI such as Latency rate, Overall time to perform operation etc.
Hope this helps.

What are some common elements/features for a more user-friendly GUI? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I presented a prototype piece of software to the "customer" of a product I've been working on. The program's requirements were extremely vague because the customer had doubts as to what can be accomplished through software (he normally deals with hardware and parts).
The customer was very impressed with the functionality of the program and really the biggest desire was to have a more user friendly GUI -- whatever that is supposed to mean. This lead me to think exactly what makes for a user-friendly GUI.
I feel like its a hard question to answer as someone who writes a program due to the fact I know all the inner workings of the GUI. I know getting some friends/coworkers/etc to play around with it for a little bit and getting feedback is a great way to test the intuitiveness of a GUI, but that doesn't mean its a user-friendly, it just means the user can eventually 'figure it out'.
I don't want this question to be specific to my project, I just wanted to let you know where I'm coming from. What do you think makes for a user-friendly GUI?
You might enjoy "About Face: The essentials of interaction design," by Alan Cooper et al.
I personally am partial to Paul Heckle's "The elements of friendly software design." Parts are out-of-date, but some axioms are timeless, like:
Don't frustrate the user.
Give the user control.
Respond to the user's actions.
There are more, but you'll have to buy the book.
Here's a few concrete things to pay attention to:
avoid the use of dialogs. They interrupt "flow"
pay attention to tab order (ie: make sure user can use tab to navigate between items)
be consistent with the platform (windows-like buttons on windows, mac-like buttons on mac, use standard shortcuts)
use standard fonts, colors and icons. Don't think you know more than your user what looks good.
tailor the interface so that the most common actions are the easiest to do
do things that give your user confidence (like automatically saving backups or having proper undo, so they don't feel like they can accidentally lose data)
make sure all windows have proper resize behavior. Give the user the ability to make input areas bigger and/or make sure they work with big fonts.
And finally,
create prototypes (paper works fine) and ask your actual users.
In General:
I like adding an "Easy Button": It could do all the default stuff automatically.
Wizards are always nice for those who want to go through step by step.
Drag and Drop capabilities
Tool Tips and descriptive ICONS.
I'd say the biggest thing is labels for inputs. I've seen too many forms that have either no labels or ambiguous labels. Also spacing, if there is a mass of white space between elements they might appear disjointed, or if they are squished together it might become difficult to distinguish between them. If there are two buttons can I easily click on the one I intend to click on?
Font choices also make for a user-friendly GUI. Sure, they are mostly aesthetic, but if I can't read what is on the screen because it is too small or in a poor font the GUI becomes more difficult to use.
Artsy items like music or images can detract from a GUI being user-friendly. Listening to the same sound on a loop can be annoying, or being slowed down when loading the application to load images can detract from being user-friendly. Imagine that the end-user will be staring at this GUI for an 8 hour day, 5 days a week. Is the GUI useful or annoying?
Use options to make the user's life easier. Let them feel like they are in control of the software rather than being dominated by it. The user should feel the software is a tool, not a necessary evil.
Small things like being able to hit "Enter" to submit a form or "Tab" to jump between elements. Make the user work as little as possible, use computers to automate their life.
Do not downplay intuitiveness, being able to figure out the GUI is a portion of being user-friendly, if the design is not intuitive or easily able to be figured out it does not invite itself for being user-friendly.
One principle that is easy to grasp is this: don't make the user do anything the computer can do for them.
Task-focused: Offer tasks and use terminology that your users know (e.g. "Find street" instead of "Search 'street' column"). When the user has selected a task, stick to that task. Do not mix significantly different tasks even if the implementation is very similar. Focus on necessary functionality, don't clutter common functionality with controls for infrequent tasks.
Explorative: Users don't expect they need to read a manual anymore, and they trust you their data is safe, even if they play around a bit. Be obvious, and be forgiving: give clear indications what will happen, and tolerate mis-clicks without adverse effect to your user (e.g. an undo function, or at least clear confirmations that data will now be deleted).
Consistent and Specific: Controls and features that look the same should work the same. Features that are different should look different. The principle of least surprise work here as well.

User interface paradigms that need changing?

Often times convention is one of the most important design consideration for user interface. Usually the advice goes to do it like Microsoft does.
This is for three reasons:
If it ain't broke, don't fix it.
If your users expect to click on a floppy disk icon to save, don't change the icon (even though some of them may have never seen an actual floppy disk).
Users don't want to re-learn the interface (and hot keys, etc.) with each different application they use.
At the same time Emmerson said "*A foolish consistency is the hobgoblin of little minds.*" So when does maintaining a consistent user interface cross the line from a good idea to stagnated innovation?
Microsoft shook up the good old WIMP GUI with the introduction of the tool bar, and then again with the Ribbon control (which is the natural evolution of the tool bar, like it or not.) Now we are seeing ribbons everywhere.
So my question is, what are some user interface paradigms that are accepted and consistent across multiple applications, but have stayed past their prime and are starting to reek? Are there some important changes that would benefit from a grass roots push by developers to innovate and improve the user interface experience for our users?
One thought that came to mind for me is the modal pop-up dialog. You know the ones that say: "Are you sure you want to . . .. - [Yes] [No] [Cancel] [Maybe]" and its evil twin "Successfully completed what you wanted to do! [OK]." We are seeing a movement away from these with the "info panel" in browsers. I think they need to be adopted in windows application development as well.
If possible please list a solution for each stale UI item.
And please don't list clippy. We all know he was a bad idea.
NOTE: This is specifically Windows client user interface paradigms, but I am certainly open to drawing inspiration from the web, the Mac, etc.
You mentioned popup modal dialogs , and I'd argue that non-modal ones are just as bad. Any dialog box remove focus from the program, they could end up behind the program and make it hard to find it, they might not even appear on the same virtual screen.
I'd like to see an end to all dialog boxes. If you need to stop someone from using the UI because of some non-normal circumstance, then remove the relevant parts of the UI from the window, and replace it with what the dialog would contain. Bring back the UI once the problem has been handled.
Clicking things on touch interfaces
It's incredibly difficult to click on things on a touch interface, because you don't know when you have pressed the screen hard enough. And if you add an animation to the button you are clicking, you most likely wont see it, because your finger is in the way. Adding other reactions, like vibrating the phone or painting waves on the screen might work, but there is usually a delay which is too large, much larger than the tactile sense of a button being pressed. So until they invent a screen with buttons that can be pressed, all touch devices should move towards dragging user interfaces (DUIs) instead.
Counter intuitively it is easier to press an object on the screen, drag it, and then release it than it is to just press and release it. It's probably because you can see the object moving when you start dragging, and you can adjust the pressure while dragging it. Dragging also has a lot more options, because you now have a direction, not just a point that you clicked. You can do different things if the user drags the object in different directions. Speed might also be used, as well as the point where the user releases the object. The release point is the real strength of DUIs, because it is very easy to release something, even with pixel precession.
Some designs have started to use DUIs, like (here we go) the iPhone, palm pre and android phones. But only part of their design is DUI, the rest is clicking. One area they all have in common is the keyboard. Instead of clicking on a key the user presses any key, then drags their finger towards the key they really wanted to click. Unlocking these phones also uses dragging.
Other easily implemented DUI features would be things like mouse gestures, where dragging in different directions, or drawing different shapes does different things. There are also alternate keyboards being researched which puts a bigger emphasis on dragging. All buttons can be changed into switches, so have to drag them down a bit to click them. With a well designed graphics, this should be intuitive to the user as well.
The Apple Human Interface Guidelines are a good read on this topic. They discuss this from a very broad point of view and the guidelines apply to any platform, not only Mac.
The file system. I want to save a file.. >OOOPs I need to think of a file name first. Well.... how about ... blah.doc.
6 months later...
Where the %#*(%& * did I save that %()#*()*ing file?
The solution is build a versioning system into the application, or better, the OS. Make files findable by their content, with a search engine, instead of forcing the user to come up with a memorable name, when all they want is for their file to not get lost.
Eliminate the save step. Type something in to the application, and it's just there, and there's no risk of losing it by some misstep, like forgetting to save. If you want an older version, you can just pick a date and see what the document looked like back then.
To build on the search engine idea: It's a pain having to navigate some arbitrary tree structure to find your stuff. Searching is much easier. However, you might still want to have something like a "folder" to group multiple files together. Well, you can build a richer metadata system, and have a "category" or "project" field, and setup the search engine to show items by project, or by category. Or group by those, or whatever new UI discovery we make next.
This question is a bit too open-ended, IMHO.
However, my main approach when designing anything is:
Fits in to wherever it is. If it's a windows app, I copy MS as much as a possible
It's simple.
It provides options
Buttons have a nice description of what the result of clicking will be, as opposed to 'yes or 'no'
Harder to answer the rest of your post without spending hours typing out an arguably useless (and repeated) set of guidelines.
In my mind, the one thing that really stands out is that USERS need more and easier control over the application's user interface appearance and organization.
So many interfaces can not be modified by the user so that the most used/favorite functions can be grouped together. This ability would make your favorite software even easier for you to get things done.
Error messages need a "Just do it!" button.
Seriously, I really don't care about your stupid error message, just DO WHAT I TOLD YOU TO DO!!!
I think the entire Document model of the web needs to change. It's not a user interface, but it leads to many, many bad user interfaces.
The document model was a good idea to connect a bunch of documents, but now the web is also a collection of applications. Today, I think the Page/document model corrupts our thinking. We end up lumping things together that aren't related, modularizing our code wrong, and in the end confusing users with our monolithic control board type websites.
Find dialogs that sit over the widget in which you are doing the search are terrible. Loads of apps do that. The find bar in Firefox works much better.
Many applications have multiple panes within the UI - eg in Outlook there's the preview pane and the inbox pane (amongst others). In these applications typically cursor key presses apply to the currently focussed pane. But there's very poor hinting to show the user which pane has focus and there are seldom keyboard shortcuts to move the focus between panes.
The focussed pane should be highlighted somehow.
Something like alt+cursor keys should move the focus around.
Ctrl-Tab and Ctrl-Shift-Tab cycle left and right through tabs instead of MRU behavior, even though in most cases the same behavior is duplicated with Ctrl-PageUp and Ctrl-PageDown.
There are a lot but here's an idea for a couple of them:
Remove some clicks like in "add another" or "search item" and the like.
This is well done with interfaces like ajax which have autocompletes ( and auto search ) but is slowly being adopted for platform UI's ( and in some cases they were originated in platform UI's. )
This is how StackOverflow does it for some scenarios.
But of course, we all know that already don't we? No need for "Seach tag" or "Add another tag" buttons, they just happen
Dialogs as you described.
Guys at Humanized proposed Transparent messages which actually are used in their product Enso and some other places.
Mac uses them for notifications ( like in Growl ) use them very well, or Ubuntu new notification system.
alt text http://blogs.sun.com/plamere/resource/NowPlayingGrowl.png
Firefox replaces the traditional "Search" dialog box with a search bar at the bottom.
Although not everyone likes the placement for next/previous as in this screenshot
And even SO ( again ) :) replace the notification with the yellow bar.
Finally:
File managers
I really like ( sometimes ) the simplicity of regular file managers, but some times I would like to work faster/better with them.
If you compare IE 4 with IE 8 you can tell the advance ( even better compare IE 4 with Google Chrome )
But if you compare Windows 95 Explorer with Win XP they are almost the same!! ( Win Vista/7 is a step forward )
But I wonder: Why haven't file managers improved as much as webbrowsers?
That's one reason I like stuff like QuickSilver but it is just a step. Much work is needed to create something like a "Perfect program launcher" or (FileManager/DesktopSearcher etc as you wish )
QuickSilver featuring "move to" action

Know any unobstrusive, simple GUI guidelines or design recommendations for notifications?

I'm in the process of designing and testing various ideas for an application whose main functionality will be to notify users of occurring events and offer them with a choice of actions for each.
The standard choice would be to create a queue of events showing a popup in the taskbar with the events and actions, but I want this tool to be the less intrusive and disrupting as possible.
What I'm after is a good book or papers on studies of how to maximize user productivity in these intrinsically disruptive scenarios (in other words, how to achieve the perfect degree of annoying-ness, not too much, not too little).
The user is supposedly interested in these events, they subscribe to them and can choose the actions to perform on each.
I prefer books and papers, but the usual StackOverflow wisdom is appreciated as well.
I'm after things like:
Don't use popups, use instead X
Show popups at most 3 seconds
Show them in the left corner
Use color X because it improves readability and disrupts less
That is, cognitive aspects of GUI design that would help users in such a scenario.
For notification, I prefer small notification windows in the bottom right corner. If they have a minimum UI allowing me to take some quick action, it would be ideal.
As model: incoming mail notification from Outlook, Skype notifications for incomming calls, etc.
I have read and recommend:
About Face 3
The Design of Everyday Things
I don't know of any formal articles but the Ubuntu UI design team have considered this issue and you may find something of value in their notification design guidelines or in this discussion by Mark Shuttleworth.
Sorry, no book recommendation here, just one piece of advise: Ultimately, you should let your users decide.
In my experience, what one user considers to be a useful feature is seen as completely broken by the second, while the third doesn't care at all.
Offer them 3-5 options how they will be alerted (including the option to turn alerts off ;-). Of course you should optimise these options as much as possible, hopefully some other answers here can help you with that.
A collection of possibilities:
Change a static tray icon. Useful if the user doesn't have to answer each message immediately, and relatively unobtrusive. Should be an overlay on the original image, making sure that the user recognizes which application it's from, and should be different enough that the user immediately understands that it's not the original icon (for example, a red / yellow exclamation mark on a blue / green background).
Change the tray icon to a dynamic variant. This will be more obtrusive, grabbing the user attention periodically, but is useful when the message is urgent. Could for example be a revolving version of a circular logo, or a pulsating square logo. Depending on the urgency, the animation could repeat endlessly (highly distracting) or once in a while. Use with care :)
Pop-over box in a corner of the screen. This should give some context info, the primary object of which is to enable the user to decide whether or not it's worth checking out immediately. Could afford clicking by using a "More" link or big "+" sign.
Focus the application window immediately. Enormously intrusive, and should not even be used in case of nuclear meltdowns (what if the user already knows the meltdown is occurring, and is looking elsewhere for a solution?). Just don't.
I think an answer depends highly on the specifics of the UI you are working within. However, for general guides
The GNOME desktop environment's human interface guidelines (HIG) is a useful resource if your environment is GNOME, and perhaps informative if it's not. There is a section on using the "desktop notification area": http://library.gnome.org/devel/hig-book/stable/desktop-notification-area.html.en. This covers not overloading the area, etc. (perhaps analogous to the win32 tray).
Apple have their own HIG document. Part of this describes using the Dock for conveying status information: http://developer.apple.com/documentation/userexperience/Conceptual/AppleHIGuidelines/XHIGMOSXEnvironment/XHIGMOSXEnvironment.html#//apple_ref/doc/uid/TP40002721-TPXREF139
Apple also have a separate HIG document for the iPhone. there are several notification techniques described within, e.g. "alerts" http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/ModalViews/ModalViews.html#//apple_ref/doc/uid/TP40006556-CH11-SW1 which are specifically described as to be used for critical information (due to their disruptiveness).
Several apple iphone apps adjust their icon to convey some status info: e.g. mail, SMS, phone all indicate the number of outstanding mails, SMS messages, or missed calls/voicemails as part of their launch icon. I can't, however, find any reference to that in a cursory scan of the apple iphone HIG.

Is "tip-of-the-day" good? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Many programs (often large ones, like MS Office, The GIMP, Maxthon) have a feature called "tip-of-the-day". It explains a small part of the program, like this one in Maxthon:
"You can hide/show the main menu bar by pressing Ctrl+F11"
You can usually browse through them by clicking next. And other options provided are "Previous", "Close", "Do not show at startup".
I think I like the way Maxthon used to handle this; in the browser's statusbar (down at the bottom usually, together with "Done", the progress-bar etc), there would sometimes be a small hint or tip on what else you could do with it.
As Joel Spolsky wrote in his article-series "User Interface Design for Programmers", people don't like reading manuals. But we still want them to use the program, and the features they could benefit from, don't we? Therefore, I think it is useful to have such a feature, without the annoyance of the pop-up on startup.
What do you think? Pop-up? Maxthonstyle? No way?
I really only like the idea of a "tip of the day" if it is displayed when I can't do anything else anyway. For example, when the program is loading a large file. Suppose it has to load some large amount of data when the program is first started. Along with the "loading" splash screen, show a small tip, and have it disappear when the program starts. It's simple, unobtrusive, and can sometimes be very helpful to some users.
I hate to bring up "World of Warcraft" as an example in a programming discussion, but it uses this technique when you first login. Here is an example loading screen. Along with the loading bar and a full screen piece of art, it displays a small tip at the bottom of the screen. Usually these tips lead users to things they can explore further (such as a settings window, character customization tools, etcetera). For example, "Pressing ESCAPE will bring up a menu that lets you customize the the look and feel of the game".
Above all else: allow the user to easily close the tips and stop them from appearing each time. Make every key close the tip dialog when pressed. Have two buttons: "Close Tip" and "Close Tip and Never Show Again", or something to that effect.
It must be easy to banish the tips---but when learning a new GUI, I use them often. If it's a tip at startup I usually turn it off after at most a dozen runs, but if tips are well designed this gives me a sense of the application space.
Ways tips could be improved:
Don't tip a user about a feature that user has used recently.
Making tips sensitive to context can be helpful (the new Vista bars are an example --- pause to get the vapors; I have just said something nice about Vista).
Tips that are unobtrusive or appear during otherwise wasted time are good.
Tip during loading screen is good, but it must be findable after loading is over. Some popular game, maybe it was Baldur's Gate, would give you a tip during loading, and then afterward you could go back and review the tips in your journal. So if you had a vague memory of a useful tip a few screens back, you could find it quickly, in the same place you were accustomed to look for other recent information. A 'recently tipped' item on the help menu perhaps?
Actually, I've never heard of Maxthon. But I actually like those as long as there is a checkbox to make them stop. I like the tips to actually tell me something interesting instead of something very obvious in the UI. But this is really preference. I don't think it is bad design to use them.
No - I dislike them pretty strongly. When I am starting a software application, I almost always have a specific task in mind. The TOTD just interrupts this flow and tries to get me to think about the software rather than the task.
This might not be a direct answer to your question, but personally, I like the way StackOverflow handles this. The badge system essentially acts as a manual, rewarding users for discovering and utilizing the functionality it has to offer. Granted, this isn't really an option for most apps but it works beautifully for StackOverflow.
I think this goes along with the issues against modals -- it's something in a user's way, despite how helpful it may be. Which is why the "Do not show at startup" is needed.
Though I've never used Maxthon before, the way it showed tips sounds like a really good idea. It's unobtrusive and entirely optional as to if users even have to pay them any attention.
IMO, it's not good idea to have a feature that has to ask the user if it should "keep quiet." ;)
And, while some tips can seem blatantly obvious, even these tips can still be useful to users that aren't quite as familiar. Those that already know it can just continue on with their day.
A tip is a good idea, users can discover things they didn't know they didn't know. But rather than using a pop up getting in the way of working, I like how World of Warcraft does it. They put the tip on the loading screen, when you have nothing better to do then stare at the progress bar anyway.
Norman Ramsey made some great points about how tips could be improved. My problem with tips of the day (and I'm speaking as someone who's implemented them in my own apps) is that they are not timely and a bit too intrusive. The typical tip of the day comes up when you start the program, and requires a button click to make it go away. When I actually see a useful tip, my train of thought is usually "I'll have to remember that when I do option ". Of course, it's forgotten by the time I get around to using . And clicking OK during program startup gets old fast, I'll usually disable the tips after the first dozen or so.
My suggestion would be to go the next step and make the tip of the day much more context sensitive. For example, if the program detects that the user is constantly going to Edit | Copy and then Edit | Paste, a good tip would be "Not for nothing, but CTRL+C followed by CTRL+V accomplishes the same thing" and tell them right when they are clicking away at the menu like a lost monkey, not during program startup. Oh, and don't interrupt their work by forcing them to click OK.
What I just suggested - is that what that damn paperclip dude used to do?
IMO Tip of the day (popup) is only within programs that have a certain level of complexity, that you use frequently. So when you open the program you learn a new trick that will help you.
Usually people either like it or hate it, so definitely have an option to disable it.
What I'm worried about with the other type is that it will go unnoticed, you wont believe the areas of programs people never look at.
Maybe put it in something like a "tool tip" (or down at the bottom like the OP described) and make it contextual. A few seconds after you change to a new mode it slides in some text about the current mode.
And YES make the OFF button easy to find!!!
Personally, I prefer software that’s simple enough to not need “Tip of the Day”.
Tip of the day can be good if it's
non-modal, and never in the way
has a "history" I can access
is context sensitive to what I do
Unfortunately, the crappy initial Office implementation Clippy of has completely killed the last idea.
So IMO a good implementation would:
Show up at startup
Make "don't show at startup" the obvious choice
Indicate (with an animation?) that TOTD is accessible from e.g. the toolbar
MouseOver the toolbar icon would give the title/abstract of the "current tip"
clicking on it would give me the tip, give forward/backward navigation through tips,
link to "show all tips" in the manual.
For a large tip database, a "related tips" link might encourage me to explore the manual
Context-sensitive
Later incarnations of Clippy were almost helpful actually: it was nonmodal and stayed out of the way not requiring interaction (the jumping around was attention-grabbing, though), and I remember a few instances where the suggestion was good - e.g. a keyboard shortcut for a command I had accessed repeatedly through the menu.
A simpler method could still be effective:
"Did you know... you can customize the print templates to look like a pie chart on LSD - the manual shows you how! [clickety]" on a print dialog
Did you know... I can remember your custom searches. Just click 'Goof/Barf/Hidden/Create Index for last Query' - and they'll show up in the 'Search' menu. They'll run much faster, too! whe working with a search/query form

Resources