Obviously a subjective question but I figure this site has built up a multinational audience so hopefully there will be some good insight.
The option I am thinking of going with is a combo box with flag images to indicate which language you want to view your application.
Pros
Everyone recognizes images so you don't have to worry about somebody not being able to select the language of choice because they don't understand what the box is for.
Combo Box supports many (as many as will fit on the page or more if has scrolling capability) using limited screen real estate.
Cons
It may not be obvious to everyone using the application that this is the way to select the language of choice.
The flag chosen to represent the language might offend speakers of that language from another country whose flag was not chosen (Which country's flag do you use for English, Spanish, Portuquese, etc.)
Another option is to use a combo box where each language is represented in its own language so speakers of that language will recognize their language in the drop down.
I am writing this for a desktop application and was curious as to whether a consensus standard has arisen either on the Web or Desktop world that most people "get".
The right answer for me is the control that most user's immediately understand the intended purpose and how to use the control.
My vote: combobox with a list of language name and then dialect in parenthesis.
For example, to list Portuguese:
English (UK)
English (US)
português (Brazil)
português (Portugal)
Language name comes first and alphabetized and written in the native language, that way it will be easiest to find. Name of dialect second so that all the dialects will be together alphbetically, making it easy to see if, for example, there is both UK and US English or just one of them. Little flags sometimes help but sometimes just add clutter.
Another thing: Let the user select language at install time. It must be the first thing that he sees. The Nullsoft installer does this well. Expecting the user to naviagte menus like Tools->Options->Configuration->International->Language in a foreign language is unacceptable!
Never assume that you can glean language from regional settings! Often Windows is configured for the local currency even though the user doesn't speak the language.
Kudos for recognizing that each language should be written in its own language! Often I see a list of languages, all written in some foreign language, and I can't tell which one to pick.
Another option is to use a combo box where each language is represented in its own language so speakers of that language will recognize their language in the drop down.
That's a fairly common practice, and it makes good sense.
Next to the flag, put "Language" and don't localize it. Nearly everyone who is familiar with changing languages in software knows what that means, and having the flag next to it will get the rest :)
This is not an easy problem. The flag idea works fairly well, but I need to train myself to look for the Union Jack. Depending on the application, I might want the Stars and Stripes instead because there is a difference between British English and American. It can get tricky if you try to overload too much meaning onto the flag. For instance, what language is meant by the Swiss flag. Or what if I only speak Spanish, but want the application to use US date and time formats. And don't even think about what will happen if you localize into Chinese. (Example: do you have a Taiwanese flag or not?)
I tend to prefer the languages written out. It gives you a lot of flexibility to specify exactly what language is meant. In addition, you can have a bit of fun sometimes. Facebook has a Pirate English option which is good for a few laughs. Google has even more fun interface language choices. And everyone who needs the Español option will know what it means.
I personally prefer a smart app that makes its best to detect to detect my language. Of course, a languages submenu tight either to a menu item (such Preferences/Language/) or a toolbar button (image is a world icon) must be there somewhere to let user override the automated choice. But in most cases, they shouldn't have to think about it.
Important: The submenu (or combobox, whatever) should contain native language names. That way, users always find their language.
Flags are not such a good idea IMO: Very small flag icons are not very distinctive. Plus it's easier to find a language name rather than a flag. And flags are related to countries, which is not quite the same as language: Some of your English users might not like a US flag that much.
Depending on the technology you use, you might find my codeproject article interesting:
http://www.codeproject.com/KB/locale/LanguageMenu.aspx
Related
I researched a lot on this and seem to be getting conflicting answers on SO and all of the web. I understand that with Section 508 that compliance DOES NOT equal accessibility.
Biggest thing is that the UI/UX designer is being told that keyboard shortcuts for the dropdown menu NEEDS to have keyboard shortcuts to be 508 compliant. I see Windows Forms applications having this, but for web development I do not think that is mandatory to be "compliant"
My other question that was answered is here: MVC 4 site 508 compliant
I partially agree with thinice, but agree with the first two sentences of the comment left.
The sentences I am referring to are:
They should be -reachable- by keyboard for 508. I'm maintaining emphasis on the difference between a shortcut and being reachable
Crixus said:
Biggest thing is that the UI/UX designer is being told that keyboard shortcuts for the dropdown menu NEEDS to have keyboard shortcuts to be 508 compliant.
You need to clarify this. Do you mean a simple <select> or a drop down for a navigation menu? As Thinice stated in comments, Section 508 just says needs to be reachable. The question becomes:
how are you adding shortcut keys to your application? Are you adding them via the accesskeys attribute or how Gmail/Yahoo Mail adds shortcut keys?
I thought I did an answer about AccessKeys, but cannot find it. Essentially accesskeys sounds like a great thing, but if you look at the keys you are allowed to use that do not interfere with either browser or Assistive Technology keys, you are quite limited. Gez Lemon did an overview of AccessKeys, and their issues. If you want to do the Yahoo!Mail approach, you have to do a bit more work. Todd Kloots made a presentation about ARIA, which may be helpful. Which leads me into the second part. If you are using JavaScript heavily on a site to do stuff, people use both 1194.21 (software application/OS) and 1194.22 (web) standards to evaluate a site. If the site uses JS to make a navmenu (YUI menu example), the drop down behavior needs to be reachable by keyboard. I would say this falls under:
§ 1194.21 Software applications and operating systems.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where the function itself or the result of performing a function can be discerned textually.
AND
(c) A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes. The focus shall be programmatically exposed so that assistive technology can track focus and focus changes.
I say both standards are used because (a) says you have to be able to get into the navigation area via the keyboard. (c) comes into play because some menus you can tab to all of the parent items, but you cannot get into the drop down part without a mouse. I have seen menus that you can tab to the sub-menu items, but the menu does not pop open. So if you just use the keyboard (mobility imparments), versus using JAWS, you will have no idea where you are.
I see Windows Forms applications having this, but for web development I do not think that is mandatory to be "compliant"
I would say actual applications, like Word, Outlook, etc., supply shortcuts to frequently used commands. If you are doing this for a web application, I would think about how many you do. This is not a mandatory piece to be compliant. If you are making like a navigation bar, I would recommend using ARIA roles, specifically role="navigation", on the parent element as a best practise.
The problem with some standards (as well as many laws) are that they're open to interpretation...
The only mention I can find in the 508 standards that mentions keyboard use is this (verbatim):
Subpart B -- Technical Standards
§ 1194.21 Software applications and operating systems.
(a) When software is designed to run on a system that has a keyboard, product functions shall be executable from a keyboard where
the function itself or the result of performing a function can be
discerned textually.
My spin on this is:
A keyboard shortcut for navigation options may be impractical given the amount of operations/features a given section may contain. It is important that they're reachable -somehow- via keyboard.
From a UX standpoint, key features should have shortcuts "just because" it's good UX practice. But to shortcut everything goes from one ditch into the other.
508 != accessibility, but if you work for a gov/edu, chances are it's in your PD to be compliant.
Another end of the spectrum is the WCAG which is pretty much coupled with 508 compliance, and in my book better defined: Keyboard stuff is under 'operable' in WCAG.
In a nutshell:
It's good practice for UX to have custom keyboard shortcuts for important features. But has no bearing on 508 compliance by itself. (With exception that functionality should be reachable by keyboard -somehow-).
There are levels of 508 compliance, if you're talking about a government project. Some departments assign 508 scores to their developers, and it factors into your score for future contracts. 508 Compliance only requires that everything is reachable by keyboard, which is usually true, in a way. Screen readers will read everything that's not hidden, and tab keys will take people through links. But if you want a good score, you must address the intent and not only the letter of the law.
Edit: Screen readers will read some hidden elements. One method is to absolutely position an item above the screen with a negative top position. Another is to use the clip property.
http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content/
But if you're using display:none, heights of zero, and javascript toggles, many screen readers will not speak these items.
In the case of a drop-down, you are actively hiding elements from screen readers etc, so you do have to fix it, because most readers won't hear things with display:none.
You will not find definitive documentation on keyboard navigation. The reason no one will specify exactly what to do, is that there are so many potential conflicts - with the browser, the OS, etc. There are also no standards, although Aria is making progress:
http://www.w3.org/TR/wai-aria-practices/#keyboard
I would not put accessKeys on a menu, if that's what you meant.
Instead see: http://www.w3.org/TR/wai-aria-practices/#aria_ex_widget
I would save actual accessKeys for major things like 'Search' and 'Home'. Adding a learning curve to your site wouldn't help the cause, if you had an accessKey for everything. If you put for example, "About Us" accessKey=A, and you had 20 accessKeys assigned to letters, it would be bad.
I've been doing 508 sites for a long time, and personally, I just don't use drop-downs. It's far simpler to add subpage menus. And I personally hate clicking on dropdowns. Dropdowns require a precision in clicking that just irritates me, and doesn't help with accessibility, because remember accessibility also includes people who don't click very well. Plus, dropdowns are limited in the number of levels you can have, not technically but from a UX view.
What I use:
Tab indexes.
Carefully placed menus so that a user won't get a huge list of links before hearing the basic idea of the site or page.
On some projects, tree menus with matching arrow-key page navigation, sequentially.
Accesskeys H for home and S for search, if needed.
The problem especially is in sorting information. Think how quickly you scan a long list of links, and then imagine sitting there and waiting for it to be read to you. Perhaps, organize your content into digestible pieces & let the search box do the scanning. Depends on the content.
Luck. :)
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.
I'm rebuilding a language selection interface for a multi-national website, and I'm beginning to think it might be better for usability to use a simple form drop down rather than the custom JavaScript drop down menu that they're currently using. Am I way off base here, or should I go with my instinct? What do you think?
Simple drop down has its advantages. When you let the browser decide what to do, instead of forcing it to do what you want via JS, then browsers for unique circumstances (such as mobile devices) will format the drop down as its native selector.
If the custom js menu provides no additional functionality then definitely go with the basic select menu. However, if there's a good reason to use the custom menu, consider implementing it in a way that uses progressive enhancement so you can be sure it provides the basic functionality for everyone and adds features for browsers that can support it.
Any user who reaches the page for setting languages, comes with a specific aim in mind. He already knows what language he wants to set here (just as in most forms people know what they want to fill in for their birth date).
For this reason, I would recommend a text box with autocomplete functionality. Here are the advantages:
a text-box with a type-ahead works much better than a dropdown in most cases when the user knows what his options are
a dropdown with searching for "R" functionality doesn't always work the same way for all browsers, and not all browsers implement searching for "RUS...." and beyond.
from a purely is-this-usable standpoint, the type-ahead will prove to be far more useful over time.
I wouldn't use a drop down for countries - they are cumbersome to use when the number of items are large (https://ux.stackexchange.com/questions/31738/what-is-the-maximum-recommended-number-of-item-to-put-in-a-drop-down-list).
The "start typing a letter" to jump directly to say Russia when pressing R is a great feature in drop down lists - although I suspect that this is a power user feature - one that a lot of users will be unaware of (basically because it's a hidden feature).
Check out this solution instead -
http://uxdesign.smashingmagazine.com/2011/11/10/redesigning-the-country-selector/
Cheers
We have an enterprise web application where every bit of text in the system is localised to the user's browser's culture setting.
So far we have only supported English, American (similar but mis-spelt ;-) and French (for the Canadian Gov't - app in English or French depending on user preference). During development we also had some European languages in mind like Dutch and German that tend to concatenate words into very long ones.
We're currently investigating support for eastern languages: Chinese, Japanese, and so on. I understand that these use phonetic input converted to written characters. How does that work on the web? Do the same events fire while inputs and textareas are being edited (we're quite Ajax heavy).
What conventions do users of these top-down languages expect online?
What effect does their dual-input (phonetic typing + conversion) have on web controls?
With RTL languages like Arabic do users expect the entire interface to be mirrored? For instance should things like OK/Cancel buttons be swapped and on the left?
As an Arabic speaker, when I do look at Arabic websites, I do expect things like OK/Cancel to be swapped.
When reading Arabic, my eyes read from right to left. So, in situations where you'd want to reader to view an affirmative/action button (e.g. OK, Submit, Yes, etc.) before a negative/inaction button (Cancel, Clear, No, etc.), you'd probably want to put the former on the right.
Caveat: As weird as it sounds, the above only applies (to me personally) when the button text is in Arabic. If the button text is in English (in a mixed-language web page), I'd prefer to see the OK button on the left.
Hope that helps.
Read Globalization Step-by-Step by Microsoft.
I can answer the specifics on CJKV, but you probably want a book on this topic. I haven't read it but CJKV Information Processing is from O'Reilly (2nd ed due Dec, 2008).
I understand that these use phonetic input converted to written characters.
How does that work on the web?
The input is done by a class of software called an IME (Input Method Editor) on Windows, Mac, and Linux (e.g. SCIM). When an IME is turned on, the input from the keyboard first goes to the IME, and the user gets to pick the correct kanji/hiragana combo. When the user commits by hitting return key, the IME types in the kanji/hiragana into the web browser using the current encoding. Encoding situation was a big mess, but if you are writing a web app, go with an encoding of Unicode. I suggest UTF-8.
Do the same events fire while inputs and textareas are being edited?
A Unicode savvy web browser and OS combo handles multiple languages. For example, one can use English normal version of Firefox to browse and post to a Japanese website. From the browsers point of view, it's just an array of "bla bla bla" in Unicode. In other words, if the event fires up in English, the same event should fire up in CJKV if you use a Unicode variant.
What conventions do users of these top-down languages expect online?
CJKV readers expect left-to-right online. Math and science textbooks are written from left-to-right. Most word processors, including localized version of Word, write left-to-right.
What effect does their dual-input (phonetic typing + conversion) have on web controls?
For the most part you should not have to worry about it, unless you are trapping keyboard events. For example, I hate using Japanese keyboard with bunch of extra keyboard. So, when I have to assign IME on/off command to some key on US keyboard. I personally use right-Alt. Also, spacebar and enter key is used during conversion, but not sure if these events are passed to browser.
The directionality question is easy to answer for East Asian languages: websites are left-to-right, top-to-bottom as per usual.
In fact, the general web design layout principles much the same. Have a look at the websites of a newspaper (name top left, navigation bar under with "Home" on the left, headline links below with most important at the top) or a search engine (don't think I need to say which US site you should compare that layout to).
However, just as Arabic/Hebrew/etc right-to-left language users will expect left-to-right progression in some contexts (embedded English fragments and so on), there are situations, even on the web, where top-to-bottom layout is preferred. This is generally done by including an image with the text layout and font desired, or using flash.
Internet Explorer has actually offered tb-rl layout with the CSS writing-mode property since version 5.5 however none of the other browsers have bothered implementing it (or ruby, which is useful for sites aimed at a young audience). IE 5.5 was released in 2000, so that's eight years of support, and there was a W3C candidate recommendation in 2003 but text layout in CSS still being poked around.
As for your worries with text input and IMEs, as long as you're not doing something bogus like trying to manually translate the virtual keys given by keydown events into text strings, you're unlikely to run into problems.
There are some additional issues you've not mentioned however. The minimum comfortably readable font size is larger than for languages written with the Latin script. Bold and italic for emphasis in flow are generally not appropriate. Han unification means to need to be picky about specifying the right fonts for the different CJK languages when working with unicode. You may want to provide both traditional and simplified interfaces for Chinese, depending on what audience you are expecting.
I've been meaning to write up a more comprehensive guide along these lines for a while, if you need more information feel free to kick me.
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.