https://docs.moodle.org/38/en/api.php?action=feedcontributions&user=Pilpi&feedformat=atomMoodleDocs - User contributions [en]2024-03-28T20:17:36ZUser contributionsMediaWiki 1.39.6https://docs.moodle.org/38/en/index.php?title=Development:Usability/Improve_Moodle_User_Experience_Consistency&diff=77315Development:Usability/Improve Moodle User Experience Consistency2010-10-29T13:53:48Z<p>Pilpi: </p>
<hr />
<div>Parent page:[[Development:Usability|Usability]]<br />
<br />
'''Project outcome: [[Development:Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]]'''<br />
<br />
This project will create a a lightweight Human Interface Guidelines style documentation for Moodle, as part of a review of Moodle's overall user interface.<br />
<br />
It is not about making usability recommendations to specific parts of Moodle, but trying to see patterns in the way UI's are made in Moodle, and to make recommendations concerning those patterns.<br />
<br />
'''Note: This is a project plan, and although I have made an effort to organize the content, as such might it not be very easily readable by random passers-by.'''<br />
<br />
{{GSOC 09}}<br />
==Overview==<br />
*'''Progress meter:''' MDL-19586<br />
*'''Resulting guidelines site:''' [[Development:Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]]<br />
* Project documents:<br />
**'''Detailed project plan (and schedule):''' [[Development:Usability/Improve Moodle User Experience Consistency/Detailed project plan]]<br />
** '''Notes:''' [[Development:Usability/Improve Moodle User Experience Consistency/Notes from UI inspection]]<br />
*'''Forum:''' [http://moodle.org/mod/forum/discuss.php?d=119507#p523934 Usability forum]<br />
*'''Blog:''' [http://www.pilpi.net/software/moodle/ Project blog]'''<br />
*'''Proposition:''' [http://moodle.org/mod/forum/discuss.php?d=119502 Introducing the project] for Google Summer of Code 2009 (based on prior discussion with Tim Hunt and Helen Foster)<br />
*'''Project student:''' [[User:Olli Savolainen]] / University of Tampere, Finland<br />
<br />
===Executive Summary===<br />
Review Moodle's overall user interface. As an intermediary step, create a lightweight Human Interface Guidelines style documentation for Moodle. After having gathered the principle interaction styles and elements, discuss them with the community and fix the most obvious inconsistencies found. <br />
<br />
=== Motivation ===<br />
In Summer 2008, I worked to [[Development:Quiz_UI_redesign|enhance the usability of the Moodle Quiz module]], based on reported needs of teachers. During this project the lack of usability documentation became obvious. On one hand, there is an implicit Moodle way of doing user interfaces, but then it is not very well documented. <br />
<br />
When I started working on the Quiz UI I was not deeply knowledgeable about Moodle as a whole. Though consistency was discussed in that project, the fact shows in the outcome. It was difficult to keep a complex UI design consistent with the whole of Moodle where the spectrum of UI elements and interaction styles used is quite limited. Moodle is just starting to introduce the fluidity of AJAX-style UIs.<br />
<br />
Although I have been developing for Moodle since Summer 2006, I also consider this an important learning experience about the whole of Moodle for myself, to gain deeper understanding about the different possiblities provided by Moodle, and about how they correspond to actual user needs.<br />
<br />
== Summer 2009: In practice ==<br />
<br />
Moodle is a web application. Web applications do not, in general, have strict consistency rules or UI guidelines. However, Moodle is also starting to be a big application. <br />
<br />
Different parts of it share similar interactions, and they should work similarly across different components, or modules. To this end, developers should be capable of searching the documentation for topics such as “selecting a group of users” or “opening a file” and find a concise explanation describing what the user experience should look like and possibly how to implement it.<br />
<br />
Based on the usage scenarios and use cases of each component, a limited amount of usability testing will be carried out. Necessary improvements will then be suggested on the user interface level to enhance the interoperability between different parts of the whole. <br />
<br />
I will implement changes, the need for which rises from the research phase that can be sufficiently usability tested, agreed about in the community, and are reasonable easy to implement in terms of software development. Larger-scale guidelines for improving consistency will be discussed in the community and documented.<br />
<br />
===Project plan===<br />
<br />
'''Detailed project plan (and schedule):''' [[Development:Usability/Improve Moodle User Experience Consistency/Detailed project plan]]<br />
<br />
The idea is to keep ideas and perceptions in this docs page and possibly in subpages. I will go through Moodle 2.0 HEAD and in case something is broken I will refer to Moodle 1.9. Results of the project will possibly be in [[Development:Interface_guidelines]] although that may still be something different from what I'm actually doing in this project - so another page might be needed. During the project I will listen to the community of developers a LOT to understand their needs and the scenarios in which they might use something like a HIG.<br />
<br />
'''TODO DONE May09: Create a ticket in tracker with the subsections of the project''' ... hm. I really don't find the tracker UI very suitable for this kind of a project. Can anyone name a real reason to use time creating those subtickets? Maybe I'll just create a single big ticket and link it here to the actual project plan.<br />
<br />
Well, it's useful to organise the stages, indicate their completion status, <br />
Moodle versions, as well as add watchers/notification and so on. Consider<br />
it a Moodle.org usability guideline :) [[User:Martin Dougiamas|Martin Dougiamas]] 08:25, 3 June 2009 (UTC)<br />
<br />
=== UIs to examine ===<br />
My current impression is that at least the following are an integral part of the core Moodle experience, and need to be evaluated as a part of this project. This list is '''not''' definitive, but serves as an initial perspective of the scope of the project.<br />
<br />
☑=initially examined for elements and interaction styles to include<br />
<br />
* Course management: Front page, category page, Main course page (including different formats; topics ☑), course completion (http://moodle.org/mod/forum/discuss.php?d=126016)<br />
* Roles management<br />
* My Moodle, User profiles, course participants list<br />
* Assignments, Chat ☑, Database activities, File management, Feedback (Questionnaire) http://moodle.org/mod/forum/discuss.php?d=52861&parent=550322, Forums(☑), Glossaries ☑, Quizzes (☑), Resources ☑, (Wikis ☑, Lessons, Hot Potatoes)<br />
* Gradebook (the new UI interoduced in 1.9 and 2.0 in 2009), Outcomes, Backup& Restore, Question bank, various Settings screens (forms).<br />
* More modules listed in using moodle forums listing (could not find it from moodle.org menus now)<br />
See also: [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&mode=hide&pid=10011&sorter/order=DESC&sorter/field=priority&resolution=-1&component=10309 Tracker items tagged 'usability']<br />
<br />
<br />
==== Various ways to categorize UIs and their parts ====<br />
* '''Goal-related''' <br />
** Functional wholes: site administration, course hierarchy management, user management, course management, student: keeping track of courses/duties, rights management (contexts,roles)<br />
** Processes: installation, logging in<br />
** Use cases: login when following link to protected page, checking for new posts, grading things<br />
** User motivations: efficiency, privacy, social meaningfulness, fitness for purpose, satisfaction/pleasantness<br />
* '''Page types''': Course page, module pages, tabbed pages, configuration pages (and rights management), user-specific pages (profile/my moodle), popups/specialised pages (help windows, chat windows, quiz question preview)<br />
* '''Functional units''': courses, modules, blocks, editors<br />
** editors: text editors (plain, wysiwyg), equation editors, image editors, sound editors<br />
** '''Modules''': Forum, Quiz, Wiki, Assignment, Glossary, Gradebook, ...<br />
** web app taxonomy: configuration, content editing pages<br />
** domain-specific taxonomy: course categories, courses, modules, blocks<br />
* '''Page regions''': Header, footer, sidebars, content area<br />
* '''Interaction styles''': wizards, forms, different course formats<br />
* '''Elements''': Tabs, different form elements, links, buttons, dialogs, breadcrumb navigation, tooltips, list tools (add element to list from a set), table tools<br />
** '''Navigational elements''': Search, breadcrumb, menu, tabs, modes, headings<br />
* '''Technology''': native in browser, plain html+css, browser scripted (js, canvas), dynamic/desktop-like (ajax, flash), plugin-based (java, flash, separate video players), email-based, IM-based, on-screen, printable, mobile, <br />
** '''Modality''': auditive, visual, tactile<br />
* Modes<br />
** global: "view as student"<br />
<br />
=== Interaction styles/elements to possibly examine ===<br />
striking through as temporarily moving to an openoffice.org document<br />
<s><br />
* consistency of feedback from any and all user actions; normal and error situations; recovery<br />
* data listings, such as quiz editing and moodle course front page<br />
** functionality: moving elements in a list (reordering), moving elements between lists <br />
** gradebook: clicking on column titles to highlight the column<br />
** tables vs. lists vs. divs with complex data<br />
** 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.<br />
** filtering selection lists MDL-17780 MDL-19285<br />
* forms <br />
** simplicity through progressive disclosure<br />
*** quiz question editing forms for various question types<br />
** 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: MDL-825)<br />
** 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 <br />
*** optimally, try again saving the data, resolving that conflict<br />
*** or at least copy what they filled in to clipboard<br />
*** 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.<br />
**** 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.<br />
** Feedback for form actions; an intermediate page giving feedback with META refresh<br />
*** slow, clumsy, issues with browser history(?), not standard with most of the rest of the web<br />
** 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.<br />
** Configuration defaults: http://moodle.org/mod/forum/discuss.php?d=124533<br />
** Date selection: use javascript selector (how about time?)<br />
** 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? <br />
* editing modes: inline editing (course frontpage) vs. editor (quiz)<br />
** related: most CMSs have separate control panels and inline editing is extra, in Moodle there is no clear distinction between control panels and content pages<br />
** http://moodle.org/mod/forum/discuss.php?d=122300#p536641<br />
** 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 <br />
* dialog title bars visuals: file selector vs. quiz dialogs<br />
* modal buttons; buttons that have an on/off state: show the command to change or the current status <br />
** 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.<br />
** 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"<br />
** 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)<br />
** In profile, enable/disable e-mail (2.0)<br />
* usage of buttons vs. links<br />
** 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)<br />
*** VS what is usually done in Moodle<br />
**** 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)<br />
** 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.<br />
** 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) <br />
*** (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.<br />
* 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<br />
** [http://www.futurice.com/services/we_can_we_care an interesting deviation from the standard tabs visual design]<br />
* Search<br />
* TITLE elements of pages: descriptive of the specific content<br />
* popup_form() dropdown command menus (add new activity to course) vs. YUI dialogs such as 'add new question' in Quiz<br />
* Help: wiki ([http://blogs.atlassian.com/news/2007/12/using_a_wiki_fo.html]), popups, inline help (http://www.pilpi.net/software/moodle/2009/06/18/inline-help/ [http://www.pathf.com/blogs/2008/04/design-pattern-2/])<br />
* usage of the frames which are rounded at the bottom. are they for summaries (m2q ► CF101 ► Resources ► tiedostot) or for the main content? (resource)<br />
* update this [modulename] button, and various additional buttons/links nearby<br />
** glossary: Import entries / Export entries Printer-friendly version<br />
** forum: subscripthion permission status, force everyone to be subscribed (->button), show/edit subscriptions, subscribe (->button)<br />
* visual consistency of toolbars (and other windowingsystem-like visuals) in tools such as equation editor, drawing tool, rich text editor<br />
* wizards, such as backup, need to act like wizards. <br />
** Back/Next (which preserve the data entered by users in other screens) and Cancel buttons on every screen with progress meter showing the active steps and the number of steps left. <br />
**Each screen is a form, so no links are used to make selections to keep the wizard consistent (the added click is secondary to the problem of potentially losing user data: even if the data was preserved, navigation links do not afford this and the user is still anxious of using back/forward browser buttons). <br />
** what makes a wizard? http://ui-patterns.com/pattern/Wizard http://designinginterfaces.com/Wizard<br />
**All of this functionality is provided by PEAR QuickForm_Controller.<br />
*** assumably quickform_wizard is a more advanced version of quickform_controller http://translate.google.com/translate?js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fwww.ambrosanio.com%2Fcomponent%2Fcontent%2Farticle%2F33-my-php%2F56-htmlquickformwizard&sl=auto&tl=en&history_state0= <br />
*** a progressive enhancement AJAX to quickform_wizard: http://www.bubbling-library.com/eng/api/docs/plugins/wizard-documentation.html<br />
</s><br />
==== Moodle / CMS elements conveying specific semantics ====<br />
* Blocks<br />
* Themes<br />
* Filters<br />
<br />
==== Future prospects ====<br />
* notification popups (like facebook's) - something like http://www.paquitosoft.com/notimoo/ but more subtle and with YUI<br />
* explore google wave's interaction styles<br />
<br />
=== Outcomes ===<br />
# As a result of having discovered consistency issues, fixes to Moodle 2.0 UI code to enhance the overall user experience (UX)<br />
# Index of the current screen types, interaction styles and elements, with their intended uses. Should also be searchable by intended use, to find out what UI elements to use in a given situation.<br />
# Secondary outcome: find and gather typical use cases of core UIs/modules -> useful for usability testing and further UI design<br />
<br />
The format in which to present the guidelines is still unclear. The main objectives are<br />
* Lightness, quickness: rather links to examples and screenshots than lengthy explanations<br />
* Interlinked elements (UI's, issues, guidelines, etc.) to facilitate keeping documentation in context and easing maintenance.<br />
<br />
=== What is ahead: challenges ===<br />
We need to do this together. Although I am promoting building at least some sort of a skeleton of a documentation on the User Experience (UX) level, the point is to create something that the community can embrace and use, as a part of the developer documentation used in everyday development discussions. Moodle already has a lot of documentation for technical considerations and it has usually been easy to get help for technical issues. [http://www.uoc.edu/portal/english/la_universitat/sala_de_premsa/entrevistes/2008/martin_dougiamas.html Usability needs to have an equally important role, as discussed many times before].<br />
<br />
The challenge in trying to standardize something such as UI designs, is that the whole point about developing applications for humans is often about creating new styles of interactions. Thus, it is key to create a strong convention to keep this documentation up-to-date. That is, whenever developers decide that something is missing in the catalog, it will be added. The most standard i.e. common and mundane tasks need to be the most easy-to-find, keeping at least them standard across Moodle.<br />
<br />
Also, usability testing the suggested solutions sufficiently for actually changing the implementation is quite a challenge during just one Summer.<br />
<br />
== Background: The Ultimate Goals ==<br />
<br />
=== Goals ===<br />
'''''Give power to the developers to create good, Moodle-style UI's'''''<br />
<br />
The main goal is to gather lightweight HIG-style documentation to help evaluate the consistency of the current UIs and to facilitate the design of future UIs. For this to be useful, using the HIG needs to be incorporated in the developer guidelines (and in the moodle developer course) of Moodle. All UIs should be validated against the HIG. It does not make sense to document all "original" interactions. Still, at least where an UI deviates from something mundane that clearly is defined in the HIG, the fact and the reasons for it should be documented with in the documentation for the code.<br />
<br />
The intended use of the main core modules will be studied and preliminary documentation will be gathered so that anyone building on an existing UI will know what user needs they are designing for. This will also facilitate usability testing since it will be transparent to what the main tasks to test against are, even to people who do not already know the UI (this seems to avoid the bias of defending the familiar, during usability tests).<br />
<br />
As opposed to the Quiz UI work of last summer, the approach is top-down. The point is to examine the goals each of the main components of the user interface, in the context of Moodle, as a whole. <br />
<br />
The goal is to create a framework for developers to think about and document the user experience (UX) of Moodle. The knowledge of what has been verified – typically with usability testing – to work for users, needs to be available. A Human Interface Guideline (HIG) is one way of thinking about it. However, there is rigidity and vastness to a typical HIG that we want to avoid: it is paramount that what is documented is both easily accessible and maintainable.<br />
<br />
It also has to be said that a HIG can never replace an actual usability practitioner. Using a HIG simply helps us take a good direction, a basis to build upon, so that usability practitioners can concentrate on the issues that really require them. Just like in the corporate world, functional testing is a separate profession because different people have skills to do programming than testing, designing interaction is a intricate profession of its own. For further discussion about this, refer to Cooper's excellent discussion about the intricacies of the software industry: [http://books.google.com/books?id=04cFCVXC_AUC&printsec=frontcover&dq=the+inmates+are+running The Inmates Are Running The Asylum] (limited edition on google books).<br />
<br />
=== Later: Documented user descriptions and scenarios ===<br />
<br />
The basic requirement of usability work is to "Know Your Users". However, at this point we do not deal with the actual profiles of users: the assumption in this project is that the community-based development style with a strong focus on feedback helps developers approximate user needs.<br />
<br />
This knowledge about users is often expressed in terms of Personas, scenarios and use cases. <br />
* [[Development:Quiz_UI_redesign_scenarios_-_Scenarios_index|Some work was done in the Quiz UI Redesign project]] but the format this was communicated in was not sufficiently easy to access. <br />
* Also, Moodle has used [http://wiki.fluidproject.org/display/fluid/Moodle+UX+Walkthrough+Working+Group?showChildren=false fluid efforts], including their personas and scenarios<br />
<br />
In a separate effort, Moodle should take a more robust approach to base its design on really knowing that we know our users, instead of the gut feeling of developers (no matter how close they might feel to teachers, students, or other users).<br />
<br />
Also other aspects of HIGs, such as keeping vocabularies consistent and accessibility issues should be considered, but they are not the focus of this project.<br />
<br />
== My competences ==<br />
<br />
In Summer 2008 I redesigned and implemented [[Development:Quiz_UI_redesign|the Quiz editing UI]]: did interviews for [[Development:Quiz_UI_redesign_scenarios_-_Scenarios_index|scenarios]], usability testing testing and community discussions. The result of this work is now included in Moodle 2.0 HEAD. <br />
<br />
Before this, I worked in the University of Tampere on a Moodle integration project. I am also an Interactive Technology major in that university. I am currently writing my thesis about Usability processes in open source projects, with last summer's Quiz work as the principal case that is examined.<br />
<br />
* [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&assigneeSelect=specificuser&assignee=pilpi&resolution=1 List of my completed tracker issues]<br />
* [http://www.linkedin.com/in/ollisavolainen LinkedIn]<br />
* [https://www.ohloh.net/accounts/pilpi Ohloh]<br />
<br />
== Current state of research (in constant state of change)==<br />
<br />
===Advice to possibly include in the final documentation===<br />
* do not relay UI design decisions to moodle admins (unless you really have different use cases where different UIs would be suitable for different sorts of users AND the UI can't take them into account "by UI design otherwise" (explain further). <br />
** moving the burden of making design decisions from development to administration seems a quasi-solution to me - in some cases admins may be interested and know their users well. But I think most of the time relaying such responsibility just gives an impression of an unfinished product. Of course they can be given the power to customize, but I think we should not think about that while the design itself is unfinished.<br />
** it needs to be carefully examined which configuration options are genuinely options that depend on different needs of different Moodle installations, and which are the effect of avoiding making strategic usability decisions that should be made during Moodle development<br />
** [http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html Joel on Software on Choices)<br />
** [http://twitter.com/eGJD/statuses/1475501418 Martin Langhoff at #mmuk09: "Options are bad, it is what we put in place when we don't make a decision"]<br />
* A hig includes an index of interaction styles that are part of standard Moodle: "if your proposition for a new UI contains new interactions, please link to it under the 'suggested interaction styles' in the HIG, and it will be checked out and discussed."<br />
* [[Development:Progressive Disclosure]]<br />
* [[Development:Tooltips]]<br />
* About the nature of guidelines: [http://en.wikipedia.org/wiki/Wikipedia:What_%22Ignore_all_rules%22_means#What_.22Ignore_all_rules.22_does_not_mean]<br />
<br />
=== Issues, to be researched further ===<br />
These are not tested and proven, but some things I have discovered while working on Moodle<br />
* forums<br />
** If users are not logged in, they sometimes get a login screen (forum) and sometimes just an error message (moodle.org blogs) when accessing content. <br />
*** It is questionable whether content that is accessible via "login as guest" button by anyone should require passing through a login screen in the first place, since most web apps do not require such - it is a hassle to remember to mention "press the login as guest button to get to the actual target of this link I am posting"<br />
**** there were references in the tracker to [http://tracker.moodle.org/browse/MDL-12705 "guest autologin"] feature but I don't know if this is it or what are the reasons for this being a setting <br />
** MDL-1626 (addressed already so letting go) [following a single thread and not entire forum does not seem to be possible. in the solution gmail+google groups, gmail automatically groups messages with the same subject line and shows them as one message ("thread") in gmail, too. The problem is still present also in google if one orders a digest mail: can't select which threads I'm interested in and threads are not sorted. is there an underlying design decision to forcing to follow all forum or none of it?]<br />
* if moodle.org wants to present usage of moodle, it should be consistent with moodle's ux itself. an example: where is the listing to all the forums from the breadcrumb?<br />
** course front page: showing/hiding sections<br />
* Feedback: sometimes Moodle gives non-localized, entirely technical and unhelpful feedback even to normal users.<br />
** "Olli - Under "Some potential things that require change, to be researched further" you mention Feedback being too technical and unhelpful feedback to normal users - could you cite an example or two to show what you mean? Thanks - Anthony "<br />
*** This needs to be researched further. For now, see my rant (written in gray) at http://moodle.org/mod/forum/discuss.php?d=117522#p524143 (sorry, haven't gotten around to doing a bug report about that yet).<br />
* Quiz:<br />
** new interaction styles introduced by usability work of summer 2008<br />
*** icons in tabs: is this a problem to someone? preview icon should in my opinion be used in all preview tabs? the reasoning is to familiarize users to the meaning of the icon by associating it with the label<br />
*** using overflow:none in listings where the content does not fit screen<br />
*** question bank window: the concept of "toolbar window", per-user open/close state persistence <br />
** integration with question bank http://tracker.moodle.org/browse/MDL-18001 (is there something similar somewhere else in moodle?)<br />
** dialog styles: ok button vs something named after the actual dialog action, cancel button, which first, apply button(?), dialog visual style<br />
* New UI work recently done on gradebook<br />
* Moodle messaging: <br />
** Might be required: unobtrusive notifications for new private / forum messages, external notifications consistently regardless of whether user is logged in<br />
** Block user: green icon? (Tim, Anthony)<br />
* Facilities for consistent undoing across Moodle, see for example [[Talk:Projects_for_new_developers#XML_templates_for_admin_settings]]<br />
* Moodle messaging: mail/whatever notifications should come regardless of being logged in (is this true in the new notification framework?), unobtrusive web notifications (moodle is the only thing to use unrequested popups; see facebook and basically any web app on the planet for less distractive interaction styles)<br />
* new gradebook: visual report disabled states<br />
* file selector visual hierarchy: icons/list selection is positioned in the dialog to communicate it is related to both the panes below it when it is related only to the right-side pane<br />
* There is a convention to create feature description pages when new features and changes are planned (sumewhat such as the page you are reading). I am struck by how much cleaner such pages are for mozilla.org, for example. https://wiki.mozilla.org/Thunderbird:Folder_Pane<br />
** are all these pages organized somewhere in the wiki centrally?<br />
* The fact that the help system is made of popups is a problem; popups get lost under other windows, and less experienced users (the primary users of the help systems) get confused by them (surprisingly few novices master the task bar very well). Yahoo dialogs don't solve it since they are modal and don't enable the user to both use the system and refer to the help at the same time. Windows has contextual help popups that split the current window, showing the help beside the normal content of the window. Also, there should be some kind of a standard for the help texts themselves; many of them explain things assuming that users know a bunch of other techie/moodle concepts.<br />
** TODO: review other web apps, how is help done<br />
** differentiate between tutorial content that explains things (non-modal popups are suitable), and with clarifications that answer to the question "what does this mean" for example with individual configuration options (inline help - always visible or not, different icon to activate than with popup help?; short text for which a popup would be too slow and cumbersome)<br />
* Headings of sections: '''always''' right under the header, before any other content, stating type of activity (=module name, configuration, course categories) and possibly name of activity (a specific activity in the context of a course)<br />
==== Other considerations ====<br />
* Guiding teachers to [[Pedagogy#Progression|better gain from Moodle's wide array of pedagogical features]] has been discussed quite a bit recently. This may require novel interaction styles: guides/wizards/assisted functionality<br />
* In Moodle Moot UK '09 Martin Dougiamas mentioned setting up functional testing in the tracker. <br />
** -> This is not very far from the goals of usability testing: <br />
**** -> some of the base work is similar since to do functional testing the core functionality has to be defined and perhaps even prioritized. <br />
** -> And usability testing core functionality is the basis of this project.<br />
** TODO: Where is this discussed and documented? http://moodle.org/mod/forum/view.php?id=56 Not here?<br />
* Configuration screens (Update [modulename]) / content editing screens (also sometimes in update [modulename]) / various buttons nearby the Update [modulename] button (glossary:Import entries / Export entries Printer-friendly version)<br />
* module configuration: a big commitment required of users up-front, giving them a huge configuration screen before they can see anything at all about what the element itself is. (advanced uploading of files)<br />
<br />
== Further reading ==<br />
** [http://www.joelonsoftware.com/articles/fog0000000033.html Joel on software: Painless functional specs] - a rather different way of writing to developers about software<br />
* [http://www.disambiguity.com/drupal7ux-how-does-drupal-talk-on-brand-personality-and-tone-of-voice/ drupal: brand personality, drupal's voice] What is Moodle's voice like? How does it address, talk to users? The first thing that springs up to mind is that Moodle's error messages are certainly not very friendly-toned, but strictly technical - does that need to be the case?<br />
* [http://www.useit.com/papers/standards.html Assessing the Usability of a User Interface Standard], By Henrik Thovtrup and Jakob Nielsen, 1991<br />
* [http://www.useit.com/alertbox/tabs.html Tabs, Used Right] - Moodle uses '''a lot''' of tabs, and I suspect examining them will reveal something ugly.<br />
* [http://www.useit.com/papers/webwriting/ Writing for the web], useful links found:<br />
** http://www.useit.com/alertbox/content-strategy.html<br />
** http://www.useit.com/papers/webwriting/rewriting.html<br />
** http://www.e-gineer.com/v1/articles/web-writing-for-many-interest-levels.htm<br />
** http://www.gooddocuments.com/homepage/homepage.htm<br />
* I will probably need to dive pretty deep in [[Development:Navigation_2.0]] ([http://moodle.org/mod/forum/discuss.php?d=116936#p519530 discussion linking consistency work with navigation])<br />
** Navigation blocks in the sideblock of all modules.<br />
* Forms usability is a related topic of its own. Progressive disclosure will give wins here if we do it right. Some kinds of guidelines could probably be found for this<br />
** http://moodle.org/mod/forum/discuss.php?d=119227#p522673<br />
* [http://tracker.moodle.org/browse/MDL-14639 Last summer's GSoc usability project]<br />
** https://docs.moodle.org/en/Student_projects/Usability_issues/T1 <br />
* To compare with current state of Moodle: [http://wiki.fluidproject.org/display/fluid/Moodle+UX+Walkthrough+Working+Group?showChildren=false fluid findings]<br />
* [http://moodle.org/mod/forum/user.php?id=636237&course=5 Thomas Hanley's forum postings]<br />
* Wikipedia guidelines: http://en.wikipedia.org/wiki/Category:Wikipedia_style_guidelines http://en.wikipedia.org/wiki/Category:Wikipedia_editing_guidelines<br />
<br />
=== HIGs ===<br />
* [http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines OLPC HIG]<br />
* [http://library.gnome.org/devel/hig-book/stable/ Gnome HIG] - a lot of what is here also applies to Moodle<br />
* [http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html iPhone HIG] - another example of comprehensive guidelines producing great interfaces<br />
** [http://developer.apple.com/documentation/UserExperience/index.html Leopard Guides: User Experience]<br />
* [http://msdn.microsoft.com/en-us/library/aa511258.aspx Windows HIG]<br />
* [http://groups.drupal.org/node/14422 Drupal User Interface best practices] (http://groups.drupal.org/node/14786) - contains lots of links to different resources, HIG's and pattern libraries<br />
* [[Development:Interface_guidelines|Current Moodle Interface Guidelines]] - Old and never completed<br />
==== About guideline/pattern/HIG writing ====<br />
* Gerard Meszaros, Jim Doble: [http://www.hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing] (Thanks to Tim Hunt!)<br />
** http://xunitpatterns.com/Introduction.html (again, thanks to Tim)<br />
* [http://ieeexplore.ieee.org/Xplore/login.jsp?url=http%3A%2F%2Fieeexplore.ieee.org%2Fiel4%2F5915%2F15768%2F00732206.pdf%3Farnumber%3D732206&authDecision=-203 Principles for a usability-oriented pattern language Mahemoff, M.J.; Johnston, L.J.] ([http://mahemoff.com/paper/principles/ "HTMLized version"])<br />
<br />
==== Patterns ====<br />
* http://ui-patterns.com/<br />
* http://visiblearea.com/cgi-bin/twiki/view/Patterns/Patterns_repository<br />
* [http://wiki.fluidproject.org/display/fluid/User+Manual+Table+of+Contents Fluid components], [http://wiki.fluidproject.org/display/fluid/Design+Patterns Fluid patterns]<br />
* collections of patterns: [http://konigi.com/interface/latest konigi], [http://www.flickr.com/groups/designpatterns/ flickr]<br />
<br />
<br />
<br />
=== Forum discussions ===<br />
* [http://moodle.org/mod/forum/discuss.php?d=119502 Introducing the project] (copy: http://moodle.org/mod/forum/discuss.php?d=119507#p523934)</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Quiz_UI_redesign&diff=76329Development:Quiz UI redesign2010-09-30T17:36:37Z<p>Pilpi: </p>
<hr />
<div>'''Status: project finished and code incorporated into Moodle 2.0 in Autumn 2008.'''<br />
<br />
* Chapter 3 of Olli's master's thesis about [http://tutkielmat.uta.fi/tutkielma_en.php?id=20867 Moodle and open source usability work] documents the core ideas of the Quiz UI Redesign work most clearly. Chapters 4 to 6 of the work document the different phases of the project.<br />
* MDL-17284 Final tracker item<br />
* [http://moodle.org/mod/forum/discuss.php?d=103869 Final forum discussion]<br />
* For permanent documentation, '''See also: [[Development:Quiz Usability portal]]'''<br />
<br />
----<br />
This is the Docs page for the Quiz UI redesign project 2008 <br />
<br />
'''The project blog''': http://www.pilpi.net/software/moodle_quiz_ui/ .<br />
<br />
* [[Development:Quiz UI redesign prototype presumptions | Quiz UI redesign prototype presumptions]]<br />
* '''[[Development:Quiz UI redesign - Design specification | Design specification]]'''<br />
* Project tracker: http://tracker.moodle.org/browse/CONTRIB-528<br />
<br />
== Related forum discussions ==<br />
Some are still missing here. The last one is the newest, and the location of current discussion. <br />
* Inquiry about the status of the UI: [http://moodle.org/mod/forum/discuss.php?d=63612 Quiz UI development]<br />
* Suggesting concrete new UI: [http://moodle.org/mod/forum/discuss.php?d=72828 New Quiz UI prototype published] <br />
** Related: [http://moodle.org/mod/forum/discuss.php?d=92870 Re: Concern of Moodle Usability - Quiz module]<br />
* Applied for funding, Tim Hunt accepted as mentor: [http://moodle.org/mod/forum/discuss.php?d=92797 Simple Quiz building user interface]<br />
* [http://moodle.org/mod/forum/discuss.php?d=99351#p439124 Community effort to learn about teacher quiz/exam usage habits]<br />
* [http://moodle.org/mod/forum/discuss.php?d=100367 Call for comments: Quiz UI redesign prototype (new iteration now usability tested)]<br />
* [http://moodle.org/mod/forum/discuss.php?d=102062 Call for comments: Quiz UI redesign demo published]<br />
* [http://moodle.org/mod/forum/discuss.php?d=103869 Should Olli's new quiz editing interface be included in Moodle 2.0?]<br />
** [http://moodle.org/mod/forum/discuss.php?d=103870 cross-post]<br />
<br />
== Scenarios ==<br />
<br />
===Scenarios work===<br />
* '''[[Development:Quiz_UI_redesign scenarios - conclusions| Scenarios work conclusions (executive summary) ]]'''<br />
* [[Development:Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F|The idea and the content of the scenarios interviews I did]]<br />
<br />
===The Scenarios===<br />
* [[Development:Quiz UI redesign scenarios - Scenarios index]]<br />
<br />
== Prototype testing ==<br />
=== June 2008 ===<br />
Published June 27th, 2008.<br />
<br />
[http://www.pilpi.net/software/moodle_quiz_ui/files/quiz_ui_redesign_prototype_2008.odp The prototype used in testing, the last iteration] (ODP 230 KB; '''in Finnish. See the '''[[Development:Quiz UI redesign - Design specification | Design specification]]''' for a more final, translated view of the UI''' )<br />
* [[Development:Quiz UI redesign - prototype testing background|Background]]<br />
* [[Development:Quiz_UI_redesign_prototype_questions#Testing_questions_used_in_spring.2Fsummer_2008|Tasks]]<br />
* [[Development:Quiz UI redesign - prototype testing report|Prototype testing report]]<br />
<br />
===Testing with the actual implementation: August 2008===<br />
See also: [[Development:Quiz_Usability_portal#Future_development]]<br />
* [[Development:Quiz_UI_redesign/usability testing of August 2008/Executive summary|Quiz UI redesign / usability testing of August 2008 / Executive summary]]<br />
* [[Development:Quiz_UI_redesign/usability testing of August 2008/Issues|Quiz UI redesign / related issues in usability testing of August 2008]]<br />
* Quiz UI redesign / [[Development:Quiz_UI_redesign/usability testing of August 2008/Summary of solutions|Direct reactions to usability testing: List of solutions]]<br />
* [[Development: Usability testing in August 2008/Test setting and tasks / background|Test setting and tasks / background]]<br />
<br />
== Development ==<br />
Moved to [[Development:Quiz UI redesign - development]]<br />
<br />
[[Category:Usability]]<br />
<br />
== Obsolete == <br />
* Obsolete: [[Development:Quiz UI redesign prototype | Quiz UI redesign prototype]] <br />
* Pretty obsolete: [[Development:Quiz UI redesign - related use cases|Use cases]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Quiz_UI_redesign&diff=76328Development:Quiz UI redesign2010-09-30T17:36:11Z<p>Pilpi: </p>
<hr />
<div>'''Status: project finished and code incorporated into Moodle 2.0 in Autumn 2008.'''<br />
<br />
* Chapter 3 of [http://tutkielmat.uta.fi/tutkielma_en.php?id=20867 Olli's master's thesis about Moodle and open source usability work] documents the core ideas of the Quiz UI Redesign work most clearly. Chapters 4 to 6 of the work document the different phases of the project.<br />
* MDL-17284 Final tracker item<br />
* [http://moodle.org/mod/forum/discuss.php?d=103869 Final forum discussion]<br />
* For permanent documentation, '''See also: [[Development:Quiz Usability portal]]'''<br />
<br />
----<br />
This is the Docs page for the Quiz UI redesign project 2008 <br />
<br />
'''The project blog''': http://www.pilpi.net/software/moodle_quiz_ui/ .<br />
<br />
* [[Development:Quiz UI redesign prototype presumptions | Quiz UI redesign prototype presumptions]]<br />
* '''[[Development:Quiz UI redesign - Design specification | Design specification]]'''<br />
* Project tracker: http://tracker.moodle.org/browse/CONTRIB-528<br />
<br />
== Related forum discussions ==<br />
Some are still missing here. The last one is the newest, and the location of current discussion. <br />
* Inquiry about the status of the UI: [http://moodle.org/mod/forum/discuss.php?d=63612 Quiz UI development]<br />
* Suggesting concrete new UI: [http://moodle.org/mod/forum/discuss.php?d=72828 New Quiz UI prototype published] <br />
** Related: [http://moodle.org/mod/forum/discuss.php?d=92870 Re: Concern of Moodle Usability - Quiz module]<br />
* Applied for funding, Tim Hunt accepted as mentor: [http://moodle.org/mod/forum/discuss.php?d=92797 Simple Quiz building user interface]<br />
* [http://moodle.org/mod/forum/discuss.php?d=99351#p439124 Community effort to learn about teacher quiz/exam usage habits]<br />
* [http://moodle.org/mod/forum/discuss.php?d=100367 Call for comments: Quiz UI redesign prototype (new iteration now usability tested)]<br />
* [http://moodle.org/mod/forum/discuss.php?d=102062 Call for comments: Quiz UI redesign demo published]<br />
* [http://moodle.org/mod/forum/discuss.php?d=103869 Should Olli's new quiz editing interface be included in Moodle 2.0?]<br />
** [http://moodle.org/mod/forum/discuss.php?d=103870 cross-post]<br />
<br />
== Scenarios ==<br />
<br />
===Scenarios work===<br />
* '''[[Development:Quiz_UI_redesign scenarios - conclusions| Scenarios work conclusions (executive summary) ]]'''<br />
* [[Development:Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F|The idea and the content of the scenarios interviews I did]]<br />
<br />
===The Scenarios===<br />
* [[Development:Quiz UI redesign scenarios - Scenarios index]]<br />
<br />
== Prototype testing ==<br />
=== June 2008 ===<br />
Published June 27th, 2008.<br />
<br />
[http://www.pilpi.net/software/moodle_quiz_ui/files/quiz_ui_redesign_prototype_2008.odp The prototype used in testing, the last iteration] (ODP 230 KB; '''in Finnish. See the '''[[Development:Quiz UI redesign - Design specification | Design specification]]''' for a more final, translated view of the UI''' )<br />
* [[Development:Quiz UI redesign - prototype testing background|Background]]<br />
* [[Development:Quiz_UI_redesign_prototype_questions#Testing_questions_used_in_spring.2Fsummer_2008|Tasks]]<br />
* [[Development:Quiz UI redesign - prototype testing report|Prototype testing report]]<br />
<br />
===Testing with the actual implementation: August 2008===<br />
See also: [[Development:Quiz_Usability_portal#Future_development]]<br />
* [[Development:Quiz_UI_redesign/usability testing of August 2008/Executive summary|Quiz UI redesign / usability testing of August 2008 / Executive summary]]<br />
* [[Development:Quiz_UI_redesign/usability testing of August 2008/Issues|Quiz UI redesign / related issues in usability testing of August 2008]]<br />
* Quiz UI redesign / [[Development:Quiz_UI_redesign/usability testing of August 2008/Summary of solutions|Direct reactions to usability testing: List of solutions]]<br />
* [[Development: Usability testing in August 2008/Test setting and tasks / background|Test setting and tasks / background]]<br />
<br />
== Development ==<br />
Moved to [[Development:Quiz UI redesign - development]]<br />
<br />
[[Category:Usability]]<br />
<br />
== Obsolete == <br />
* Obsolete: [[Development:Quiz UI redesign prototype | Quiz UI redesign prototype]] <br />
* Pretty obsolete: [[Development:Quiz UI redesign - related use cases|Use cases]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Quiz_UI_redesign_%C2%AD_what_makes_a_scenarios_interview%3F&diff=73215Development:Quiz UI redesign what makes a scenarios interview?2010-06-19T17:51:07Z<p>Pilpi: Redirecting to Development:Quiz UI redesign - what makes a scenarios interview?</p>
<hr />
<div>#REDIRECT [[Development:Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Quiz_UI_redesign_%C2%AD_what_makes_a_scenarios_interview%3F&diff=73214Development:Quiz UI redesign what makes a scenarios interview?2010-06-19T17:50:21Z<p>Pilpi: New page: #REDIRECT https://docs.moodle.org/en/Development:Quiz_UI_redesign__ what_makes_a_scenarios_interview%3F</p>
<hr />
<div>#REDIRECT https://docs.moodle.org/en/Development:Quiz_UI_redesign__<br />
what_makes_a_scenarios_interview%3F</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72361Development:Moodle User Interface Guidelines2010-05-22T11:46:32Z<p>Pilpi: /* Relevant guidelines from other sites */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
DRAFT DOCUMENT<br />
<br /><br /><br />
<br />
Many of the pages below are incomplete or obsolete.<br />
<br /><br /><br />
<br />
These guidelines were produced as part of a student project in 2009, and are not yet official Moodle guidelines.<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
<br />
* [http://developer.fellowshipone.com/patterns/ Design Patterns Library & Code Standards] by Fellowship technologies<br />
<br />
== See also ==<br />
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
* '''[[Using Moodle book]]'''<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72360Development:Moodle User Interface Guidelines2010-05-22T11:46:17Z<p>Pilpi: /* Relevant guidelines from other sites */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
DRAFT DOCUMENT<br />
<br /><br /><br />
<br />
Many of the pages below are incomplete or obsolete.<br />
<br /><br /><br />
<br />
These guidelines were produced as part of a student project in 2009, and are not yet official Moodle guidelines.<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
* [http://developer.fellowshipone.com/patterns/ Design Patterns Library & Code Standards] by Fellowship technologies<br />
<br />
== See also ==<br />
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
* '''[[Using Moodle book]]'''<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Address_Bar&diff=72267Development:Address Bar2010-05-18T20:30:57Z<p>Pilpi: what a horrible sentence it was I found - fixed</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Address Bar'''<br />
<br />
On the web, URLs (web addresses, ''Uniform Resource Locator'') are a part of the user interface and some users routinely use the address bar to navigate sites (for example, for getting higher in the hierarchy if they don't find an easier way in the site navigation).<br />
<br />
In Moodle, The form of URLs is determined by a motivation to make work easy for developers, which is important in an open source community. Usually it is enough to just look at the URL to know which PHP file to edit. <br />
<br />
As a consequence, the site hierarchy is not reflected in the URL - the end user is not considered the primary user of URLs, unlike usually recommended. <br />
<br />
Examples<br />
* Course front pages are at moodlesite/course/view.php?id=2<br />
* Regardless of the course an activity module instance, such as a forum belongs to, it's URL is moodlesite/mod/forum/view.php?id=13<br />
<br />
== Guidelines ==<br />
# URLs should be as short as possible.<br />
# No underscores in parameter names or files names<br />
# Never use two words when one would do.<br />
<br />
===Activity modules===<br />
<br />
*''index.php'' - lists all instances for that module in a course<br />
*''view.php'' - displays a particular instance<br />
*''config.html'' - configure an instance of the module<br />
<br />
===Blocks===<br />
<br />
*''config.html'' - configure an instance of the block<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:User_Data_Always_Safe&diff=72220Development:User Data Always Safe2010-05-17T12:49:52Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''User Data Always (Always) Safe'''<br />
<br />
In all cases, the user's work is sacrosanct. Nothing your <br />
application does should lose or destroy user's work without <br />
explicit user action. - GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
<br />
* [http://moodle.org/mod/forum/discuss.php?d=130005 Please comment in the related discussion forum] </big><br />
<br />
Every part in Moodle should commit to keeping the data user has entered, safe. <br />
<br />
Not being capable of trusting an application affects the user experience fatally. If the browser seems likely to destroy everything given to it, eventually it makes users paranoid and writing their work in a word processor and only copying the final work into the browser. <br />
<br />
This issue requires further user research to find the exact issues involved, but there are also some generally well known mechanisms to employ.<br />
<br />
As Moodle is a web application, keeping user data safe is not trivial.<br />
<br />
==Challenges==<br />
* Users may leave forms without submitting them<br />
** Learning from some desktop applications (GNOME settings dialogs), users may assume their settings get automatically saved when they just enter them.<br />
** Accidentally hitting the back button<br />
** Clicking on a link on the form itself, assuming it is safe<br />
** Pushing a button on their keyboard resulting in accidental usage of the back/next buttons<br />
* Users may fill out forms "inappropriately"<br />
** Missing data <br />
** Session may have expired<br />
*** When user gets logged out for whatever reason: the session ID changes when they log in again so even if they manage to login (in a different window) while keeping the form data, submitting the form again fails and the user loses all submitted data. At a minimum, Moodle should give the user their data back so they do not lose it. <br />
** User may have logged out accidentally (browser crash; browser restores the browser session but not the Moodle session)<br />
** User may no longer be capable of completing the action due to loss of permissions or other reasons<br />
*** A forum post they are were replying to was deleted<br />
*** The time to edit a post has passed while the user was editing the post<br />
* Users may submit data when the server has gone down or network connection lost<br />
<br />
==Solutions==<br />
<br />
=== Preserve submitted data or giving it back to the user to keep, until it can be saved ===<br />
Taking care of the user's data actively when designing an application is really the only thing that can really keep users safe. Know your users and their context, and find out what they might want to do in an error situation.<br />
<br />
If a user has posted something, but it cannot be saved, never ever just throw the data away (like for example, Forum currently does).<br />
Design your application to request the user what should be done. This requires understanding the situations users may end up in. Examples:<br />
* If the user's session has gotten closed (the user is no longer logged in), request the user to log in again, and tell them about the situation: "'''What you tried to send is safe, but not yet saved.''' The [insert descriptive label for data here] you posted could not be saved, since you are not logged in. Please log in to have Moodle try again to save it for you."<br />
==== Giving the user their data back, for copying to the clipboard ====<br />
Issue: In case the user has gotten logged out, it may be a security risk to give the data out. In other error situations, this is a recommended strategy. <br />
<br />
In some browsers it is possible to have a javascripted button that copies the contents of a text field onto the clipboard. This can be used to decrease the user's effort. Not all users are fluent with the clipboard.<br />
<br />
* If a forum posting can not be saved due to, for example, editing time having ended, offer the user alternative options that make sense. "30 minutes have passed, so you can no longer edit your forum post. Shown below is what you posted, so you can copy it to your clipboard and from there somewhere safe."<br />
* If a forum reply can not be saved due to the parent item having been deleted, offer users the option to copy their item to the clipboard. In addition, the UI can offer users an option to add their reply to another post in the same thread.<br />
<br />
=== Undo ===<br />
Often, confirmation dialogs (such as preventing accidental leaving of an unsaved form with a javascript dialog) are frustrating to users. In some situations it may be smart to allow the user to perform a potentially destructive action but then give them a chance to undo it, like gmail does.<br />
[[Image:gmail-undo-example.png|left|frame]]<br />
<br style="clear: both" /><br />
<br />
=== Autosave ===<br />
Related forum threads:<br />
* [http://moodle.org/mod/forum/discuss.php?d=74710 AJAX-like Autosave for quiz]<br />
* [http://moodle.org/mod/forum/discuss.php?d=107073 Autosave for Forum Compose?]<br />
In situations where preserving the user's data is critical independent of server or client machine crashes, autosaving the data at a regular interval may be used. <br />
* Autosaving can either mean saving form data continuously, not saving the old version, or keeping a version history. Adding version history functionality requires careful context-sensitive UI design. (Wordpress uses autosaving extensively and may be referred to if this strategy is selected)<br />
** Autosaving can be implemented using AJAX or by just submitting the form in question in the background using javascript.<br />
* The strain on the server produced by autosave can be reduced by only sending new changes to the server, instead of always sending the contents of the form to the server at a specific interval <br />
* When technologies such as Google Gears or the HTML5 equivalent are in use, autosaving can also be done on the local machine, without straining the server.<br />
** This is also probably the only possible strategy when the server has gone down or when the network connection has been lost<br />
<br />
=== "Save as draft" button ===<br />
Sometimes it may be appropriate to let users save their work, before it is finished, without yet publishing it.<br />
<br />
=== Javascript confirmation upon leaving "dirty" form ===<br />
If the user is about to leave page with a form without submitting it, issue a javascript confirmation dialog confirming if they want to do this.<br />
=== TinyMCE ===<br />
The new rich text editor in Moodle 2.0, [[TinyMCE]] apparently does not lose text written in it if you accidentally go back (or forward) in your browser history and then return to the page you were writing on. It is apparently possible though some work to get TinyMCE work in earlier versions of Moodle.<br />
<br />
=== Browser-based solutions ===<br />
Unrelated to Moodle development, browsers may one day integrate functionality currently provided as an [http://lifehacker.com/5097334/lazarus-form-recovery-saves-web-page-form-data extension to at least Firefox] ([https://addons.mozilla.org/en-US/firefox/addon/6984 alternate link]), always storing form data for later recovery. This may raise privacy issues though. <br />
<br />
Also developer tools such as Firebug HTTP traffic listening or the Firefox Tamper Data extension can be used in recovering lost data: Initiate traffic listening, repost the data, read in the tool what data was posted and copy it to the clipboard.<br />
<br />
Users should not have resort to paranoia of writing first in notepad and then copying it to the browser, or using somethin such as these tools.<br />
<br />
It seems the GNOME usability focused browser Epiphany gives confirmations upon leaving "dirty" forms (if trying to close window/tab) even if it is not programmed in (needs to be confirmed).<br />
<br />
== More information ==<br />
* Discussion: [http://moodle.org/mod/forum/discuss.php?d=130005 Critical: Keeping user data safe]<br />
** Linked threads: [http://moodle.org/mod/forum/discuss.php?d=130010] [http://moodle.org/mod/forum/discuss.php?d=130007]<br />
* Directory of [[Development:Major_usability_issues_in_Moodle|Major usability issues in Moodle]]<br />
* A solution applicable in some scenarios: MDL-18014 Tracker item for autosave (thanks Mauno Korpelainen)<br />
* [http://code.google.com/p/tinyautosave/ TinyMCE autosave plugin] (thanks Mauno Korpelainen)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Wizard&diff=72181Development:Wizard2010-05-15T16:03:03Z<p>Pilpi: /* Backup */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''<br />
<br />
== Problem ==<br />
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge <br />
* The task users need to perform naturally divides into subtasks, and the nature or number of subtasks depends on what is selected in some other (preceding) tasks<br />
<br />
== Context ==<br />
You are designing an UI for users who are not experts at a given task that involves entering a lot of information or making intricate selections that depend on each other. <br />
== Forces: factors that affect selection ==<br />
* Unexperienced users may get frustrated<br />
** if too many choices, dependent on each other, are presented to them at once<br />
** if they do not have all the background information related to a task <br />
* Experienced users easily get frustrated<br />
** if a task they know is split into too many phases <br />
** if the order they enter data into the application is controlled<br />
* Any user can be frustrated by lack of control in the process, i.e. not knowing the number of steps left or not being capable of controlling the process (returning back in the process to an earlier screen in case of a misunderstanding or mistake, for example)<br />
<br />
== Solution ==<br />
<br />
A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps. <br />
<br />
=== Elements of a wizard ===<br />
<br />
==== Status display ====<br />
Displays the steps required to complete the wizard, and indicates the step the user is in currently, giving important feedback to the user resulting from their actions, making the application seem responsive.<br />
<br />
==== Navigation buttons ====<br />
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided. <br />
** Obviously, the first page of the wizard does not include a previous button, nor do pages which are a result of actions that can not be undone. <br />
** Unlike one might assume, the Previous button acts as a submit button for the current page, just like the Next button. If the user has made changes on the current page when they decide to return to a previous step, those changes are saved.<br />
**Provide a Previous button whenever possible to maximize user control. <br />
* '''Next''': Used for moving to the next step<br />
** When the next step is to actually start an operation (usually the last step of the wizard), the button is in the same position, but the label is an action verb such as "Start Backup". This is to let users know that they are doing something that actually has consequences and not just continuing to enter data. If the operation that the user is about to start cannot be undone or is in some other way potentially dangerous, consider adding a javascript warning dialog confirming the user wants to continue.<br />
* '''Cancel''': If there is a specific page from which the user can be assumed to have arrived to the wizard from, clicking Cancel will return them to this page. If you can not be sure, determine a reasonable default.<br />
** The Cancel button should in most cases (except in very simple Wizards) have a javascript confirmation dialog associated with it, noting them that all the information they have entered will be lost, and asking them if they really want to continue.<br />
<br />
=== Notes ===<br />
The user should be capable of using the browser's back button normally in a wizard. <br />
* After pressing the Next button, the user should end up in the step that was before the page <br />
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence<br />
* If the user cannot return to the previous step anymore, the user should be returned to the earliest possible screen, or alternatively the wizard should be reinitialized and the user sent to the first page of the wizard <br />
<br />
If there is a danger that experienced users want to use the functionality provided by the wizard and that they want more control than what the wizard provides, provide an alternate user interface to them.<br />
<br />
== Common mistakes ==<br />
<br />
Moodle Wizards typically do not have all of the required buttons nor the status display.<br />
<br />
Each screen is a form, so no links are used for moving between the screens but the next/previous should be used. The added click of selecting a form field and then pressing 'next' is secondary to the problem of potentially losing user data: even if the data is preserved (using javascript which cannot be relied upon anyway), navigation links do not afford this so the user is left anxious. Also usage of back/forward browser buttons is problematic if what user has selected is not saved in the session using a the next/prev buttons (which are technically form submit buttons).<br />
<br />
== Examples and implementation ==<br />
<br />
=== Backup ===<br />
<br />
[[Image:wizard-mockup.png|thumb]] <br />
This mockup (MDL-20036) demonstrates the main features of a wizard. <br />
* Status display and controls for controlling the wizard<br />
* The visual hierarchy of the page expresses that the content in the box with the darker background is part of the wizard, and that this wizard is completes the process of backing up the Course Course Fullname 101.<br />
<br />
Note that this wizard is in the sense not typical that it only contains one step where the user actually does anything actively (enters information). The fact that the single screen contains a lot of information may slow down novices, but since backup can be considered an advanced operation, slowing down more experienced users would be worse.<br />
<br />
* '''Note''': Moodle 2.0 contains a implementation of a wizard done according to MDL-20036 (see MDL-22142). View it at http://qa.moodle.net/backup/backup.php?id=1 (requires login with the qa site testing credentials). A screenshot should be added here as soon as Moodle 2.0 is released.<br />
<br />
'''Further examples and code samples: [[Development:Wizard Examples and Code Samples]]'''<br />
<br />
== Related guidelines ==<br />
Another way of only showing unexperienced users what they understand is using [[Development:Progressive_Disclosure|Progressive Disclosure]]<br />
<br />
== Related issues in the tracker ==<br />
* TODO: all the issues with installation and backup<br />
<br />
== (Optional) Further information / Sources ==<br />
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]<br />
* http://ui-patterns.com/pattern/Wizard<br />
* http://www.welie.com/patterns/showPattern.php?patternID=wizard<br />
* http://uipatternfactory.com/p=wizard/<br />
* http://en.wikipedia.org/wiki/Wizard_(software)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Wizard&diff=72180Development:Wizard2010-05-15T16:02:37Z<p>Pilpi: /* Backup */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''<br />
<br />
== Problem ==<br />
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge <br />
* The task users need to perform naturally divides into subtasks, and the nature or number of subtasks depends on what is selected in some other (preceding) tasks<br />
<br />
== Context ==<br />
You are designing an UI for users who are not experts at a given task that involves entering a lot of information or making intricate selections that depend on each other. <br />
== Forces: factors that affect selection ==<br />
* Unexperienced users may get frustrated<br />
** if too many choices, dependent on each other, are presented to them at once<br />
** if they do not have all the background information related to a task <br />
* Experienced users easily get frustrated<br />
** if a task they know is split into too many phases <br />
** if the order they enter data into the application is controlled<br />
* Any user can be frustrated by lack of control in the process, i.e. not knowing the number of steps left or not being capable of controlling the process (returning back in the process to an earlier screen in case of a misunderstanding or mistake, for example)<br />
<br />
== Solution ==<br />
<br />
A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps. <br />
<br />
=== Elements of a wizard ===<br />
<br />
==== Status display ====<br />
Displays the steps required to complete the wizard, and indicates the step the user is in currently, giving important feedback to the user resulting from their actions, making the application seem responsive.<br />
<br />
==== Navigation buttons ====<br />
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided. <br />
** Obviously, the first page of the wizard does not include a previous button, nor do pages which are a result of actions that can not be undone. <br />
** Unlike one might assume, the Previous button acts as a submit button for the current page, just like the Next button. If the user has made changes on the current page when they decide to return to a previous step, those changes are saved.<br />
**Provide a Previous button whenever possible to maximize user control. <br />
* '''Next''': Used for moving to the next step<br />
** When the next step is to actually start an operation (usually the last step of the wizard), the button is in the same position, but the label is an action verb such as "Start Backup". This is to let users know that they are doing something that actually has consequences and not just continuing to enter data. If the operation that the user is about to start cannot be undone or is in some other way potentially dangerous, consider adding a javascript warning dialog confirming the user wants to continue.<br />
* '''Cancel''': If there is a specific page from which the user can be assumed to have arrived to the wizard from, clicking Cancel will return them to this page. If you can not be sure, determine a reasonable default.<br />
** The Cancel button should in most cases (except in very simple Wizards) have a javascript confirmation dialog associated with it, noting them that all the information they have entered will be lost, and asking them if they really want to continue.<br />
<br />
=== Notes ===<br />
The user should be capable of using the browser's back button normally in a wizard. <br />
* After pressing the Next button, the user should end up in the step that was before the page <br />
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence<br />
* If the user cannot return to the previous step anymore, the user should be returned to the earliest possible screen, or alternatively the wizard should be reinitialized and the user sent to the first page of the wizard <br />
<br />
If there is a danger that experienced users want to use the functionality provided by the wizard and that they want more control than what the wizard provides, provide an alternate user interface to them.<br />
<br />
== Common mistakes ==<br />
<br />
Moodle Wizards typically do not have all of the required buttons nor the status display.<br />
<br />
Each screen is a form, so no links are used for moving between the screens but the next/previous should be used. The added click of selecting a form field and then pressing 'next' is secondary to the problem of potentially losing user data: even if the data is preserved (using javascript which cannot be relied upon anyway), navigation links do not afford this so the user is left anxious. Also usage of back/forward browser buttons is problematic if what user has selected is not saved in the session using a the next/prev buttons (which are technically form submit buttons).<br />
<br />
== Examples and implementation ==<br />
<br />
=== Backup ===<br />
<br />
[[Image:wizard-mockup.png|thumb]] <br />
This mockup (MDL-20036) demonstrates the main features of a wizard. <br />
* Status display and controls for controlling the wizard<br />
* The visual hierarchy of the page expresses that the content in the box with the darker background is part of the wizard, and that this wizard is completes the process of backing up the Course Course Fullname 101.<br />
<br />
Note that this wizard is in the sense not typical that it only contains one step where the user actually does anything actively (enters information). The fact that the single screen contains a lot of information may slow down novices, but since backup can be considered an advanced operation, slowing down more experienced users would be worse.<br />
<br />
* '''Note''': Moodle 2.0 contains a implementation of a wizard done according to MDL-20036 (see MDL-22142). View it at http://qa.moodle.net/backup/backup.php?id=1 (requires login). A screenshot should be added here as soon as Moodle 2.0 is released.<br />
<br />
'''Further examples and code samples: [[Development:Wizard Examples and Code Samples]]'''<br />
<br />
== Related guidelines ==<br />
Another way of only showing unexperienced users what they understand is using [[Development:Progressive_Disclosure|Progressive Disclosure]]<br />
<br />
== Related issues in the tracker ==<br />
* TODO: all the issues with installation and backup<br />
<br />
== (Optional) Further information / Sources ==<br />
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]<br />
* http://ui-patterns.com/pattern/Wizard<br />
* http://www.welie.com/patterns/showPattern.php?patternID=wizard<br />
* http://uipatternfactory.com/p=wizard/<br />
* http://en.wikipedia.org/wiki/Wizard_(software)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Wizard&diff=72179Development:Wizard2010-05-15T16:01:09Z<p>Pilpi: /* Backup */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''<br />
<br />
== Problem ==<br />
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge <br />
* The task users need to perform naturally divides into subtasks, and the nature or number of subtasks depends on what is selected in some other (preceding) tasks<br />
<br />
== Context ==<br />
You are designing an UI for users who are not experts at a given task that involves entering a lot of information or making intricate selections that depend on each other. <br />
== Forces: factors that affect selection ==<br />
* Unexperienced users may get frustrated<br />
** if too many choices, dependent on each other, are presented to them at once<br />
** if they do not have all the background information related to a task <br />
* Experienced users easily get frustrated<br />
** if a task they know is split into too many phases <br />
** if the order they enter data into the application is controlled<br />
* Any user can be frustrated by lack of control in the process, i.e. not knowing the number of steps left or not being capable of controlling the process (returning back in the process to an earlier screen in case of a misunderstanding or mistake, for example)<br />
<br />
== Solution ==<br />
<br />
A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps. <br />
<br />
=== Elements of a wizard ===<br />
<br />
==== Status display ====<br />
Displays the steps required to complete the wizard, and indicates the step the user is in currently, giving important feedback to the user resulting from their actions, making the application seem responsive.<br />
<br />
==== Navigation buttons ====<br />
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided. <br />
** Obviously, the first page of the wizard does not include a previous button, nor do pages which are a result of actions that can not be undone. <br />
** Unlike one might assume, the Previous button acts as a submit button for the current page, just like the Next button. If the user has made changes on the current page when they decide to return to a previous step, those changes are saved.<br />
**Provide a Previous button whenever possible to maximize user control. <br />
* '''Next''': Used for moving to the next step<br />
** When the next step is to actually start an operation (usually the last step of the wizard), the button is in the same position, but the label is an action verb such as "Start Backup". This is to let users know that they are doing something that actually has consequences and not just continuing to enter data. If the operation that the user is about to start cannot be undone or is in some other way potentially dangerous, consider adding a javascript warning dialog confirming the user wants to continue.<br />
* '''Cancel''': If there is a specific page from which the user can be assumed to have arrived to the wizard from, clicking Cancel will return them to this page. If you can not be sure, determine a reasonable default.<br />
** The Cancel button should in most cases (except in very simple Wizards) have a javascript confirmation dialog associated with it, noting them that all the information they have entered will be lost, and asking them if they really want to continue.<br />
<br />
=== Notes ===<br />
The user should be capable of using the browser's back button normally in a wizard. <br />
* After pressing the Next button, the user should end up in the step that was before the page <br />
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence<br />
* If the user cannot return to the previous step anymore, the user should be returned to the earliest possible screen, or alternatively the wizard should be reinitialized and the user sent to the first page of the wizard <br />
<br />
If there is a danger that experienced users want to use the functionality provided by the wizard and that they want more control than what the wizard provides, provide an alternate user interface to them.<br />
<br />
== Common mistakes ==<br />
<br />
Moodle Wizards typically do not have all of the required buttons nor the status display.<br />
<br />
Each screen is a form, so no links are used for moving between the screens but the next/previous should be used. The added click of selecting a form field and then pressing 'next' is secondary to the problem of potentially losing user data: even if the data is preserved (using javascript which cannot be relied upon anyway), navigation links do not afford this so the user is left anxious. Also usage of back/forward browser buttons is problematic if what user has selected is not saved in the session using a the next/prev buttons (which are technically form submit buttons).<br />
<br />
== Examples and implementation ==<br />
<br />
=== Backup ===<br />
<br />
[[Image:wizard-mockup.png|thumb]] <br />
This mockup (MDL-20036) demonstrates the main features of a wizard. <br />
* Status display and controls for controlling the wizard<br />
* The visual hierarchy of the page expresses that the content in the box with the darker background is part of the wizard, and that this wizard is completes the process of backing up the Course Course Fullname 101.<br />
<br />
Note that this wizard is in the sense not typical that it only contains one step where the user actually does anything actively (enters information). The fact that the single screen contains a lot of information may slow down novices, but since backup can be considered an advanced operation, slowing down more experienced users would be worse.<br />
<br />
* '''Note''': Moodle 2.0 contains a implementation of a wizard done according to MDL-20036 (see MDL-22142). View it at http://qa.moodle.net/backup/backup.php (requires login). A screenshot should be added here as soon as Moodle 2.0 is released.<br />
<br />
'''Further examples and code samples: [[Development:Wizard Examples and Code Samples]]'''<br />
<br />
== Related guidelines ==<br />
Another way of only showing unexperienced users what they understand is using [[Development:Progressive_Disclosure|Progressive Disclosure]]<br />
<br />
== Related issues in the tracker ==<br />
* TODO: all the issues with installation and backup<br />
<br />
== (Optional) Further information / Sources ==<br />
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]<br />
* http://ui-patterns.com/pattern/Wizard<br />
* http://www.welie.com/patterns/showPattern.php?patternID=wizard<br />
* http://uipatternfactory.com/p=wizard/<br />
* http://en.wikipedia.org/wiki/Wizard_(software)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Wizard&diff=72178Development:Wizard2010-05-15T15:38:29Z<p>Pilpi: /* Backup */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''<br />
<br />
== Problem ==<br />
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge <br />
* The task users need to perform naturally divides into subtasks, and the nature or number of subtasks depends on what is selected in some other (preceding) tasks<br />
<br />
== Context ==<br />
You are designing an UI for users who are not experts at a given task that involves entering a lot of information or making intricate selections that depend on each other. <br />
== Forces: factors that affect selection ==<br />
* Unexperienced users may get frustrated<br />
** if too many choices, dependent on each other, are presented to them at once<br />
** if they do not have all the background information related to a task <br />
* Experienced users easily get frustrated<br />
** if a task they know is split into too many phases <br />
** if the order they enter data into the application is controlled<br />
* Any user can be frustrated by lack of control in the process, i.e. not knowing the number of steps left or not being capable of controlling the process (returning back in the process to an earlier screen in case of a misunderstanding or mistake, for example)<br />
<br />
== Solution ==<br />
<br />
A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps. <br />
<br />
=== Elements of a wizard ===<br />
<br />
==== Status display ====<br />
Displays the steps required to complete the wizard, and indicates the step the user is in currently, giving important feedback to the user resulting from their actions, making the application seem responsive.<br />
<br />
==== Navigation buttons ====<br />
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided. <br />
** Obviously, the first page of the wizard does not include a previous button, nor do pages which are a result of actions that can not be undone. <br />
** Unlike one might assume, the Previous button acts as a submit button for the current page, just like the Next button. If the user has made changes on the current page when they decide to return to a previous step, those changes are saved.<br />
**Provide a Previous button whenever possible to maximize user control. <br />
* '''Next''': Used for moving to the next step<br />
** When the next step is to actually start an operation (usually the last step of the wizard), the button is in the same position, but the label is an action verb such as "Start Backup". This is to let users know that they are doing something that actually has consequences and not just continuing to enter data. If the operation that the user is about to start cannot be undone or is in some other way potentially dangerous, consider adding a javascript warning dialog confirming the user wants to continue.<br />
* '''Cancel''': If there is a specific page from which the user can be assumed to have arrived to the wizard from, clicking Cancel will return them to this page. If you can not be sure, determine a reasonable default.<br />
** The Cancel button should in most cases (except in very simple Wizards) have a javascript confirmation dialog associated with it, noting them that all the information they have entered will be lost, and asking them if they really want to continue.<br />
<br />
=== Notes ===<br />
The user should be capable of using the browser's back button normally in a wizard. <br />
* After pressing the Next button, the user should end up in the step that was before the page <br />
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence<br />
* If the user cannot return to the previous step anymore, the user should be returned to the earliest possible screen, or alternatively the wizard should be reinitialized and the user sent to the first page of the wizard <br />
<br />
If there is a danger that experienced users want to use the functionality provided by the wizard and that they want more control than what the wizard provides, provide an alternate user interface to them.<br />
<br />
== Common mistakes ==<br />
<br />
Moodle Wizards typically do not have all of the required buttons nor the status display.<br />
<br />
Each screen is a form, so no links are used for moving between the screens but the next/previous should be used. The added click of selecting a form field and then pressing 'next' is secondary to the problem of potentially losing user data: even if the data is preserved (using javascript which cannot be relied upon anyway), navigation links do not afford this so the user is left anxious. Also usage of back/forward browser buttons is problematic if what user has selected is not saved in the session using a the next/prev buttons (which are technically form submit buttons).<br />
<br />
== Examples and implementation ==<br />
<br />
=== Backup ===<br />
<br />
[[Image:wizard-mockup.png|thumb]] <br />
This mockup (MDL-20036) demonstrates the main features of a wizard. <br />
* Status display and controls for controlling the wizard<br />
* The visual hierarchy of the page expresses that the content in the box with the darker background is part of the wizard, and that this wizard is completes the process of backing up the Course Course Fullname 101.<br />
<br />
Note that this wizard is in the sense not typical that it only contains one step where the user actually does anything actively (enters information). The fact that the single screen contains a lot of information may slow down novices, but since backup can be considered an advanced operation, slowing down more experienced users would be worse.<br />
<br />
* '''Note''': Moodle 2.0 contains a implementation of a wizard done according to MDL-20036 (see MDL-22142). View it at [http://qa.moodle.net/backup/backup.php]. A screenshot should be added here as soon as Moodle 2.0 is released.<br />
<br />
'''Further examples and code samples: [[Development:Wizard Examples and Code Samples]]'''<br />
<br />
== Related guidelines ==<br />
Another way of only showing unexperienced users what they understand is using [[Development:Progressive_Disclosure|Progressive Disclosure]]<br />
<br />
== Related issues in the tracker ==<br />
* TODO: all the issues with installation and backup<br />
<br />
== (Optional) Further information / Sources ==<br />
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]<br />
* http://ui-patterns.com/pattern/Wizard<br />
* http://www.welie.com/patterns/showPattern.php?patternID=wizard<br />
* http://uipatternfactory.com/p=wizard/<br />
* http://en.wikipedia.org/wiki/Wizard_(software)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Wizard&diff=72177Development:Wizard2010-05-15T15:38:01Z<p>Pilpi: /* Backup */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''<br />
<br />
== Problem ==<br />
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge <br />
* The task users need to perform naturally divides into subtasks, and the nature or number of subtasks depends on what is selected in some other (preceding) tasks<br />
<br />
== Context ==<br />
You are designing an UI for users who are not experts at a given task that involves entering a lot of information or making intricate selections that depend on each other. <br />
== Forces: factors that affect selection ==<br />
* Unexperienced users may get frustrated<br />
** if too many choices, dependent on each other, are presented to them at once<br />
** if they do not have all the background information related to a task <br />
* Experienced users easily get frustrated<br />
** if a task they know is split into too many phases <br />
** if the order they enter data into the application is controlled<br />
* Any user can be frustrated by lack of control in the process, i.e. not knowing the number of steps left or not being capable of controlling the process (returning back in the process to an earlier screen in case of a misunderstanding or mistake, for example)<br />
<br />
== Solution ==<br />
<br />
A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps. <br />
<br />
=== Elements of a wizard ===<br />
<br />
==== Status display ====<br />
Displays the steps required to complete the wizard, and indicates the step the user is in currently, giving important feedback to the user resulting from their actions, making the application seem responsive.<br />
<br />
==== Navigation buttons ====<br />
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided. <br />
** Obviously, the first page of the wizard does not include a previous button, nor do pages which are a result of actions that can not be undone. <br />
** Unlike one might assume, the Previous button acts as a submit button for the current page, just like the Next button. If the user has made changes on the current page when they decide to return to a previous step, those changes are saved.<br />
**Provide a Previous button whenever possible to maximize user control. <br />
* '''Next''': Used for moving to the next step<br />
** When the next step is to actually start an operation (usually the last step of the wizard), the button is in the same position, but the label is an action verb such as "Start Backup". This is to let users know that they are doing something that actually has consequences and not just continuing to enter data. If the operation that the user is about to start cannot be undone or is in some other way potentially dangerous, consider adding a javascript warning dialog confirming the user wants to continue.<br />
* '''Cancel''': If there is a specific page from which the user can be assumed to have arrived to the wizard from, clicking Cancel will return them to this page. If you can not be sure, determine a reasonable default.<br />
** The Cancel button should in most cases (except in very simple Wizards) have a javascript confirmation dialog associated with it, noting them that all the information they have entered will be lost, and asking them if they really want to continue.<br />
<br />
=== Notes ===<br />
The user should be capable of using the browser's back button normally in a wizard. <br />
* After pressing the Next button, the user should end up in the step that was before the page <br />
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence<br />
* If the user cannot return to the previous step anymore, the user should be returned to the earliest possible screen, or alternatively the wizard should be reinitialized and the user sent to the first page of the wizard <br />
<br />
If there is a danger that experienced users want to use the functionality provided by the wizard and that they want more control than what the wizard provides, provide an alternate user interface to them.<br />
<br />
== Common mistakes ==<br />
<br />
Moodle Wizards typically do not have all of the required buttons nor the status display.<br />
<br />
Each screen is a form, so no links are used for moving between the screens but the next/previous should be used. The added click of selecting a form field and then pressing 'next' is secondary to the problem of potentially losing user data: even if the data is preserved (using javascript which cannot be relied upon anyway), navigation links do not afford this so the user is left anxious. Also usage of back/forward browser buttons is problematic if what user has selected is not saved in the session using a the next/prev buttons (which are technically form submit buttons).<br />
<br />
== Examples and implementation ==<br />
<br />
=== Backup ===<br />
<br />
[[Image:wizard-mockup.png|thumb]] <br />
This mockup (MDL-20036) demonstrates the main features of a wizard. <br />
* Status display and controls for controlling the wizard<br />
* The visual hierarchy of the page expresses that the content in the box with the darker background is part of the wizard, and that this wizard is completes the process of backing up the Course Course Fullname 101.<br />
<br />
Note that this wizard is in the sense not typical that it only contains one step where the user actually does anything actively (enters information). The fact that the single screen contains a lot of information may slow down novices, but since backup can be considered an advanced operation, slowing down more experienced users would be worse.<br />
<br />
* '''Note''': Moodle 2.0 contains a implementation of a wizard done according to MDL-20036. View it at [http://qa.moodle.net/backup/backup.php]. A screenshot should be added here as soon as Moodle 2.0 is released.<br />
<br />
http://tracker.moodle.org/browse/MDL-22142<br />
<br />
'''Further examples and code samples: [[Development:Wizard Examples and Code Samples]]'''<br />
<br />
== Related guidelines ==<br />
Another way of only showing unexperienced users what they understand is using [[Development:Progressive_Disclosure|Progressive Disclosure]]<br />
<br />
== Related issues in the tracker ==<br />
* TODO: all the issues with installation and backup<br />
<br />
== (Optional) Further information / Sources ==<br />
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]<br />
* http://ui-patterns.com/pattern/Wizard<br />
* http://www.welie.com/patterns/showPattern.php?patternID=wizard<br />
* http://uipatternfactory.com/p=wizard/<br />
* http://en.wikipedia.org/wiki/Wizard_(software)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Page_structure_and_types&diff=72176Development:Page structure and types2010-05-15T15:18:54Z<p>Pilpi: /* See also */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}<br />
<br />
This page describes the structure of different types of Moodle pages, using the default theme 'standard' as an example. Much of what is described here can be changed in a custom theme ([[#See also|See also]]).<br />
<br />
== Basic page structure ==<br />
[[Image:basic-page-structure.png||Image 1: Basic page structure]]<br />
<br />
Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.<br />
<br />
=== Header ===<br />
In addition to the main heading of the page, the header also has another area for content defined (right aligned in the above image). Depending on the page, the content of this area is either a navigation menu or the user login info. <br />
<br />
=== Navigation bar ===<br />
<br />
The navigation bar contains a breadcrumb menu. Additionally, it has an element (right aligned in the above image), the contents of which depend on the page and often on the permissions the user viewing the page has.<br />
<br />
=== Main content area ===<br />
<br />
In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.<br />
<br />
The content of the page in the middle is controlled by the teacher. <br />
* Teacher(s) can add and edit the actual content, <br />
* The overall sequencing and organization of the content is controlled by the selected [[Development:Course Format|Course Format]].<br />
<br />
=== Footer ===<br />
<br />
The footer contains a link to the documentation wiki for the page in question, login info, and a link (with the appearance roughly of a button) to go higher up in the hierarchy of the Moodle site.<br />
<br />
=== Implementation ===<br />
Note: May be obsolete from Moodle 2.0 onwards.<br />
<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
<br />
==== Page layout ====<br />
# Print headings with print_heading, use the CSS hooks for IDs and Classes<br />
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes (TODO: Advice usage of boxes in UI design context, is there an unwritten rule when to use them?)<br />
<br />
== Page types == <br />
<br />
TODO: see [[Development_talk:Page_structure_and_types]]<br />
<br />
== Who controls what? ==<br />
<br />
(TODO: Perhaps move this section to moodle site structure or on a page of its own?)<br />
=== Teachers ===<br />
As a metaphor from physical education world, a course is an independent playground for a teacher. This is where they communicate to students the essence of the course. <br />
<br />
The means for teachers to do this in Moodle are:<br />
* in the center column of the content area (course index, containing mostly links to activity modules), and <br />
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles). <br />
<br />
The goals teachers have doing this, i.e. what it means to communicate a course's essence: <br />
* Communicate what is expected of students<br />
* Communicate the overall contents of the course<br />
* The course itself: Give means/tools for students to learn (as described by social constructionism)<br />
<br />
=== Students ===<br />
<br />
Interact mainly with the activity modules placed in a course by a teacher.<br />
<br />
== See also ==<br />
<br />
Please add relevant links to implementation advice.<br />
<br />
* [[Navigation_block]]<br />
* [[Moodle_2.0_release_notes#Navigation]]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Page_structure_and_types&diff=72175Development:Page structure and types2010-05-15T15:16:03Z<p>Pilpi: /* Teachers */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}<br />
<br />
This page describes the structure of different types of Moodle pages, using the default theme 'standard' as an example. Much of what is described here can be changed in a custom theme ([[#See also|See also]]).<br />
<br />
== Basic page structure ==<br />
[[Image:basic-page-structure.png||Image 1: Basic page structure]]<br />
<br />
Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.<br />
<br />
=== Header ===<br />
In addition to the main heading of the page, the header also has another area for content defined (right aligned in the above image). Depending on the page, the content of this area is either a navigation menu or the user login info. <br />
<br />
=== Navigation bar ===<br />
<br />
The navigation bar contains a breadcrumb menu. Additionally, it has an element (right aligned in the above image), the contents of which depend on the page and often on the permissions the user viewing the page has.<br />
<br />
=== Main content area ===<br />
<br />
In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.<br />
<br />
The content of the page in the middle is controlled by the teacher. <br />
* Teacher(s) can add and edit the actual content, <br />
* The overall sequencing and organization of the content is controlled by the selected [[Development:Course Format|Course Format]].<br />
<br />
=== Footer ===<br />
<br />
The footer contains a link to the documentation wiki for the page in question, login info, and a link (with the appearance roughly of a button) to go higher up in the hierarchy of the Moodle site.<br />
<br />
=== Implementation ===<br />
Note: May be obsolete from Moodle 2.0 onwards.<br />
<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
<br />
==== Page layout ====<br />
# Print headings with print_heading, use the CSS hooks for IDs and Classes<br />
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes (TODO: Advice usage of boxes in UI design context, is there an unwritten rule when to use them?)<br />
<br />
== Page types == <br />
<br />
TODO: see [[Development_talk:Page_structure_and_types]]<br />
<br />
== Who controls what? ==<br />
<br />
(TODO: Perhaps move this section to moodle site structure or on a page of its own?)<br />
=== Teachers ===<br />
As a metaphor from physical education world, a course is an independent playground for a teacher. This is where they communicate to students the essence of the course. <br />
<br />
The means for teachers to do this in Moodle are:<br />
* in the center column of the content area (course index, containing mostly links to activity modules), and <br />
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles). <br />
<br />
The goals teachers have doing this, i.e. what it means to communicate a course's essence: <br />
* Communicate what is expected of students<br />
* Communicate the overall contents of the course<br />
* The course itself: Give means/tools for students to learn (as described by social constructionism)<br />
<br />
=== Students ===<br />
<br />
Interact mainly with the activity modules placed in a course by a teacher.<br />
<br />
== See also ==<br />
<br />
* [[Developement:How_Moodle_outputs_HTML]]<br />
* [[Navigation_block]]<br />
* [[Moodle_2.0_release_notes#Navigation]]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Page_structure_and_types&diff=72174Development:Page structure and types2010-05-15T15:15:33Z<p>Pilpi: /* See also */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}<br />
<br />
This page describes the structure of different types of Moodle pages, using the default theme 'standard' as an example. Much of what is described here can be changed in a custom theme ([[#See also|See also]]).<br />
<br />
== Basic page structure ==<br />
[[Image:basic-page-structure.png||Image 1: Basic page structure]]<br />
<br />
Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.<br />
<br />
=== Header ===<br />
In addition to the main heading of the page, the header also has another area for content defined (right aligned in the above image). Depending on the page, the content of this area is either a navigation menu or the user login info. <br />
<br />
=== Navigation bar ===<br />
<br />
The navigation bar contains a breadcrumb menu. Additionally, it has an element (right aligned in the above image), the contents of which depend on the page and often on the permissions the user viewing the page has.<br />
<br />
=== Main content area ===<br />
<br />
In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.<br />
<br />
The content of the page in the middle is controlled by the teacher. <br />
* Teacher(s) can add and edit the actual content, <br />
* The overall sequencing and organization of the content is controlled by the selected [[Development:Course Format|Course Format]].<br />
<br />
=== Footer ===<br />
<br />
The footer contains a link to the documentation wiki for the page in question, login info, and a link (with the appearance roughly of a button) to go higher up in the hierarchy of the Moodle site.<br />
<br />
=== Implementation ===<br />
Note: May be obsolete from Moodle 2.0 onwards.<br />
<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
<br />
==== Page layout ====<br />
# Print headings with print_heading, use the CSS hooks for IDs and Classes<br />
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes (TODO: Advice usage of boxes in UI design context, is there an unwritten rule when to use them?)<br />
<br />
== Page types == <br />
<br />
TODO: see [[Development_talk:Page_structure_and_types]]<br />
<br />
== Who controls what? ==<br />
<br />
(TODO: Perhaps move this section to moodle site structure or on a page of its own?)<br />
=== Teachers ===<br />
As a metaphor from physical education world, a course is an independent playground for a teacher. This is where they communicate to students the essence of the course. <br />
<br />
The means for teachers to do this in Moodle are:<br />
* in the center column of the content area (course index, containing mostly links to activity modules), and <br />
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles). <br />
<br />
The goals teachers have doing this, i.e. what it means to communicate a course's essence: <br />
* Communicate what is expected of students<br />
* Communicate the overall contents of the course (curriculum)<br />
* The course itself: Give means/tools for students to learn (as described by social constructionism)<br />
<br />
=== Students ===<br />
<br />
Interact mainly with the activity modules placed in a course by a teacher.<br />
<br />
== See also ==<br />
<br />
* [[Developement:How_Moodle_outputs_HTML]]<br />
* [[Navigation_block]]<br />
* [[Moodle_2.0_release_notes#Navigation]]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72173Development:Moodle User Interface Guidelines2010-05-15T15:05:01Z<p>Pilpi: </p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
== See also ==<br />
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
* '''[[Using Moodle book]]'''<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72172Development:Moodle User Interface Guidelines2010-05-15T15:04:34Z<p>Pilpi: </p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
The guidelines are also available at [[Category:Moodle_User_Interface_Guidelines]]<br />
<br />
==Moodle basics==<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
== See also ==<br />
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
* '''[[Using Moodle book]]'''<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72171Development:Moodle User Interface Guidelines2010-05-15T15:02:12Z<p>Pilpi: /* See also */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
== See also ==<br />
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
* '''[[Using Moodle book]]'''<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development_talk:Moodle_User_Interface_Guidelines&diff=72168Development talk:Moodle User Interface Guidelines2010-05-15T14:53:27Z<p>Pilpi: </p>
<hr />
<div>== Missing guidelines ==<br />
<br />
=== Unwritten guidelines ===<br />
* Moodle basics<br />
** Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])<br />
* Building blocks<br />
* Hierarchy Browsing List<br />
** [[Development:Course Format|Course Format]]<br />
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design) <br />
** Filter <br />
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)<br />
* Dialog<br />
* Popup Window<br />
* Link lists (menus)<br />
* [[Development:Page Heading|Page Heading]]<br />
<br />
=== Proposed elements ===<br />
We will probably need a process to get these accepted across the community<br />
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])<br />
<br />
=== Guidelines that require further research/discussion ===<br />
'''[[Development:Major usability issues in Moodle]] (separate design projects)'''<br />
<br />
These are plans to create new interaction styles, switch existing conventions for more usable ones, or issues that are still unclear and need to be further discussed to become actual guidelines.<br />
<br />
* [[Development:Switch Button|Switch Button]]<br />
* [[Development:Add element|Add element]]<br />
* [[Development:Jump Navigation|Jump Navigation]]<br />
* Move Element (Course front page model vs. quiz)<br />
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)<br />
* Further research required: Search<br />
* Further research required: Editing modes<br />
* Further research required: Data Listing<br />
* Waiting for developments of Navigation 2.0: Tabs<br />
* Command Popup Menu<br />
<br />
== Todo ==<br />
* [[Development:Moodle User Interface Guidelines:Problem-Solution Summary Table|Problem-Solution Summary Table]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.1.1])<br />
* [[Development:Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])<br />
<br />
--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)<br />
<br />
----</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72167Development:Moodle User Interface Guidelines2010-05-15T14:53:07Z<p>Pilpi: /* Elements */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
== See also ==<br />
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
<br />
'''[[Using Moodle book]]'''<br />
<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development_talk:Moodle_User_Interface_Guidelines&diff=72166Development talk:Moodle User Interface Guidelines2010-05-15T14:52:50Z<p>Pilpi: </p>
<hr />
<div>== Missing guidelines ==<br />
<br />
=== Unwritten guidelines ===<br />
* Moodle basics<br />
** Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])<br />
* Building blocks<br />
** [[Development:Course Format|Course Format]]<br />
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design) <br />
** Filter <br />
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)<br />
* Dialog<br />
* Popup Window<br />
* Link lists (menus)<br />
* [[Development:Page Heading|Page Heading]]<br />
<br />
=== Proposed elements ===<br />
We will probably need a process to get these accepted across the community<br />
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])<br />
<br />
=== Guidelines that require further research/discussion ===<br />
'''[[Development:Major usability issues in Moodle]] (separate design projects)'''<br />
<br />
These are plans to create new interaction styles, switch existing conventions for more usable ones, or issues that are still unclear and need to be further discussed to become actual guidelines.<br />
<br />
* [[Development:Switch Button|Switch Button]]<br />
* [[Development:Add element|Add element]]<br />
* [[Development:Jump Navigation|Jump Navigation]]<br />
* Move Element (Course front page model vs. quiz)<br />
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)<br />
* Further research required: Search<br />
* Further research required: Editing modes<br />
* Further research required: Data Listing<br />
* Waiting for developments of Navigation 2.0: Tabs<br />
* Command Popup Menu<br />
<br />
== Todo ==<br />
* [[Development:Moodle User Interface Guidelines:Problem-Solution Summary Table|Problem-Solution Summary Table]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.1.1])<br />
* [[Development:Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])<br />
<br />
--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)<br />
<br />
----</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72165Development:Moodle User Interface Guidelines2010-05-15T14:52:26Z<p>Pilpi: /* Moodle basics */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
* Hierarchy Browsing List<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
== See also ==<br />
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
<br />
'''[[Using Moodle book]]'''<br />
<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Page_structure_and_types&diff=72164Development:Page structure and types2010-05-15T14:51:52Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}<br />
<br />
This page describes the structure of different types of Moodle pages, using the default theme 'standard' as an example. Much of what is described here can be changed in a custom theme ([[#See also|See also]]).<br />
<br />
== Basic page structure ==<br />
[[Image:basic-page-structure.png||Image 1: Basic page structure]]<br />
<br />
Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.<br />
<br />
=== Header ===<br />
In addition to the main heading of the page, the header also has another area for content defined (right aligned in the above image). Depending on the page, the content of this area is either a navigation menu or the user login info. <br />
<br />
=== Navigation bar ===<br />
<br />
The navigation bar contains a breadcrumb menu. Additionally, it has an element (right aligned in the above image), the contents of which depend on the page and often on the permissions the user viewing the page has.<br />
<br />
=== Main content area ===<br />
<br />
In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.<br />
<br />
The content of the page in the middle is controlled by the teacher. <br />
* Teacher(s) can add and edit the actual content, <br />
* The overall sequencing and organization of the content is controlled by the selected [[Development:Course Format|Course Format]].<br />
<br />
=== Footer ===<br />
<br />
The footer contains a link to the documentation wiki for the page in question, login info, and a link (with the appearance roughly of a button) to go higher up in the hierarchy of the Moodle site.<br />
<br />
=== Implementation ===<br />
Note: May be obsolete from Moodle 2.0 onwards.<br />
<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
<br />
==== Page layout ====<br />
# Print headings with print_heading, use the CSS hooks for IDs and Classes<br />
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes (TODO: Advice usage of boxes in UI design context, is there an unwritten rule when to use them?)<br />
<br />
== Page types == <br />
<br />
TODO: see [[Development_talk:Page_structure_and_types]]<br />
<br />
== Who controls what? ==<br />
<br />
(TODO: Perhaps move this section to moodle site structure or on a page of its own?)<br />
=== Teachers ===<br />
As a metaphor from physical education world, a course is an independent playground for a teacher. This is where they communicate to students the essence of the course. <br />
<br />
The means for teachers to do this in Moodle are:<br />
* in the center column of the content area (course index, containing mostly links to activity modules), and <br />
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles). <br />
<br />
The goals teachers have doing this, i.e. what it means to communicate a course's essence: <br />
* Communicate what is expected of students<br />
* Communicate the overall contents of the course (curriculum)<br />
* The course itself: Give means/tools for students to learn (as described by social constructionism)<br />
<br />
=== Students ===<br />
<br />
Interact mainly with the activity modules placed in a course by a teacher.<br />
<br />
== See also ==<br />
<br />
* [[Developement:How_Moodle_outputs_HTML]]<br />
<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development_talk:Page_structure_and_types&diff=72163Development talk:Page structure and types2010-05-15T14:51:05Z<p>Pilpi: New page: == Page types == In progress: Once Moodle 2.0 is clearer, can be continued. TODO: This <s>should correspond</s> to [[Development:Migrating_your_code_to_the_2.0_rendering_API#You_can_h...</p>
<hr />
<div><br />
== Page types == <br />
<br />
In progress: Once Moodle 2.0 is clearer, can be continued.<br />
<br />
TODO: This <s>should correspond</s> to [[Development:Migrating_your_code_to_the_2.0_rendering_API#You_can_have_different_layout.php_files_for_different_page]]. '''Actually,''' the page types of a hig should describe the different page types that offer differing kinds of interaction. The relationship between a technical page type to the interaction page types is probably N to 1.<br />
<br />
* Editing page<br />
* Site configuration page<br />
* Module configuration page (Update this xxx)<br />
* Organizing page<br />
* Teacher content page<br />
* Application/module functionality page<br />
* Course page<br />
* Data listing page<br />
* Student content page<br />
* Content accumulating page (views to forums posts)<br />
<br />
Hm, on some pages several of these many may apply?</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Page_structure_and_types&diff=72162Development:Page structure and types2010-05-15T14:50:16Z<p>Pilpi: /* Page types */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}<br />
<br />
This page describes the structure of different types of Moodle pages, using the default theme 'standard' as an example. Much of what is described here can be changed in a custom theme ([[#See also|See also]]).<br />
<br />
== Basic page structure ==<br />
[[Image:basic-page-structure.png||Image 1: Basic page structure]]<br />
<br />
Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.<br />
<br />
=== Header ===<br />
In addition to the main heading of the page, the header also has another area for content defined (right aligned in the above image). Depending on the page, the content of this area is either a navigation menu or the user login info. <br />
<br />
=== Navigation bar ===<br />
<br />
The navigation bar contains a breadcrumb menu. Additionally, it has an element (right aligned in the above image), the contents of which depend on the page and often on the permissions the user viewing the page has.<br />
<br />
=== Main content area ===<br />
<br />
In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.<br />
<br />
The content of the page in the middle is controlled by the teacher. <br />
* Teacher(s) can add and edit the actual content, <br />
* The overall sequencing and organization of the content is controlled by the selected [[Development:Course Format|Course Format]].<br />
<br />
=== Footer ===<br />
<br />
The footer contains a link to the documentation wiki for the page in question, login info, and a link (with the appearance roughly of a button) to go higher up in the hierarchy of the Moodle site.<br />
<br />
=== Implementation ===<br />
Note: May be obsolete from Moodle 2.0 onwards.<br />
<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
<br />
==== Page layout ====<br />
# Print headings with print_heading, use the CSS hooks for IDs and Classes<br />
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes (TODO: Advice usage of boxes in UI design context, is there an unwritten rule when to use them?)<br />
<br />
== Page types == <br />
<br />
TODO: see [[Development_talk:Page_structure_and_types]]<br />
<br />
== Who controls what? ==<br />
<br />
(TODO: Perhaps move this section to moodle site structure or on a page of its own?)<br />
=== Teachers ===<br />
As a metaphor from physical education world, a course is an independent playground for a teacher. This is where they communicate to students the essence of the course. <br />
<br />
The means for teachers to do this in Moodle are:<br />
* in the center column of the content area (course index, containing mostly links to activity modules), and <br />
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles). <br />
<br />
The goals teachers have doing this, i.e. what it means to communicate a course's essence: <br />
* Communicate what is expected of students<br />
* Communicate the overall contents of the course (curriculum)<br />
* The course itself: Give means/tools for students to learn (as described by social constructionism)<br />
<br />
=== Students ===<br />
<br />
Interact mainly with the activity modules placed in a course by a teacher.<br />
<br />
== See also ==<br />
<br />
* [[Developement:How_Moodle_outputs_HTML]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Page_structure_and_types&diff=72161Development:Page structure and types2010-05-15T14:49:11Z<p>Pilpi: /* Implementation */</p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}<br />
<br />
This page describes the structure of different types of Moodle pages, using the default theme 'standard' as an example. Much of what is described here can be changed in a custom theme ([[#See also|See also]]).<br />
<br />
== Basic page structure ==<br />
[[Image:basic-page-structure.png||Image 1: Basic page structure]]<br />
<br />
Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.<br />
<br />
=== Header ===<br />
In addition to the main heading of the page, the header also has another area for content defined (right aligned in the above image). Depending on the page, the content of this area is either a navigation menu or the user login info. <br />
<br />
=== Navigation bar ===<br />
<br />
The navigation bar contains a breadcrumb menu. Additionally, it has an element (right aligned in the above image), the contents of which depend on the page and often on the permissions the user viewing the page has.<br />
<br />
=== Main content area ===<br />
<br />
In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.<br />
<br />
The content of the page in the middle is controlled by the teacher. <br />
* Teacher(s) can add and edit the actual content, <br />
* The overall sequencing and organization of the content is controlled by the selected [[Development:Course Format|Course Format]].<br />
<br />
=== Footer ===<br />
<br />
The footer contains a link to the documentation wiki for the page in question, login info, and a link (with the appearance roughly of a button) to go higher up in the hierarchy of the Moodle site.<br />
<br />
=== Implementation ===<br />
Note: May be obsolete from Moodle 2.0 onwards.<br />
<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
# All pages should call print_header, and supply a standard navigation path to be displayed in it. Where possible, it should look like: COURSE >> INDEX >> INSTANCE >> SUBPAGES...<br />
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.<br />
<br />
==== Page layout ====<br />
# Print headings with print_heading, use the CSS hooks for IDs and Classes<br />
# Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes (TODO: Advice usage of boxes in UI design context, is there an unwritten rule when to use them?)<br />
<br />
== Page types == <br />
<br />
NOT FINAL TEXT, in progress. <br />
<br />
TODO: Think about if a page type specific visual hierarchy could be devised?<br />
<br />
TODO: This <s>should correspond</s> to [[Development:Migrating_your_code_to_the_2.0_rendering_API#You_can_have_different_layout.php_files_for_different_page]]. '''Actually,''' the page types of a hig should describe the different page types that offer differing kinds of interaction. The relationship between a technical page type to the interaction page types is probably N to 1.<br />
<br />
* Editing page<br />
* Site configuration page<br />
* Module configuration page (Update this xxx)<br />
* Organizing page<br />
* Teacher content page<br />
* Application/module functionality page<br />
* Course page<br />
* Data listing page<br />
* Student content page<br />
* Content accumulating page (views to forums posts)<br />
<br />
Hm, on some pages several of these many may apply?<br />
<br />
== Who controls what? ==<br />
<br />
(TODO: Perhaps move this section to moodle site structure or on a page of its own?)<br />
=== Teachers ===<br />
As a metaphor from physical education world, a course is an independent playground for a teacher. This is where they communicate to students the essence of the course. <br />
<br />
The means for teachers to do this in Moodle are:<br />
* in the center column of the content area (course index, containing mostly links to activity modules), and <br />
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles). <br />
<br />
The goals teachers have doing this, i.e. what it means to communicate a course's essence: <br />
* Communicate what is expected of students<br />
* Communicate the overall contents of the course (curriculum)<br />
* The course itself: Give means/tools for students to learn (as described by social constructionism)<br />
<br />
=== Students ===<br />
<br />
Interact mainly with the activity modules placed in a course by a teacher.<br />
<br />
== See also ==<br />
<br />
* [[Developement:How_Moodle_outputs_HTML]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Interface_guidelines&diff=72160Development:Interface guidelines2010-05-15T14:46:45Z<p>Pilpi: </p>
<hr />
<div>{{Work in progress}}<br />
This document is not authoritative, it is a collection of ideas and under construction.<br />
<br />
==Keeping it simple==<br />
<br />
Use the minimum interface required to get the job done.<br />
Order the elements by contexts. Give the user a strong orientation where the places are to do several things.<br />
<br />
==Standard pages==<br />
<br />
See [[Development:Address_Bar|Address Bar/URL UI guideline]]<br />
<br />
==One script per major function/page==<br />
<br />
...<br />
<br />
==Page layout==<br />
See: [[Development:Page_structure_and_types#Implementation|Basic page _structure UI guideline]]<br />
<br />
The information that was here has been included there.<br />
<br />
==Form layout==<br />
<br />
See: [[Development:Form|Form UI guideline]] <br />
<br />
==Dealing with tables==<br />
<br />
Use the print_table function whenever possible.<br />
<br />
==Standard navigation tools==<br />
<br />
See: <br />
* [[Development:Page_structure_and_types#Basic_page_structure|Basic page structure UI guideline]]<br />
* [[Development:Link|Link UI guideline]]<br />
* [[Development:Button|Button UI guideline]]<br />
<br />
The information that was here has been incorporated to those pages<br />
<br />
==URLs==<br />
See [[Development:Address_Bar|Address Bar UI guideline]]<br />
<br />
==Buttons vs links==<br />
<br />
See: [[Development:Button]] and [[Development:Link]] UI guidelines.<br />
<br />
The information that was here has been integrated to those documents.<br />
<br />
==Language strings==<br />
<br />
# Use your own language strings in a separate file. Don't use existing language files from moodle.php or other lang files. So translators can translate in the contexts in different ways as terms are used in the special learning culture.<br />
<br />
==CSS naming==<br />
<br />
* Don't add font, color or layout definitions in code. This belongs to CSS theme files.<br />
* See [[Standards|theme standards]]<br />
<br />
==Linking to help==<br />
<br />
* Help buttons should be on the right of the thing (as an exception it can be left, if the thing is right-aligned)<br />
<br />
==Related topics==<br />
<br />
Robin Good's Latest News. "Interaction Design Meets Online Real Estate" 1 Mar. 2005 http://www.masternewmedia.org/news/2005/03/01/interaction_design_meets_online_real.htm<br />
<br />
The article presents a view of virtual spaces with the focus on human actions. It reminded me of communicative approaches like Moodle. The interface serves as the handle of all the communication tools.<br />
<br />
==See also==<br />
<br />
* [[Development:Usability]]<br />
* [[Development:Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]] GSOC 2009 project<br />
<br />
[[Category:Coding guidelines|Interface]]<br />
[[Category:Moodle User Interface Guidelines]]<br />
<br />
[[pt:Guia para interface]]<br />
[[es:Manual de estilo de la interfaz]]<br />
[[ja:インターフェースガイドライン]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72159Development:Moodle User Interface Guidelines2010-05-15T14:46:03Z<p>Pilpi: /* Relevant guidelines from other sites */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
* Hierarchy Browsing List<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
== See also ==<br />
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
<br />
'''[[Using Moodle book]]'''<br />
<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development_talk:Moodle_User_Interface_Guidelines&diff=72158Development talk:Moodle User Interface Guidelines2010-05-15T14:45:19Z<p>Pilpi: </p>
<hr />
<div>== Missing guidelines ==<br />
<br />
=== Unwritten guidelines ===<br />
* Building blocks<br />
** [[Development:Course Format|Course Format]]<br />
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design) <br />
** Filter <br />
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)<br />
* Dialog<br />
* Popup Window<br />
* Link lists (menus)<br />
* [[Development:Page Heading|Page Heading]]<br />
<br />
=== Proposed elements ===<br />
We will probably need a process to get these accepted across the community<br />
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])<br />
<br />
=== Guidelines that require further research/discussion ===<br />
'''[[Development:Major usability issues in Moodle]] (separate design projects)'''<br />
<br />
These are plans to create new interaction styles, switch existing conventions for more usable ones, or issues that are still unclear and need to be further discussed to become actual guidelines.<br />
<br />
* [[Development:Switch Button|Switch Button]]<br />
* [[Development:Add element|Add element]]<br />
* [[Development:Jump Navigation|Jump Navigation]]<br />
* Move Element (Course front page model vs. quiz)<br />
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)<br />
* Further research required: Search<br />
* Further research required: Editing modes<br />
* Further research required: Data Listing<br />
* Waiting for developments of Navigation 2.0: Tabs<br />
* Command Popup Menu<br />
<br />
== Todo ==<br />
* [[Development:Moodle User Interface Guidelines:Problem-Solution Summary Table|Problem-Solution Summary Table]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.1.1])<br />
* [[Development:Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])<br />
<br />
--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)<br />
<br />
----</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72157Development:Moodle User Interface Guidelines2010-05-15T14:45:04Z<p>Pilpi: /* Todo */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
* Hierarchy Browsing List<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
<br />
== See also ==<br />
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
<br />
'''[[Using Moodle book]]'''<br />
<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines:Help_requested&diff=72156Development:Moodle User Interface Guidelines:Help requested2010-05-15T14:44:51Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > Help requested<br />
<br />
You can help by '''commenting on [[Development:Guideline_template]] and on the [[Development:Moodle_User_Interface_Guidelines|guidelines listed]]''' [http://moodle.org/mod/forum/discuss.php?d=126884 in the appropriate forum]. The template describes how the actual guidelines are supposed to be written, so it might be a good idea to read and compare these side-by-side. If you wish, you can even add new guidelines yourself - don't worry about if they look right yet or not - and I can take a look at them too. During July 2009, the number of guidelines will increase - if not by you, then by me. '''I will hope to have a lot of eyes on them to make sure they are easy to understand and use'''.<br />
<br />
The point is to have something everybody will use in development. I want you to reject this, but do it now, please, not later :). [http://moodle.org/mod/forum/discuss.php?d=126884 Tell me what you think might be better]. Let us build this together.<br />
<br />
=== About writing these guidelines ===<br />
* Some pages use the [[Development:Guideline template|Guideline template]], others are freeform prose</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72155Development:Moodle User Interface Guidelines2010-05-15T14:44:33Z<p>Pilpi: /* About writing these guidelines */</p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
* Hierarchy Browsing List<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
<br />
== See also ==<br />
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
<br />
'''[[Using Moodle book]]'''<br />
<br />
<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
== Todo ==<br />
* [[Development:Moodle User Interface Guidelines:Problem-Solution Summary Table|Problem-Solution Summary Table]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.1.1])<br />
* [[Development:Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Moodle_User_Interface_Guidelines&diff=72154Development:Moodle User Interface Guidelines2010-05-15T14:44:10Z<p>Pilpi: </p>
<hr />
<div>__NOTOC__<br />
<p class="note"><br />
<br />
NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines. <br />
<br />
In fact, many of the pages below are currently incomplete or obsolete. They still need a lot of work to be regarded as useful and authoritative guidelines.<br />
<br />
</p><br />
<br />
<br />
These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. <br />
<br />
It does not catalogue all the elements in use in Moodle, but is intended a reference of reusable elements sharing that common Moodle style. We aim to update this reference as new common practices appear. [[Development:Moodle User Interface Guidelines:Introduction|More...]]<br />
* [[Development:Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]<br />
<br />
==Moodle basics==<br />
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])<br />
* [[Development:Page structure and types|Page structure and different page types]]<br />
* [[Roles and capabilities]]<br />
* [[Groups]]<br />
<br />
==Moodle UI library==<br />
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).<br />
=== Elements ===<br />
* [[Development:Big Select List|Big Select List]]<br />
* Hierarchy Browsing List<br />
<br />
* [[Development:Tooltip|Tooltip]]<br />
* [[Development:Link|Link]]<br />
* [[Development:Button|Button]]<br />
* [[Development:Address Bar|Address Bar]] (URLs)<br />
<br />
=== Interaction Styles ===<br />
* [[Development:Wizard|Wizard]]<br />
* [[Development:Help Popups|Help Popups]] (See [[Development:Interface_guidelines#Linking_to_help|Linking to help]] for now)<br />
* [[Development:Feedback page|Feedback page]]<br />
* [[Development:Form|Form]] (incomplete)<br />
** [[Development:Radio button|Radio button]]<br />
** [[Development:Checkbox|Checkbox]]<br />
** [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== General design guidelines ==<br />
* [[Development:Progressive Disclosure|Progressive Disclosure]]<br />
* [[Development:User Data Always Safe|User Data Always (Always) Safe]] <br />
* [[Development:Feedback (User Interface Guideline)|Feedback]] (Incomplete)<br />
=== Relevant guidelines from other sites ===<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]<br />
<br />
<br />
== See also ==<br />
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]<br />
<br />
'''[[Using Moodle book]]'''<br />
=== About writing these guidelines ===<br />
* Some pages use the [[Development:Guideline template|Guideline template]], others are freeform prose<br />
=== Usability in Moodle ===<br />
* [[Development:Usability|Usability]]<br />
* [[Usability_FAQ|Usability FAQ]]<br />
<br />
=== Implementation advice ===<br />
* [[Development:Developer_documentation|Developer documentation]]<br />
* UI coding: [[Development:Interface_guidelines]]<br />
<br />
== Todo ==<br />
* [[Development:Moodle User Interface Guidelines:Problem-Solution Summary Table|Problem-Solution Summary Table]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.1.1])<br />
* [[Development:Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])<br />
<br />
[[Category:Developer|User Interface Guidelines]]<br />
[[Category:Developer tools|User Interface Guidelines]]<br />
[[Category:Usability|User Interface Guidelines]]<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development_talk:Moodle_User_Interface_Guidelines&diff=72153Development talk:Moodle User Interface Guidelines2010-05-15T14:43:40Z<p>Pilpi: New page: == Missing guidelines == === Unwritten guidelines === * Building blocks ** Course Format ** Block (not a technical guide but a guideline how what to take in...</p>
<hr />
<div><br />
== Missing guidelines ==<br />
<br />
=== Unwritten guidelines ===<br />
* Building blocks<br />
** [[Development:Course Format|Course Format]]<br />
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design) <br />
** Filter <br />
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)<br />
* Dialog<br />
* Popup Window<br />
* Link lists (menus)<br />
* [[Development:Page Heading|Page Heading]]<br />
<br />
=== Proposed elements ===<br />
We will probably need a process to get these accepted across the community<br />
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])<br />
<br />
=== Guidelines that require further research/discussion ===<br />
'''[[Development:Major usability issues in Moodle]] (separate design projects)'''<br />
<br />
These are plans to create new interaction styles, switch existing conventions for more usable ones, or issues that are still unclear and need to be further discussed to become actual guidelines.<br />
<br />
* [[Development:Switch Button|Switch Button]]<br />
* [[Development:Add element|Add element]]<br />
* [[Development:Jump Navigation|Jump Navigation]]<br />
* Move Element (Course front page model vs. quiz)<br />
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)<br />
* Further research required: Search<br />
* Further research required: Editing modes<br />
* Further research required: Data Listing<br />
* Waiting for developments of Navigation 2.0: Tabs<br />
* Command Popup Menu<br />
<br />
--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)<br />
<br />
----</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Feedback_(User_Interface_Guideline)&diff=72152Development:Feedback (User Interface Guideline)2010-05-15T14:41:56Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Feedback'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''Status: INCOMPLETE '''<br />This is a guideline for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread]}}<br />
== Problem ==<br />
In order to make it possible for the user to use an application meaningfully, the application must respond meaningfully to each user action.<br />
<br />
== Solution ==<br />
<br />
See: '''GNOME Human Interface Guidelines: [http://library.gnome.org/devel/hig-book/stable/feedback.html.en Feedback] ''' <br />
(for Desktop but still a great guide and mostly applicable to Moodle.)<br />
<br />
== Examples and implementation ==<br />
=== Feedback pages ===<br />
[[Development:Feedback_page|Feedback pages]] are often used in Moodle to provide feedback to the user about successful filling of a form, such as a submission of configuration page or posting to a forum thread.<br />
<br />
=== Wizards ===<br />
<br />
TODO: [[Development:Wizard|Wizards]] should use the status display that tells the user about the steps available and the active step, as feedback to the user about their actions.<br />
<br />
==== Installation ====<br />
The Moodle installation wizard gives the user feedback about its progress by outputting new rows to the current page being displayed, allowing the page to load completely only when the process is complete.<br />
<br />
== Common mistakes ==<br />
<br />
== Related guidelines ==<br />
* [[Development:Feedback page]]<br />
== Related issues in the tracker ==<br />
* TODO: development of Moodle feedback away from the feedback page towards showing feedback on the resulting content page.<br />
<br />
<br />
== Further information / Sources ==<br />
<br />
* TODO: Test and create guideline for: MDL-18224 MDL-18225<br />
* See [http://mahara.org/view/view.php?id=3482 presentation] ([http://mahara.org/artefact/file/download.php?file=14278&view=3482 alternate link]) of workshop by David Mudrak for the future direction of feedback<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:User_Data_Always_Safe&diff=72151Development:User Data Always Safe2010-05-15T14:41:08Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''User Data Always (Always) Safe'''<br />
<br />
<big>'''This is the single most serious usability flaw in Moodle. It also requires a lot of software engineering work to get right.'''<br />
<br />
In all cases, the user's work is sacrosanct. Nothing your <br />
application does should lose or destroy user's work without <br />
explicit user action. - GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]<br />
<br />
* [http://moodle.org/mod/forum/discuss.php?d=130005 Please comment in the related discussion forum] </big><br />
<br />
Every part in Moodle should commit to keeping the data user has entered, safe. <br />
<br />
* In 2009 Facebook has several groups where users have spelled out their frustration when Moodle had lost hours of their work.<br />
* In Finland whenever you tell someone you work for/on Moodle, students spill out their frustration since everyone seems to have the experience of Moodle losing their work. <br />
<br />
Not being capable of trusting an application affects the user experience fatally. Eventually it makes users paranoid and writing their work in a word processor and only copying the final work into the browser, which seems likely to destroy everything given to it. <br />
<br />
This issue requires further user research to find the exact issues involved, but there are also some generally well known mechanisms to employ.<br />
<br />
As Moodle is a web application, keeping user data safe is not trivial.<br />
<br />
==Challenges==<br />
* Users may leave forms without submitting them<br />
** Learning from some desktop applications (GNOME settings dialogs), users may assume their settings get automatically saved when they just enter them.<br />
** Accidentally hitting the back button<br />
** Clicking on a link on the form itself, assuming it is safe<br />
** Pushing a button on their keyboard resulting in accidental usage of the back/next buttons<br />
* Users may fill out forms "inappropriately"<br />
** Missing data <br />
** Session may have expired<br />
*** When user gets logged out for whatever reason: the session ID changes when they log in again so even if they manage to login (in a different window) while keeping the form data, submitting the form again fails and the user loses all submitted data. At a minimum, Moodle should give the user their data back so they do not lose it. <br />
** User may have logged out accidentally (browser crash; browser restores the browser session but not the Moodle session)<br />
** User may no longer be capable of completing the action due to loss of permissions or other reasons<br />
*** A forum post they are were replying to was deleted<br />
*** The time to edit a post has passed while the user was editing the post<br />
* Users may submit data when the server has gone down or network connection lost<br />
* '''There is very probably a lot more: research required.'''<br />
<br />
==Solutions==<br />
<br />
=== Preserve submitted data or giving it back to the user to keep, until it can be saved ===<br />
Taking care of the user's data actively when designing an application is really the only thing that can really keep users safe. Know your users and their context, and find out what they might want to do in an error situation.<br />
<br />
If a user has posted something, but it cannot be saved, never ever just throw the data away (like for example, Forum currently does).<br />
Design your application to request the user what should be done. This requires understanding the situations users may end up in. Examples:<br />
* If the user's session has gotten closed (the user is no longer logged in), request the user to log in again, and tell them about the situation: "'''What you tried to send is safe, but not yet saved.''' The [insert descriptive label for data here] you posted could not be saved, since you are not logged in. Please log in to have Moodle try again to save it for you."<br />
==== Giving the user their data back, for copying to the clipboard ====<br />
Issue: In case the user has gotten logged out, it may be a security risk to give the data out. In other error situations, this is a recommended strategy. <br />
<br />
In some browsers it is possible to have a javascripted button that copies the contents of a text field onto the clipboard. This can be used to decrease the user's effort. Not all users are fluent with the clipboard.<br />
<br />
* If a forum posting can not be saved due to, for example, editing time having ended, offer the user alternative options that make sense. "30 minutes have passed, so you can no longer edit your forum post. Shown below is what you posted, so you can copy it to your clipboard and from there somewhere safe."<br />
* If a forum reply can not be saved due to the parent item having been deleted, offer users the option to copy their item to the clipboard. In addition, the UI can offer users an option to add their reply to another post in the same thread.<br />
<br />
=== Undo ===<br />
Often, confirmation dialogs (such as preventing accidental leaving of an unsaved form with a javascript dialog) are frustrating to users. In some situations it may be smart to allow the user to perform a potentially destructive action but then give them a chance to undo it, like gmail does.<br />
[[Image:gmail-undo-example.png|left|frame]]<br />
<br style="clear: both" /><br />
<br />
=== Autosave ===<br />
Related forum threads:<br />
* [http://moodle.org/mod/forum/discuss.php?d=74710 AJAX-like Autosave for quiz]<br />
* [http://moodle.org/mod/forum/discuss.php?d=107073 Autosave for Forum Compose?]<br />
In situations where preserving the user's data is critical independent of server or client machine crashes, autosaving the data at a regular interval may be used. <br />
* Autosaving can either mean saving form data continuously, not saving the old version, or keeping a version history. Adding version history functionality requires careful context-sensitive UI design. (Wordpress uses autosaving extensively and may be referred to if this strategy is selected)<br />
** Autosaving can be implemented using AJAX or by just submitting the form in question in the background using javascript.<br />
* The strain on the server produced by autosave can be reduced by only sending new changes to the server, instead of always sending the contents of the form to the server at a specific interval <br />
* When technologies such as Google Gears or the HTML5 equivalent are in use, autosaving can also be done on the local machine, without straining the server.<br />
** This is also probably the only possible strategy when the server has gone down or when the network connection has been lost<br />
<br />
=== "Save as draft" button ===<br />
Sometimes it may be appropriate to let users save their work, before it is finished, without yet publishing it.<br />
<br />
=== Javascript confirmation upon leaving "dirty" form ===<br />
If the user is about to leave page with a form without submitting it, issue a javascript confirmation dialog confirming if they want to do this.<br />
=== TinyMCE ===<br />
The new rich text editor in Moodle 2.0, [[TinyMCE]] apparently does not lose text written in it if you accidentally go back (or forward) in your browser history and then return to the page you were writing on. It is apparently possible though some work to get TinyMCE work in earlier versions of Moodle.<br />
<br />
=== Browser-based solutions ===<br />
Unrelated to Moodle development, browsers may one day integrate functionality currently provided as an [http://lifehacker.com/5097334/lazarus-form-recovery-saves-web-page-form-data extension to at least Firefox] ([https://addons.mozilla.org/en-US/firefox/addon/6984 alternate link]), always storing form data for later recovery. This may raise privacy issues though. <br />
<br />
Also developer tools such as Firebug HTTP traffic listening or the Firefox Tamper Data extension can be used in recovering lost data: Initiate traffic listening, repost the data, read in the tool what data was posted and copy it to the clipboard.<br />
<br />
Users should not have resort to paranoia of writing first in notepad and then copying it to the browser, or using somethin such as these tools.<br />
<br />
It seems the GNOME usability focused browser Epiphany gives confirmations upon leaving "dirty" forms (if trying to close window/tab) even if it is not programmed in (needs to be confirmed).<br />
<br />
== More information ==<br />
* Discussion: [http://moodle.org/mod/forum/discuss.php?d=130005 Critical: Keeping user data safe]<br />
** Linked threads: [http://moodle.org/mod/forum/discuss.php?d=130010] [http://moodle.org/mod/forum/discuss.php?d=130007]<br />
* Directory of [[Development:Major_usability_issues_in_Moodle|Major usability issues in Moodle]]<br />
* MDL-18014 Tracker item for autosave (thanks Mauno Korpelainen)<br />
* [http://code.google.com/p/tinyautosave/ TinyMCE autosave plugin] (thanks Mauno Korpelainen)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Progressive_Disclosure&diff=72150Development:Progressive Disclosure2010-05-15T14:40:54Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Progressive Disclosure'''<br />
<br />
== Problem ==<br />
'''You have lots of features, some of which are only needed by a part of your user base and (seriously) distract the rest.'''<br />
<br />
: You have allowed a wide variety of users (user groups) into your user base, which has lead to varying goals. Some are just learning or only want to get the job done. Others want to do something (that requires) more (options/visible features). <br />
<br />
How to accommodate for everybody's needs?<br />
<br />
== Context ==<br />
You are designing an existing or a new user interface for Moodle. You have found out the goals of the user groups with differing needs.<br />
<br />
== Forces: factors that affect selection ==<br />
* Unexperienced users need to first learn the fundamental functionality of an application to be capable of diving in features needed in special situations.<br />
* Unexperienced users may want to play with options to learn them, but may get confused if the application does something unexpected and if they do not know how to go back to the original ("safe") state of the application.<br />
* Users who need some specific additional features do not want to see the ''other special features required by someone else'' - since they do not need it, it is distracting.<br />
* Users who need the hidden features may be distracted if finding functionality they need is hidden and requires extra effort to access. <br />
* Some functionality that is rarely needed on some Moodle sites may be always-required basic functionality on other sites.<br />
<br />
== Solution ==<br />
<br />
[[Image:progressivedisclosure.png|thumb|Image 1: Progressive disclosure in a form]]<br />
<br />
: Progressive disclosure '''defers advanced or rarely used features to a secondary screen''' <nowiki>(or to a section hidden by default)</nowiki>, making applications easier to learn and less error-prone. (Jakob Nielsen; [[Development:Progressive_Disclosure#Further_information_.2F_Sources|edited]])<br />
<br />
: In its purest format, progressive disclosure is about offering a good teaser. (Wikipedia)<br />
<br />
After studying the users' needs, you will know what options or controls are unnecessary to the most common uses of the application. Decide '''reasonable default''' values that are assumed when the user does not see these options.<br />
<br />
# Hide the unnecessary options or controls from the UI that shows by default when a user comes to the UI for the first time.<br />
# Provide one or more icons or links that can be used to reveal the hidden options. (A button should only be used if there is a special reason to do so.) The icon/link should indicate its use and the fact that the options in question are optional. <br />
<br />
Each icon/link should only have options related to a specific user goal; if there are many different goals, create separate icons/links to show just one set of options (related to one user goal) at a time.<br />
<br />
The trick is to let the '''less-experienced users know what they can safely ignore'''. They may be curious and take a peek, but they do so it in the safety of knowing they can still go back and ignore it if what they see is confusing. Also users of the initially hidden features benefit since ''they can skip those extra features they do not need''.<br />
<br />
=== Reasonable defaults ===<br />
* Any options that are hidden with progressive disclosure should have [[Development:Reasonable defaults|reasonable defaults]] so that the application does the Right Thing even if the user does not understand the option in question.<br />
* If users change values of options, they may not understand all the implications. '''Always indicating the default value''' next to or in the form element allows them to revert to the safe defaults ([[Development:Progressive_Disclosure#Related_issues_in_the_tracker|summer 2009 recommendation]]).<br />
<br />
=== Persistence ===<br />
<br />
Unless you have a specific reason not to, make the state of the progressive disclosure persistent across page views for any given user. In other words, when a userselects to see the additional functionality, it will be already open when the user accesses the screen the next time. (Until they hide it again.) <br />
<br />
This way, more experienced users don't constantly have to hunt down options they need frequently.<br />
<br />
The persistence is specific to the element in question. Showing one element does not mean opening any other elements hidden with progressive disclosure.<br />
<br />
=== Predictability ===<br />
Make sure the users who need the advanced functionality find it. Make it easy for the user to discern the elements that appeared when they pushed the Advanced button (or equivalent). The element that the user needs to click to see it needs to be clearly and unambiguously labeled.<br />
<br />
It should be obvious which options were added when the element to show the hidden parts was clicked. In Moodle forms, the items that appeared should be signaled with the [decision not made: see MDL-20011] sign to differentiate them from the items that were visible by default.<br />
<br />
=== Configurability ===<br />
<br />
For some options it may be possible that '''on some sites a given option can not have a reasonable default but should always be selected by users'''. Consider making it possible to disable progressive disclosure in the site configuration for such options.<br />
<br />
== Common mistakes ==<br />
<br />
There are no such things in reality as a novice, an intermediate or an advanced user. Different personas have various dimensions of know-how in terms of computer literacy. You '''have to know what the goals of the greater part of all users''', as well as the goals of the users who need more options. Otherwise, you will get the split, of which options should be hidden from novice users, wrong.<br />
<br />
A common mistake is making users choose what their skill level is, and based on that show more or fewer controls. Progressive disclosure should be based on '''scenarios''' that different actual personas (prototypical users) will be in, and the selection of features to hide is based on knowing their goals.<br />
<br />
== Examples and implementation ==<br />
<br />
<br />
[[Image:progressivedisclosure.png|thumb|Image 1: Progressive disclosure in a form]]<br />
=== ''Simple'' progressive disclosure in a form ===<br />
From: Quiz "Update this Quiz" screen<br />
<br />
* '''Reasonable defaults:''' The options are designed so that ignoring them is safe. (Verify!)<br />
* '''Persistence:''' Moodle remembers the state the form was left in from page load to another. <br />
* '''Predictability:''' The label of the fieldset ("Question behaviour"), within which the 'Show advanced' button is, gives a rough clue about what is hidden behind the button.<br />
<br />
'''Further examples and code samples: [[Development:Progressive Disclosure Implementation]]''' (change the name of this page to "Progressive Disclosure Examples and Code Samples?)<br />
<br />
== Related issues in the tracker ==<br />
<br />
* CREATE: Visible Defaults: The default values of the options should be visible.<br />
** Related: MDL-19659<br />
* MDL-20011 To provide other differentiation from the red required field asterisk * than colour, change the advanced item sign to <big>⚙</big> and include it in the button. Is this utf8 character available in all fonts possibly used with Moodle? <br />
** <small>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 so in addition to being descriptive it is known from elsewhere) lozenge: ◊ In modal logic, the lozenge expresses the possibility of the following expression. For example, the expression ◊P expresses that it is possible that P is true. (Probably this is not commonly understood though)</small><br />
* To be decided: Moodle currently uses various forms of progressive disclosure. Some of these could probably be removed for consistency.<br />
* MDL-20010 Progressive disclosure in Override permissions does not indicate what is advanced<br />
<br />
== Further information / Sources ==<br />
* HTML 5 [http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element details element] can be used to implement a certain type of progressive disclosure as browsers mature (in summer 2009 there was no support yet)<br />
* Jakob Nielsen's Alertbox: [http://www.useit.com/alertbox/progressive-disclosure.html Progressive Disclosure] <br />
* Wikipedia: [http://en.wikipedia.org/wiki/Progressive_disclosure Progressive disclosure]<br />
* Related: [http://www.time-tripper.com/uipatterns/Progressive_Disclosure UI Patterns and Techniques: Progressive Disclosure] (Nielsen calls this Staged Disclosure instead)<br />
* Msdn: [http://msdn.microsoft.com/en-us/library/aa511487.aspx Progressive disclosure controls]<br />
(TODO: search [http://moodle.org/public/search/?cx=017878793330196534763%3A-0qxztjngoy&cof=FORID%3A9&ie=UTF-8&q=progressive+disclosure&sa=Search+moodle.org#919 progressive disclosure] for examples and add some here)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Dropdown_Lists&diff=72149Development:Dropdown Lists2010-05-15T14:40:38Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Dropdown Lists'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''Status: INCOMPLETE'''<br /> This is a guideline for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] }}<br />
== Problem ==<br />
<br />
== Context ==<br />
== Forces: factors that affect selection ==<br />
* There may be too little room for several radio buttons or even for a checkbox<br />
* Dropdowns hide information, and thus slow down users. If users need to make selections in multiple dropdowns one after another, usage quickly becomes frustrating. Dropdowns often require very careful mouse manipulation as the vertical space that needs to be hit usually is not very big. If you click a couple of pixels off, you get to start all over again, and frustration adds up.<br />
<br />
== Solution ==<br />
== Common mistakes ==<br />
<br />
Dropdown lists are used in Moodle (1.9) too much, and should be replaced with a checkbox when the choice is just yes/no, or otherwise usually with radio buttons. <br />
<br />
A dropdown menu is not a navigation menu, but a form element. Hiding the submit button and making the form element submit automatically when a value is selected raises serious accessibility issues: among others, keyboard navigation is seriously hindered on many browsers. Where one is needed, a navigation menu (usually a CSS styled unordered list in HTML) should be used.<br />
<br />
'''Never''' use single select boxes for selection of multiple items (ctrl/shift click to select multiple). Instead always use checkboxes.<br />
<br />
== Examples and implementation ==<br />
<br />
=== Example title ===<br />
== Related guidelines ==<br />
[[Development:Checkbox|Checkboxes]] and [[Development:Radio button|Radio buttons]] should be used instead in most cases.<br />
<br />
== Related issues in the tracker ==<br />
TODO: go through the misuses of dropdown lists and create tickets<br />
<br />
== Further information / Sources ==<br />
GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/controls-option-menus.html.en Drop-down Lists]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Checkbox&diff=72148Development:Checkbox2010-05-15T14:40:21Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Checkbox'''<br />
<br />
== Problem ==<br />
You want to know if a user wants to enable an option or not. <br />
* You want the user to make a binary choice: an option is on or not.<br />
* You may also have several related options, amongst which the user can select zero or more.<br />
<br />
== Context ==<br />
You are designing a form.<br />
<br />
== Forces: factors that affect selection ==<br />
* Radio buttons and dropdown menus are too verbose for a binary choice<br />
* Dropdown menus hide the other choice<br />
<br />
== Solution ==<br />
<br />
Create a checkbox with an id attribute. Add a label for the checkbox '''after''' the checkbox (in left-to-right languages, on the right of the checkbox). As the text content of the label element, write the result of checking the box: <br />
<br />
[] Show me the money<br />
<br />
Moodle forms have a left column for the descriptions of the elements in forms, and a right column for the element itself. Checkboxes should have a easy-to-scan short caption on the left column, so that items are easy to find. Both the checkbox and the actual label of the checkbox on its right side should describe the exact meaning. If there are several related options, group them under the same caption.<br />
<br />
Money display: [] Show me the money<br />
[] Only show big money<br />
<br />
Determine a reasonable default for the value: checked, or unchecked. the reasonable default should be such that if a user does not notice the option, they probably do not mind leaving it to default. If no reasonable default can be determined, you may want to consider highlighting the checkbox in the form it is in, since it is impossible to make a checkbox a required field per se. <br />
<br />
: (Another use of the checkbox is to require users to always check a checkbox, i.e. "[ ] I have read and I accept the terms and conditions", but in this case it is not really an option at all.)<br />
<br />
A special case: Sometimes you may want users to be capable of selecting multiple items in a set, but limit the number of items (a kind of a mix between radio buttons and checkboxes). HTML does not support this limitation directly, but it has to be scripted either in Javascript or server side, in PHP.<br />
<br />
== Common mistakes ==<br />
<br />
* Do not express the option label as a question: "Do you want to see the money?"<br />
* Do not invert the option to negative voice: "Don't show me the money". Most times, only positive voice should be used.<br />
* Do not use radio buttons or dropdowns when there are only two choices.<br />
* '''Never''' use single select boxes for selection of multiple items (ctrl/shift click to select multiple). Instead '''always''' use checkboxes.<br />
<br />
TODO: Add further common mistakes from [http://moodle.org/mod/forum/discuss.php?d=126481]<br />
<br />
== Examples and implementation ==<br />
<br />
Some examples of good and bad implementation:<br />
<br />
* Course settings (course/edit.php) - BAD: uses dropdown yes/no rather than checkbox, uses question (is this a metacourse?)<br />
* Updating or adding database module (course/modedit.php?update=19&return=1) - BAD: uses dropdown yes/no for ratings and comments. Also asks question Require approval?<br />
* In general, a review of each modules is needed as we have similar issues with assignment (prevent late submissions, etc.)<br />
<br />
== Related guidelines ==<br />
<br />
* Radio buttons<br />
* [[Development:Switch Button|Switch Button]]<br />
* Sometimes extra options should be hidden with [[Development:Progressive Disclosure|Progressive disclosure]]<br />
<br />
<br />
== Related issues in the tracker ==<br />
<br />
* MDL-19659 - Usability test: Proper display of configuration variables' default values; related: http://moodle.org/mod/forum/discuss.php?d=124533<br />
** TODO: turn dropdowns into checkboxes and radio buttons in most of Moodle (http://moodle.org/mod/forum/discuss.php?d=126481 )<br />
** TODO: See [[User:Frank_Ralf/Moodle_forms1#Checkboxes]]<br />
<br />
== Further information / Sources ==<br />
* [http://moodle.org/mod/forum/discuss.php?d=126481 Alternatives to yes/no dropdown menus?]<br />
* [http://library.gnome.org/devel/hig-book/stable/controls-check-boxes.html.en GNOME HIG: Check Boxes]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Radio_button&diff=72147Development:Radio button2010-05-15T14:40:05Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Radio button'''<br />
<br />
== Problem ==<br />
There are multiple choices, of which the user can only select one.<br />
<br />
== Context ==<br />
You are designing a form.<br />
<br />
== Forces: factors that affect selection ==<br />
* Radio buttons and dropdown menus are too verbose for a binary choice: use check boxes instead.<br />
* Dropdown menus hide the other choice<br />
* Some times there is no room for a set of radio buttons<br />
<br />
== Solution ==<br />
<br />
Create a set of radio buttons, each with an id attribute. Add a label for each radio button '''after''' the radio button (in left-to-right languages, on the right of the radio button). As the text content of the label element, write the result of selecting the radio button in question: <br />
<br />
Show me the<br />
() Money<br />
() Way to happiness<br />
() Glimmering light of an LCD screen<br />
<br />
Moodle forms have a left column for the descriptions of the elements in forms, and a right column for the element itself. Radio buttons should have a easy-to-scan short caption on the left column, so that items are easy to find. <br />
<br />
Display of desired things Show me the:<br />
() Money<br />
() Way to happiness<br />
() Glimmering light of an LCD screen<br />
<br />
Determine a reasonable default for the value of the set of radio buttons. The reasonable default should be such that if a user does not notice the option, they probably do not mind leaving it to default. If no reasonable default can be determined, you can make the set of radio buttons a required field and have none of the radio buttons selected by default.<br />
<br />
A special case: Sometimes you may want users to be capable of selecting multiple items in a set, but limit the number of items (a kind of a mix between radio buttons and checkboxes). HTML does not support this limitation directly, but you can use checkboxes and then script it either in Javascript or server side, in PHP.<br />
<br />
== Common mistakes ==<br />
<br />
Do not express the option label as a question: "Do you want to see the money?"<br />
<br />
Do not invert the option to negative voice: "Don't show me the money". Most times, only positive voice should be used.<br />
<br />
Do not use radio buttons or dropdowns when there are only two choices.<br />
<br />
== Examples and implementation ==<br />
<br />
<br />
== Related guidelines ==<br />
<br />
* [[Development:Checkbox|Checkbox]]<br />
* [[Development:Switch Button|Switch Button]]<br />
* Sometimes extra options should be hidden with [[Development:Progressive Disclosure|Progressive disclosure]]<br />
<br />
== Related issues in the tracker ==<br />
<br />
* MDL-19659 - Usability test: Proper display of configuration variables' default values; related: http://moodle.org/mod/forum/discuss.php?d=124533<br />
** TODO: turn dropdowns into checkboxes and radio buttons in most of Moodle (http://moodle.org/mod/forum/discuss.php?d=126481 )<br />
** TODO: See [[User:Frank_Ralf/Moodle_forms1]]<br />
<br />
== Further information / Sources ==<br />
* [http://moodle.org/mod/forum/discuss.php?d=126481 Alternatives to yes/no dropdown menus?]<br />
* [http://library.gnome.org/devel/hig-book/stable/controls-radio-buttons.html.en GNOME HIG: Radio Buttons]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Form&diff=72146Development:Form2010-05-15T14:39:50Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Form'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''Status: INCOMPLETE'''<br />This is a guideline template for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread]}}<br />
<br />
== Problem ==<br />
You want to allow users to enter information into the application.<br />
<br />
== Forces: factors that affect selection ==<br />
* There may not be much space. Forms elements are typically verbose and forms require at least a submit button.<br />
<br />
== Solution ==<br />
<br />
Moodle uses progressive disclosure to hide form items that are suspected to be needed a minority of users.<br />
<br />
On simple forms, (less than one page / four elements or less) autofocus the first field of the form on body onload<br />
* 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: [http://tracker.moodle.org/browse/MDL-825 MDL-825]) <br />
<br />
Date selection: use javascript selector (how about time?)<br />
<br />
* Show the more important settings at the top<br />
* Each entry should have a label, and if necessary, a help file<br />
* If there are more than 10 options, split them into required and optional/extra/advanced parameters<br />
<br />
== Common mistakes ==<br />
Autofocusing a field by default is an accessibility issue, see MDL-20410<br />
<br />
== Examples and implementation ==<br />
<br />
=== Site configuration forms ===<br />
=== Module configuration forms ("Update this Forum")===<br />
<br />
== Related guidelines ==<br />
* [[Development:Radio button|Radio button]]<br />
* [[Development:Checkbox|Checkbox]]<br />
* [[Development:Dropdown Lists|Dropdown lists]] (incomplete)<br />
<br />
== Related issues in the tracker ==<br />
<br />
* TODO: Configuration defaults http://moodle.org/mod/forum/discuss.php?d=124533<br />
* TODO: Inconsistency with 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?<br />
<br />
== Further information / Sources ==<br />
<br />
* http://moodle.org/mod/forum/discuss.php?d=122545#p554845<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Feedback_page&diff=72145Development:Feedback page2010-05-15T14:39:35Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Feedback page'''<br />
<br />
{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''Status: INCOMPLETE'''<br />This is a guideline for a [[Development:Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] }}<br />
== Problem ==<br />
You need to give the user [[Development:Feedback|Feedback]] after they have filled a [[Development:Form|Form]].<br />
<br />
== Context ==<br />
== Forces: factors that affect selection ==<br />
* In order to not break the browser's back button, the page that a form is POSTed to needs to redirect to another page<br />
* A separate feedback page slows users down<br />
<br />
== Solution ==<br />
Separate feedback pages are often used in Moodle to provide feedback to the user about successful filling of a form, such as a submission of configuration page or posting to a forum thread.<br />
<br />
Feedback pages include a link to the following page (determined by the developer), and also redirect the user to that page after a specified time.<br />
<br />
== Examples and implementation ==<br />
[[Image:Feedback-page_Moodle2.png|frame|left]]<br />
<br style="clear:both" /><br />
<br />
== Related guidelines ==<br />
== Related issues in the tracker ==<br />
* TODO: Make somehow visually distinct the user-made content that the feedback page shows, so that it does not seem like a part of the feedback page itself.<br />
<br />
== Further information / Sources ==<br />
* [[Development:Feedback|Feedback]]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Wizard&diff=72144Development:Wizard2010-05-15T14:38:46Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''<br />
<br />
== Problem ==<br />
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge <br />
* The task users need to perform naturally divides into subtasks, and the nature or number of subtasks depends on what is selected in some other (preceding) tasks<br />
<br />
== Context ==<br />
You are designing an UI for users who are not experts at a given task that involves entering a lot of information or making intricate selections that depend on each other. <br />
== Forces: factors that affect selection ==<br />
* Unexperienced users may get frustrated<br />
** if too many choices, dependent on each other, are presented to them at once<br />
** if they do not have all the background information related to a task <br />
* Experienced users easily get frustrated<br />
** if a task they know is split into too many phases <br />
** if the order they enter data into the application is controlled<br />
* Any user can be frustrated by lack of control in the process, i.e. not knowing the number of steps left or not being capable of controlling the process (returning back in the process to an earlier screen in case of a misunderstanding or mistake, for example)<br />
<br />
== Solution ==<br />
<br />
A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps. <br />
<br />
=== Elements of a wizard ===<br />
<br />
==== Status display ====<br />
Displays the steps required to complete the wizard, and indicates the step the user is in currently, giving important feedback to the user resulting from their actions, making the application seem responsive.<br />
<br />
==== Navigation buttons ====<br />
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided. <br />
** Obviously, the first page of the wizard does not include a previous button, nor do pages which are a result of actions that can not be undone. <br />
** Unlike one might assume, the Previous button acts as a submit button for the current page, just like the Next button. If the user has made changes on the current page when they decide to return to a previous step, those changes are saved.<br />
**Provide a Previous button whenever possible to maximize user control. <br />
* '''Next''': Used for moving to the next step<br />
** When the next step is to actually start an operation (usually the last step of the wizard), the button is in the same position, but the label is an action verb such as "Start Backup". This is to let users know that they are doing something that actually has consequences and not just continuing to enter data. If the operation that the user is about to start cannot be undone or is in some other way potentially dangerous, consider adding a javascript warning dialog confirming the user wants to continue.<br />
* '''Cancel''': If there is a specific page from which the user can be assumed to have arrived to the wizard from, clicking Cancel will return them to this page. If you can not be sure, determine a reasonable default.<br />
** The Cancel button should in most cases (except in very simple Wizards) have a javascript confirmation dialog associated with it, noting them that all the information they have entered will be lost, and asking them if they really want to continue.<br />
<br />
=== Notes ===<br />
The user should be capable of using the browser's back button normally in a wizard. <br />
* After pressing the Next button, the user should end up in the step that was before the page <br />
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence<br />
* If the user cannot return to the previous step anymore, the user should be returned to the earliest possible screen, or alternatively the wizard should be reinitialized and the user sent to the first page of the wizard <br />
<br />
If there is a danger that experienced users want to use the functionality provided by the wizard and that they want more control than what the wizard provides, provide an alternate user interface to them.<br />
<br />
== Common mistakes ==<br />
<br />
Moodle Wizards typically do not have all of the required buttons nor the status display.<br />
<br />
Each screen is a form, so no links are used for moving between the screens but the next/previous should be used. The added click of selecting a form field and then pressing 'next' is secondary to the problem of potentially losing user data: even if the data is preserved (using javascript which cannot be relied upon anyway), navigation links do not afford this so the user is left anxious. Also usage of back/forward browser buttons is problematic if what user has selected is not saved in the session using a the next/prev buttons (which are technically form submit buttons).<br />
<br />
== Examples and implementation ==<br />
<br />
=== Backup ===<br />
<br />
[[Image:wizard-mockup.png|thumb]] Moodle currently has no wizards with a proper UI (August 2009), but this mockup (MDL-20036) demonstrates the main features of a wizard. <br />
* Status display and controls for controlling the wizard<br />
* The visual hierarchy of the page expresses that the content in the box with the darker background is part of the wizard, and that this wizard is completes the process of backing up the Course Course Fullname 101.<br />
<br />
Note that this wizard is in the sense not typical that it only contains one step where the user actually does anything actively (enters information). The fact that the single screen contains a lot of information may slow down novices, but since backup can be considered an advanced operation, slowing down more experienced users would be worse.<br />
<br />
'''Further examples and code samples: [[Development:Wizard Examples and Code Samples]]'''<br />
<br />
== Related guidelines ==<br />
Another way of only showing unexperienced users what they understand is using [[Development:Progressive_Disclosure|Progressive Disclosure]]<br />
<br />
== Related issues in the tracker ==<br />
* TODO: all the issues with installation and backup<br />
<br />
== (Optional) Further information / Sources ==<br />
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]<br />
* http://ui-patterns.com/pattern/Wizard<br />
* http://www.welie.com/patterns/showPattern.php?patternID=wizard<br />
* http://uipatternfactory.com/p=wizard/<br />
* http://en.wikipedia.org/wiki/Wizard_(software)<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Address_Bar&diff=72143Development:Address Bar2010-05-15T14:38:31Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Address Bar'''<br />
<br />
On the web, URLs (web addresses, ''Uniform Resource Locator'') are a part of the user interface and some users routinely use the address bar to navigate sites (for example, for getting higher in the hierarchy if they don't find an easier way in the site navigation).<br />
<br />
In Moodle, The form of URLs is determined by a motivation to make work easy for developers, which is important in an open source community to make it easy to edit different parts of Moodle. Usually it is enough to just look at the URL to know which PHP file to edit. <br />
<br />
As a consequence, the site hierarchy is not reflected in the URL - the end user is not considered the primary user of URLs, unlike usually recommended. <br />
<br />
Examples<br />
* Course front pages are at moodlesite/course/view.php?id=2<br />
* Regardless of the course an activity module instance, such as a forum belongs to, it's URL is moodlesite/mod/forum/view.php?id=13<br />
<br />
== Guidelines ==<br />
# URLs should be as short as possible.<br />
# No underscores in parameter names or files names<br />
# Never use two words when one would do.<br />
<br />
===Activity modules===<br />
<br />
*''index.php'' - lists all instances for that module in a course<br />
*''view.php'' - displays a particular instance<br />
*''config.html'' - configure an instance of the module<br />
<br />
===Blocks===<br />
<br />
*''config.html'' - configure an instance of the block<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Button&diff=72142Development:Button2010-05-15T14:38:14Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Link'''<br />
<br />
== Problem ==<br />
The user needs to be provided the choice to issue a command. This command may be to submit form data.<br />
<br />
== Forces: factors that affect selection ==<br />
* Links take up less screen real estate than buttons<br />
* Buttons should be preferred for (at least primary) commands<br />
* A button is like a promise to the user that something will happen: the state of the application will change when the button is clicked. 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.<br />
<br />
== Solution ==<br />
The label of a button should be a command verb: "Save Settings".<br />
<br />
Actions which can modify the state of Moodle (data files, database, session information) should be performed through buttons.<br />
<br />
Buttons should never be used for navigation. Instead, use [[Development:Link|links]].<br />
<br />
With buttons, the command is usually mediated to the server in form of a POST parameter. Pressing the back button results the browser asking if the user wants to resubmit the form. To avoid this and keep the back button functional, redirect (using HTTP headers) the resulting page, to a new page after processing the data the browser sent.<br />
<br />
== Related guidelines ==<br />
* [[Development:Link|Link]]<br />
<br />
== Related issues in the tracker ==<br />
* TODO: The course groups management UI uses buttons for navigation within the UI<br />
<br />
== Further information / Sources ==<br />
* [http://www.useit.com/alertbox/20040510.html Visualizing Links<nowiki>: 7 Design Guidelines (Jakob Nielsen's Alertbox)</nowiki>]<br />
* [http://www.useit.com/alertbox/command-links.html Command Links (Jakob Nielsen's Alertbox)]<br />
* [http://www.useit.com/alertbox/within_page_links.html Avoid Within-Page Links (Jakob Nielsen's Alertbox)]<br />
* [http://www.useit.com/alertbox/nanocontent.html First 2 Words: A Signal for the Scanning Eye (Jakob Nielsen's Alertbox)]<br />
<br />
* [http://msdn.microsoft.com/en-us/library/aa511454.aspx Buttons vs. Links http://msdn.microsoft.com/en-us/library/aa511454.aspx]<br />
* [http://discuss.joelonsoftware.com/default.asp?design.4.403046.4 links: http://msdn.microsoft.com/en-us/library/aa511483.aspx]<br />
* [http://discuss.joelonsoftware.com/default.asp?design.4.403046.4 http://discuss.joelonsoftware.com/default.asp?design.4.403046.4]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Link&diff=72141Development:Link2010-05-15T14:37:59Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Link'''<br />
<br />
== Problem ==<br />
The user needs to be provided the choice to issue a command or to navigate in the user interface.<br />
<br />
== Forces: factors that affect selection ==<br />
* Links take up less screen real estate than buttons<br />
* Links are meant primarily for navigation and users may not expect clicking them to have consequences<br />
** If used for commands, this can be alleviated by having the link label clearly state what it does as command verbs: "Undo"<br />
<br />
== Solution ==<br />
Best practice is to label navigational links the same to their target page's main heading (or title). This way, the user experience has continuity: users get what they expect.<br />
<br />
For command links, use an action verb. When using command links, the command is mediated to the server in form of a GET parameter. To keep all Moodle URLs bookmarkable, redirect (using HTTP headers) any page, the url of which contains GET parameters that result in user data being changed, to a new URL that does not contain the GET parameter.<br />
<br />
Popups are adviced against. Users easily lose context when a new window opens. If you absolutely must use popups, have the actual URL in the href attribute of the HTML anchor (a) element, and use an event to create the popup. This way, links are still bookmarkable, can be opened to a new tab, and still work without javascript.<br />
<br />
I have testified numerous times in usability testing, <br />
a user clicking a link: when a new window opens, the user<br />
does not realize this (despite a new button appearing in <br />
the task bar of the operating system). They are puzzled <br />
and lost when the back button is broken. <br />
--[[User:Olli Savolainen|Olli Savolainen]] 19:26, 8 August 2009 (UTC)<br />
<br />
=== Icons ===<br />
Links should include associated image (if available). For example, looking at an assignment in a course displays the assignment pic and then the assignment description as a single link; however, most of the blocks like the activity block exclude the image from the link. This is important as some folks are more graphically rather than text oriented and click on the picture and do not understand why it is not working. We need to be consistent (see MDL-6820). ([[Development:Interface_guidelines]])<br />
<br />
== Related guidelines ==<br />
* [[Development:Button]]<br />
<br />
== Further information / Sources ==<br />
* [http://www.useit.com/alertbox/20040510.html Visualizing Links<nowiki>: 7 Design Guidelines (Jakob Nielsen's Alertbox)</nowiki>]<br />
* [http://www.useit.com/alertbox/command-links.html Command Links (Jakob Nielsen's Alertbox)]<br />
* [http://www.useit.com/alertbox/within_page_links.html Avoid Within-Page Links (Jakob Nielsen's Alertbox)]<br />
* [http://www.useit.com/alertbox/nanocontent.html First 2 Words: A Signal for the Scanning Eye (Jakob Nielsen's Alertbox)]<br />
<br />
* [http://msdn.microsoft.com/en-us/library/aa511454.aspx Buttons vs. Links http://msdn.microsoft.com/en-us/library/aa511454.aspx]<br />
* [http://discuss.joelonsoftware.com/default.asp?design.4.403046.4 links: http://msdn.microsoft.com/en-us/library/aa511483.aspx]<br />
* [http://discuss.joelonsoftware.com/default.asp?design.4.403046.4 http://discuss.joelonsoftware.com/default.asp?design.4.403046.4]<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Tooltip&diff=72140Development:Tooltip2010-05-15T14:37:27Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Tooltip'''<br />
<br />
== Problem ==<br />
You have an item in the user interface, the visual outlook of which does not communicate its function and usage. There is insufficient room in the UI for a more verbose UI element, the function and usage of which would be more clear at a glance.<br />
<br />
<br />
<br />
== Forces: factors that affect selection ==<br />
* Elements that appear only if the user knows where to look for them may never be discovered.<br />
<br />
== Solution ==<br />
Moodle uses tooltips extensively. Tooltips can be simple title elements or YUI tooltips can be used for bigger tooltips.<br />
<br />
== Common mistakes ==<br />
Tooltips are best used on functional elements that can be clicked, as an aiding device helping the user understand the concequences of the click. They should be avoided on static, nonfunctional elements, and [[Development:Help Popups|Help Popups]] should usually be used instead.<br />
<br />
== Examples and implementation ==<br />
<br />
Moodle has many command icons, which have tooltips to help users understand/remember their usage.<br />
<br />
In Moodle 2.0, YUI tooltips are used to display quick previews of [[Development:Help Popups|Help Popups]].<br />
<br />
== Further information / Sources ==<br />
TODO<br />
<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpihttps://docs.moodle.org/38/en/index.php?title=Development:Big_Select_List&diff=72139Development:Big Select List2010-05-15T14:36:56Z<p>Pilpi: </p>
<hr />
<div>[[Development: Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Big Select List'''<br />
<br />
== Problem ==<br />
User needs to select one or more items from a potentially '''very''' large master list.<br />
<br />
<br />
== Forces: factors that affect selection ==<br />
<br />
* If there are too many items in a list from which a user has to find items to select, finding what they need becomes difficult<br />
** The largest Moodle sites have hundreds of thousands of users, tens of thousands of courses, and some courses contain over a thousand students. <br />
* If there is a list with radio buttons it can be searched with the browser's find functionality, if the user knows it<br />
* The SELECT element in HTML can have multiple items in it selected by pushing an additional key on the keyboard while clicking with the mouse<br />
** requires quite intricate hand coordination which is probably too much for some of our users <br />
** the selection is easily lost by accident <br />
** users might not know about the additional key<br />
* A list with too many elements on it is very slow to load<br />
* A complete list of all options becomes awkward to work with before it reaches 100 entries, even if it is sorted alphabetically.<br />
* If interaction with the list (adding selection, searching) requires a new page load, it easily becomes very slow and it becomes less apparent what the application did in reaction to the user's action<br />
* Some users may not have javascript support on, so it cannot be depended on<br />
<br />
== Solution ==<br />
[[Image:bigselectlist-assignroles-moodle2.png|thumb|Image 1: Big Select List (Moodle 2.0)]]<br />
* Put two select boxes side by side and buttons for adding and removing elements between them.<br />
* Under each select box, add a text field and a 'Search' button next to it. (In Moodle 1.9, only under the select box on the right)<br />
<br />
Users can select one or more elements in one of the select lists, and press <nowiki>[◀ Add]</nowiki> or <nowiki>[Remove ▶]</nowiki> to move them to the other list.<br />
<br />
Users can write a search term (which fields of the user's profile does this search?) and trigger the <nowiki>[Search]</nowiki> to have the list only show those users with data matching the search terms. This is the only way to use the UI in case there are too many users in the list and they can not be listed all at once.<br />
<br />
== Examples and implementation ==<br />
TODO: Further explain the example below.<br />
=== Assign course roles UI ===<br />
[[Image:bigselectlist-assignroles-moodle2.png|thumb|Image 1: Big Select List (Moodle 2.0)]]<br />
[[Image:bigselectlist-assignroles.png|thumb|Image 2: Moodle 1.9 version of Big Select List with lots of selectable users]]<br />
*Assign role 'x' in Course: y<br />
** [http://cvs.moodle.org/moodle/admin/roles/assign.php?revision=1.98&view=markup /moodle2cvs/admin/roles/assign.php]<br />
<br />
TODO: Create [[Development:Big Select List Implementation]]<br />
<br />
=== Bulk User actions ===<br />
See http://moodle.org/mod/forum/discuss.php?d=126884#p565022<br />
<br />
"Another data point for the "Big Select List": the bulk user actions page has a similar but different interface. The positions of the "selected" and "available" users are swapped, the "filter" (rather than search) box is at the very top, and the add/remove buttons are below the lists, rather than between the lists. "<br />
<br />
=== Groups: Add/remove users ===<br />
An extended variation which also shows which groups a given user is in already.<br />
<br />
== Further information / Sources ==<br />
TODO: Anyone, if you know of any, please add references if you know any other place this kind of an UI is discussed or described. Was it created originally for Moodle?<br />
<br />
<br />
[[Category:Moodle User Interface Guidelines]]</div>Pilpi