Student projects/Usability issues/T7

Principles for Usable Design

Usefulness

• Value: The system should provide necessary utilities and address the real needs of users.
• Relevance: The information and functions provided to the user should be relevant to the user's task and context.

Consistency

Consistency and standards

Follow appropriate standards/conventions for the platform and the suite of products. Within an application (or a suite of applications), make sure that actions, terminology, and commands are used consistently:

Colours and icons

Colours have meanings at Moodle: (e.g. yellow means question mark). Icons can be checked at /server/moodle/pix in order to be consistent and don't use two different icons for the same meaning or one icon for two different meanings.

Upload image/file

Several guidelines should be followed:

1. It should be considered the two types of uploading categories [Student_projects/Usability_issues/Upload#Conclusion File Repository API].
2. Order is also important (the most logical order is name, size, modified and rename) and the files should be able to be ordered by every field.
3. All possibilities in which it could be possible to upload files should be considered. Examples are: 1. grading system, 2. making comments, 3. adding an entry of an activity, 4. in the description of the activity, 5. importing all the information of the activity module
4. Usually there are two locations to upload files: C:\server\moodledata\2\moddata\activitymodule (it is used when students should upload files/images for the assignment / exercise or other module activity) and C:\server\moodledata\2 (for storing other images associated to an activity module but do not constitute the main issue in the activity)
5. The grading accessed through the Grades section of the Administrator menu should be the same, and allow the same functionality, that the one accessed from the view of the activity module.

How to enrol/unenrol users

There is a standard about how to do so.

Tab keyborard

The use is from up to down and from left to right generally. However there are some exceptions that happen when there are too many icons before the item that usually users want to access.

Tab guidelines

Several guidelines mentioned in Jakob Nielsen's Website should be followed:

1. Alternate between views within the same context.
2. It logically chunks the content behind the tabs so users can easily predict what they'll find when they select a given tab. (Card sorting is one option for researching this "mini-IA" problem. If you don't find clearly distinct groupings, then tabs are likely the wrong interface control for managing your content.)
3. Users don't need to simultaneously see content from multiple tabs.
4. The tabs are roughly parallel in nature.
5. The currently selected tab is highlighted. This is a really important feature that has not been implemented in Moodle tabs.
6. The unselected tabs are clearly visible and readable.
7. The current tab is connected to the content area, just as it would be if we were shuffling several physical index cards that had tabs stuck to them.
8. The labels are short and use plain language, rather than made-up terms.
9. The labels in the rightmost example above use Title-Style Capitalization: each word's first letter is uppercased.
10. There's only one row of tabs.
11. The row of tabs is on top of the panel — not on the sides or the bottom where users would often overlook them.
12. The scope controlled by the tabs should be obvious from the visual design.
13. Fast response time ensures that clicking a new tab immediately brings the corresponding panel to the front. This is probably achieved through AJAX, but the programming technique is not important. What is important is to make the action fast enough (ideally <0.1 s) that people feel there's a physical connection between their mouse click and the appearance of the chosen panel.

Submit button at bottom, at top, or both

1. Site Administration: the pages there are short and it makes more sense to put the submit button at the bottom. Usually they are in the settings page and in order to change an option you must read through all of them to find the one you need to change. Moreover the pages that need to have links repeated at the bottom and at the top (such as Accounts > Browse list of users) already have the links repeated.
2. Administration of a course: here it makes more sense to have the submit option both at both ends because it is a mechanical job, the pages are long, and perhaps you know by heart the default configuration so what you want to do is save time. An example that has been changed is the backup functionality. Perhaps you want to backup the whole content of a course (which is the default configuration) so you don't have to scroll down all pages and you save time. This is the case for settings, grade preferences, edit course, backup and override permissions in course.
3. Administration of a course with short pages: there are some pages which are short and does not make sense to have all buttons duplicated. This is for example the case for Groups. Having buttons at both sides can make the page more confusing and less usable.

Hide / show a resource

There is a set of policies that would allow users to know what they are doing and help developers to code it:

1. The icon displays the current value, but if you put the mouse over the icon, the description is about the value to be implemented.
2. When hoving the mouse over the show / hide icon, it should say "hide this week for students", not just hide. The whole information about the hiding must be displayed.
3. When you show / enable something, the colour of the description should turn black or dark blue. If you hide / disable something, the colour of the description should turn into grey or light blue.
4. Recommendation: it would be more standard and usable to change the visible / hide icon for a textbox "view" and a stand-alone checkbox in order to select if it's visible or not, at list in the tables where icons are not necessary because there is enough space.

Grading

There are two grading types:

1. Type of grading 1: Includes the gradebook and quick grading that would have the following fields: Information about the user and time, Grade, Feedback, excluded, hidden, hidden until, locked, locked after, feedback, format, html format (that is all the information of the gradebook and the quickgrading).
2. Type of grading 2: Used in the Forum rating, you can grade (often you chose the grade with a select box) and a link to the first type of grading.

Metacourses functionalities

In general module activities should have group modes, visibility and category functionalities

Information architecture

When thinking about an information architecture, several steps must be followed: getting an idea of what the user wants, comparing to other sofware the user is familiar to, asking to the forum and making a usability test and making some architecture information test. As mentioned in Nielsen website, there are several ways to improve information architecture:

1. Merge the two sections
2. Rename the two existing sections
3. Explain the two choices
4. Restructure the site
5. Move information around
6. Add cross-reference links

Shortcuts at Moodle

Shortcuts are sometimes a good solution to save time for example the CTRL-Enter functionality for save, upload or submit buttons.

Help at Moodle

When adding some help it would be extremely useful to:

1. Add a short sentence to describe what he/she could find in the help file.
2. Make a summary of the content of the help icon. Not all users have the same knowledge of Moodle and it can happen that novices are annoyed because it is too difficult for them, while advanced moodle users don't find all the information they need. To this end it would be important to make a short help paragraph for starters and a detailed description with advanced functionalities and a detailed help for users with experience.
3. Make a demo; this would be really valuable mostly for novices. It will be useful that the demo is accompanied by a tutorial with some screenshots such as the gradebook tutorial. There are several places where users can view demos which are not exclusive: Moodle Docs page of the demo, tutorial page, in the pop up of the help menu, to a new popup that opens when clicking the video help icon (which would be next to the help icon) To implement it, there are several solutions:

• An always-ready program that instantly captures and shares images and video from your computer to anywhere: To add the video and audio to the web application it would be possible to add JW FLV MEDIA PLAYER and moreover there is a plugin of JW for mediawiki. It must be considered that the only request to implement this is that the user should have flash installed.
• Youtube or Metacafe
• Moodletutorials was specifically designed for hosting video demos. You could then link to the video from Moodle docs.

Previous consistency errors

• Editing: Words “Edit” and “Update” both used to mean the same thing. “Update” meaning can be ambiguous. Universal change to “edit” as “update” can refer to updating system/saving/refreshing
• Resources selection from activities area on topic page: Users looking into available (uploaded) course resources from this link in the activities box are not given any indication about what type of document is being listed. Add the accepted descriptive icon beside the name of listed resources (e.g. Word, folder, PDF).
• Resource entry: When you enter the resource screen, there is space for a resource summary but this sometimes (though not always) appears with the resource icon and name on the topics page where you are placing the resources link – depends on resource type. Consistently add resource summary to topic section where linked, but allow it to be edited out easily.

Real-world conventions

Use commonly understood concepts, terms and metaphors, follow real-world conventions (when appropriate), and present information in a natural and logical order (e.g. ISO/IEC 11581 Icon symbols and functions).

Simplicity

• Simplicity: Reduce clutter and eliminate any unnecessary or irrelevant elements.
• Visibility: Keep the most commonly used options for a task visible (and the other options easily accessible).
• Self-evidency: Design a system to be usable without instruction by the appropriate target user of the system: if appropriate, by a member of the general public or by a user who has the appropriate subject-matter knowledge but no prior experience with the system. Display data in a manner that is clear and obvious to the appropriate user.

Communication

• Feedback: Provide appropriate, clear, and timely feedback to the user so that he sees the results of his actions and knows what is going on with the system.
• Structure: Use organization to reinforce meaning. Put related things together, and keep unrelated things separate.
• Sequencing: Organize groups of actions with a beginning, middle, and end, so that users know where they are, when they are done, and have the satisfaction of accomplishment.
• Help and documentation: Ensure that any instructions are concise and focused on supporting the user's task.

Error Prevention and Handling

• Forgiveness: Allow reasonable variations in input. Prevent the user from making serious errors whenever possible, and ask for user confirmation before allowing a potentially destructive action.
• Error recovery: Provide clear, plain-language messages to describe the problem and suggest a solution to help users recover from any errors.
• Undo and redo: Provide "emergency exits" to allow users to abandon an unwanted action. The ability to reverse actions relieves anxiety and encourages user exploration of unfamiliar options.

Efficiency

• Efficacy: (For frequent use) Accommodate a user’s continuous advancement in knowledge and skill. Do not impede efficient use by a skilled, experienced user.
• Shortcuts: (For frequent use) Allow experienced users to work more quickly by providing abbreviations, function keys, macros, or other accelerators, and allowing customization or tailoring of frequent actions.
• User control: (For experienced users) Make users the initiators of actions rather than the responders to increase the users’ sense that they are in charge of the system.

Workload Reduction

• Supportive automation: Make the user’s work easier, simpler, faster, or more fun. Automate unwanted workload.
• Reduce memory load: Keep displays brief and simple, consolidate and summarize data, and present new information with meaningful aids to interpretation. Do not require the user to remember information. Allow recognition rather than recall.
• Free cognitive resources for high-level tasks: Eliminate mental calculations, estimations, comparisons, and unnecessary thinking. Reduce uncertainty.

Usability Judgment

• It depends: There will often be tradeoffs involved in design, and the situation, sound judgment, experience should guide how those tradeoffs are weighed.
• A foolish consistency...: There are times when it makes sense to bend or violate some of the principles or guidelines, but make sure that the violation is intentional and appropriate.

Note: this information was extracted of the page General guidelines and adapted to be used for Moodle developers.