SE401:33:Heuristic Evaluation

Ten Usability Heuristics

Jakob Nielsons' 10 Usability Heuristics will be used to evaluate our current system.

We will be evaluating what we have added to the system, not the base components

These are ten general principles for user interface design.

They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

• Any changes to the html document are shown immediately as the user makes them.
• Mashup elements are displayed in the right side of the application, the user can edit or delete the elements from there.

- Some elements are not displayed in the html e.g. imported RSS feeds.

• Advanced users are able to switch between html source and html preview and edit both views (views are consistent).

- JavaScript code is commented out and uncommented when the document is saved - the user is not told this.

• JavaScript elements are represented with dummy code (image placeholders with correct dimensions).
• When the user does one of the following operations they are informed through pop-up boxes.

- Blank fields for required element attributes.

- Illegal characters in element names.

- Duplicate mashup element names.

- Invalid size dimensions.

• Potential mistakes that are not identified.

- Google or Yahoo! Map keys.

- Valid RSS URLs (that they are RSS feeds, not webpages).

- YouTube URLs.

• User is notified through dialog boxes when there is a problem loading from a RSS feed.

- Some URLs are corrected (missing http:// is valid).

- Invalid URL - Instantly.

- Connection timeout - 5 seconds.

• Formatting RSS feeds does not show modifications.

- Removing locations only alerts user to the number of entries deleted.

- Removed entries are temporarily printed to the console

- Approximating locations only alerts user to the number of possible fixes.

- Changes are temporarily printed to the console

Match between system and the real world

The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms.

Follow real-world conventions, making information appear in a natural and logical order.

• RSS Feeds

- Naming an element is a common action.

- Users are expected to know basic computer terms e.g. URL

• Formatting RSS Feeds

- Naming an element is a common action.

- Tool tips are provided to further explain dialog box fields

- The term 'format' may not be understood by some users.

- Selecting an RSS feed is intuitive.

- Format for may not be obvious what it is for until the user tries it a few times.

• Format for Google Maps

- Adding city/country may not be correctly understood as appending.

- Preview format shows the user what the add city/country will do.

- The city/country textfields are toogled by the check box to aid the users connection between the two.

- Optimising may not be understood exactly what that means.

- Removing possible invalid entries is self explanatory.

- Approximating locations does not guarantee fix all the invalid entries but users may think it does.

• Google Maps

- Naming an element is a common action.

- Tool tips are provided to further explain dialog box fields.

- Key is needed for the map to work on the users website, they need to already understand this.

- Selecting an RSS feed to mash with the Google Map may be illogical with feeds that contain no address data.

• Yahoo! Maps

- Naming an element is a common action.

- Tool tips are provided to further explain dialog box fields

- Application ID is needed and and the user must sign up for this, the ID will only work with the URL.

- Selecting an RSS feed to mash with the Yahoo Map may be illogical with feeds that contain no address data.

• YouTube

- Naming an element is a common action.

- Entering URL should be obvious for users with some Internet experience

User control and freedom

Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state

without having to go through an extended dialogue. Support undo and redo.

• Undo/Redo support is supported by base but:

- Mashup elements can be undone but are not removed from sidebar.

- Can cause program to crash.

- Redo seems to work.

- Deleting mashup elements works better for undoing elements.

- Deleting a mashup element and undoing the delete replaces code but not actual object in sidebar (causes problems).

- Editing dialogs are provided for mashup elements to make changes instead of using undo.

Consistency and standards

Users should not have to wonder whether different words, situations, or actions mean the same thing.

Follow platform conventions.

• Mashup elements follow HTML naming conventions where possible.

- "width" and "height" used for defining map sizes

- "key" and "id" used for defining map keys and ids

- "URL" is a commonly used Internet term

- "name" isn't an HTML term but it has a unambiguous meaning in real life.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place.

Either eliminate error-prone conditions or check for them and present users with a confirmation option before

they commit to the action.

• Dialog entry errors

- Blank fields are checked where needed and user is alerted before action commits.

- Invalid characters are checked where needed.

- Duplicate element names are checked.

- Alphabetic text in width and height field are checked (only allow numerical).

• URL fetching

- Invalid URLs are tested on submit and if invalid an error message is displayed before action commits.

- YouTube URLs are not checked for validity.

- RSS feeds are not checked for RSS data (ie. XML document with correct tags).

• User can break code for JavaScript mashup elements by inserting anything before it.

Recognition rather than recall

Minimize the user's memory load by making objects, actions, and options visible.

The user should not have to remember information from one part of the dialogue to another.

Instructions for use of the system should be visible or easily retrievable whenever appropriate.

• Only tooltips provided to help user. No help documentation.
• Preview of RSS formatting when adding city/country helps user see what will happen.
• No information is needed to be remembered between dialog boxes.
• Tooltips provided for toolbar icons to help user remember meaning.
• Mashup elements are shown on the sidebar to show the user what they have created.

- Mashup element editing boxes provided to remind user what attributes they assigned to each.

Flexibility and efficiency of use

Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user

such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

• View source toggle allows the user to switch between HTML preview and HTML source code.

- Provided by the base program, but still useful to view mashup elements commented code (the final code).

- Target users of application was more towards novice users.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed.

Every extra unit of information in a dialogue competes with the relevant units of information and diminishes

their relative visibility.

• RSS feed and YouTube dialogs are kept very simple.

- No irrelevant information.

• Google and Yahoo Maps slightly more complicated

- Width and Height are not essential attributes to display but useful for editing.

• Formatting RSS is more complicated than rest.

- Multiple dialog boxes for different formats.

- Initial dialog simple and no irrelevant info.

- Google Map formatting is more complex but no irrelevant info.

Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem,

and constructively suggest a solution.

• General dialog box error messages inform the user of their mistake

- Blank field errors do not specify what fields were left blank.

- Duplicate name errors tell the user what the name was and that it already exists, and to select a new name.

- Illegal character errors tell the user of the name they used, the illegal characters, and to select a new name.

- Invalid dimension errors (either non-numerical or negative) tell the user that the size was invalid, but does not specify why.

• RSS fetching errors displays the reason why it failed

- "Invalid URL" should be enough information to explain why it failed.

- "Unable to connect to server" may not be enough information for novice users. They may think their URL is wrong.

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide

help and documentation. Any such information should be easy to search, focused on the user's task,

list concrete steps to be carried out, and not be too large.

• No documentation exists for our system.

◄ Back