SSW Rules to Better Interfaces

1. Do you know to use Popup forms?

   Some people like popup forms. Some do not.

   Popup modal forms are no good:

   • as you can’t read or edit something else in a window behind
   • as they take a lot of time to load in a browser (ask any CRM 4 user)

   Popup forms are good:

   • as it is obvious you have an action step to perform before continuing
   • as they simplify a form that has lots of fields
   • if they can’t get lost behind another window
   • if you make them clear by dimming the background (see below)

   

   Bad example: if this was a popup form it would be easier to focus on where to look (as a minimum you would be looking at half the screen)

   

   Good example: the popup with the dimmed background is much more intuitive

2. Do you realize that a good interface should not require instructions?

   The corner stone of good user interface design is that if your users need instructions, you haven't done a good job. Of course with particularly complex applications there will be exceptions to this rule, but all developers should aim to make your designs as self evident as possible.

   

   Figure: A good interface does not need instructions!

3. Do you realize that when it comes to interface design 'less is more'?

   How to make a user interface great:

   • Less is more - keep your design as simple and uncluttered as possible
   • Understand the importance of Defaults - Aim for 'Next', 'Next', 'Next'
   • Hide advanced options, but make them easy to find!

   Most developers think about user interface last. They spend their time worrying about class design, threading, and system architecture. All this is important, of course. But the user only experiences software on the surface level. It might be fantastic under the covers, but if the user interface is not intuitive the user will think the application is just hopeless. If the user interface doesn't afford an easy and simple understanding of how to operate the application, you'll get a lot of unhappy customers and unnecessary support calls. Do yourself a favor, take some time to think about UI first.

   

   Figure: Bad Example - An example of a poor UI

   

   Figure: Good Example - See the fly? (an example of excellent usability) Dutch manufacturers realized that a fly painted on the porcelain of a urinal nearly always became a "target" for men using the facility. And the fly is positioned in precisely the right place for minimal spillage or splash back. Clever people those Dutch!

   

   Figure: Good Example - iPhone has probably the best known UI for mobiles

4. Do you make the homepage a portal?

   Do you put useful current information on the homepage? Do you make it easy to use your core functions?

   E.g. Top billing customers for the month and a button under it for adding an invoice

   E.g. See the number of bugs counted by the most common

   

   Figure: The homepage of TWA is a portal.

   

   Figure: Adobe's Creative Suite also opens a portal 'homepage'.

5. Do you know how to make message boxes user friendly?

   Message boxes should have consistent and informative titles and descriptions, and icons should be used appropriately.

   Title
   The title should contain the application name, so the user knows what application generated the warning/error. This is especially important when developing add-ins (e.g. Outlook add-ins or Smart Tags) as it can be difficult to know what caused the message box to pop up. Application.ProductName and Application.ProductVersion should be used to retrieve the data from AssemblyInfo. There is no need for the title to contain a brief description of the error because that information is readily available in the message box itself.

   

   Figure: Bad Example - Title contains brief description of error, which is already contained in the message box

   

   Figure: Good Example - Title contains Product Name ("SSW eXtreme Emails!") and Product Version ("12.56")

   We have a program called SSW Code Auditor to check for this rule. Note: The Version Number in the title should only contain the Major and the Minor version numbers (e.g. 11.28) and not the complete Major.Minor.Revision.Build Numbers (e.g. 11.28.92.1198)

   
   

   Description
   The description should explain what the error was, followed by the why it occurred. Information that is useful for debugging should be included with errors where possible in a "Details" section. You should also avoid making the text unnecessarily wide. e.g.

   

   Figure: Bad Example - A message box that does not intuitively alert the user

   • This is confusing, because it uses different terminology to the title ("estimate" instead of "quote")
   • There is no punctuation
   • The word "Error" is meaningless
   • Line breaks are not present, so the message box is too wide and the text may wrap in the wrong spot

   

   Figure: Good Example - A message box that is clear, consistent and intuitive

   • Terminology is consistent
   • Punctuation is present
   • "Details" indicates that this information is useful for debugging
   • The text is split across three lines, and the technical information after Details is separated from the description of the error.

   Icon
   Including an icon is important because not only does it give the user a visual indication of the type of message, but without it only the Default beep sound is used. The icon should reflect the type of information being presented:

   Icon	Name	When to use
   	MessageBoxIcon.Information	Non-error information, e.g. Database connection test completed successfully.
   	MessageBoxIcon.Warning	A non-critical error, e.g. The input was invalid.
   	MessageBoxIcon.Error	Critical error in the program, e.g. Program file was not found
   	MessageBoxIcon.Question	NEVER use this.  According to Microsoft, the Question mark is being phased out, as any of the other three: Error, Warning or Information can easily be reworded into a Question, and Question does not show the user the severity of the issue that has just occurred. E.g.  If you want to ask the user whether they want to save a file before closing, you should use the Warning Icon.

   
   

   We have a program called SSW Code Auditor to check for this rule.

6. Do you avoid giving an Error message for validation purposes?

   If you do a search and no matches are found display a message indicating zero results were returned rather than an error message.

   

   Figure: Bad Example - No matches found on searching is not an "Error"

   However, a user thinks that either:

   1. They have done something wrong (i.e. they are incompetent) OR
   2. The software is broken (i.e. your application is incompetent)

   Forcing the user into this opinion is a good way to make them avoid using your software in the future.

   Instead, use the term Information" when validation is required.

   

   Figure: Good Example - Only use "Error" when appropriate

7. Do you use messages that are concise and informative?

   It is important to use terminology that your users will understand. Do not to use technical terms that may confuse your users. Use consistent words and phrasing for similar situations. For example, the following phrases have the same meaning which is the best one?

   • Not enough memory.
   • There is not enough memory.
   • There is not enough free memory.
   • Insufficient memory.
   • No memory was available.
   • Your computer does not have sufficient memory.
   • Memory resource is not enough.
   • Ran out of memory.
   • You may be out of memory.

   Microsoft uses this one:

   

   Figure: Good Example - Microsoft error message is concise

   Some other message types that Microsoft uses are:

   Message type	Sample message
   Not enough disk space	There is not enough disk space to complete the operation. Delete some unneeded files on your hard disk, and then try again.
   File not found	The program cannot find the file filename.
   Re-running setup	The filename file is missing. Run Setup again to reinstall the missing file. For more information about running Setup, press F1.

   Consider using or adapting them in your application in similar scenarios. Only include the information that the user needs and will understand.

8. Do you make login state clear?

   Make login state clear to help the user know the current state.

   

   Figure: Bad Example - Logged in state - web form.

   

   Figure: Bad Example - Logged in state - win form.

   

   Figure: Good Example - Logged in state - web form.

   

   Figure: Good Example - Logged in state - win form.

   

   Figure: Good Example - Logged off state - web form.

9. Do you log usage?

   So you can see what functions are being used more often (e.g. reports, menu items)

   Plus, you can work out what fields to show on search pages (standard and advanced tabs) and which parameters are being used.

10. Do you make your data easy to search?

    

    Good example: search box makes it easy to find data

11. Do you avoid using message boxes?

    There is nothing quite as annoying as persistent pop up message boxes, demanding your attention.

    Only use them in the following scenarios:

    • Confirming the deletion of a record
    • Kicking off a long running process

12. Do you know there are specific rules for different interfaces?

    Read the specific rules below:

    • Windows Applications
    • Reports, Charts and Dates
    • Wizards
    • Data Controls
    • Data Entry Forms
    • Mobile UI

Links

• http://www.asktog.com/basics/firstPrinciples.html
• http://msdn.microsoft.com/library/Default.asp?url=/library/en-us/dnwue/html/ch09f.asp

Acknowledgements

Adam Cogan
Edward Forgacs
David Klein