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.