Note:

If you want to create a new page for developers, you should create it on the Moodle Developer Resource site.

Usability/Improve Moodle User Experience Consistency/Notes from UI inspection

From MoodleDocs
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

This is a page to jot down notes while studying the different aspects of the Moodle UI. The outputs of processing this page will be:

  • Items to usability test (and from these, potential UI guidelines)
  • UI guidelines
    • Bugs in tracker where violations are found
  • New usability projects

Moodle style

Moodle-specific (more or less)

Moodle hierarchy

Page types

Guideline: Page_structure_and_types

In addition to the main heading of the page, the header also has another area for content defined. Depending on the page, the content of this area is either a nevigation menu or the user login info. hmmm: why does it depend on the theme what functionality there is on a page? What sense does it make to make it easier to logout on some pages and harder on some others, do you really think you can predict when users want to navigate and when they want to logout?

  • Areas: Main title area: MTA-L MTA-R, breadcrumb area BC-L BC-R, left column, content, right column, footer
  • All pages: Main title (course name), breadbrumb; Navi 2.0: update this modulename leaving?at bottom: Moodle docs for this page; You are logged in as ...; BUTTON to go to Turn to link or menu or sthone level up (?) in Moodle hierarchy
  • Module page: jump navigation with next/prev, module-specific controls (update this modulename)glossary: Import entries / Export entries Printer-friendly version ;forum: subscripthion permission status, force everyone to be subscribed (->button), show/edit subscriptions, subscribe (->button) often tabbed
  • Moodle front page, Course page: login info + logout, role switching, editing mode switch, left and right columns for blocks
  • Settings page: Login info (=no jump navi, not even in module config, contrary to module page)

Data listings

  • functionality: moving elements in a list (reordering), moving elements between lists
  • gradebook: clicking on column titles to highlight the column
  • tables vs. lists vs. divs with complex data
  • alternating colours for rows: in general it is a good idea and helps to guide the eye better than just a table grid. There should be a contrast in luminosity of the rows (just alternating hue might not be enough), to make sure also colorblind people can see the difference. Also if some rows/colours can be selected, changing their background colour again, this might have to be rethought.
  • filtering selection lists [https://tracker.moodle.org/browse/MDL-17780 MDL-17780] [https://tracker.moodle.org/browse/MDL-19285 MDL-19285][1]
data tables
  • settings tables: Override permissions
  • selection/link tables: Override permissions, Locally assigned roles
  • Data tables, for example Using Moodle p127: minus icons , vertical centering, user profile picture as a column of its own

Tooltips

  • on static elements (icons without link/action)

Big Select List

Issues: Icon for advanced items, default values

Hierarchy browsing list

left one is list of containers, right one shows contents (roles UI: http://test.moodle.org/head/group/index.php?id=2&group=7)

Jump menu (course page, module page) Make more findable: visually navigation menu and not dropdown, context-sensitive title

Dropdown command menus

(popup_form())

(gradebook)-> YUI dialogs where possible

Course jump navigation with next/prevs

Help system: popups, wiki popupsinline/tooltip-popup

Forms

See Forms

Intermediary pages after form submission

Moodle elements common to the web

Tabs

Make subtabs look like tabs

even though users are already accustomed to the fact that tabs are not used in as a regular fashion as was originally thought, tabs in the same tab bar should still have some common denominators. Document these, compare with other HIGs an interesting deviation from the standard tabs visual design

Breadcrumb

Recommendations: always show the module directory (listing all the activities of the module in the course, for example, all quizzes in the course)

Search: expand!

Do not hide the search button (SE1)

Always provide search button. This is required for accessibility and helps identify the functionality of the text field.

think about the items you need to index (for example, in forum, include not only the text of postings but also titles and author names)


participants block & searching for users, browse users under Site Admin, use the filter on the top with advanced option, in participants block, the search option is at the bottom and is just for name, in message it is in a separate tab → find consistency (anthony)

Javascript dialogs;

layout, title bars visuals

Embeddable tools

equation editor, drawing tool, rich text editor, audio player, audio recorder, video player (?)

Visual consistency!

Wizards: installation, backup

DONE: Wizard

* Back/Next (which preserve the data entered by users in other screens) and Cancel buttons must be on every screen with progress meter showing the active steps and the number of steps left.

Switches/toggles/Modal buttons

Guideline: Switch Button

'buttons that have an on/off state: show the command to change or the current status

According to the strictest rules of form element usage, everything should ideally be done with radio buttons and a submit button to confirm the selection. However, this is very clumsy.

track/subscribe a forum: button saying yes/no in the forums listing of a course VS link saying "Subscribe to this forum"/"Unsubscribe from this forum" or "Track unread posts"/"Don't track unread posts"

show/hide controls (eye icon/button): should it reflect the current status or the status after pushing? one idea is to have a button-style control with pressed/non-pressed visual status (thanks to Hans de Zwart)

In profile, enable/disable e-mail (2.0)

http://tracker.moodle.org/browse/MDL-3994

examples of alternative solutions

Help

Tooltips

tooltips: if it has a tooltip, signal that with something visually. If it is clickable, the tooltip should describe the action clicking results in.

  • the only tooltip for a help icon can be something along the lines of “show help” (this also applies to info/warning icons and the like). Users may assume from the cursor shape that something that has a help icon is clickable and then won't wait for the tooltip before clicking since what the clickable item does is not unclear: it should show the help.
  • if an icon shows the type of an item, it should not be clickable (since it is not actionable) and should have a tooltip to describe the type
Inline tips

TODO: there is a lot of inline help in Using Moodle that could be included in Moodle.

MDL-19570

p.69 forums: they can draft and rewrite

p.98 what effect does group mode have in quiz

p. 123 offline assignments as reminders

p. 76 uin your syllabus, let students know how often you intend to respond to questions and posts (anecdote from jason)

p.77 make expectations for student conduct clear

quiz capabilities explanations, ex. p.116

p.116 manual grading only possible for essay q's → show in tab title

  • p.36 paw
  • p.s30 paws

p.38 adding media content add resource → media → RIGHT SORT OF LINK

p. 21 meta course paw

inline helps

Moodle 2.0 forum: Mail now → by default this forum sends out an e-mail 30 minutes after you have posted it, to allow you time to make changes, to everyone who has subscribed this forum. If you are sure you are not going to want to change it, check “Mail now”.

Any current popup help that is in any form that only explains a meaning of a term or an option briefly

  • p.86 even if you've set chat times, the chat is always open to students (why? Another option?)
new help files

Parts from Using Moodle:

dependencies: 97 quiz adaptive mode vs. apply penalties ?

p. 88 creative chat practices

p.114 the same question will never appear twice in an attempt ...

p. 118 UI

p. 50 users must have an account on your moodle site before you can assign them a role


file repository: tell the user if they can't upload any new files BEFORE they have already searched them

Editing modes

  • Editing modes: inline editing (course frontpage) vs. editor (quiz)
  • Reordering items: course page vs quiz edit

Direct editing: summary, number of weeks/topics, hidden sections

at the top of each section you'll see a hand holding a pencil: summary text for course section


edit modes: facebook-style? (but we need to be capable of moving items from a week to another...)


tabs: do not confuse editing with content? (on the other hand, everybody has gotten used to it?) → editing application in tab vs tab as editing mode


Marginal elements/styles

  • Bottom-rounded boxes
  • Everything centered by default
  • Grey rounded boxes for listings?
  • "See this post in context"
  • separate lists of links?
  • single item of something: forum posting visual style, attachment in upper right corner
  • Role overrides: the permissions the role currently has are highlighted in white https://docs.moodle.org/en/Image:OverridePermissionsBasic.png
  • with text fields: format selection (Moodle auto-format, Plain text format, HTML format, Markdown format)
  • grading table with funny scrolling
  • quiz hideable window

Consistent web style

Links/buttons

Moved: Button, Link

  • back links: roles ui at the bottom of each tab
  • buttons for actions, links for navigation. Issues: G3c, T1c, C1c
  • Button: Used for actions – user selections that change the state of the application (i.e. usually database or moodle_data files) – always use a button. If creating a form and a submit button is not feasible, use the link:<button> element or as a last option a link that is masqueraded as a button with CSS (arrow cursor, box shape, no underline, black text [or theme default colour]). Examples: Save a form, start a preview (enters the user into a preview mode), the commands of course edit mode
  • But like facebook seems to do it now (2009-05) to remove clutter, sometimes when an element is clearly a command, it may be okay to make it look like a button only after the user hovers over it.
  • Link: Navigation. In general, every action that just takes the user on a new page and does not change the state of the application is navigating: enter configuration screen, change tab, view a module (such as an assignment).
  • general guidelines of using buttons for commands/actions (non-bookmarkable POST or AJAX request -> not in URL) and links for navigation/location (GET request -> shows also in URL)
    • VS what is usually done in Moodle
      • In profile, clicking (this e-mail address is disabled) does not explain it but just removes the link! (Apparently fixed for 2.0 but raises another issue of changing status of a setting with an icon)
  • http://natbat.net/2009/Jun/10/styling-buttons-as-links/ - is the only UI difference that reloading (and browser history otherwise) works badly with POST? (this can be fixed with a HTTP redirect)
    • (08:22:26 AM) timhunt: Olli, the real reason for the difference between GET and POST comes when you think about web caches, or clicking reload in the browser, or, getting more technical, REST web services. (08:23:18 AM) timhunt: A POST does something, and should not be repeated, or served from a cache, without careful thought. A GET, that just pulls information, can safely be served from a cache, or repeated.
    • in general, use links for navigation and buttons for actions. But this is a thin line: if you have an action (say, take a course) but want the user to go to the course page to join (why are there no "info for outsiders" course pages?), you could have a link that looks like a button, or a link that says "more info". If you see a need to stray from this, please consult the usability forum.'
    • A button is like a promise that something will happen, so buttons should not be used for navigation since that fails user expectations. When there is a link users can expect it to make sense to open it in a new tab, for instance. On the other hand, there are situations where users want to open “actions” such as search in new windows, since for them they are navigation and not commands.

Buttons vs. Links http://msdn.microsoft.com/en-us/library/aa511454.aspx

links: http://msdn.microsoft.com/en-us/library/aa511483.aspx

http://discuss.joelonsoftware.com/default.asp?design.4.403046.4

Page titles → page types

in general, links should have titles the same as their target pages: what is the current situation with this?


Make sure every page has them; make context-specific

Update [modulename]

Really needs to be called settings/options unless there is an excuse not to

Paradigm shifts / new elements

Inline help (tooltip/inline)

See Help

Progress bar

Whenever there is a process going on (such as installation) where at the moment we are just pushing further parts of the page to the browser as something progresses, have a progress bar of some kind, enabling users to predict how long it will take. (Sometimes prediction is impossible but it still helps giving users a sense that there is a finite number of items to complete)

Confirmation dialogs: Replace with undo (gmail-style) or add ajax dialog

hover sections, hideable sections

  • Find discussion of the usability of facebook/wordpress. Is this style protected by copyright/patent?
  • Publish the suggestion

General recommendations / design advice

Consistency of feedback

from any and all user actions; normal and error situations; recovery

Design Instead of Options

already covered in Usability#Don.27t_automatically_suggest_a_new_preference

add no new features unless there is a clear user need (-> joelonsoftware:moving menu bars). Context: you are designing new functionality to Moodle (an application). You know the goals of your users.While designing, you come to think of new functionality that someone might need. solution: unless you can find users whose goals the functionality would help meet AND those users are your core target personas, don't add it. Consider creating an optional module or an entirely new application with the new functionality to see if there is aseparate user group that would prefer that functionality instead of the original application.

  • avoid making an option
  • if you have to,
    • form
    • hidden form
    • toggle (status+button, command button?, dropdown?, clickable status icon?)
    • button

TODO: check original project document to see if something there is missing from here related to this

Communicate dependencies

consistency: dependencies; proximate (configuration options in the same module) vs vertical (hierarchy; sth higher or lower in hierarchy affects this role/setting/OtherThing)

  • communicate dependencies: if the functionality of an element (form element/feature/module) depends on or changes as a result of the state of another element (configuration setting), communicate this in the UI either by changing the UI accordingly (for example, by disabling the form elements in question) or if that is not feasible, by telling this in writing in the UI.
    • what are the default capabilities for each role in a given context
    • dependencies between options s.97 quiz adaptive mode vs. apply penalties
      • s.89 messaging: is messaging enabled?
      • s.22 every activity in the course will have that group mode set → visible in modules?
    • Is the dependency status shown in both the course settings and in each activity?If you’ve not forced the group mode in your course settings, you can set it for each activity, either when adding the activity (in the common module settings), or by clicking the group mode icon opposite the activity name when editing is turned on for your course page. The group mode icon toggles between the three possible group modes shown in Table 4-1.
    • edit modes vs view/normal/student modes; which change affects which users, what is visible to which users? quiz preview, course front page
    • → yellow info boxes for metainformation that is visible only to the current user for example in preview: metainfo boxes; Q1cprogressive disclosure
    • modality in UI?

Visual hierarchy

Moved to Major_usability_issues_in_Moodle#Visual_hierarchy

Note: This is not graphic design as such, but usage of UI elements in a way that communicates their relationships clearly, facilitating users' preconscious scanning of the UI to make sense of it quickly: more information: [5]

How to turn this into a guideline? Perhaps if we define certain page types several moodle pages would fit in then most pages would have some common factors. Then again, this also risks restricting design too much.


(11:06:14) Olli (pilpi): one big issue is visual hierarchy of screens, i.e. even if there is not as much content on a screen as there was in the old quiz editing UI, in many places there seems to be no organization of the content, and as things are centered by default understanding the structure of some pages can be pretty bothersome - instead of "letting your eyes do the work", you have to really think about what is where

(11:06:43) Olli (pilpi): that is already better

(11:07:10) Tim Hunt: Is that on your list of things to write about?

(11:08:13) Olli (pilpi): yes, but I think I will have to talk to julian or someone about it since I am not sure how to make it a guideline. it includes things like usage of headings and those funny grey partially rounded boxes

(11:08:38) Tim Hunt: Well, there is a point where themes have an impact on usability.

(11:08:50) Tim Hunt: But the standard theme should be right by default.

(11:08:55) Olli (pilpi): exactly.

Progressive disclosure

Moved: Progressive_Disclosure_Implementation Styles:

  • Search options (progressive disclosure with arrow):Keep selected users, even if they no longer match the search,If only one user matches the search, select them automatically,Match the search text anywhere in the user's name
  • show/hide controls, click to toggle:
  • plus/minus:module corner, table column collapse: plus (hidden), minus (shown)
  • eye: eyelid closed (hidden) or open (shown)
  • search options in assign roles: arrow pointing to left (hidden) or down (shown) → this is used in drupal also for progressive disclosure in forms instead of a “show advanced” button. In moodle arrows are used also for moving elements.

Forms

[https://tracker.moodle.org/browse/MDL-19659 MDL-19659]

  • simplicity through progressive disclosure
    • quiz question editing forms for various question types
  • on simple forms, (less than one page / four elements or less) autofocus the first field of the form on body onload IF none of the fields have any changed content in them (i.e. if the user is not returning to the page from browser history, see: [https://tracker.moodle.org/browse/MDL-825 MDL-825])
  • Configuration defaults: http://moodle.org/mod/forum/discuss.php?d=124533
  • Date selection: use javascript selector (how about time?)
  • Buttons in each module configuration: save and return to course / save and display / cancel. Are there really use cases to support having this choice each time?


If a required item is missing, moodle scrolls the user to the first required item

No jargon in form items.

Either have the label of the element clear for those who are unfamiliar with programming, web development or moodle lingo, or add a help item. (issue i1)


Never (ever) lose user submitted form data.

Moved to User_Data_Always_Safe

Users should not have resort to paranoia of writing first in notepad and then copying it to the browser, or using somethin such as http://lifehacker.com/5097334/lazarus-form-recovery-saves-web-page-form-data ) Users may

  1. Leave forms without submitting (not understanding they need to save or accidental click of “convenient” browser back button in keyboard)
  2. Enter forum post editing before editing time is up and save a big amount of changes after the time is up (they have no way of knowing if the time is up).
  3. Submit a form after the server has suddenly gone down or to maintenance mode

Solutions: When a user submits data that can not be saved because of application restrictions (forum post editing time passed, obligatory form fields not filled), think about the scenario in question: what might the user want to do with the data as a second option?

  • No other options: show them the data so they can copy and paste it for later use
  • Save in a different manner/place: for example, when a forum post has expired, the user is quite likely to want to post a new comment in the thread mentioning what they were about to add to/change in the original posting. Tell them changes have not been saved due to [reason], and let them choose if they want to create a new posting instead. Give them at least the new version back, or optimally a simple graphical representation of the changes they made after the last version that could be saved.
  • If they are about to leave a 'dirty' form, warn them about this with a javascript dialog.
  • In case the user's computer fails, AJAX autosaving might be the only viable option.
  • In case the server fails, storing the form data in a cookie (or if available, with Google Gears or a future standard solution for this) on the client's computer is possible, showing the data to the user again when they return to the form once the server is up again. When they successfully submit the form, delete the cookie. I am not sure about the privacy implications of this though.

TODO: make this a guideline, link as a meta bug and add other bugs inside it.

make form data not disappear when change on browser history


https://docs.moodle.org/en/User:Frank_Ralf/Moodle_forms1#Checkboxes

[https://tracker.moodle.org/browse/MDL-19659 MDL-19659]

    • simplicity through progressive disclosure
      • quiz question editing forms for various question types
    • on simple forms, (less than one page / four elements or less) autofocus the first field of the form on body onload IF none of the fields have any changed content in them (i.e. if the user is not returning to the page from browser history, see: [https://tracker.moodle.org/browse/MDL-825 MDL-825])
    • autosave as a standard on all forms: in case of network outage / simultaneous editing by someone else / some other conflict situation, always tell the user there was an error and **give the users their data back** so that they can
      • optimally, try again saving the data, resolving that conflict
      • or at least copy what they filled in to clipboard
      • currently losing data is also a problem when the editing time of a forum post has passed but the user is already in the post editing form and has changed something: moodle gives an error message that editing time has passed, and just discards all the changes the user tried to save.
        • The same applies when user gets logged out for whatever reason: the session ID changes when they log in again so even if they manage to do that (in a different window), submitting the form again fails and the user loses all submitted data: if there are no security issues to this, Moodle should give the user their data back so they do not lose it.
    • Feedback for form actions; an intermediate page giving feedback with META refresh
      • slow, clumsy, issues with browser history(?), not standard with most of the rest of the web
    • Like in WordPress, javascript confirmation if the user presses the back button when already having filled in data but not submitted the form. Especially when using ctrl and shift with arrow keys to move around in text (though it's possibly a marginal use case), it is easy to inadvertedly trigger the shortcut key of the back button in the browser.
    • related: when editing something in a form, if the user is exiting the page without saving page, give a javascript alert on pageunload (?) confirming whether the user wants to save the changes first
    • Configuration defaults: http://moodle.org/mod/forum/discuss.php?d=124533
    • Date selection: use javascript selector (how about time?)
    • Buttons in each module configuration: save and return to course / save and display / cancel. Are there really use cases to support having this choice each time?

Dropdowns

if a config element is disabled because another element has not been selected (to activate the feature in question), grey the element out

dropdowns: Think about how many detailed mouse clicks it's going to take to choose, say, Times New Roman. First, you have to click on the down arrow. Then, using the scroll bar, you have to carefully scroll until Times New Roman is in view. Many of these dropdowns are carelessly designed to show only two or three items at a time, so this scrolling is none too easy, especially if you have a lot of fonts. It involves either carefully dragging the thumb (with such a small range of movement, it's probably unlikely that this will work), or clicking repeatedly on the second down arrow, or trying to click in the area between the thumb and the down area -- which will eventually stop working when the thumb gets low enough, annoying you even further. Finally, if you do manage to get Times New Roman into view, you have to click on it. If you miss, you get to start all over again. Now multiply by 10, if, say, you want to use a fancy font for the first letter in each of your chapters, and you're really unhappy.

http://www.joelonsoftware.com/uibook/chapters/fog0000000060.html

 http://www.useit.com/alertbox/20040927.html

Required red asterisk / advanced green asterisk...

re: chat with sam@moodle.org/Home on june 22th: took a look at unicode. it would be great to have something semantically linked to hoping to go for something would be more memorable as to avoid users double checking which one meant required and which one meant advanced - luckily asterisk is pretty strongly used as 'required' but it would help if the 'advanced' would be far from it. relatively anonymous ones: †‡•‣⇨ ♯☛ place of interest ⌘ gear: ⚙ (too strong? denotes advanced in os X - now that it is not an icon I think ) lozenge: ◊ In modal logic, the lozenge expresses the possibility of the following expression. For example, the expression File:4f84db7080b44ff7c04eba184c08e57e.png expresses that it is possible that P is true.

Submit buttons

  • moduulit:Save and return to course, Save and display, Cancel
  • (forgot password also has cancel button, in addition to OK); the following page has 'Continue'
  • -> action buttons should have an action (even verb), such as Next step
  • reset course has “reset course” “select default” “deselect all” “cancel”
  • Override permissions: Save changes and Cancel at the top and the bottom of the screen
  • replace single-page dialogs with an YUI dialog at library level

Intermediate pages for success (or other results), with META REFRESH - in which situations are we meant to use them?

Javascript

Avoid javascript flicker; hide beforehand with CSS

The Add question dialog's ugly inner parts can show on a slow connection/machine for as long as ten seconds. This is more than enough for the user to assume it as a normal part of the UI and for his/her cognitive processes to start trying to figure out what that functionality does in that context. When the UI disappears, the user gets confused.

https://docs.moodle.org/en/Development:JavaScript_guidelines#Different_CSS_when_JavaScript_is_on_or_off Other JS-only elements of the quiz editing UI are already doing this. See if this works to fix it. If it does, add a paragraph under that heading, explaining that this should always be done. It is definitely worth it to get this precluded before there is lots of progressive enhancement javascript in Moodle. viittaa myös täällä ja perustele miksi liittyy jos liittyy: https://docs.moodle.org/en/Development:Unobtrusive_Javascript

http://www.baekdal.com/articles/usability/usable-XMLHttpRequest/

Separate projects

Moved to Major_usability_issues_in_Moodle

Retrieved from "https://docs.moodle.org/dev/index.php?title=Usability/Improve_Moodle_User_Experience_Consistency/Notes_from_UI_inspection&oldid=15372"
Powered by MediaWiki