DianeW_SteveS

__** Diane Ware **__
 * __Steve Smedsrud__**

of Use || 25 – 22.5 || 22.4 – 20 || 19 - 17.5 || 17.4 – 15 || 14 - 0 || Distinguishable || 15 – 13.5 || 13.4 – 12 || 11 – 10.5 || 10.4 – 9 || 8 - 0 || Design/ Appearance || 15 – 13.5 || 13.4 – 12 || 11 – 10.5 || 10.4 – 9 || 8 – 0 ||
 * Familiarity || 30 – 27 || 26 – 24 || 23 – 21 || 20 – 18 || 18 - 0 ||
 * || The application’s structure (title bar, menu bar, main window work area, etc.) is familiar, with user tools, such as radio buttons and drop down lists, working as expected. || Most of the application’s user tools work as expected. || Some of the application’s user tools work as expected. || One or two of the user tools work as expected. || None of the user tools work as expected ||
 * Ease
 * || Application is easy for the user to use. Errors or mistakes are readily fixed. Cues are available on buttons, controls/links, etc., to guide user. Each part of application is consistent in usage. Similar items are grouped together, such as in tabs. || Application is somewhat easy to use. Errors or mistakes usually can be fixed. Cues are not always available to guide the user. Most parts of the application are consistent in usage. Most similar items are grouped together. || Application can be tricky to use. Errors or mistakes sometimes are fixed. The user gets lost at times. Some parts of the application work the same, others do not. Some similar items are grouped, others are not. || Application is hard to use. Errors or mistakes can’t be fixed. The user has a hard time navigating around the application. Few of the parts of the app work the same. Few similar items are grouped. || None of the previously mentioned ease of use items are fulfilled. ||
 * Distinction/
 * || The user is able to distinguish readily certain items on the interface. Important buttons or other items are noticed readily. Buttons, labels, etc. are labeled correctly, definitively so user has no doubt of what item does. Icons match their usage. Interface language is user-friendly, not “geek speak”. || The user can mostly distinguish readily items on the interface. Important buttons or other items are mostly easy to find. Most buttons, labels, etc. are labeled correctly. Most icons match their usage. Most interface language is user-friendly. || The user sometimes cannot distinguish between interface items. Important buttons or other items sometimes are hard to find. Some buttons, labels, etc are labeled correctly. Some icons match their usage. Some interface language is user friendly. || Few of the previously mentioned points are present. || None of the previously mentioned points are present. ||
 * Color/
 * || Interface contrast is just the right balance – not too sharp, not too dull. Words/sentences are easily readable against background. User can adjust interface settings preferences. Interface works well, but looks good too. Default interface colors easy on the eye. || Interface contrast is somewhat balanced. Words/sentences are usually readable against the background. User can mostly adjust interface settings preferences. Interface works good, looks okay. Default interface colors okay. || Interface contrast is a little hard on the eyes. Some words/sentences are readable against the background. Some interface settings preferences are adjustable. Interface looks better than it works. Default interface colors somewhat harsh on eye. || Interface contrast is hard on the eyes. Many of the words/sentences hard to read against background. Few interface settings preferences are adjustable. Default interface colors hard on the eyes. || None of the previously mentioned points are present. ||
 * Recall || 10 – 9 || 8.9 – 8 || 7.9 – 7 || 6.9 – 6 || 5.9 – 0 ||
 * || The interface remembers all of the previous settings of the user, such as files opened previously, adjustable window frame sizes, font sizes, etc., so user’s settings ready to go for next time. || The interface remembers on most of the previous settings. || The interface remembers some of the previous settings. || The interface remembers few of the previous settings. || The interface remembers none of the previous settings. ||
 * Global Usage || 5 – 4.5 || 4.45 – 4 || 3.95 – 3.5 || 3.45 – 3 || 2.95 - 0 ||
 * || The interface is setup so people of other cultures can use the interface without too much difficulty. || The interface is mostly setup so people of other cultures can use the interface without too much difficulty. || The interface is somewhat setup so people of other cultures can use the interface without too much difficulty. || The interface is setup only slightly so people of other cultures can use the interface without too much difficulty. || The interface is NOT setup so people of other cultures can use the interface without too much difficulty. ||

**I. Overview** The rationale for spending time and effort to design an interface for the user is based upon the savings acquired from the organization designing the interface and the benefits for the user. When time and effort are used efficiently to design an interface, this will enable the organization to save the extra costs involved to redo the interface at a later time. This involves researching the best means to design the interface before it is actually created. Not only are savings obtained from the organization, but profits are obtained as well, if the interface is researched beforehand. If an interface is designed with the user in mind, and not designed according to the team within the organization, then it is highly likely that the user will be quite happy with the application’s interface. The user will feel comfortable with the interface. The user will be able to use the interface without too much trouble. This will result in the user wanting to use the application regularly and will probably also result in the user deciding to purchase further products from the organization. The remainder of this document will discuss the necessary guidelines and practices that will help design an interface that is best for the user and best for the organization that is designing the interface.

**II. 6 Critical Principles to Consider In User Interface Design and Rubric**
Presented below are six guidelines. These guidelines should be used to help the application developer design an interface that will be very acceptable to the user.

**1. Familiarity**

Although it is probably an application developer’s main quest, to design an original interface, full of many high-tech ideas and gadgets, this does not, however, typically translate into a usable interface for the end-user. Most end-users have at least some computer experience, which, nowadays, is most likely with a graphical user interface. And so with this in mind, an application developer should realize that most computer users have had experience with Windows operating system-type interfaces. Pictured below is a Microsoft Windows WordPad document. This is the general structure for most modern application interfaces.

And so this general structure should be maintained, so that the user feels comfortable and familiar with the interface. The user will have far less trouble using the interface in this case. And the user’s other applications, placed on the operating system’s “desktop” at the same time, will function similarly to the interface, and so the user can move back and forth between applications and will not have to be burdened by knowing differences in major functionality.

Additionally, the interface’s tools should function as expected. For example, radio buttons should work as expected, scroll bars should work as expected, check boxes should work as expected, etc. And keyboard controls, mnemonics, and other controls should work as expected.

Here is an example of an application, the QuickTime 4.0 Player  , which was released in June 1999. The developers of this application were looking to create an application that appeared very similar to a real world object. All the buttons on the player were supposed to work as an actual hand-held music player.



The developers erred in this matter, as can be seen immediately, since this interface does not resemble the WordPad interface, shown above. Although at first glance a user could quickly figure out the location of the play button, the pause button, and the volume control button, how does the user save a song? How does the user open a new song? How does the user change the size or the viewing window of the player? Can the player be minimized to allow room on the computer desktop for accessing other applications? None of these questions can be answered promptly, since the interface doesn’t resemble the WordPad interface – no menu bar and no standard tool bar can be accessed, where the user could find clues or direct answers to these questions.

And here is an example, taken from the August 1999 edition of the  //Visual Basic Programmer's Journal 101 Tech Tips for VB Developers, // of controls being used in an irregular manner to how they are typically used:

Normally, radio buttons are used when only one option is to be selected from a group of items. But in this case, the  //Visual Basic Programmer's Journal recommended changing the code of check boxes so that they function as radio buttons. But this would be quite confusing to the typical user, who has grown accustomed to using radio buttons for this purpose. This is not recommended. //


 * 2. Ease of Use **

The application interface should also be designed so that the end-user can use the application without going to the help documentation provided by the application (which should be provided, this is also necessary in the completed application).

Here is an example of an interface design that could be difficult for the user from the Interface Hall of Shame under Terminology, the author shows a part of the CSE HTML Validator v3.05 interface:

As the author mentions, how can a user tell which flags are for which purpose? Which flag checks for tags specific to Internet Explorer? Which flag checks for tags specific to Netscape Navigator? Which flag displays a warning against the use of the  tags? Which flag controls whether sound is played during validation? What does Flag 14 do?

The author gives the answers for each question, and then shows a far better way to make this particular part of the interface more user-friendly: For example, notice that the author uses Internet Explorer Specific, as a check box, whereas in the original form, Flag 1 is specific to Internet Explorer. But how could the user tell this just by looking at all the flag check boxes? The numbers next to the check boxes are meaningless.

In particular, for this Ease of Use category, the user should be able to cancel errors or mistakes readily, without causing the entire application to crash or having to start a new project with the application. Little cues should be available for the user, such as buttons should appear enabled or disabled, menu options/links should be grayed-out if not available of darkened if available, etc. Also, keyboard mnemonics should work as usual, and more should be available too, if the application has new buttons or tool bar items for the application’s precise needs. This is also mentioned in the Familiarity section above. And keys on the keyboard should function as usual.

Below is an example of the tab key on the keyboard not functioning as expected in a part of this application: This was taken from Unisyn’s Automate Pro. The developers of this interface did not allow the tab key to work as typical. In the image above, the small numbers indicate how the tab key navigates through the text fields and buttons. Normally, you would expect the For Date: text field to be the first tab key spot, and the For Time: to be the second tab key spot, and so on.

Consistency should be taking place too – each part of the application interface should work similarly, so if a particular print button in one part of the interface prints to the screen, then if this button appears again, such as in another tab of the interface, it should do the same here again, so the user is not confused or frustrated. Finally, similar interface items should be grouped together, especially if tabs are used. For instance, if one tab contains a group of formatting options for a text document, then another tab could have a group of color options for the text document. This is better than grouping both the formatting options and the color options in one tab.

Here is an example of an interface failing to have consistency in different parts of the interface: The above screen shot of the IBM’s AudioStation, a CD-player application, shows a list of CD Tracks on the left side, and a Playlist on the right side. This was obtained from the Interface Hall of Shame, under the Controls page. The author of this page noted that double-clicking on a song in the Track List will cause the song to be copied to the Playlist. Yet, double-clicking on a song in the Playlist will not remove the song from there. And whereas the Track List supports extended multiple selections, the user can select only a single song at a time from the Playlist. This is not consistent.

The author also noted some other troubles with IBM’s AudioStation: 1. Command buttons placed at the top of the window rather than at the bottom (violates Familiarity). 2. The Add button is the only control that has a mnemonic access character (violates Ease of Use and Familiarity). 3. The Add button only works when the Track list has focus, but is not disabled otherwise (violates Ease of Use and Familiarity). 4. 3D fond decreases readability (violates Color/Design/Appearance).


 * 3. Distinction/Distinguishable **

The end-user should be able to distinguish readily certain items on the interface. If something is important enough for the user to use, the developer should make certain the user can notice it. A very important button? Make it of an adequate size and place it where the user can see it promptly. Also make sure button, labels, etc. are labeled correctly, definitively, so the user has no doubt of what a button or text box does/needs. Icons should also match the purpose they’re being used for.

Here is an example of a button that is hard to distinguish within the application’s interface: This example is from IBM’s ReadCD application. As is noted in the Interface Hall of Shame page describing the above, the background and the button are very similar in color, so it is hard to clearly distinguish the button. This apparently is the reason IBM’s developers placed “Click here to put book away” next to the button, so the user could notice the button. Possibly a better idea would have been to design the button larger, a different color, and labeled “put book away” on the button.

Below is an example of buttons that don’t adequately describe their use and possibly are redundant: The dialog is displayed when a user attempts to exit from XFM, the Linux X-windows File Manager. Quoted from the []page, are these pertinent yet slightly funny questions:

The designer of this dialog could have been more specific. Why not instead of “Continue” did the designer “Yes”? And instead of “Cancel”, why not “No”. And as mentioned on the web page link stated above, what is the difference between “Cancel” and “Abort”? There may be a precise difference, but it is not readily apparent on the surface to the user.
 * Does "Continue" mean "continue using XFM" or "continue to exit"?
 * Is "Cancel" somehow different from "Abort"?
 * Isn't it about time someone complained about this?

An application interface should also attempt to have the language of the overall interface be compatible with the user’s knowledge and language. Using language more familiar with the developer, often amusingly known as “geek speak”, is not going to be appreciated or found useful for the end-user, especially if the end-user has limited computer science knowledge. In other words, instead of using “this will overload the memory”, use “this will cause the program so stop working”. Below is an example of this: This image was again taken from the Interface Hall of Shame. This is a screen shot of the Database menu item form Woodworkers Estimate Helper. The program is designed for woodworkers and cabinet makers and it could probably be assumed that most of these workers have limited knowledge of “geek speak”. The use of the words “Database”, “Records”, and the message “Key Validation Error” that can appear at times could have been replaced with words more understandable to woodworkers and cabinet makers. Most likely these workers will become frustrated with this interface, as will their employers eventually, and this application will not be sought after, purchased for new editions. Not a good idea for a developer interested in generating profits.


 * 4. Color/Design/Appearance **

The color scheme, the overall design, and the appearance of an interface are very important to application’s interface as well. The contrast should be just the right balance – not too sharp, and not too dull. Words and sentences should be readable; that is, it wouldn’t be advisable to place yellow fonts against a white background, for instance.

Here is an example of text that is difficult for the user to read:

This is was taken from []linked from the Interface Hall of Shame. The author of this site obtained the above from a tutorial released to members of a very large organization. As can be noted, it is difficult to read. Both the fonts of the letters and the contrast of the white and yellow letters against the light aqua background make it difficult to read.

The user should also be able to adjust the settings/colors so as to accommodate the user’s own preferences of the application. This is especially important if the user has chosen to change the operating system’s interface color and contrast settings – the application’s interface should be compatible in this regard.

And here is another example of text in an interface that is difficult to read, and violates the user’s preferred display preferences: The above is a screen shot from a tutorial for Pirates: Quest for the seas. As mentioned at the site, []the tutorial ignores the user’s display preferences and uses hard-coded colors. This is probably quite frustrating for the user. And the yellow font against the green background could be hard on certain users’s eyes. And what if a user is color-blind? Will yellow against green yet be readable to such an individual?

As is stated by some in the application interface design industry, “Looking Good” over “Working Well” should not be one of the goals when designing the interface. The goals should be centered on what the user will appreciate. It should also be remembered that the default colors of the interface should be easy on the eye; the design should not be too harsh.


 * 5. Recall **

Interfaces should remember the settings that the user used previously – such as files that were already opened from the last time, the size of the window should be recalled, font usage, etc. so that the user’s settings are ready to go for the next time.

Here is an example that illustrates this, taken once more from the Interface Hall of Shame site, in particular the page on Interface Stupidity: Please keep in mind this information is from older versions of Microsoft Windows. As the author of this site lamented, normally a Microsoft Word document is never opened in Microsoft’s WordPad. However, whenever a user wants to open a WordPad document, Microsoft assumes that the document should be opened with Word. This is annoying for users. The author of this site also mentions that WordPad doesn’t recall the last files types used. For instance, if (*.txt) for text files is used the last time in WordPad, the File Open dialog should default to text documents when opened once again. But this does not occur. This, again, is annoying and frustrating for users. A user would like to be able to resume their former user parameters once the application interface is opened once again.


 * 6. Global Usage **

Is the interface set up so that people of other cultures/nationalities can use the interface without too much difficulty? This can be quite important.

Below is an example of an application that makes it difficult for people of other languages to understand the application interface: The above screen shot is from PMC for Windows 2.3, a complex application for automating industrial maintenance management. It is actually available in several languages, but only for the main part of the application interface. The user interface for installation of the program is not available in different languages, only the English language. This is a great hinderance to users of other languages.

Another example of an application interface not practicing global usage is below: Most address text fields in application interfaces are designed only to accept addresses from the United States. If a form with text fields employs edit-checking, and the user attempting to enter an address hails from another country, then the address entered could be different from the standard US address. In Interface Hall of Shame, within the Globalization page, a fictitious name of someone from Norway is given:

Ola Nordmann Brattøret 8 1352 Kolsås Norway

If this address were entered into text fields employing self-editing, errors would occur, particularly in regards to the state field or the address field. The author of the article recommends a form of text fields such as is shown below, which would enable the user to enter his or her address in its own structure:
 * III. New Developments in UI Design **

After doing some searching on the Internet, three interesting and innovative interface designs are listed and described below.

1. Smart Technologies.

Smart Technologies produces interactive white boards: The projection camera placed above and in front of the whiteboard projects an image of a typical OS GUI desktop onto the whiteboard. The user then can interact with this whiteboard similar to a touch screen computer. No mouse is used.

Although a little hard to see in this small picture, the tray at the bottom front of the whiteboard, called the Smart Board Pen Tray, holds four plastic pen tools and an eraser. These devices do not actually interact with the whiteboard similarly to a mouse, but it is their absence in the tray that produces a response by the Smart Board. When, for instance, a blue colored pen tool is removed from the tray, an optical sensor recognizes its absence from the tray. The Smart Board software will process the next contact with the interactive whiteboard surface as a pen action. So using the pen or a finger will produce a blue line on the board. The pen tool itself is not the actual producer of the line. The Smart Board uses very similar software, such as from Windows or Mac OS’s so those application interfaces, such as Microsoft Paint, functions the same. The only difference is the input device. So the critique of this interface would be the same as for those applications. And if those applications follow the six guidelines mentioned above, then all is well.


 * Part B **

Microsoft Word is a word processor designed by Microsoft. It was first released in 1983 under the name Multi-Tool Word for Xenix systems. Subsequent versions were later written for several other platforms (see the time line chart below). In 1981, Microsoft hired Charles Simonyi and Richard Brodie the primary developers of Bravo, the first GUI word processor. Simonyi and Brodie started work on a word processor called //Multi-Tool Word//. Microsoft announced Multi-Tool Word for MS-DOS in 1983 and renamed it //Microsoft Word//. Free demonstration copies of the application were bundled with the November 1983 issue of PC World, making it the first program to be distributed on-disk with a magazine.

Over the next 5 years Microsoft revamped and released 6 revisions to its Word program, which was not much of a seller because of WordPerfect’s much advanced interface, yet with the revisions Microsoft would soon had a contender for the word processing market. Below is a versions and timeline release outline which include releases for other than PC based OS.


 * Versions for **__Microsoft Windows__** include the following: **


 * **Year Released** ||  **Name**  ||  **Version**  ||  **Comments**  ||
 * 1989 || Word for Windows 1.0 || 1.0 || code-named [|Opus] ||
 * 1990 || Word for Windows 1.1 || 1.1 || code-named [|Bill the Cat] ||
 * 1990 || Word for Windows 1.1a || 1.1a || for Windows 3.1 ||
 * 1991 || Word for Windows 2.0 || 2.0 || code-named [|Spaceman Spiff] ||
 * 1993 || Word for Windows 6.0 || 6.0 || code-named T3 (renumbered 6 to bring Windows version numbering in line with that of DOS version, Macintosh version and also [|WordPerfect], the main competing word processor at the time; also a 32-bit version for [|Windows NT]only) ||
 * 1995 || Word 95 || 7.0 || included in [|Office 95] ||
 * 1997 || Word 97 || 8.0 || included in [|Office 97] ||
 * 1998 || Word 98 || 8.5 || only sold as part of [|Office 97]Powered By Word 98, which was only available in Japan and Korea ||
 * 1999 || Word 2000 || 9.0 || included in [|Office 2000] ||
 * 2001 || Word 2002 || 10.0 || included in [|Office XP] ||
 * 2003 || Office Word 2003 || 11.0 || included in [|Office 2003] ||
 * 2006 || Office Word 2007 || 12.0 || * included in [|Office 2007]; released to businesses on November 30, 2006, released worldwide to consumers on January 30, 2007
 * can run on Linux using Wine[|[85]] ||
 * 2010 || Word 2010 || 14.0 || included in [|Office 2010] ||

//Note: Version number 13 was skipped due to// [|//superstition//]//.//
 * Versions for the **[|**Macintosh**]** (Mac OS and Mac OS X) include the following: **


 * **Year Released** ||  **Name**  ||  **Comments**  ||
 * 1985 || Word 1 ||  ||
 * 1987 || Word 3 ||  ||
 * 1989 || Word 4 || part of Office 1.0 and 1.5 ||
 * 1991 || Word 5 || * part of Office 3.0
 * requires System 6.0.2, 512 KB of RAM (1 MB for 5.1, 2 MB to use spell check and thesaurus), 6.5 MB available hard drive space[|[9]]
 * last version to support 68000-based Macs[|[9]] ||
 * 1992 || Word 5.1 || part of Office 3.0 ||
 * 1993 || Word 6 || * part of Office 4.2
 * shares code and user interface with Word for Windows 6
 * requires System 7.0, 4 MB of RAM (8 MB recommended), at least 10 MB available hard drive space, 68020 CPU[|[9]] ||
 * 1998 || Word 98 || * part of [|Office 98 Macintosh Edition]
 * requires PowerPC-based Mac ||
 * 2000 || Word 2001 || * part of [|Microsoft Office 2001]
 * last version compatible with [|Mac OS] ||
 * 2001 || Word v. X || * part of [|Office v. X]
 * first version for [|Mac OS X]only ||
 * 2004 || Word 2004 || part of [|Office 2004] ||
 * 2008 || Word 2008 || part of [|Office 2008] ||
 * 2010 || Word 2011 || part of [|Office 2011] ||
 * Versions for **[|**MS-DOS**]


 * **Year Released** ||  **Name**  ||  **Comments**  ||
 * 1983 || Word 1 ||  ||
 * 1985 || Word 2 ||  ||
 * 1986 || Word 3 ||  ||
 * 1987 || Word 4 ||  ||
 * 1989 || Word 5 ||  ||
 * 1991 || Word 5.1 ||  ||
 * 1991 || Word 5.5 || first DOS version to use a Windows-like user interface ||
 * 1993 || Word 6.0 ||  ||


 * Versions for the **[|**Atari ST**]**: **


 * **Year Released** ||  **Name**  ||  **Comments**  ||
 * 1988 || Microsoft Write || a conversion of Microsoft Word 1.05 for Mac ||


 * Versions for **[|**OS/2**]** include the following: **


 * **Year Released** ||  **Name**  ||  **Comments**  ||
 * 1992 || Microsoft Word for OS/2 version 1.1B ||  ||
 * 1992 || Microsoft Word for OS/2 version 1.1B ||  ||

Word at 1983 (a screenshot of [|Microsoft Word 5.0] graphic interface (1983) under MS-DOS):

[|Microsoft Word 1.0] for Macintosh (1983):

[|Microsoft Word 5.1a] for Macintosh (1985 German language format below) and the English version next page:

Microsoft Word 1.0 for Windows (1989):

Microsoft Word 5.5 (1991 for MS-DOS):

Microsoft Word 2.0 for Windows:

Microsoft Word 6.0 for Windows (1994):

Microsoft Word 97 for Windows (1996):

Reference List:

1. []

2. []

3. []

4. []

5. []

6. []

7. []

8. []

9. []

10. []

11. []

12. []

13. []

14. []

15. []

16. []

17. []