MoodleDocs - User contributions [en]

Checkbox

2019-04-16T09:08:37Z

Pilpi: /* Common mistakes */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Checkbox'''

== Problem ==
You want to know if a user wants to enable an option or not.
* You want the user to make a binary choice: an option is on or not.
* You may also have several related options, amongst which the user can select zero or more.

== Context ==
You are designing a form.

== Forces: factors that affect selection ==
* Radio buttons and dropdown menus are too verbose for a binary choice
* Dropdown menus hide the other choice

== Solution ==

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:

[] Show me the money

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.

Money display: [] Show me the money
[] Only show big money

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.

: (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.)

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.

== Common mistakes ==

* Do not express the option label as a question: "Do you want to see the money?"
* Do not invert the option to negative voice: "Don't show me the money". Most times, only positive voice should be used.
* Do not use radio buttons or dropdowns when there are only two choices.
* '''Never''' use single select boxes for selection of multiple items (which require user to ctrl/shift click items, to select multiple). Instead '''always''' use checkboxes.

TODO: Add further common mistakes from [http://moodle.org/mod/forum/discuss.php?d=126481]

== Examples and implementation ==

Some examples of good and bad implementation:

* Course settings (course/edit.php) - BAD: uses dropdown yes/no rather than checkbox, uses question (is this a metacourse?)
* 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?
* In general, a review of each modules is needed as we have similar issues with assignment (prevent late submissions, etc.)

== Related guidelines ==

* Radio buttons
* [[Switch Button|Switch Button]]
* Sometimes extra options should be hidden with [[Progressive Disclosure|Progressive disclosure]]

== Related issues in the tracker ==

* MDL-19659 - Usability test: Proper display of configuration variables' default values; related: http://moodle.org/mod/forum/discuss.php?d=124533
** TODO: turn dropdowns into checkboxes and radio buttons in most of Moodle (http://moodle.org/mod/forum/discuss.php?d=126481 )
** TODO: See [[User:Frank_Ralf/Moodle_forms1#Checkboxes]]

== Further information / Sources ==
* [http://moodle.org/mod/forum/discuss.php?d=126481 Alternatives to yes/no dropdown menus?]
* [https://developer.gnome.org/hig/3.14/check-boxes.html.en GNOME HIG: Check Boxes]

[[Category:Moodle User Interface Guidelines]]

Themes overview

2019-02-15T11:28:23Z

Pilpi: /* Better than CSS correct erroneous claim about css variables

{{Template:Themes}}
Welcome to the new world of themes in Moodle!

A Moodle theme allows the user to change the look and feel of a Moodle site. Themes can be applied on the site, category, course and activity levels by users with permissions to do so. Themes can be designed for specific devices such as mobile phones or tablets. This page explains how themes work in Moodle and is intended to help you create or modify most themes for Moodle.

You can use contributed themes or create your entire own to share with the community. Themes can also be based on parent themes with only few customizations. Themes accomplish this using CSS, changing the underlying markup structure and also adding Javascript to add more advanced behaviors.

Most theme developers simply add a few changes to their new theme by basing it on an existing one. The Moodle Theme architecture is designed in such a way whereby the base theme will act as a fall-back that is used when nothing has been defined in the theme based on it. This makes it easy to create new themes that simply seek out to make minor changes.

==Whats new?==

When Moodle releases a new version. All changes that affect themes are listed in the theme/upgrade.txt file. This is the most up-to date place to find about all changes to a specific version of Moodle and will always be kept up to date.

[https://github.com/moodle/moodle/blob/master/theme/upgrade.txt View upgrade notes]

==The structure of a theme==

Some important things to know when building good themes:

# '''config.php''' - this file is required in every theme. It defines configuration settings and definitions required to make the theme work in Moodle. These include theme, file, region, default region and options.
# '''Layouts and layout files''' - in config.php there is one definition for each page type (see [[#theme_layouts_table|Appendix A: Theme layouts]] for a list of over 12 types). Each page type definition tells Moodle which layout file will be used, what block regions this page type should display and so on. The layout file contains the HTML and the minimum PHP required to display basic structure of pages.
# '''The boost theme''' - is intended to be the best theme to use as a starting point for building a new theme. It supports all the latest theme features and it tries to stay as true to the [http://getbootstrap.com/ Bootstrap] css framework as possible. [[Creating a theme based on boost]]

===Files and folders===
A theme's files are placed in a folder with under moodle/theme folder and have subfolders. They are laid out like this:

{| class="nicetable"
|-
! Directory
! File
! Description
|-
| /
| config.php
| Contains all of the configuration and definitions for each theme
|-
| /
| lib.php
| Contains speciality functions that are used by theme
|-
| /classes
| *.php
| Contains auto-loaded classes for the theme. See [[Automatic class loading]] for more details.
|-
| /classes/output
| *.php
| This is the location for the theme to define overridden renderers. See [[Output renderers]] for more details.
|-
| /
| settings.php
| Contains custom theme settings. These local settings are defined by the theme allowing an administrator to easily alter something about the way it looks or operates. (eg a background colour, or a header image)
|-
| /
| version.php
| Contains the theme name, version number and Moodle version requirements for using the theme
|-
| /fonts/
| *.woff, *.ttf, *.eot, *.svg, *.otf
| Theme fonts (since 2.6).
|-
| /fonts_core/
| *.woff, *.ttf, *.eot, *.svg, *.otf
| Contains fonts that override standard core fonts (since 2.6).
|-
| /fonts_plugins/plugintype/pluginname/
| *.woff, *.ttf, *.eot, *.svg, *.otf
| Contains fonts that override plugin fonts (since 2.6).
|-
| /amd/src/
| *.js
| All specialty JavaScript files the theme requires should be located in here. Javascript should be written as an AMD module. For more information see [[Javascript Modules]].
|-
| /lang/[langcode]/
| *.php
| Any special language files the theme requires should be located in here.
|-
| /templates/
| *.mustache
| Contains the mustache template files for the themes. (Including overridden ones). See [[Templates]] for more information.
|-
| /layout/
| *.php
| Contains the layout files for the theme.
|-
| /pix/
| *.png, *.jpg, *.gif, *.svg
| Contains any images the theme makes use of either in CSS or in the layout files.
|-
| /pix/
| favicon.ico
| The favicon to display for this theme.
|-
| /pix/
| screenshot.png
| A screenshot of the theme to be displayed in on the theme selection screen.
|-
| /pix_core/
| *.png, *.jpg, *.gif, *.svg
| Contains images that override standard core images.
|-
| /pix_plugins/plugintype/pluginname/
| *.png, *.jpg, *.gif, *.svg
| Contains images that override plugin images.
|-
| /style/
| *.css
| Default location for CSS files.
|-
| /less/
| *.less
| Default location for Less files if your theme uses less.
|-
| /scss/
| *.scss
| Default location for SCSS files if your theme uses SCSS.
|}

There are also several other places that stylesheets can be included from (see the CSS how and why section below).

It is possible to override icons used in base themes without interfering with core code by placing these in dataroot/pix and dataroot/pix_plugins. Where a theme extends a base theme and provides its own icons, these icons will still be used.

It is possible to override mustache templates used in base themes without interfering with core code by placing these in templates/[componentname]/[templatename].mustache.

==Theme options==
All theme options are set within the config.php file for the theme. The settings that are most used are: parents, sheets, layouts, and javascripts. Have a look at the '''[[#theme_options_table|theme options table]]''' for a complete list of theme options which include lesser used specialised or advanced settings.

===Basic theme config example===
Lets have a look at the boost theme configuration file and the different bits that make it up:
<code php>
defined('MOODLE_INTERNAL') || die();

require_once(__DIR__ . '/lib.php');

$THEME->name = 'boost';
$THEME->sheets = [];
$THEME->editor_sheets = [];
$THEME->scss = function($theme) {
return theme_boost_get_main_scss_content($theme);
};

$THEME->layouts = [
// Most backwards compatible layout without the blocks - this is the layout used by default.
'base' => array(
'file' => 'columns1.php',
'regions' => array(),
),
// Standard layout with blocks, this is recommended for most pages with general information.
'standard' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// Main course page.
'course' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
'options' => array('langmenu' => true),
),
'coursecategory' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// Part of course, typical for modules - default page layout if $cm specified in require_login().
'incourse' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// The site home page.
'frontpage' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
'options' => array('nonavbar' => true),
),
// Server administration scripts.
'admin' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// My dashboard page.
'mydashboard' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
'options' => array('langmenu' => true),
),
// My public page.
'mypublic' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
'login' => array(
'file' => 'login.php',
'regions' => array(),
'options' => array('langmenu' => true),
),

// Pages that appear in pop-up windows - no navigation, no blocks, no header.
'popup' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nonavbar' => true),
),
// No blocks and minimal footer - used for legacy frame layouts only!
'frametop' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nocoursefooter' => true),
),
// Embeded pages, like iframe/object embeded in moodleform - it needs as much space as possible.
'embedded' => array(
'file' => 'embedded.php',
'regions' => array()
),
// Used during upgrade and install, and for the 'This site is undergoing maintenance' message.
// This must not have any blocks, links, or API calls that would lead to database or cache interaction.
// Please be extremely careful if you are modifying this layout.
'maintenance' => array(
'file' => 'maintenance.php',
'regions' => array(),
),
// Should display the content and basic headers only.
'print' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nonavbar' => false),
),
// The pagelayout used when a redirection is occuring.
'redirect' => array(
'file' => 'embedded.php',
'regions' => array(),
),
// The pagelayout used for reports.
'report' => array(
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre',
),
// The pagelayout used for safebrowser and securewindow.
'secure' => array(
'file' => 'secure.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre'
)
];

$THEME->parents = [];
$THEME->enable_dock = false;
$THEME->csstreepostprocessor = 'theme_boost_css_tree_post_processor';
$THEME->extrascsscallback = 'theme_boost_get_extra_scss';
$THEME->prescsscallback = 'theme_boost_get_pre_scss';
$THEME->yuicssmodules = array();
$THEME->rendererfactory = 'theme_overridden_renderer_factory';
$THEME->undeletableblocktypes = '';
</code>

===Basic theme example settings explained===
First up you will notice everything is added to $THEME. This is the theme's configuration object, it is created by Moodle using default settings and is then updated by whatever settings you add to it.

; $THEME->name : The first setting, is the theme's name. This should simply be whatever your theme's name is, most likely whatever you named your theme directory.

; $THEME->sheets : An array containing the names of the CSS stylesheets to include for this theme. Boost uses scss instead of css so it doesn't list any files here. Note that it is just the name of the stylesheet and does not contain the directory or the file extension. Moodle assumes that the theme's stylesheets will be located in the styles directory of the theme and have .css as an extension.

; $THEME->editorsheets : An array containing the names of the CSS stylesheets to include for the TinyMCE text editor content area. Boost does not list any stylesheets here so TinyMCE will use plain text styles.

; $THEME->layouts : In this example, boost maps each of the 18 different layout types to one of 6 different layout files. For more information see the [[#Layouts|layouts]] section below.

; $THEME->parents : This defines the themes that the theme will extend. Boost has no parents, but if you were extending boost you would list it here like: $THEME->parents = ['boost'];

; $THEME->enable_dock : Boost does not support docking blocks. For a example of a theme with a dock for blocks, see theme_bootstrapbase.

; $THEME->csstreepostprocessor : Boost uses a function to post process the CSS. This is an advanced feature and is used in boost to automatically apply vendor prefixes to CSS styles.

; $THEME->yuicssmodules : This is an old setting that defines a list of YUI css files to load. These files interfere with existing styles and it is recommended to set this to an empty string to prevent any files being included.

; $THEME->rendererfactory : Almost all themes need this setting to be set to 'theme_overridden_renderer_factory' or the theme will not be able to customise any core renderers.

; $THEME->undeletableblocktypes : This is a comma separated list of block types that cannot be deleted in this theme. If you don't define this - the admin and settings blocks will be undeletable by default. Because Boost provides alternate ways to navigate it does not require any blocks.

'''''Note''''': When you first begin writing themes, make sure you take a look at the configuration files of the other themes that get shipped with Moodle. You will get a good picture of how everything works, and what is going on in a theme, simply by reading it and taking notice of what it is including or excluding.

==CSS==
===Locations of CSS files===
First lets look at where CSS can be included from within Moodle:
; \theme\themename\style\*.css : This is the default location for all of the stylesheets that are used by a theme and the place which should be used by a theme designer if this theme is using CSS. Alternatives to CSS are LESS and SCSS which are more powerful, flexible and easier to maintain.

New theme developers should note that the order in which CSS files are found and included creates a hierarchy. This order ensures that the rules, within a theme's style sheets, take precedence over identical rules in other files that may have been introduced before. This can both extend another files definitions (see parent array in the config file) and also ensures that the current theme's CSS rules/definitions have the last say.

There are other locations that can be used (although very rarely) to include CSS in a page. A developer of a php file can manually specify a stylesheet from anywhere within Moodle, like the database. Usually, if code is doing this, it is because there is a non-theme config or plugin setting that contains information requires special CSS information. As a theme designer you should be aware of, but not have to worry about, these locations of CSS files. Here are some examples:

; {pluginpath}\styles.css e.g. \block\blockname\styles.css or \mod\modname\styles.css : Every plugin can have its own styles.css file. This file should only contain the required CSS rules for the module and should not add anything to the look of the plugin such as colours, font sizes, or margins other than those that are truly required.<br />Theme specific styles for a plugin should be located within the themes styles directory.
; {pluginpath}\styles_themename.css : This should only ever be used by plugin developers. It allows them to write CSS that is designed for a specific theme without having to make changes to that theme. You will notice that this is never used within Moodle and is designed to be used only by contributed code.

As theme designers, we will only use the first method of introducing CSS: adding rules to a stylesheet file located in the theme's style directory.
===Better than CSS===
Browsers understand CSS well - but it is hard to write and maintain. The language does not support inheritance and reuse. [https://developer.mozilla.org/en-US/docs/Web/CSS/Using_CSS_variables Support for variables] exists in more modern browsers only. This is why CSS pre-processors were invented. Moodle supports 2 different types of CSS pre-processors (Less and Sass) but the Sass pre-processor is recommended by far.

For more information on Less and Sass see:
* [https://en.wikipedia.org/wiki/Less_(stylesheet_language) Less (wikipedia)]
* [https://en.wikipedia.org/wiki/Sass_(stylesheet_language) Sass (wikipedia)]

To use either one, define $THEME->lessfile = 'filename'; or $THEME->scss = 'filename'; in your themes config.php. Moodle will then use one of it's in-built CSS pre-processor to compile the CSS the first time it is loaded (or everytime if themedesignermode is enabled in $CFG).

===Moodle's core CSS organisation===
The next thing to look at is the organisation of CSS and rules within a theme. Although as a theme designer it is entirely up to you as to how you create and organise your CSS. Please note that none of the themes provided in the standard install by Moodle use CSS stylesheets directly. Instead they use either LESS or SCSS to generate the style sheets. They all list one main LESS or SCSS file named "moodle" in the less or scss folders and this file uses imports to load all other required files.

===How to write effective CSS rules within Moodle===
Writing good CSS rules is incredibly important.

Due to performance requirements and browser limitations, all of the CSS files are combined into a single CSS file that gets included every time. This means that rules need to be written in such a way as to minimise the chances of a collision leading to unwanted styles being applied. Whilst writing good CSS is something most designers strive for we have implemented several new body classes and prompt developers to use appropriate classnames.

====<body> CSS id and classes ====
The ID tag that gets applied to the body will always be a representation of the URI. For example if you are looking at a forum posting and the URI is '/mod/forum/view.php' then the body tags ID will be '#page-mod-forum-view'.

As well as the body's ID attribute the URI is also exploded to form several CSS classes that get added to the body tag, so in the above example '/mod/forum/view' you would end up with the following classes being added to the body tag '.path-mod', '.path-mod-forum'. Note that '.path-mod-forum-view' is not added as a class, this is intentionally left out to lessen confusion and duplication as rules can relate directly to the page by using the ID and do not require the final class.

The body ID and body classes described above will form the bread and butter for many of the CSS rules you will need to write for your theme, however there are also several other very handy classes that get added to the body tag that will be beneficial to you once you start your journey down the rabbit hole that is themeing. Some of the more interesting classes are listed below.

* If JavaScript is enabled then 'jsenabled' will be added as a class to the body tag allowing you to style based on JavaScript being enabled or not.
* Either 'dir-rtl' or 'dir-ltr' will be added to the body as a class depending on the direction of the language pack: rtl = right to left, ltr = left to right. This allows you to determine your text-alignment based on language if required.
* A class will be added to represent the language pack currently in use, by default en_utf8 is used by Moodle and will result in the class 'lang-en_utf8' being added to the body tag.
* The wwwroot for Moodle will also be converted to a class and added to the body tag allowing you to stylise your theme based on the URL through which it was reached. e.g. http://sam.moodle.local/moodle/ will become '.sam-moodle-local—moodle'
* If the current user is not logged then '.notloggedin' will be added to the body tag.
* The course format type will be added such as format-weeks
* The course id, context id and category id are all added as in "course-11 context-616 cmid-202 category-1"
* The pagelayout is added as "pagelayout-incourse"

What does all of this look like in practise? Well using the above example /mod/forum/view.php you would get at least the following body tag:
<code html>
<body id="page-mod-forum-view" class="format-weeks forumtype-social path-mod path-mod-forum safari dir-ltr lang-en yui-skin-sam yui3-skin-sam damyon-per-in-moodle-com--stable_master pagelayout-incourse course-11 context-616 cmid-202 category-1 jsenabled">
</code>

====Writing your rules====

By following the [[CSS coding style]] and CSS best-practices and understanding the [http://htmlhelp.com/reference/css/structure.html#cascade cascading order] of CSS a theme developer will reduce collisions and lines of CSS that is written. CSS classes have been placed where it is believed anyone may want to apply their own styles.

When starting to write rules make sure that you have a good understanding of where you want those rules to be applied, it is a good idea to make the most of the body classes mentioned above.
If you want to write a rule for a specific page make use of the body tag's ID, e.g.:

<code css>#page-mod-forum-view .forumpost {
border: 1px solid blue;
}</code>

If you want to write a rule that will be applied all throughout the forum.:

<code css>.path-mod-forum .forumpost {
border: 1px solid blue;
}</code>

The other very important thing to take into consideration is the structure leading up to the tag you want to style. Browsers apply conflicting styles with priority on the more specific selectors. It can be very beneficial to keep this in mind and write full selectors that rely on the structure of the tags leading to the tag you wish to style.

By making use of body id's and classes and writing selectors to take into account the leading structure you can greatly minimise the chance of a collision both with Moodle now and in the future.

It is also important to write as FEW rules as possible. CSS is extremely hard to maintain and lots of CSS is bad for client side performance. Themes based on the Bootstrap CSS framework can achieve most things without writing a single additional CSS rule. Please read [http://v4-alpha.getbootstrap.com/ the Bootstrap documentation] and learn how to use Bootstrap well to avoid adding unnecessary CSS rules for things already provided by the framework.

==Layouts==
Layouts are defined in '''config.php'''.

All themes are required to define the layouts they wish to be responsible for as well as create; however, many layout files are required by those layouts. If the theme is overriding another theme then it is a case of deciding which layouts this new theme should override. If the theme is a completely fresh start then you will need to define a layout for each of the different possibilities.

It is also important to note that a new theme that will base itself on another theme (overriding it) does not need to define any layouts or use any layout files if there are no changes that it wishes to make to the layouts of the existing theme.

As mentioned earlier, layouts are defined in config.php within $THEME->layouts. The following is an example of one such layout definition:
<code php>
$THEME->layouts = array(
// Standard layout with blocks, this is recommended for most pages with general information
'standard' => array(
'theme' => 'boost',
'file' => 'columns2.php',
'regions' => array('side-pre'),
'defaultregion' => 'side-pre'
)
)
</code>
The first thing Moodle looks at is the name of the layout, in this case it is `standard` (the array key in PHP), it then looks at the settings for the layout, this is the theme, file, regions, and default region. There are also a couple of other options that can be set by a layout.

; theme : is the theme the layout file exists in. That's right: you can make use of layouts from other installed themes. ''Optional''
; file : is the name of the layout file this layout wants to use. ''Required''
; regions : is the different block regions (places you can put blocks) within the theme. ''Required''
; defaultregion : is the default location when adding new blocks. '''Required if regions is non-empty, otherwise optional'''
; options : an array of layout specific options described in detail below. '''Optional'''

The '''theme''' is optional. Normally the the layout file is looked for in the current theme, or, if it is not there, in the parent theme. However, you can use a layout file from any other theme by giving the theme name here.

You can define whatever regions you like. You just need to pick a name for each one. Most themes just use one or both of '''side_pre''' and '''side_post''', which is like 'left side' and 'right side', except in right to left languages, when they are reversed. If you say in config.php that your the layout provides regions called 'fred' and 'barney', then you must call $OUTPUT->blocks_for_region('fred') and $OUTPUT->blocks_for_region('barney') somewhere in the layout file.

The final setting '''options''' is a special case that only needs to be set if you want to make use of it. This setting allows the theme designer to specify special options that they would like to create that can be later accessed within the layout file. This allows the theme to make design decisions during the definition and react upon those decisions in what ever layout file is being used.

One such place this has been used is within the boost theme. If you take a look first at theme/boost/config.php you will notice that several layouts specify options '''langmenu''' and '''nonavbar''' which can both be set to either true or false. The layout options can then be used on the layout .php files, mustache templates and renderers.
<code php>
<?php
$hasnavbar = (empty($PAGE->layout_options['nonavbar']) && $PAGE->has_navbar());
$hasfooter = (empty($PAGE->layout_options['nofooter']));
?>
</code>

==Layout files==
Layout files are used to provide a different layout of the elements of the page for different types of pages in Moodle.

In the config.php for a theme - there is a list of 'layouts' which map a page type to a specific php page in the layout folder for the theme.

For example:
''theme/boost/config.php''
<code php>
...
'popup' => array(
'file' => 'columns1.php',
'regions' => array(),
'options' => array('nofooter' => true, 'nonavbar' => true),
),
...
</code>

This means every page that has pagetype 'popup' will be displayed with the 'theme/themename/layout/columns1.php' file, it will have no block regions and there are some options that will be available to the page in the global variable "$PAGE->layout_options".

It is possible to implement a layout file directly in php by echoing the HTML for the page, or mixing php tags with HTML - but a better way to create a layout file is to gather all the information required for the layout into a context and render it with a mustache template.

[[Templates| Read about mustache templates]]

Using templates for layout files makes a lot of sense because they are easier to read and maintain than mixing PHP and HTML in the same file.

A simple example of a layout file using a template is at:

''theme/boost/layout/columns1.php''
<code php>
<?php

$bodyattributes = $OUTPUT->body_attributes([]);

$templatecontext = [
'sitename' => format_string($SITE->shortname, true, ['context' => context_course::instance(SITEID), "escape" => false]),
'output' => $OUTPUT,
'bodyattributes' => $bodyattributes
];

echo $OUTPUT->render_from_template('theme_boost/columns1', $templatecontext);
</code>

This example puts some variables into a templatecontext and then calls "render_from_template" to render the mustache template for this layout. The template is located at: "theme/boost/templates/columns1.mustache". It is possible to put PHP classes in the context for the mustache template - and any public properties or methods which accept no arguments will be available to the template. $OUTPUT has several useful public methods which accept no arguments and is a valuable class when creating a layout template in mustache.

The mustache template for this layout is shown here:

''theme/boost/templates/columns1.mustache''
<code handlebars>
{{{ output.doctype }}}
<html {{{ output.htmlattributes }}}>
<head>
<title>{{{ output.page_title }}}</title>
<link rel="shortcut icon" href="{{{ output.favicon }}}" />
{{{ output.standard_head_html }}}
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

<body {{{ bodyattributes }}}>

<div id="page-wrapper">

{{{ output.standard_top_of_body_html }}}

<div id="page" class="container-fluid">
<div id="page-content" class="row">
<div id="region-main-box" class="col-xs-12">
<section id="region-main">
<div class="card card-block">
{{{ output.course_content_header }}}
{{{ output.main_content }}}
{{{ output.course_content_footer }}}
</div>
</section>
</div>
</div>
</div>
</div>
{{{ output.standard_end_of_body_html }}}
</body>
</html>
{{#js}}
require(['theme_boost/loader']);
{{/js}}
</code>

Explaining each line of this template will answer a lot of questions. This example contains only the very minimal required functions to generate a valid layout. You should consider all of the sections below as required in every layout file (although any of the HTML tags can and should be altered).

<code handlebars>
{{{ output.doctype }}}
</code>

This is an example of calling a function on $OUTPUT in php. Because there is a public method on the output class named "doctype" which accepts no arguments - mustache will call it and return the output. We call a function to generate the doctype tag because calling this function returns us the correct HTML for the document type for this theme AND it sets a different content type header (including the charset) depending on the doc type for the theme. Setting a correct charset in every page is important to prevent a class of XSS attacks.

<code handlebars>
<html {{{ output.htmlattributes }}}>
</code>

Now we have returned our root tag - the html tag. We included a set of default attributes for the page by calling the htmlattributes function of our output class. This includes the correct language attribute for the entire page and can include an xml namespace for XHTML documents.

<code handlebars>
<head>
<title>{{{ output.page_title }}}</title>
</code>

Now we have started the head section of our document and set the title for the page. Notice the title is already escaped by the output class so we are using triple mustache tags "{{{" to avoid double escaping.

<code handlebars>
<link rel="shortcut icon" href="{{{ output.favicon }}}" />
</code>

We call a function to get the url to the favicon. The favicon is a file in the theme pix directory and it is served through the "theme/image.php" file which adds special caching headers for images.

<code handlebars>
{{{ output.standard_head_html }}}
</code>

The standard head html function performs a lot of setup that is required for our page. It internally creates the block regions, creates meta tags including keywords for SEO, initialises the common javascript modules, generates links to the style sheets and injects any additional HTML set by the $CFG->additionalhtmlhead setting.

<code handlebars>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
</head>

</code>

This viewport meta tag is recommended by bootstrap for "proper viewport rendering and touch zooming".

<code handlebars>
<body {{{ bodyattributes }}}>
</code>

The body attributes include the language direction and standard classes for the page.

<code handlebars>

<div id="page-wrapper">

</code>

In the Boost theme we use a page-wrapper div to prevent content from disappearing under the fixed header.

<code handlebars>
{{{ output.standard_top_of_body_html }}}

</code>

The standard_top_of_body_html should be included in every layout and includes skip links for accessibility as well as initialising jquery, yui and our own static javascript files.

<code handlebars>
<div id="page" class="container-fluid">
<div id="page-content" class="row">
<div id="region-main-box" class="col-xs-12">
<section id="region-main">
<div class="card card-block">
</code>

This is standard HTML tags defining the content region for this page. The classes come from bootstrap 4.

<code handlebars>
{{{ output.course_content_header }}}
</code>

The course content header allows Moodle plugins to inject things in the top of the page. This is used for "notifications" for example (which are the alert boxes you see after submitting a form).

<code handlebars>
{{{ output.main_content }}}
</code>

The main content function returns the real content for the page.

<code handlebars>
{{{ output.course_content_footer }}}
</code>

The course content footer is used mainly by course formats to insert things after the main content.

<code handlebars>
</div>
</section>
</div>
</div>
</div>
</div>
</code>

We close all our open tags...

<code handlebars>
{{{ output.standard_end_of_body_html }}}
</code>

This function will add all of the javascript that was required while rendering the page. Javascript is added at the end of the document so that it does not block rendering the page.
<code handlebars>
</body>
</html>
</code>

We finish the HTML for our page.
<code handlebars>
{{#js}}
require(['theme_boost/loader']);
{{/js}}
</code>

This final section is required for bootstrap 4 themes and loads all the Bootstrap 4 Javascript dependencies.

If we had block regions in this layout we would need to insert them in the template. The way we would do this is by getting the HTML for the block region in our layout php file, adding it to the context and then including it in our template.

''theme/boost/layout/columns2.php''
<code php>
...
$blockshtml = $OUTPUT->blocks('side-pre');
$hasblocks = strpos($blockshtml, 'data-block=') !== false;
...
$templatecontext = [
...
'sidepreblocks' => $blockshtml,
'hasblocks' => $hasblocks,
...
];
...
echo $OUTPUT->render_from_template('theme_boost/columns2', $templatecontext);
</code>

''theme/boost/templates/columns2.mustache''
<code handlebars>
...
{{#hasblocks}}
<section data-region="blocks-column" class="hidden-print">
{{{ sidepreblocks }}}
</section>
{{/hasblocks}}
...
</code>

When writing layout files think about the different layouts and how the HTML that each makes use of will differ. You will most likely find you do not need a different layout file for each layout, most likely you will be able to reuse the layout files you create across several layouts. You can of course make use of layout options as well to further reduce the number of layout files you need to produce.

Of course as mentioned above if you are customising an existing theme then you may not need to create any layouts or layout files at all.

==Language File==

You need to create a language file for your theme with a few standard strings in it. At a minimum create a file called lang/en/theme_themename.php in your theme folder. For example, the 'boost' theme has a language file called lang/en/theme_boost.php.

You '''must''' define the following lines in your file (example is from Boost theme, adapt as required):

<code php>
$string['pluginname'] = 'Boost';
$string['region-side-pre'] = 'Right';
$string['choosereadme'] = 'Boost is a modern highly-customisable theme. This theme is intended to be used directly, or as a parent theme when creating new themes utilising Bootstrap 4.';
</code>

Without the above you will get notices for the missing strings.

==Making use of images==
Right at the start when listing the features of the new themes system one of the features mentioned was the ability to override any of the standard images within Moodle from within your theme. At this point we will look at both how to make use of your own images within your theme, and secondly how to override the images being used by Moodle.
So first up a bit about images within Moodle,

# Images you want to use within your theme '''need''' to be located within your theme's pix directory.
# You can use sub directories within the pix directory of your theme.
# Images used by Moodle's core are located within the pix directory of Moodle.
# Modules, blocks and other plugins should also store their images within a pix directory.

So making use of your own images first up. Lets assume you have added two image files to the pix directory of your theme.

* /theme/yourthemename/pix/imageone.jpg
* /theme/yourthemename/pix/subdir/imagetwo.png

Notice that one image is a JPEG image, and the second is a PNG. Also the second image is in a subdirectory.

The following code snippet illustrates how to make use of your images within your layout file so they can be inserted by your layout template.
''theme/yourtheme/layout/somelayout.php''
<code php>
...
$templatecontext = [
...
$imageone => $OUTPUT->pix_url('imageone', 'theme'),
$imagetwo => $OUTPUT->pix_url('subdir/imagetwo', 'theme'),
...
];

echo $OUTPUT->render_from_template('theme_yourtheme/somelayout', $templatecontext);
</code>

We use a method of Moodle's output library to generate the URL to the image. Its not too important how that functions works but it is important that we use it as it is what allows images within Moodle to be over-rideable.
'''DO NOT''' include the image file extension. Moodle will work it out automatically and it will not work if you do include it.

''theme/yourtheme/templates/somelayout.mustache''
<code handlebars>
...
<img src="{{{imageone}}}" alt="Please give your image alt text or set the role to presentation" width="50" height="50">
<img src="{{{imagetwo}}}" alt="Please give your image alt text or set the role to presentation" width="50" height="50">
...
</code>

The following is how you would use the images from within CSS, SCSS or Less as background images.

<code css>
.divone {
background-image: url([[pix:theme|imageone]]);
}

.divtwo {
background-image: url([[pix:theme|subdir/imagetwo]]);
}
</code>

If this case we have to use some special notations that Moodle looks for. Whenever Moodle hands out a CSS file it first searches for all ''[[something]]'' tags and replaces them with what is required.

The final thing to notice with both of the cases above is that at no point do we include the images file extension.
The reason for this leads us into the next topic, how to override images.

From within a theme you can VERY easily override any standard image within Moodle by simply adding the replacement image to the theme's pix directory in the same sub directory structure as it is in Moodle.
So for instance we wanted to override the following two images:
# /pix/moodlelogo.gif
# /pix/i/user.gif
We would simply need to add our replacement images to the theme in the following locations
# /theme/themename/pix_core/moodlelogo.gif
# /theme/themename/pix_core/i/user.gif
''Note that we have created a '''pix_core''' directory in our theme. For a specific activity module like chat we need a '''pix_plugins/mod/chat''' directory. This directory is "pix_plugins" and then the plugin type (mod) and then the plugin name (chat).

Now the other very cool thing to mention is that Moodle looks for not just replacements of the same image type (jpg, gif, etc...) but also replacements in any image format. This is why above when working with our images we never specified the images file extension.
This means that the following would also work:
# /theme/themename/pix_core/moodlelogo.png
# /theme/themename/pix_core/i/user.bmp

For a more detailed description of how this all works see the page on [[Using images in a theme]].

==Adding custom fonts==
{{Moodle 2.6}}

CSS3 standard introduced the possibility to specify custom fonts, see [http://www.w3schools.com/css/css3_fonts.asp CSS3 Fonts tutorial].

Since 2.6 Moodle includes support for plugin or theme fonts. It is very similar to theme images and pix subdirectories.

===Font file locations===

Depending on where you intend to use the font put it into one of the following locations:
* /lib/fonts/ - fonts used in core
* /plugindir/fonts/ - fonts used by plugin
* /theme/sometheme/fonts/ - theme specific fonts

You can also override core and plugin fonts in theme:
* /theme/sometheme/fonts_core/ - overridden core fonts
* /theme/sometheme/fonts_plugins/plugintype_pluginname/ - overridden fonts of some plugin

Notes:
* subdirectories are not allowed
* use only lowercase alphanumeric characters and underscore in font file names
* WOFF (Web Open Font Format), TTF (True Type Fonts), OTF (OpenType Fonts), SVG (Scalable Vector Graphic) and EOT (Embedded OpenType) fonts are supported, but for the sake of humanity (And [https://tracker.moodle.org/browse/MDL-15169 MDL_15169] ) please use only WOFF fonts to encourage the quick death of IE8.

===CSS placeholders===

<code css>
@font-face {
font-family: ThreeDumb;
src: url([[font:mod_book|3dumb.woff]]);
}
</code>

The placeholder references file /mod/book/fonts/3dumb.woff, the new fontface could be for example used for book headings:

<code css>
.path-mod-book .book_chapter_title {
font-family: ThreeDumb;
}
</code>

If you want to use some font in theme only, you can for example:

<code css>
@font-face {
font-family: goodDogFont;
src: url([[font:theme|good_dog.woff]]);
}

a {font-family:goodDogFont;}
</code>

The font would be stored in /theme/yourtheme/fonts/good_dog.woff file.

===More free fonts===

Please respect all licenses for font redistribution, you can get some nice free fonts from [http://www.fontsquirrel.com http://www.fontsquirrel.com] for example.

===Warning===

This is not intended for forcing of something like Comic Sans on all your visitors...

==Compiling LESS on the fly==
{{Moodle 2.7}}

You can now provide a LESS file that will be compiled (and cached) on the fly. The purpose of this feature is to dynamically allow the customisation of LESS variables.

===Set up your theme===

# Create a .less file in a less folder. Eg. <code>theme/yourtheme/less/myfile.less</code>
# Edit your theme config file, and set $THEME->'''lessfile''' to the name of your file (do not include .less). Eg. <code>$THEME->lessfile = 'myfile'</code>

That's it, the LESS file will be compiled and included in the page on the fly, but that is not very useful yet.

Please note that any file referenced in $THEME->sheets that shares the same name than the LESS file will be silently ignored.

===Inheriting from a parent===

Even if your theme is inheriting from a parent, the LESS file itself will not inherit from anything, this is something you should do manually. For instance, if you want your LESS file to include all of the LESS code provided by ''theme_bootstrapbase'', usually to change the variables, you need to manually import the file like this:

<code>
@import "../../bootstrapbase/less/moodle.less";
</code>

The path needs to be relative and not absolute. You would definitely want to add that rule first in your file and add anything else below it.

===Programmatically injecting LESS===

There are two theme options to specify a callback function that you need to know about:

# $THEME->'''extralesscallback''': To return raw LESS code to be injected.
# $THEME->'''lessvariablescallback''': To return an array of variables and their values.

Typically you will want to simply inject variables, but if you need to perform more complex manipulations, you can return some raw LESS code. The variables returned by the callback are always injected last.

===Performance===

Compiling LESS on the fly is a slow operation, and even though the result is cached you should be aware of it. If you have enabled the configuration setting ''themedesignermode'' you will definintely notice the slowness as the cache only lives for a very short period of time. Ideally your theme should precompile the LESS into CSS, but if you want to provide theme settings to your user, then using this feature is for you.

===Example===

You can refer to the theme ''theme_more'' for an example on how to use this feature.

==Compiling SCSS on the fly==
{{Moodle 3.2}}

You can now provide a SCSS file that will be compiled (and cached) on the fly. The purpose of this feature is to dynamically allow the customisation of SCSS variables. See the [[SCSS|dedicated page on SCSS]].

==Unobvious Things==
===Getting Your Theme to Appear Correctly in Theme Selector===
If you follow the examples on this page to the letter, when you go to the Theme Selector page you may be discouraged to find that your theme does not appear like the other themes do. In fact, instead of your theme's name, you will see something along the lines of <nowiki>[[pluginname]]</nowiki>.

To correct this, you must add the theme/THEMENAME/lang/en/theme_THEMENAME.php file, where THEMENAME is the name of the theme folder. Inside that file, add the string "$string['pluginname'] = 'THEMENAME'; ". Make THEMENAME the name of your theme, however you want it displayed in the Theme selector.

Also, make sure to change your config.php file and version.php file to reflect the correct name:

In config.php: $THEME->name = 'NAME';

In version.php: $plugin->component = 'theme_NAME'; // Full name of the plugin (used for diagnostics)

The screenshot for the theme should be about 500x400 px.

===Required theme divs===

Some parts of Moodle may rely on particular divs, for example the div with id 'page-header'.

Consequently all themes must include at least the divs (with the same ids) that are present in the 'boost' theme.

Missing out these elements may result in unexpected behaviour within specific modules or other plugins.

==Caching==
When Moodle is not running in theme designer mode it will look for a cached version of the compiled CSS for the current theme to serve to the browser requesting the page. If the cached file doesn't yet exist then the CSS will be built and cached during the page request.

The cached CSS is located on disk in Moodle's local cache:
<Moodle data directory >/localcache/theme/<global theme revision>/<theme_name>/css/all_<theme subrevision>.css

The cache path consists of a global theme revision (themerev config value) and a per theme subrevision (themesubrev plugin config value). If either of those are incremented it will change the path to the cache file and cause a new file to be generated.

Individual theme's CSS cache can be built by using the admin CLI script:
php admin/cli/build_theme_css.php --themes boost

The script will only increment the theme subrevision of the theme(s) being built which means existing theme cache's remain untouched.

==Appendix A==
=== Theme options ===

{| class="nicetable" id="theme_options_table"
|-
! Setting
! Effect
|-
| $THEME->'''blockrtlmanipulations'''
| Allows the theme to manipulate how the blocks are displayed in a ''right-to-left'' language. Not recommended since we automatically flip CSS for rtl.
|-
| $THEME->'''csspostprocess'''
| Allows the user to provide the name of a function that all CSS should be passed to before being delivered.
|-
| $THEME->'''csstreepostprocessor''' (Since 3.2)
| Allows the user to provide the name of a function that can perform manipulations on an in-memory representation of the CSS tree. Some useful manipulations are available such as the "theme_boost\autoprefixer" which will automatically add vendor prefixes to all CSS that requires them.
|-
| $THEME->'''doctype'''
| The doctype of the served documents.
|-
| $THEME->'''editor_sheets'''
| An array of stylesheets to include just within the body of the TinyMCE text editor. This is required if you want content to resemble its final appearance in the page, while it is being edited in the text editor.
|-
| $THEME->'''enablecourseajax'''
| If set to false the course AJAX features will be disabled.
|-
| $THEME->'''enable_dock'''
| If set to true the side dock is enabled for blocks.
|-
| $THEME->'''prescsscallback'''
| The name of a function that will return some SCSS code to inject at the beginning of the SCSS file specified in $THEME->scss. (Since 3.2)
|-
| $THEME->'''extrascsscallback'''
| The name of a function that will return some SCSS code to inject at the end of the SCSS file specified in $THEME->scss. (Since 3.2)
|-
| $THEME->'''extralesscallback'''
| The name of a function that will return some LESS code to inject at the end of the LESS file specified in $THEME->lessfile. (Since 2.7)
|-
| $THEME->'''hidefromselector'''
| Used to hide a theme from the theme selector (unless theme designer mode is on). Accepts true or false.
|-
| $THEME->'''javascripts'''
| An array containing the names of JavaScript files located in /javascript/ to include in the theme. (gets included in the head). This setting should no longer be used - please use AMD [[Javascript Modules]] instead.
|-
| $THEME->'''javascripts_footer'''
| As above but will be included in the page footer. This setting should no longer be used - please use AMD [[Javascript Modules]] instead.
|-
| $THEME->'''layouts'''
| An array setting the layouts for the theme
|-
| $THEME->'''lessfile'''
| The name of a LESS file in the theme's less/ folder to compile on the fly. Sheets with the same name will be ignored. (Since 2.7)
|-
| $THEME->'''lessvariablescallback'''
| The name of a function that will modify some LESS variables before compiling the LESS file specified in $THEME->lessfile. (Since 2.7)
|-
| $THEME->'''scss'''
| The name of a SCSS file in the theme's scss/ folder to compile on the fly. Sheets with the same name will be ignored. This can also be a function which returns SCSS, in which case all import paths will be relative to the scss folder in this theme or any of it's parents. (Since 3.2)
|-
| $THEME->'''name'''
| Name of the theme. Most likely the name of the directory in which this file resides.
|-
| $THEME->'''parents'''
| An array of themes to inherit from. If the theme you inherit from inherits from a parent as well, you need to indicate the grand parent here too.
|-
| $THEME->'''parents_exclude_javascripts'''
| An array of JavaScript files NOT to inherit from the themes parents
|-
| $THEME->'''parents_exclude_sheets'''
| An array of stylesheets not to inherit from the themes parents
|-
| $THEME->'''plugins_exclude_sheets'''
| An array of plugin sheets to ignore and not include.
|-
| $THEME->'''renderfactory'''
| Sets a custom render factory to use with the theme, used when working with custom renderers. You most likely want this set to "theme_overridden_renderer_factory".
|-
| $THEME->'''sheets'''
| An array of stylesheets to include for this theme. Should be located in the theme's style directory. Not required if using less or scss.
|-
| $THEME->'''yuicssmodules'''
| An array of YUI CSS modules to be included. This setting should probably be set to '' to prevent and YUI CSS being included.
|-
| $THEME->'''undeletableblocktypes'''
| An array of Block types that must exist on all pages in this theme or this theme will be unusable. If a block type listed here is missing when a page is loaded - it will be auto-created (but only shown for themes that require it).
|-
| $THEME->'''addblockposition'''
| Either BLOCK_ADDBLOCK_POSITION_FLATNAV, BLOCK_ADDBLOCK_POSITION_DEFAULT or BLOCK_ADDBLOCK_POSITION_CUSTOM. Defines where to put the "Add a block" controls when editing is enabled.
|}

===The different layouts as of 21st April 2013===
{| class="nicetable" id="theme_layouts_table"
|-
! Layout
! Purpose
|-
| base
| Most backwards compatible layout without the blocks - this is the layout used by default.
|-
| standard
| Standard layout with blocks, this is recommended for most pages with general information.
|-
| course
| Main course page.
|-
| coursecategory
| Use for browsing through course categories.
|-
| incourse
| Default layout while browsing a course, typical for modules.
|-
| frontpage
| The site home page.
|-
| admin
| Administration pages and scripts.
|-
| mydashboard
| My dashboard page.
|-
| mypublic
| My public page.
|-
| login
| The login page.
|-
| popup
| Pages that appear in pop-up windows - no navigation, no blocks, no header.
|-
| frametop
| Used for legacy frame layouts only. No blocks and minimal footer.
|-
| embedded
| Used for embedded pages, like iframe/object embedded in moodleform - it needs as much space as possible
|-
| maintenance
| Used during upgrade and install. This must not have any blocks, and it is a good idea if it does not have links to other places - for example there should not be a home link in the footer.
|-
| print
| Used when the page is being displayed specifically for printing.
|-
| redirect
| Used when a redirection is occurring
|-
| report
| Used for reports.
|-
| secure
| Used for safebrowser and securewindow.
|}

==See also==
* MoodleBites Theme Design - completely online courses [https://www.moodlebites.com/mod/page/view.php?id=3208 Level 1] and [https://www.moodlebites.com/mod/page/view.php?id=3210 Level 2] are designed to assist Moodle administrators, designers, and developers get up-to-speed with Moodle Theme design, and are run by [https://www.hrdnz.com HRDNZ] (Certified Moodle Partner since 2006).

[[Category:Plugins]]

User Data Always Safe

2018-09-07T10:19:38Z

Pilpi: /* Preserve submitted data or giving it back to the user to keep, until it can be saved */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''User Data Always (Always) Safe'''

In all cases, the user's work is sacrosanct. Nothing your
application does should lose or destroy user's work without
explicit user action. - GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]

* [http://moodle.org/mod/forum/discuss.php?d=130005 Please comment in the related discussion forum] </big>

Every part in Moodle should commit to keeping the data user has entered, safe.

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.

This issue requires further user research to find the exact issues involved, but there are also some generally well known mechanisms to employ.

As Moodle is a web application, keeping user data safe is not trivial.

==Challenges==
* Users may leave forms without submitting them
** Learning from some desktop applications (GNOME settings dialogs), users may assume their settings get automatically saved when they just enter them.
** Accidentally hitting the back button
** Clicking on a link on the form itself, assuming it is safe
** Pushing a button on their keyboard resulting in accidental usage of the back/next buttons
* Users may fill out forms "inappropriately"
** Missing data
** Session may have expired
*** 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.
** User may have logged out accidentally (browser crash; browser restores the browser session but not the Moodle session)
** User may no longer be capable of completing the action due to loss of permissions or other reasons
*** A forum post they are were replying to was deleted
*** The time to edit a post has passed while the user was editing the post
* Users may submit data when the server has gone down or network connection lost

==Solutions==

=== Preserve submitted data or giving it back to the user to keep, until it can be saved ===
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.

If a user has posted something, but it cannot be saved, never ever just throw the data away (like for example, Forum currently does).
Design your application to request the user what should be done. This requires understanding the situations users may end up in. Examples:
* 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.
* Suggested error message example: "'''What you tried to send is safe, but not yet saved.''' The [message] 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."
==== Giving the user their data back, for copying to the clipboard ====
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.

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.

* 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."
* 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.

=== Undo ===
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.
[[Image:gmail-undo-example.png|left|frame]]
<br style="clear: both" />

=== Autosave ===
Related forum threads:
* [http://moodle.org/mod/forum/discuss.php?d=74710 AJAX-like Autosave for quiz]
* [http://moodle.org/mod/forum/discuss.php?d=107073 Autosave for Forum Compose?]
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.
* 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)
** Autosaving can be implemented using AJAX or by just submitting the form in question in the background using javascript.
* 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
* 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.
** This is also probably the only possible strategy when the server has gone down or when the network connection has been lost

=== "Save as draft" button ===
Sometimes it may be appropriate to let users save their work, before it is finished, without yet publishing it.

=== Javascript confirmation upon leaving "dirty" form ===
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.
=== TinyMCE ===
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.

=== Browser-based solutions ===
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.

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.

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.

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).

== More information ==
* Discussion: [http://moodle.org/mod/forum/discuss.php?d=130005 Critical: Keeping user data safe]
** Linked threads: [http://moodle.org/mod/forum/discuss.php?d=130010] [http://moodle.org/mod/forum/discuss.php?d=130007]
* Directory of [[Major_usability_issues_in_Moodle|Major usability issues in Moodle]]
* A solution applicable in some scenarios: MDL-18014 Tracker item for autosave (thanks Mauno Korpelainen)
* [http://code.google.com/p/tinyautosave/ TinyMCE autosave plugin] (thanks Mauno Korpelainen)

[[Category:Moodle User Interface Guidelines]]

Quiz UI redesign

2014-11-19T15:05:45Z

Pilpi:

'''Status: project finished and code incorporated into Moodle 2.0 in Autumn 2008.'''

* Chapter 3 (especially page 18 and onwards) 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. ([https://drive.google.com/viewerng/viewer?url=http://tampub.uta.fi/bitstream/handle/10024/81866/gradu04510.pdf?sequence=1 Online view])

* MDL-17284 Final tracker item
* [http://moodle.org/mod/forum/discuss.php?d=103869 Final forum discussion]
* For permanent documentation, '''See also: [[Quiz Usability portal]]'''

----
This is the Docs page for the Quiz UI redesign project 2008

'''The project blog''': http://www.pilpi.net/software/moodle_quiz_ui/ .

* [[Quiz UI redesign prototype presumptions | Quiz UI redesign prototype presumptions]]
* '''[[Quiz UI redesign - Design specification | Design specification]]'''
* Project tracker: http://tracker.moodle.org/browse/CONTRIB-528

== Related forum discussions ==
Some are still missing here. The last one is the newest, and the location of current discussion.
* Inquiry about the status of the UI: [http://moodle.org/mod/forum/discuss.php?d=63612 Quiz UI development]
* Suggesting concrete new UI: [http://moodle.org/mod/forum/discuss.php?d=72828 New Quiz UI prototype published]
** Related: [http://moodle.org/mod/forum/discuss.php?d=92870 Re: Concern of Moodle Usability - Quiz module]
* Applied for funding, Tim Hunt accepted as mentor: [http://moodle.org/mod/forum/discuss.php?d=92797 Simple Quiz building user interface]
* [http://moodle.org/mod/forum/discuss.php?d=99351#p439124 Community effort to learn about teacher quiz/exam usage habits]
* [http://moodle.org/mod/forum/discuss.php?d=100367 Call for comments: Quiz UI redesign prototype (new iteration now usability tested)]
* [http://moodle.org/mod/forum/discuss.php?d=102062 Call for comments: Quiz UI redesign demo published]
* [http://moodle.org/mod/forum/discuss.php?d=103869 Should Olli's new quiz editing interface be included in Moodle 2.0?]
** [http://moodle.org/mod/forum/discuss.php?d=103870 cross-post]

== Scenarios ==

===Scenarios work===
* '''[[Quiz_UI_redesign scenarios - conclusions| Scenarios work conclusions (executive summary) ]]'''
* [[Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F|The idea and the content of the scenarios interviews I did]]

===The Scenarios===
* [[Quiz UI redesign scenarios - Scenarios index]]

== Prototype testing ==
=== June 2008 ===
Published June 27th, 2008.

[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 '''[[Quiz UI redesign - Design specification | Design specification]]''' for a more final, translated view of the UI''' )
* [[Quiz UI redesign - prototype testing background|Background]]
* [[Quiz_UI_redesign_prototype_questions#Testing_questions_used_in_spring.2Fsummer_2008|Tasks]]
* [[Quiz UI redesign - prototype testing report|Prototype testing report]]

===Testing with the actual implementation: August 2008===
See also: [[Quiz_Usability_portal#Future_development]]
* [[Quiz_UI_redesign/usability testing of August 2008/Executive summary|Quiz UI redesign / usability testing of August 2008 / Executive summary]]
* [[Quiz_UI_redesign/usability testing of August 2008/Issues|Quiz UI redesign / related issues in usability testing of August 2008]]
* Quiz UI redesign / [[Quiz_UI_redesign/usability testing of August 2008/Summary of solutions|Direct reactions to usability testing: List of solutions]]
* [[ Usability testing in August 2008/Test setting and tasks / background|Test setting and tasks / background]]

== Development ==
Moved to [[Quiz UI redesign - development]]

[[Category:Usability]]

== Obsolete ==
* Obsolete: [[Quiz UI redesign prototype | Quiz UI redesign prototype]]
* Pretty obsolete: [[Quiz UI redesign - related use cases|Use cases]]

Quiz UI redesign

2012-10-16T12:05:27Z

Pilpi:

'''Status: project finished and code incorporated into Moodle 2.0 in Autumn 2008.'''

* Chapter 3 (especially page 18 and onwards) 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. [https://docs.google.com/viewer?url=http%3A%2F%2Ftutkielmat.uta.fi%2Fhaekokoversio.php%3Fid%3D20867 Online view]
* MDL-17284 Final tracker item
* [http://moodle.org/mod/forum/discuss.php?d=103869 Final forum discussion]
* For permanent documentation, '''See also: [[Quiz Usability portal]]'''

----
This is the Docs page for the Quiz UI redesign project 2008

'''The project blog''': http://www.pilpi.net/software/moodle_quiz_ui/ .

* [[Quiz UI redesign prototype presumptions | Quiz UI redesign prototype presumptions]]
* '''[[Quiz UI redesign - Design specification | Design specification]]'''
* Project tracker: http://tracker.moodle.org/browse/CONTRIB-528

== Related forum discussions ==
Some are still missing here. The last one is the newest, and the location of current discussion.
* Inquiry about the status of the UI: [http://moodle.org/mod/forum/discuss.php?d=63612 Quiz UI development]
* Suggesting concrete new UI: [http://moodle.org/mod/forum/discuss.php?d=72828 New Quiz UI prototype published]
** Related: [http://moodle.org/mod/forum/discuss.php?d=92870 Re: Concern of Moodle Usability - Quiz module]
* Applied for funding, Tim Hunt accepted as mentor: [http://moodle.org/mod/forum/discuss.php?d=92797 Simple Quiz building user interface]
* [http://moodle.org/mod/forum/discuss.php?d=99351#p439124 Community effort to learn about teacher quiz/exam usage habits]
* [http://moodle.org/mod/forum/discuss.php?d=100367 Call for comments: Quiz UI redesign prototype (new iteration now usability tested)]
* [http://moodle.org/mod/forum/discuss.php?d=102062 Call for comments: Quiz UI redesign demo published]
* [http://moodle.org/mod/forum/discuss.php?d=103869 Should Olli's new quiz editing interface be included in Moodle 2.0?]
** [http://moodle.org/mod/forum/discuss.php?d=103870 cross-post]

== Scenarios ==

===Scenarios work===
* '''[[Quiz_UI_redesign scenarios - conclusions| Scenarios work conclusions (executive summary) ]]'''
* [[Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F|The idea and the content of the scenarios interviews I did]]

===The Scenarios===
* [[Quiz UI redesign scenarios - Scenarios index]]

== Prototype testing ==
=== June 2008 ===
Published June 27th, 2008.

[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 '''[[Quiz UI redesign - Design specification | Design specification]]''' for a more final, translated view of the UI''' )
* [[Quiz UI redesign - prototype testing background|Background]]
* [[Quiz_UI_redesign_prototype_questions#Testing_questions_used_in_spring.2Fsummer_2008|Tasks]]
* [[Quiz UI redesign - prototype testing report|Prototype testing report]]

===Testing with the actual implementation: August 2008===
See also: [[Quiz_Usability_portal#Future_development]]
* [[Quiz_UI_redesign/usability testing of August 2008/Executive summary|Quiz UI redesign / usability testing of August 2008 / Executive summary]]
* [[Quiz_UI_redesign/usability testing of August 2008/Issues|Quiz UI redesign / related issues in usability testing of August 2008]]
* Quiz UI redesign / [[Quiz_UI_redesign/usability testing of August 2008/Summary of solutions|Direct reactions to usability testing: List of solutions]]
* [[ Usability testing in August 2008/Test setting and tasks / background|Test setting and tasks / background]]

== Development ==
Moved to [[Quiz UI redesign - development]]

[[Category:Usability]]

== Obsolete ==
* Obsolete: [[Quiz UI redesign prototype | Quiz UI redesign prototype]]
* Pretty obsolete: [[Quiz UI redesign - related use cases|Use cases]]

Quiz UI redesign

2012-10-16T12:04:02Z

Pilpi: added online view link to thesis

'''Status: project finished and code incorporated into Moodle 2.0 in Autumn 2008.'''

* 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. [https://docs.google.com/viewer?url=http%3A%2F%2Ftutkielmat.uta.fi%2Fhaekokoversio.php%3Fid%3D20867 Online view]
* MDL-17284 Final tracker item
* [http://moodle.org/mod/forum/discuss.php?d=103869 Final forum discussion]
* For permanent documentation, '''See also: [[Quiz Usability portal]]'''

----
This is the Docs page for the Quiz UI redesign project 2008

'''The project blog''': http://www.pilpi.net/software/moodle_quiz_ui/ .

* [[Quiz UI redesign prototype presumptions | Quiz UI redesign prototype presumptions]]
* '''[[Quiz UI redesign - Design specification | Design specification]]'''
* Project tracker: http://tracker.moodle.org/browse/CONTRIB-528

== Related forum discussions ==
Some are still missing here. The last one is the newest, and the location of current discussion.
* Inquiry about the status of the UI: [http://moodle.org/mod/forum/discuss.php?d=63612 Quiz UI development]
* Suggesting concrete new UI: [http://moodle.org/mod/forum/discuss.php?d=72828 New Quiz UI prototype published]
** Related: [http://moodle.org/mod/forum/discuss.php?d=92870 Re: Concern of Moodle Usability - Quiz module]
* Applied for funding, Tim Hunt accepted as mentor: [http://moodle.org/mod/forum/discuss.php?d=92797 Simple Quiz building user interface]
* [http://moodle.org/mod/forum/discuss.php?d=99351#p439124 Community effort to learn about teacher quiz/exam usage habits]
* [http://moodle.org/mod/forum/discuss.php?d=100367 Call for comments: Quiz UI redesign prototype (new iteration now usability tested)]
* [http://moodle.org/mod/forum/discuss.php?d=102062 Call for comments: Quiz UI redesign demo published]
* [http://moodle.org/mod/forum/discuss.php?d=103869 Should Olli's new quiz editing interface be included in Moodle 2.0?]
** [http://moodle.org/mod/forum/discuss.php?d=103870 cross-post]

== Scenarios ==

===Scenarios work===
* '''[[Quiz_UI_redesign scenarios - conclusions| Scenarios work conclusions (executive summary) ]]'''
* [[Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F|The idea and the content of the scenarios interviews I did]]

===The Scenarios===
* [[Quiz UI redesign scenarios - Scenarios index]]

== Prototype testing ==
=== June 2008 ===
Published June 27th, 2008.

[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 '''[[Quiz UI redesign - Design specification | Design specification]]''' for a more final, translated view of the UI''' )
* [[Quiz UI redesign - prototype testing background|Background]]
* [[Quiz_UI_redesign_prototype_questions#Testing_questions_used_in_spring.2Fsummer_2008|Tasks]]
* [[Quiz UI redesign - prototype testing report|Prototype testing report]]

===Testing with the actual implementation: August 2008===
See also: [[Quiz_Usability_portal#Future_development]]
* [[Quiz_UI_redesign/usability testing of August 2008/Executive summary|Quiz UI redesign / usability testing of August 2008 / Executive summary]]
* [[Quiz_UI_redesign/usability testing of August 2008/Issues|Quiz UI redesign / related issues in usability testing of August 2008]]
* Quiz UI redesign / [[Quiz_UI_redesign/usability testing of August 2008/Summary of solutions|Direct reactions to usability testing: List of solutions]]
* [[ Usability testing in August 2008/Test setting and tasks / background|Test setting and tasks / background]]

== Development ==
Moved to [[Quiz UI redesign - development]]

[[Category:Usability]]

== Obsolete ==
* Obsolete: [[Quiz UI redesign prototype | Quiz UI redesign prototype]]
* Pretty obsolete: [[Quiz UI redesign - related use cases|Use cases]]

Usability

2012-03-12T09:03:58Z

Pilpi: /* See also: */ Fixed link to Syndia's thesis

{{GSOC 09}}
Some pointers, links, and resources on the topic of usability with respect to Moodle.

For general information on the concept of usability see
[http://www.lukew.com/ff/entry.asp?797 Definition of user experience (UX)].

==Contribute to Moodle through Usability testing==

An ongoing need of a project such as Moodle is to keep the interface usable as the code matures. Improvements and added functionality may seem like a wonderful innovation from the coder's or administrator's point of view, but if the end-user is confused or frustrated by it (or can't even find it!), its usefulness drops dramatically.

The idea of usability testing is simple: a person who is well-versed in Moodle gets together a small number of willing participants, who have no previous experience of using Moodle, and who are not technology experts (such as web designers etc...). The closer these people are to the "typical user" (for example a high school student), the better. The person conducting the test simply observes the participant as he/she tries to achieve a number of tasks. A video/sound recording can also be made with the prior consent of the participant, and is useful for later analysis.

The person conducting the test then pools together the issues that were common between most participants, and produces a short and concise report that is then used by Moodle developers to improve the user interface.

This sort of contribution requires no coding skills whatsoever, not even HTML. You just need to be familiar with using Moodle as a learner.

The links at the bottom of this article include Steve Krug's book, "Don't make me think!". This books is the best introduction to Usability testing I know of.

See also: [[Usability_testing_protocol|Usability testing protocol]]

== "Bike Sheds" ==

Because changes with regard to Usability are necessarily visual and on the surface, it is a potential Bike Shed issue. This is a metaphor bandied around in Open Source circles that suggests (in brief) that the smaller the change, the greater the discussions that surround it in forums and mailing lists. People proposing small improvements to Moodle should be aware of this phenomenon and not take the level of discussion as an implicit criticism of their suggestion.

You can read a well-written account of this metaphor that [http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING originated on the BSD mailing list] under http://www.bikeshed.com.

==Avoid the word "intuitive"==

(Definition: [http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=444 Intuitive])

Intuitive is a word you should avoid in discussions of usability as its meaning is often confused.

It is generally accepted that a large part of usability is based on familiarity and experience. Human Interface Guidelines published by people such as Apple or Gnome strive for logic and consistency so that the learning can be easier, and the experience more valuable. Using 'intuitive' as a short-hand for something that is familiar often gives the impression that if something is 'intuitive' then it is so regardless of prior learning or experience and therefore equally true for everyone. It suggests that the goodness or badness of an interface is situated within the interface itself, rather than in the relationship between the user and the interface.

Very few people would object to the statement that 'Apple software is more intuitive than Windows software' yet to someone who has only used Windows software, this is clearly not the case. Avoiding using the word yourself and mentally translating other people's use of intuitive as 'something I like' e.g. "Moodle's block system is unintuitive" = "Moodle's block system is something I don't like" may help to defuse arguments because it is harder to argue about personal opinions that are stated explicitly as personal opinion rather than disguised as objective statements about the software.

Therefore what is called intuitive, in the case of Moodle, will depend on your experience and expectations of other learning systems, web applications or sites, as well as software in general and thus varies from person to person. Usability studies should therefore average out the expectations of many people to find what is 'intuitive' and check to see if different groups (e.g. users of particular alternative systems, total beginners) have different expectations.

This article explains more and better (with diagrams!): http://www.uie.com/articles/design_intuitive/

==Learnability versus usability==

People often confuse these topics, understandably as they do have a great deal in common. Generally what are referred to as 'usability' improvements make things both easier to learn and easier for experienced users. Occasionally decisions need to be made favouring one over the other, and in those situations it helps to be explicit which of the two you are referring to. There are many successful software tools that sacrifice learnability so that power-users can be more efficient. It seems likely that Moodle will continue to lean towards learnability in these cases, though again 99% of the time these goals are not in conflict.

==Don't automatically suggest a new preference==

In open source projects it is often easier (in the short term) to defuse any disagreement by 'adding a preference'. This means you end up with double (or triple..) the code to achieve the same thing.

'''Every time you provide an option, you're asking the user to make a decision.''' - [http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html Joel on Software: Choices]

# That's more code to write, debug, maintain etc. And once you end up with preferences interacting the potential combinations become astronomical and you end up in the situation that no two people are actually running the same program.
# Each new preference wastes user attention span and time. If you think you really need to add a preference, consider applying [[Progressive_Disclosure|progressive disclosure]].

This can, over time lead to a profusion of preferences, each of which has a cost that needs to be weighed against its benefit. Sometimes finding a solution that pleases everyone (to some degree) is preferable to adding preferences for each idea. Learn to know what your users really need. Instead of pleasing everyone separately, [http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php make opinionated software].

This is explained far better by Havoc Pennington in his piece on Open Source and User Interface, in particular the "Question of Preferences " section about half way through: http://www106.pair.com/rhp/free-software-ui.html

==Is Moodle a website?==

The somewhat tricky thing with regard to Moodle's usability is that Moodle is a web application, not a web site (though the line between the two is sometimes blurry) and few, if any, books have been written for that class of software. Therefore many applicable pieces of advice (from web, software or product usability guides) need to be reassessed with Moodle's nature in mind.

== Additional Resources ==

=== Websites ===

* 37 Signals Blog: Signal versus Noise http://www.37signals.com/svn/
* Jakob Nielsen's website http://useit.com/
** [http://www.elearningpost.com/articles/archives/jakob_nielsen_on_e_learning/ an interview of Jakob Nielsen about e-learning]
* Joel Spolsky's User Interface Design for Programmers http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
* First Principles of Interaction Design by Tog (Bruce Tognazzini) http://www.asktog.com/basics/firstPrinciples.html
* [http://mpt.net.nz/archive/2008/08/01/free-software-usability Challenges of usability in an Open Source context]
* [http://wiki.fluidproject.org/display/fluid/Design+Handbook Fluid Design Handbook], an excellent resource to User Centered Design methods
* [http://mashable.com/2009/01/09/user-experience-design/ 10 Most Common Misconceptions About User Experience Design]

=== Books ===

'''Web specific'''

* [http://www.sensible.com/ Don't Make Me Think] by Steve Krug
:A really good book, full of good info yet brief, well written and accessible. A [http://www.sensible.com/chapter.html sample chapter] is made available on his site, as well as [http://www.sensible.com/secondedition/index.html 3 complete chapters] from the 1st edition in pdf format, covering a complete script for usability testing.

* [http://www.digital-web.com/articles/defensive_design_for_the_web/ Defensive Design For The Web] by [http://www.37signals.com/ 37 Signals] (Matthew Lindeman and Jason Fried).

* [http://www.zeldman.com/dwws/ Designing with Web Standards, 2nd ed.] by Jeffrey Zeldman

'''Moodle specific'''
* [http://www.pilpi.net/masters User experience design in open source development: Approaches to usability work in the Moodle community] by Olli Savolainen

'''Computer specific'''

* [http://books.google.fi/books?id=04cFCVXC_AUC&dq=the+inmates+are+running+the+asylum&printsec=frontcover&source=bn&hl=en&ei=COknSur4FIfz_AaDzuXYAQ&sa=X&oi=book_result&ct=result&resnum=4 The inmates are running the asylum - Why High-Tech Products Drive Us Crazy and How to Restore the Sanity] by Alan Cooper
:A usability classic: a thought-stimulating, yet an entertaining higher-level perspective on the friction between user-centered thinking and software engineering thinking, and on solutions to start really designing for the actual goals of the users using Personas, Goals and Scenarios.
* [http://books.google.com/books?id=D39vjmLfO3kC The Humane Interface] by Jef Raskin
:Jef, who sadly passed away recently, has been more and more research focused for the last 15 years, since his days helping to create the first Macintosh. This led to a discarding all practical considerations to concieve of the 'perfect' UI, rather than attending to the pragmatic, checklist-style "improve your site in 15 minutes" genre. However his writing is excellent in consistently laying the blame for problems with the computer and its software, not the user. It is often easy to fall into the trap of thinking 'stupid' users are the problem, rather than simply a design parameter. It is however worth remembering that (unless you are a research fellow) many of these technical faults must be worked with to a certain degree, and that "perfection can often be the enemy of the good".

'''General'''

* ''Psychology of Everyday Things'' by Donald Norman (new edition aka [http://books.google.com/books?id=EXwkGwAACAAJ The Design of Everyday Things])
:It's a classic, so some of the examples are a bit dated, but the basic message that it is fundamentally hard for a designer (no matter how smart) to place themselves mentally in the position of a user is put across well. I think about this book's simple message every time I push a door I was supposed to pull and vice versa.
* [http://books.google.com/books?id=h_wAbnGlOC4C Emotional Design: Why We Love (or Hate) Everyday Things] by Donald Norman

== See also: ==
* [[Usability FAQ]]
* [[Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]]
* [http://moodle.org/mod/data/view.php?d=55&rid=4640 "Make the Most of Your Studies: A Case Study and Web Usability Study Using the Collaborative Virtual Learning Environment Moodle with Postgraduate Students from Oil & Gas Related Courses"] MSc Dissertation by [http://moodle.org/user/view.php?id=757944&course=1 Syndia Lengyel]

[[Category:Usability]]
[[Category:Usability]]

[[ja:開発:ユーザビリティ]]

Usability

2012-03-12T09:00:11Z

Pilpi: /* Books */ Noticed, though late that my work about Usability practice in the Moodle community had been forgotten from here altogether.

{{GSOC 09}}
Some pointers, links, and resources on the topic of usability with respect to Moodle.

For general information on the concept of usability see
[http://www.lukew.com/ff/entry.asp?797 Definition of user experience (UX)].

==Contribute to Moodle through Usability testing==

An ongoing need of a project such as Moodle is to keep the interface usable as the code matures. Improvements and added functionality may seem like a wonderful innovation from the coder's or administrator's point of view, but if the end-user is confused or frustrated by it (or can't even find it!), its usefulness drops dramatically.

The idea of usability testing is simple: a person who is well-versed in Moodle gets together a small number of willing participants, who have no previous experience of using Moodle, and who are not technology experts (such as web designers etc...). The closer these people are to the "typical user" (for example a high school student), the better. The person conducting the test simply observes the participant as he/she tries to achieve a number of tasks. A video/sound recording can also be made with the prior consent of the participant, and is useful for later analysis.

The person conducting the test then pools together the issues that were common between most participants, and produces a short and concise report that is then used by Moodle developers to improve the user interface.

This sort of contribution requires no coding skills whatsoever, not even HTML. You just need to be familiar with using Moodle as a learner.

The links at the bottom of this article include Steve Krug's book, "Don't make me think!". This books is the best introduction to Usability testing I know of.

See also: [[Usability_testing_protocol|Usability testing protocol]]

== "Bike Sheds" ==

Because changes with regard to Usability are necessarily visual and on the surface, it is a potential Bike Shed issue. This is a metaphor bandied around in Open Source circles that suggests (in brief) that the smaller the change, the greater the discussions that surround it in forums and mailing lists. People proposing small improvements to Moodle should be aware of this phenomenon and not take the level of discussion as an implicit criticism of their suggestion.

You can read a well-written account of this metaphor that [http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING originated on the BSD mailing list] under http://www.bikeshed.com.

==Avoid the word "intuitive"==

(Definition: [http://www.usabilityfirst.com/glossary/main.cgi?function=display_term&term_id=444 Intuitive])

Intuitive is a word you should avoid in discussions of usability as its meaning is often confused.

It is generally accepted that a large part of usability is based on familiarity and experience. Human Interface Guidelines published by people such as Apple or Gnome strive for logic and consistency so that the learning can be easier, and the experience more valuable. Using 'intuitive' as a short-hand for something that is familiar often gives the impression that if something is 'intuitive' then it is so regardless of prior learning or experience and therefore equally true for everyone. It suggests that the goodness or badness of an interface is situated within the interface itself, rather than in the relationship between the user and the interface.

Very few people would object to the statement that 'Apple software is more intuitive than Windows software' yet to someone who has only used Windows software, this is clearly not the case. Avoiding using the word yourself and mentally translating other people's use of intuitive as 'something I like' e.g. "Moodle's block system is unintuitive" = "Moodle's block system is something I don't like" may help to defuse arguments because it is harder to argue about personal opinions that are stated explicitly as personal opinion rather than disguised as objective statements about the software.

Therefore what is called intuitive, in the case of Moodle, will depend on your experience and expectations of other learning systems, web applications or sites, as well as software in general and thus varies from person to person. Usability studies should therefore average out the expectations of many people to find what is 'intuitive' and check to see if different groups (e.g. users of particular alternative systems, total beginners) have different expectations.

This article explains more and better (with diagrams!): http://www.uie.com/articles/design_intuitive/

==Learnability versus usability==

People often confuse these topics, understandably as they do have a great deal in common. Generally what are referred to as 'usability' improvements make things both easier to learn and easier for experienced users. Occasionally decisions need to be made favouring one over the other, and in those situations it helps to be explicit which of the two you are referring to. There are many successful software tools that sacrifice learnability so that power-users can be more efficient. It seems likely that Moodle will continue to lean towards learnability in these cases, though again 99% of the time these goals are not in conflict.

==Don't automatically suggest a new preference==

In open source projects it is often easier (in the short term) to defuse any disagreement by 'adding a preference'. This means you end up with double (or triple..) the code to achieve the same thing.

'''Every time you provide an option, you're asking the user to make a decision.''' - [http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html Joel on Software: Choices]

# That's more code to write, debug, maintain etc. And once you end up with preferences interacting the potential combinations become astronomical and you end up in the situation that no two people are actually running the same program.
# Each new preference wastes user attention span and time. If you think you really need to add a preference, consider applying [[Progressive_Disclosure|progressive disclosure]].

This can, over time lead to a profusion of preferences, each of which has a cost that needs to be weighed against its benefit. Sometimes finding a solution that pleases everyone (to some degree) is preferable to adding preferences for each idea. Learn to know what your users really need. Instead of pleasing everyone separately, [http://gettingreal.37signals.com/ch04_Make_Opinionated_Software.php make opinionated software].

This is explained far better by Havoc Pennington in his piece on Open Source and User Interface, in particular the "Question of Preferences " section about half way through: http://www106.pair.com/rhp/free-software-ui.html

==Is Moodle a website?==

The somewhat tricky thing with regard to Moodle's usability is that Moodle is a web application, not a web site (though the line between the two is sometimes blurry) and few, if any, books have been written for that class of software. Therefore many applicable pieces of advice (from web, software or product usability guides) need to be reassessed with Moodle's nature in mind.

== Additional Resources ==

=== Websites ===

* 37 Signals Blog: Signal versus Noise http://www.37signals.com/svn/
* Jakob Nielsen's website http://useit.com/
** [http://www.elearningpost.com/articles/archives/jakob_nielsen_on_e_learning/ an interview of Jakob Nielsen about e-learning]
* Joel Spolsky's User Interface Design for Programmers http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html
* First Principles of Interaction Design by Tog (Bruce Tognazzini) http://www.asktog.com/basics/firstPrinciples.html
* [http://mpt.net.nz/archive/2008/08/01/free-software-usability Challenges of usability in an Open Source context]
* [http://wiki.fluidproject.org/display/fluid/Design+Handbook Fluid Design Handbook], an excellent resource to User Centered Design methods
* [http://mashable.com/2009/01/09/user-experience-design/ 10 Most Common Misconceptions About User Experience Design]

=== Books ===

'''Web specific'''

* [http://www.sensible.com/ Don't Make Me Think] by Steve Krug
:A really good book, full of good info yet brief, well written and accessible. A [http://www.sensible.com/chapter.html sample chapter] is made available on his site, as well as [http://www.sensible.com/secondedition/index.html 3 complete chapters] from the 1st edition in pdf format, covering a complete script for usability testing.

* [http://www.digital-web.com/articles/defensive_design_for_the_web/ Defensive Design For The Web] by [http://www.37signals.com/ 37 Signals] (Matthew Lindeman and Jason Fried).

* [http://www.zeldman.com/dwws/ Designing with Web Standards, 2nd ed.] by Jeffrey Zeldman

'''Moodle specific'''
* [http://www.pilpi.net/masters User experience design in open source development: Approaches to usability work in the Moodle community] by Olli Savolainen

'''Computer specific'''

* [http://books.google.fi/books?id=04cFCVXC_AUC&dq=the+inmates+are+running+the+asylum&printsec=frontcover&source=bn&hl=en&ei=COknSur4FIfz_AaDzuXYAQ&sa=X&oi=book_result&ct=result&resnum=4 The inmates are running the asylum - Why High-Tech Products Drive Us Crazy and How to Restore the Sanity] by Alan Cooper
:A usability classic: a thought-stimulating, yet an entertaining higher-level perspective on the friction between user-centered thinking and software engineering thinking, and on solutions to start really designing for the actual goals of the users using Personas, Goals and Scenarios.
* [http://books.google.com/books?id=D39vjmLfO3kC The Humane Interface] by Jef Raskin
:Jef, who sadly passed away recently, has been more and more research focused for the last 15 years, since his days helping to create the first Macintosh. This led to a discarding all practical considerations to concieve of the 'perfect' UI, rather than attending to the pragmatic, checklist-style "improve your site in 15 minutes" genre. However his writing is excellent in consistently laying the blame for problems with the computer and its software, not the user. It is often easy to fall into the trap of thinking 'stupid' users are the problem, rather than simply a design parameter. It is however worth remembering that (unless you are a research fellow) many of these technical faults must be worked with to a certain degree, and that "perfection can often be the enemy of the good".

'''General'''

* ''Psychology of Everyday Things'' by Donald Norman (new edition aka [http://books.google.com/books?id=EXwkGwAACAAJ The Design of Everyday Things])
:It's a classic, so some of the examples are a bit dated, but the basic message that it is fundamentally hard for a designer (no matter how smart) to place themselves mentally in the position of a user is put across well. I think about this book's simple message every time I push a door I was supposed to pull and vice versa.
* [http://books.google.com/books?id=h_wAbnGlOC4C Emotional Design: Why We Love (or Hate) Everyday Things] by Donald Norman

== See also: ==
* [[Usability FAQ]]
* [[Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]]
* [http://moodle.org/mod/data/view.php?d=19&rid=2486 "Make the Most of Your Studies: A Case Study and Web Usability Study Using the Collaborative Virtual Learning Environment Moodle with Postgraduate Students from Oil & Gas Related Courses"] MSc Dissertation by [http://moodle.org/user/view.php?id=757944&course=1 Syndia Lengyel]

[[Category:Usability]]
[[Category:Usability]]

[[ja:開発:ユーザビリティ]]

Moodle User Interface Guidelines

2011-08-22T14:14:03Z

Pilpi: /* See also */

__NOTOC__
<p class="note">

DRAFT DOCUMENT
<br /><br />

Many of the pages below are incomplete or obsolete.
<br /><br />

These guidelines were produced as part of a student project in 2009, and are not yet official Moodle guidelines.
</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [https://docs.moodle.org/20/en/Roles_and_capabilities Roles and capabilities]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

* [http://developer.fellowshipone.com/patterns/ Design Patterns Library & Code Standards] by Fellowship technologies

== See also ==
* Further development on Talk page: [[Talk:Moodle_User_Interface_Guidelines]]
* '''[https://docs.moodle.org/20/en/Using_Moodle_book Using Moodle book]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines

2011-08-22T14:11:53Z

Pilpi: /* See also */

__NOTOC__
<p class="note">

DRAFT DOCUMENT
<br /><br />

Many of the pages below are incomplete or obsolete.
<br /><br />

These guidelines were produced as part of a student project in 2009, and are not yet official Moodle guidelines.
</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [https://docs.moodle.org/20/en/Roles_and_capabilities Roles and capabilities]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

* [http://developer.fellowshipone.com/patterns/ Design Patterns Library & Code Standards] by Fellowship technologies

== See also ==
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]
* '''[https://docs.moodle.org/20/en/Using_Moodle_book Using Moodle book]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines

2011-08-22T14:11:35Z

Pilpi:

__NOTOC__
<p class="note">

DRAFT DOCUMENT
<br /><br />

Many of the pages below are incomplete or obsolete.
<br /><br />

These guidelines were produced as part of a student project in 2009, and are not yet official Moodle guidelines.
</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [https://docs.moodle.org/20/en/Roles_and_capabilities Roles and capabilities]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

* [http://developer.fellowshipone.com/patterns/ Design Patterns Library & Code Standards] by Fellowship technologies

== See also ==
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]
* '''[Using Moodle book https://docs.moodle.org/20/en/Using_Moodle_book]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines:Introduction

2011-08-22T14:08:37Z

Pilpi:

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Introduction'''

'''These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces. '''

'''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.'''

''The primary purpose'' is to document what is already there, the parts of Moodle that are proven by practice to work. What is the Moodle style - what is specific about the Moodle UI that makes it Moodlish and is better than any other UI for the purpose it serves? It often seems it is difficult to know how to make an UI coherent with the Moodle style. I have started to find out, and I intend to document it. This way, Moodle can give a more consistent user experience in the future, by helping developers quickly find what there already is. The guidelines under the heading '''Moodle UI library''' are meant for this.

All of the guidelines are to have a link to a document called "Examples and Code Samples: [Guideline Name] ", where it is documented where to look for examples on how to implement a given guideline in practice.

''The other, and perhaps a longer-term purpose'' is to have a bit of a reference and a foundation to invoke discussion about usability issues. There are many guidelines that often apply not only to Moodle but also to other web applications. Getting them right also helps to make Moodle more welcoming to people coming from elsewhere on the web, and use Moodle only occasionally. These guidelines are under the heading '''General design guidelines'''.

Usability/Improve Moodle User Experience Consistency

2010-10-29T13:53:48Z

Pilpi:

Parent page:[[Usability|Usability]]

'''Project outcome: [[Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]]'''

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.

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.

'''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.'''

{{GSOC 09}}
==Overview==
*'''Progress meter:''' MDL-19586
*'''Resulting guidelines site:''' [[Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]]
* Project documents:
**'''Detailed project plan (and schedule):''' [[Usability/Improve Moodle User Experience Consistency/Detailed project plan]]
** '''Notes:''' [[Usability/Improve Moodle User Experience Consistency/Notes from UI inspection]]
*'''Forum:''' [http://moodle.org/mod/forum/discuss.php?d=119507#p523934 Usability forum]
*'''Blog:''' [http://www.pilpi.net/software/moodle/ Project blog]'''
*'''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)
*'''Project student:''' [[User:Olli Savolainen]] / University of Tampere, Finland

===Executive Summary===
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.

=== Motivation ===
In Summer 2008, I worked to [[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.

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.

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.

== Summer 2009: In practice ==

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.

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.

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.

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.

===Project plan===

'''Detailed project plan (and schedule):''' [[Usability/Improve Moodle User Experience Consistency/Detailed project plan]]

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 [[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.

'''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.

Well, it's useful to organise the stages, indicate their completion status,
Moodle versions, as well as add watchers/notification and so on. Consider
it a Moodle.org usability guideline :) [[User:Martin Dougiamas|Martin Dougiamas]] 08:25, 3 June 2009 (UTC)

=== UIs to examine ===
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.

☑=initially examined for elements and interaction styles to include

* Course management: Front page, category page, Main course page (including different formats; topics ☑), course completion (http://moodle.org/mod/forum/discuss.php?d=126016)
* Roles management
* My Moodle, User profiles, course participants list
* 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)
* Gradebook (the new UI interoduced in 1.9 and 2.0 in 2009), Outcomes, Backup& Restore, Question bank, various Settings screens (forms).
* More modules listed in using moodle forums listing (could not find it from moodle.org menus now)
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']

==== Various ways to categorize UIs and their parts ====
* '''Goal-related'''
** Functional wholes: site administration, course hierarchy management, user management, course management, student: keeping track of courses/duties, rights management (contexts,roles)
** Processes: installation, logging in
** Use cases: login when following link to protected page, checking for new posts, grading things
** User motivations: efficiency, privacy, social meaningfulness, fitness for purpose, satisfaction/pleasantness
* '''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)
* '''Functional units''': courses, modules, blocks, editors
** editors: text editors (plain, wysiwyg), equation editors, image editors, sound editors
** '''Modules''': Forum, Quiz, Wiki, Assignment, Glossary, Gradebook, ...
** web app taxonomy: configuration, content editing pages
** domain-specific taxonomy: course categories, courses, modules, blocks
* '''Page regions''': Header, footer, sidebars, content area
* '''Interaction styles''': wizards, forms, different course formats
* '''Elements''': Tabs, different form elements, links, buttons, dialogs, breadcrumb navigation, tooltips, list tools (add element to list from a set), table tools
** '''Navigational elements''': Search, breadcrumb, menu, tabs, modes, headings
* '''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,
** '''Modality''': auditive, visual, tactile
* Modes
** global: "view as student"

=== Interaction styles/elements to possibly examine ===
striking through as temporarily moving to an openoffice.org document
<s>
* consistency of feedback from any and all user actions; normal and error situations; recovery
* data listings, such as quiz editing and moodle course front page
** functionality: moving elements in a list (reordering), moving elements between lists
** gradebook: clicking on column titles to highlight the column
** tables vs. lists vs. divs with complex data
** alternating colours for rows: in general it is a good idea and helps to guide the eye better than just a table grid. There should be a contrast in luminosity of the rows (just alternating hue might not be enough), to make sure also colorblind people can see the difference. Also if some rows/colours can be selected, changing their background colour again, this might have to be rethought.
** filtering selection lists MDL-17780 MDL-19285
* forms
** simplicity through progressive disclosure
*** quiz question editing forms for various question types
** on simple forms, (less than one page / four elements or less) autofocus the first field of the form on body onload IF none of the fields have any changed content in them (i.e. if the user is not returning to the page from browser history, see: MDL-825)
** autosave as a standard on all forms: in case of network outage / simultaneous editing by someone else / some other conflict situation, always tell the user there was an error and **give the users their data back** so that they can
*** optimally, try again saving the data, resolving that conflict
*** or at least copy what they filled in to clipboard
*** currently losing data is also a problem when the editing time of a forum post has passed but the user is already in the post editing form and has changed something: moodle gives an error message that editing time has passed, and just discards all the changes the user tried to save.
**** The same applies when user gets logged out for whatever reason: the session ID changes when they log in again so even if they manage to do that (in a different window), submitting the form again fails and the user loses all submitted data: if there are no security issues to this, Moodle should give the user their data back so they do not lose it.
** Feedback for form actions; an intermediate page giving feedback with META refresh
*** slow, clumsy, issues with browser history(?), not standard with most of the rest of the web
** Like in WordPress, javascript confirmation if the user presses the back button when already having filled in data but not submitted the form. Especially when using ctrl and shift with arrow keys to move around in text (though it's possibly a marginal use case), it is easy to inadvertedly trigger the shortcut key of the back button in the browser.
** Configuration defaults: http://moodle.org/mod/forum/discuss.php?d=124533
** Date selection: use javascript selector (how about time?)
** Buttons in each module configuration: save and return to course / save and display / cancel. Are there really use cases to support having this choice each time?
* editing modes: inline editing (course frontpage) vs. editor (quiz)
** 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
** http://moodle.org/mod/forum/discuss.php?d=122300#p536641
** 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
* dialog title bars visuals: file selector vs. quiz dialogs
* modal buttons; buttons that have an on/off state: show the command to change or the current status
** According to the strictest rules of form element usage, everything should ideally be done with radio buttons and a submit button to confirm the selection. However, this is very clumsy.
** track/subscribe a forum: button saying yes/no in the forums listing of a course VS link saying "Subscribe to this forum"/"Unsubscribe from this forum" or "Track unread posts"/"Don't track unread posts"
** show/hide controls (eye icon/button): should it reflect the current status or the status after pushing? one idea is to have a button-style control with pressed/non-pressed visual status (thanks to Hans de Zwart)
** In profile, enable/disable e-mail (2.0)
* usage of buttons vs. links
** general guidelines of using buttons for commands/actions (non-bookmarkable POST or AJAX request -> not in URL) and links for navigation/location (GET request -> shows also in URL)
*** VS what is usually done in Moodle
**** In profile, clicking (this e-mail address is disabled) does not explain it but just removes the link! (Apparently fixed for 2.0 but raises another issue of changing status of a setting with an icon)
** 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.
** http://natbat.net/2009/Jun/10/styling-buttons-as-links/ - is the only UI difference that reloading (and browser history otherwise) works badly with POST? (this can be fixed with a HTTP redirect)
*** (08:22:26 AM) timhunt: Olli, the real reason for the difference between GET and POST comes when you think about web caches, or clicking reload in the browser, or, getting more technical, REST web services. (08:23:18 AM) timhunt: A POST does something, and should not be repeated, or served from a cache, without careful thought. A GET, that just pulls information, can safely be served from a cache, or repeated.
* 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
** [http://www.futurice.com/services/we_can_we_care an interesting deviation from the standard tabs visual design]
* Search
* TITLE elements of pages: descriptive of the specific content
* popup_form() dropdown command menus (add new activity to course) vs. YUI dialogs such as 'add new question' in Quiz
* 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/])
* usage of the frames which are rounded at the bottom. are they for summaries (m2q ► CF101 ► Resources ► tiedostot) or for the main content? (resource)
* update this [modulename] button, and various additional buttons/links nearby
** glossary: Import entries / Export entries Printer-friendly version
** forum: subscripthion permission status, force everyone to be subscribed (->button), show/edit subscriptions, subscribe (->button)
* visual consistency of toolbars (and other windowingsystem-like visuals) in tools such as equation editor, drawing tool, rich text editor
* wizards, such as backup, need to act like wizards.
** 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.
**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).
** what makes a wizard? http://ui-patterns.com/pattern/Wizard http://designinginterfaces.com/Wizard
**All of this functionality is provided by PEAR QuickForm_Controller.
*** 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=
*** a progressive enhancement AJAX to quickform_wizard: http://www.bubbling-library.com/eng/api/docs/plugins/wizard-documentation.html
</s>
==== Moodle / CMS elements conveying specific semantics ====
* Blocks
* Themes
* Filters

==== Future prospects ====
* notification popups (like facebook's) - something like http://www.paquitosoft.com/notimoo/ but more subtle and with YUI
* explore google wave's interaction styles

=== Outcomes ===
# As a result of having discovered consistency issues, fixes to Moodle 2.0 UI code to enhance the overall user experience (UX)
# 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.
# Secondary outcome: find and gather typical use cases of core UIs/modules -> useful for usability testing and further UI design

The format in which to present the guidelines is still unclear. The main objectives are
* Lightness, quickness: rather links to examples and screenshots than lengthy explanations
* Interlinked elements (UI's, issues, guidelines, etc.) to facilitate keeping documentation in context and easing maintenance.

=== What is ahead: challenges ===
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].

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.

Also, usability testing the suggested solutions sufficiently for actually changing the implementation is quite a challenge during just one Summer.

== Background: The Ultimate Goals ==

=== Goals ===
'''''Give power to the developers to create good, Moodle-style UI's'''''

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.

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).

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.

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.

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).

=== Later: Documented user descriptions and scenarios ===

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.

This knowledge about users is often expressed in terms of Personas, scenarios and use cases.
* [[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.
* Also, Moodle has used [http://wiki.fluidproject.org/display/fluid/Moodle+UX+Walkthrough+Working+Group?showChildren=false fluid efforts], including their personas and scenarios

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).

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.

== My competences ==

In Summer 2008 I redesigned and implemented [[Quiz_UI_redesign|the Quiz editing UI]]: did interviews for [[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.

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.

* [http://tracker.moodle.org/secure/IssueNavigator.jspa?reset=true&assigneeSelect=specificuser&assignee=pilpi&resolution=1 List of my completed tracker issues]
* [http://www.linkedin.com/in/ollisavolainen LinkedIn]
* [https://www.ohloh.net/accounts/pilpi Ohloh]

== Current state of research (in constant state of change)==

===Advice to possibly include in the final documentation===
* 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).
** 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.
** 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
** [http://www.joelonsoftware.com/uibook/chapters/fog0000000059.html Joel on Software on Choices)
** [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"]
* 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."
* [[Progressive Disclosure]]
* [[Tooltips]]
* 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]

=== Issues, to be researched further ===
These are not tested and proven, but some things I have discovered while working on Moodle
* forums
** 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.
*** 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"
**** 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
** 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?]
* 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?
** course front page: showing/hiding sections
* Feedback: sometimes Moodle gives non-localized, entirely technical and unhelpful feedback even to normal users.
** "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 "
*** 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).
* Quiz:
** new interaction styles introduced by usability work of summer 2008
*** 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
*** using overflow:none in listings where the content does not fit screen
*** question bank window: the concept of "toolbar window", per-user open/close state persistence
** integration with question bank http://tracker.moodle.org/browse/MDL-18001 (is there something similar somewhere else in moodle?)
** dialog styles: ok button vs something named after the actual dialog action, cancel button, which first, apply button(?), dialog visual style
* New UI work recently done on gradebook
* Moodle messaging:
** Might be required: unobtrusive notifications for new private / forum messages, external notifications consistently regardless of whether user is logged in
** Block user: green icon? (Tim, Anthony)
* Facilities for consistent undoing across Moodle, see for example [[Talk:Projects_for_new_developers#XML_templates_for_admin_settings]]
* 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)
* new gradebook: visual report disabled states
* 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
* 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
** are all these pages organized somewhere in the wiki centrally?
* 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.
** TODO: review other web apps, how is help done
** 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)
* 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)
==== Other considerations ====
* 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
* In Moodle Moot UK '09 Martin Dougiamas mentioned setting up functional testing in the tracker.
** -> This is not very far from the goals of usability testing:
**** -> some of the base work is similar since to do functional testing the core functionality has to be defined and perhaps even prioritized.
** -> And usability testing core functionality is the basis of this project.
** TODO: Where is this discussed and documented? http://moodle.org/mod/forum/view.php?id=56 Not here?
* 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)
* 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)

== Further reading ==
** [http://www.joelonsoftware.com/articles/fog0000000033.html Joel on software: Painless functional specs] - a rather different way of writing to developers about software
* [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?
* [http://www.useit.com/papers/standards.html Assessing the Usability of a User Interface Standard], By Henrik Thovtrup and Jakob Nielsen, 1991
* [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.
* [http://www.useit.com/papers/webwriting/ Writing for the web], useful links found:
** http://www.useit.com/alertbox/content-strategy.html
** http://www.useit.com/papers/webwriting/rewriting.html
** http://www.e-gineer.com/v1/articles/web-writing-for-many-interest-levels.htm
** http://www.gooddocuments.com/homepage/homepage.htm
* I will probably need to dive pretty deep in [[Navigation_2.0]] ([http://moodle.org/mod/forum/discuss.php?d=116936#p519530 discussion linking consistency work with navigation])
** Navigation blocks in the sideblock of all modules.
* 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
** http://moodle.org/mod/forum/discuss.php?d=119227#p522673
* [http://tracker.moodle.org/browse/MDL-14639 Last summer's GSoc usability project]
** https://docs.moodle.org/en/Student_projects/Usability_issues/T1
* To compare with current state of Moodle: [http://wiki.fluidproject.org/display/fluid/Moodle+UX+Walkthrough+Working+Group?showChildren=false fluid findings]
* [http://moodle.org/mod/forum/user.php?id=636237&course=5 Thomas Hanley's forum postings]
* Wikipedia guidelines: http://en.wikipedia.org/wiki/Category:Wikipedia_style_guidelines http://en.wikipedia.org/wiki/Category:Wikipedia_editing_guidelines

=== HIGs ===
* [http://wiki.laptop.org/go/OLPC_Human_Interface_Guidelines OLPC HIG]
* [http://library.gnome.org/devel/hig-book/stable/ Gnome HIG] - a lot of what is here also applies to Moodle
* [http://developer.apple.com/iphone/library/documentation/UserExperience/Conceptual/MobileHIG/Introduction/Introduction.html iPhone HIG] - another example of comprehensive guidelines producing great interfaces
** [http://developer.apple.com/documentation/UserExperience/index.html Leopard Guides: User Experience]
* [http://msdn.microsoft.com/en-us/library/aa511258.aspx Windows HIG]
* [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
* [[Interface_guidelines|Current Moodle Interface Guidelines]] - Old and never completed
==== About guideline/pattern/HIG writing ====
* Gerard Meszaros, Jim Doble: [http://www.hillside.net/patterns/writing/patternwritingpaper.htm A Pattern Language for Pattern Writing] (Thanks to Tim Hunt!)
** http://xunitpatterns.com/Introduction.html (again, thanks to Tim)
* [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"])

==== Patterns ====
* http://ui-patterns.com/
* http://visiblearea.com/cgi-bin/twiki/view/Patterns/Patterns_repository
* [http://wiki.fluidproject.org/display/fluid/User+Manual+Table+of+Contents Fluid components], [http://wiki.fluidproject.org/display/fluid/Design+Patterns Fluid patterns]
* collections of patterns: [http://konigi.com/interface/latest konigi], [http://www.flickr.com/groups/designpatterns/ flickr]

=== Forum discussions ===
* [http://moodle.org/mod/forum/discuss.php?d=119502 Introducing the project] (copy: http://moodle.org/mod/forum/discuss.php?d=119507#p523934)

Quiz UI redesign

2010-09-30T17:36:37Z

Pilpi:

'''Status: project finished and code incorporated into Moodle 2.0 in Autumn 2008.'''

* 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.
* MDL-17284 Final tracker item
* [http://moodle.org/mod/forum/discuss.php?d=103869 Final forum discussion]
* For permanent documentation, '''See also: [[Quiz Usability portal]]'''

----
This is the Docs page for the Quiz UI redesign project 2008

'''The project blog''': http://www.pilpi.net/software/moodle_quiz_ui/ .

* [[Quiz UI redesign prototype presumptions | Quiz UI redesign prototype presumptions]]
* '''[[Quiz UI redesign - Design specification | Design specification]]'''
* Project tracker: http://tracker.moodle.org/browse/CONTRIB-528

== Related forum discussions ==
Some are still missing here. The last one is the newest, and the location of current discussion.
* Inquiry about the status of the UI: [http://moodle.org/mod/forum/discuss.php?d=63612 Quiz UI development]
* Suggesting concrete new UI: [http://moodle.org/mod/forum/discuss.php?d=72828 New Quiz UI prototype published]
** Related: [http://moodle.org/mod/forum/discuss.php?d=92870 Re: Concern of Moodle Usability - Quiz module]
* Applied for funding, Tim Hunt accepted as mentor: [http://moodle.org/mod/forum/discuss.php?d=92797 Simple Quiz building user interface]
* [http://moodle.org/mod/forum/discuss.php?d=99351#p439124 Community effort to learn about teacher quiz/exam usage habits]
* [http://moodle.org/mod/forum/discuss.php?d=100367 Call for comments: Quiz UI redesign prototype (new iteration now usability tested)]
* [http://moodle.org/mod/forum/discuss.php?d=102062 Call for comments: Quiz UI redesign demo published]
* [http://moodle.org/mod/forum/discuss.php?d=103869 Should Olli's new quiz editing interface be included in Moodle 2.0?]
** [http://moodle.org/mod/forum/discuss.php?d=103870 cross-post]

== Scenarios ==

===Scenarios work===
* '''[[Quiz_UI_redesign scenarios - conclusions| Scenarios work conclusions (executive summary) ]]'''
* [[Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F|The idea and the content of the scenarios interviews I did]]

===The Scenarios===
* [[Quiz UI redesign scenarios - Scenarios index]]

== Prototype testing ==
=== June 2008 ===
Published June 27th, 2008.

[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 '''[[Quiz UI redesign - Design specification | Design specification]]''' for a more final, translated view of the UI''' )
* [[Quiz UI redesign - prototype testing background|Background]]
* [[Quiz_UI_redesign_prototype_questions#Testing_questions_used_in_spring.2Fsummer_2008|Tasks]]
* [[Quiz UI redesign - prototype testing report|Prototype testing report]]

===Testing with the actual implementation: August 2008===
See also: [[Quiz_Usability_portal#Future_development]]
* [[Quiz_UI_redesign/usability testing of August 2008/Executive summary|Quiz UI redesign / usability testing of August 2008 / Executive summary]]
* [[Quiz_UI_redesign/usability testing of August 2008/Issues|Quiz UI redesign / related issues in usability testing of August 2008]]
* Quiz UI redesign / [[Quiz_UI_redesign/usability testing of August 2008/Summary of solutions|Direct reactions to usability testing: List of solutions]]
* [[ Usability testing in August 2008/Test setting and tasks / background|Test setting and tasks / background]]

== Development ==
Moved to [[Quiz UI redesign - development]]

[[Category:Usability]]

== Obsolete ==
* Obsolete: [[Quiz UI redesign prototype | Quiz UI redesign prototype]]
* Pretty obsolete: [[Quiz UI redesign - related use cases|Use cases]]

Quiz UI redesign

2010-09-30T17:36:11Z

Pilpi:

'''Status: project finished and code incorporated into Moodle 2.0 in Autumn 2008.'''

* 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.
* MDL-17284 Final tracker item
* [http://moodle.org/mod/forum/discuss.php?d=103869 Final forum discussion]
* For permanent documentation, '''See also: [[Quiz Usability portal]]'''

----
This is the Docs page for the Quiz UI redesign project 2008

'''The project blog''': http://www.pilpi.net/software/moodle_quiz_ui/ .

* [[Quiz UI redesign prototype presumptions | Quiz UI redesign prototype presumptions]]
* '''[[Quiz UI redesign - Design specification | Design specification]]'''
* Project tracker: http://tracker.moodle.org/browse/CONTRIB-528

== Related forum discussions ==
Some are still missing here. The last one is the newest, and the location of current discussion.
* Inquiry about the status of the UI: [http://moodle.org/mod/forum/discuss.php?d=63612 Quiz UI development]
* Suggesting concrete new UI: [http://moodle.org/mod/forum/discuss.php?d=72828 New Quiz UI prototype published]
** Related: [http://moodle.org/mod/forum/discuss.php?d=92870 Re: Concern of Moodle Usability - Quiz module]
* Applied for funding, Tim Hunt accepted as mentor: [http://moodle.org/mod/forum/discuss.php?d=92797 Simple Quiz building user interface]
* [http://moodle.org/mod/forum/discuss.php?d=99351#p439124 Community effort to learn about teacher quiz/exam usage habits]
* [http://moodle.org/mod/forum/discuss.php?d=100367 Call for comments: Quiz UI redesign prototype (new iteration now usability tested)]
* [http://moodle.org/mod/forum/discuss.php?d=102062 Call for comments: Quiz UI redesign demo published]
* [http://moodle.org/mod/forum/discuss.php?d=103869 Should Olli's new quiz editing interface be included in Moodle 2.0?]
** [http://moodle.org/mod/forum/discuss.php?d=103870 cross-post]

== Scenarios ==

===Scenarios work===
* '''[[Quiz_UI_redesign scenarios - conclusions| Scenarios work conclusions (executive summary) ]]'''
* [[Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F|The idea and the content of the scenarios interviews I did]]

===The Scenarios===
* [[Quiz UI redesign scenarios - Scenarios index]]

== Prototype testing ==
=== June 2008 ===
Published June 27th, 2008.

[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 '''[[Quiz UI redesign - Design specification | Design specification]]''' for a more final, translated view of the UI''' )
* [[Quiz UI redesign - prototype testing background|Background]]
* [[Quiz_UI_redesign_prototype_questions#Testing_questions_used_in_spring.2Fsummer_2008|Tasks]]
* [[Quiz UI redesign - prototype testing report|Prototype testing report]]

===Testing with the actual implementation: August 2008===
See also: [[Quiz_Usability_portal#Future_development]]
* [[Quiz_UI_redesign/usability testing of August 2008/Executive summary|Quiz UI redesign / usability testing of August 2008 / Executive summary]]
* [[Quiz_UI_redesign/usability testing of August 2008/Issues|Quiz UI redesign / related issues in usability testing of August 2008]]
* Quiz UI redesign / [[Quiz_UI_redesign/usability testing of August 2008/Summary of solutions|Direct reactions to usability testing: List of solutions]]
* [[ Usability testing in August 2008/Test setting and tasks / background|Test setting and tasks / background]]

== Development ==
Moved to [[Quiz UI redesign - development]]

[[Category:Usability]]

== Obsolete ==
* Obsolete: [[Quiz UI redesign prototype | Quiz UI redesign prototype]]
* Pretty obsolete: [[Quiz UI redesign - related use cases|Use cases]]

Quiz UI redesign what makes a scenarios interview?

2010-06-19T17:51:07Z

Pilpi: Redirecting to Quiz UI redesign - what makes a scenarios interview?

#REDIRECT [[Quiz_UI_redesign_-_what_makes_a_scenarios_interview%3F]]

Quiz UI redesign what makes a scenarios interview?

2010-06-19T17:50:21Z

Pilpi: New page: #REDIRECT https://docs.moodle.org/en/Development:Quiz_UI_redesign__ what_makes_a_scenarios_interview%3F

#REDIRECT https://docs.moodle.org/en/Development:Quiz_UI_redesign__
what_makes_a_scenarios_interview%3F

Moodle User Interface Guidelines

2010-05-22T11:46:32Z

Pilpi: /* Relevant guidelines from other sites */

__NOTOC__
<p class="note">

DRAFT DOCUMENT
<br /><br />

Many of the pages below are incomplete or obsolete.
<br /><br />

These guidelines were produced as part of a student project in 2009, and are not yet official Moodle guidelines.
</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

* [http://developer.fellowshipone.com/patterns/ Design Patterns Library & Code Standards] by Fellowship technologies

== See also ==
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]
* '''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines

2010-05-22T11:46:17Z

Pilpi: /* Relevant guidelines from other sites */

__NOTOC__
<p class="note">

DRAFT DOCUMENT
<br /><br />

Many of the pages below are incomplete or obsolete.
<br /><br />

These guidelines were produced as part of a student project in 2009, and are not yet official Moodle guidelines.
</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

* [http://developer.fellowshipone.com/patterns/ Design Patterns Library & Code Standards] by Fellowship technologies

== See also ==
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]
* '''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Address Bar

2010-05-18T20:30:57Z

Pilpi: what a horrible sentence it was I found - fixed

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Address Bar'''

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).

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.

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.

Examples
* Course front pages are at moodlesite/course/view.php?id=2
* 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

== Guidelines ==
# URLs should be as short as possible.
# No underscores in parameter names or files names
# Never use two words when one would do.

===Activity modules===

*''index.php'' - lists all instances for that module in a course
*''view.php'' - displays a particular instance
*''config.html'' - configure an instance of the module

===Blocks===

*''config.html'' - configure an instance of the block

[[Category:Moodle User Interface Guidelines]]

User Data Always Safe

2010-05-17T12:49:52Z

Pilpi:

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''User Data Always (Always) Safe'''

In all cases, the user's work is sacrosanct. Nothing your
application does should lose or destroy user's work without
explicit user action. - GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]

* [http://moodle.org/mod/forum/discuss.php?d=130005 Please comment in the related discussion forum] </big>

Every part in Moodle should commit to keeping the data user has entered, safe.

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.

This issue requires further user research to find the exact issues involved, but there are also some generally well known mechanisms to employ.

As Moodle is a web application, keeping user data safe is not trivial.

==Challenges==
* Users may leave forms without submitting them
** Learning from some desktop applications (GNOME settings dialogs), users may assume their settings get automatically saved when they just enter them.
** Accidentally hitting the back button
** Clicking on a link on the form itself, assuming it is safe
** Pushing a button on their keyboard resulting in accidental usage of the back/next buttons
* Users may fill out forms "inappropriately"
** Missing data
** Session may have expired
*** 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.
** User may have logged out accidentally (browser crash; browser restores the browser session but not the Moodle session)
** User may no longer be capable of completing the action due to loss of permissions or other reasons
*** A forum post they are were replying to was deleted
*** The time to edit a post has passed while the user was editing the post
* Users may submit data when the server has gone down or network connection lost

==Solutions==

=== Preserve submitted data or giving it back to the user to keep, until it can be saved ===
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.

If a user has posted something, but it cannot be saved, never ever just throw the data away (like for example, Forum currently does).
Design your application to request the user what should be done. This requires understanding the situations users may end up in. Examples:
* 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."
==== Giving the user their data back, for copying to the clipboard ====
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.

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.

* 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."
* 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.

=== Undo ===
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.
[[Image:gmail-undo-example.png|left|frame]]
<br style="clear: both" />

=== Autosave ===
Related forum threads:
* [http://moodle.org/mod/forum/discuss.php?d=74710 AJAX-like Autosave for quiz]
* [http://moodle.org/mod/forum/discuss.php?d=107073 Autosave for Forum Compose?]
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.
* 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)
** Autosaving can be implemented using AJAX or by just submitting the form in question in the background using javascript.
* 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
* 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.
** This is also probably the only possible strategy when the server has gone down or when the network connection has been lost

=== "Save as draft" button ===
Sometimes it may be appropriate to let users save their work, before it is finished, without yet publishing it.

=== Javascript confirmation upon leaving "dirty" form ===
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.
=== TinyMCE ===
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.

=== Browser-based solutions ===
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.

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.

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.

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).

== More information ==
* Discussion: [http://moodle.org/mod/forum/discuss.php?d=130005 Critical: Keeping user data safe]
** Linked threads: [http://moodle.org/mod/forum/discuss.php?d=130010] [http://moodle.org/mod/forum/discuss.php?d=130007]
* Directory of [[Major_usability_issues_in_Moodle|Major usability issues in Moodle]]
* A solution applicable in some scenarios: MDL-18014 Tracker item for autosave (thanks Mauno Korpelainen)
* [http://code.google.com/p/tinyautosave/ TinyMCE autosave plugin] (thanks Mauno Korpelainen)

[[Category:Moodle User Interface Guidelines]]

Wizard

2010-05-15T16:03:03Z

Pilpi: /* Backup */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''

== Problem ==
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge
* 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

== Context ==
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.
== Forces: factors that affect selection ==
* Unexperienced users may get frustrated
** if too many choices, dependent on each other, are presented to them at once
** if they do not have all the background information related to a task
* Experienced users easily get frustrated
** if a task they know is split into too many phases
** if the order they enter data into the application is controlled
* 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)

== Solution ==

A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps.

=== Elements of a wizard ===

==== Status display ====
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.

==== Navigation buttons ====
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided.
** 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.
** 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.
**Provide a Previous button whenever possible to maximize user control.
* '''Next''': Used for moving to the next step
** 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.
* '''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.
** 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.

=== Notes ===
The user should be capable of using the browser's back button normally in a wizard.
* After pressing the Next button, the user should end up in the step that was before the page
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence
* 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

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.

== Common mistakes ==

Moodle Wizards typically do not have all of the required buttons nor the status display.

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).

== Examples and implementation ==

=== Backup ===

[[Image:wizard-mockup.png|thumb]]
This mockup (MDL-20036) demonstrates the main features of a wizard.
* Status display and controls for controlling the wizard
* 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.

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.

* '''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.

'''Further examples and code samples: [[Wizard Examples and Code Samples]]'''

== Related guidelines ==
Another way of only showing unexperienced users what they understand is using [[Progressive_Disclosure|Progressive Disclosure]]

== Related issues in the tracker ==
* TODO: all the issues with installation and backup

== (Optional) Further information / Sources ==
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]
* http://ui-patterns.com/pattern/Wizard
* http://www.welie.com/patterns/showPattern.php?patternID=wizard
* http://uipatternfactory.com/p=wizard/
* http://en.wikipedia.org/wiki/Wizard_(software)

[[Category:Moodle User Interface Guidelines]]

Wizard

2010-05-15T16:02:37Z

Pilpi: /* Backup */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''

== Problem ==
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge
* 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

== Context ==
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.
== Forces: factors that affect selection ==
* Unexperienced users may get frustrated
** if too many choices, dependent on each other, are presented to them at once
** if they do not have all the background information related to a task
* Experienced users easily get frustrated
** if a task they know is split into too many phases
** if the order they enter data into the application is controlled
* 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)

== Solution ==

A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps.

=== Elements of a wizard ===

==== Status display ====
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.

==== Navigation buttons ====
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided.
** 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.
** 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.
**Provide a Previous button whenever possible to maximize user control.
* '''Next''': Used for moving to the next step
** 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.
* '''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.
** 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.

=== Notes ===
The user should be capable of using the browser's back button normally in a wizard.
* After pressing the Next button, the user should end up in the step that was before the page
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence
* 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

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.

== Common mistakes ==

Moodle Wizards typically do not have all of the required buttons nor the status display.

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).

== Examples and implementation ==

=== Backup ===

[[Image:wizard-mockup.png|thumb]]
This mockup (MDL-20036) demonstrates the main features of a wizard.
* Status display and controls for controlling the wizard
* 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.

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.

* '''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.

'''Further examples and code samples: [[Wizard Examples and Code Samples]]'''

== Related guidelines ==
Another way of only showing unexperienced users what they understand is using [[Progressive_Disclosure|Progressive Disclosure]]

== Related issues in the tracker ==
* TODO: all the issues with installation and backup

== (Optional) Further information / Sources ==
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]
* http://ui-patterns.com/pattern/Wizard
* http://www.welie.com/patterns/showPattern.php?patternID=wizard
* http://uipatternfactory.com/p=wizard/
* http://en.wikipedia.org/wiki/Wizard_(software)

[[Category:Moodle User Interface Guidelines]]

Wizard

2010-05-15T16:01:09Z

Pilpi: /* Backup */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''

== Problem ==
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge
* 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

== Context ==
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.
== Forces: factors that affect selection ==
* Unexperienced users may get frustrated
** if too many choices, dependent on each other, are presented to them at once
** if they do not have all the background information related to a task
* Experienced users easily get frustrated
** if a task they know is split into too many phases
** if the order they enter data into the application is controlled
* 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)

== Solution ==

A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps.

=== Elements of a wizard ===

==== Status display ====
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.

==== Navigation buttons ====
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided.
** 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.
** 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.
**Provide a Previous button whenever possible to maximize user control.
* '''Next''': Used for moving to the next step
** 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.
* '''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.
** 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.

=== Notes ===
The user should be capable of using the browser's back button normally in a wizard.
* After pressing the Next button, the user should end up in the step that was before the page
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence
* 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

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.

== Common mistakes ==

Moodle Wizards typically do not have all of the required buttons nor the status display.

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).

== Examples and implementation ==

=== Backup ===

[[Image:wizard-mockup.png|thumb]]
This mockup (MDL-20036) demonstrates the main features of a wizard.
* Status display and controls for controlling the wizard
* 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.

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.

* '''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.

'''Further examples and code samples: [[Wizard Examples and Code Samples]]'''

== Related guidelines ==
Another way of only showing unexperienced users what they understand is using [[Progressive_Disclosure|Progressive Disclosure]]

== Related issues in the tracker ==
* TODO: all the issues with installation and backup

== (Optional) Further information / Sources ==
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]
* http://ui-patterns.com/pattern/Wizard
* http://www.welie.com/patterns/showPattern.php?patternID=wizard
* http://uipatternfactory.com/p=wizard/
* http://en.wikipedia.org/wiki/Wizard_(software)

[[Category:Moodle User Interface Guidelines]]

Wizard

2010-05-15T15:38:29Z

Pilpi: /* Backup */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''

== Problem ==
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge
* 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

== Context ==
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.
== Forces: factors that affect selection ==
* Unexperienced users may get frustrated
** if too many choices, dependent on each other, are presented to them at once
** if they do not have all the background information related to a task
* Experienced users easily get frustrated
** if a task they know is split into too many phases
** if the order they enter data into the application is controlled
* 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)

== Solution ==

A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps.

=== Elements of a wizard ===

==== Status display ====
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.

==== Navigation buttons ====
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided.
** 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.
** 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.
**Provide a Previous button whenever possible to maximize user control.
* '''Next''': Used for moving to the next step
** 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.
* '''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.
** 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.

=== Notes ===
The user should be capable of using the browser's back button normally in a wizard.
* After pressing the Next button, the user should end up in the step that was before the page
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence
* 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

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.

== Common mistakes ==

Moodle Wizards typically do not have all of the required buttons nor the status display.

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).

== Examples and implementation ==

=== Backup ===

[[Image:wizard-mockup.png|thumb]]
This mockup (MDL-20036) demonstrates the main features of a wizard.
* Status display and controls for controlling the wizard
* 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.

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.

* '''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.

'''Further examples and code samples: [[Wizard Examples and Code Samples]]'''

== Related guidelines ==
Another way of only showing unexperienced users what they understand is using [[Progressive_Disclosure|Progressive Disclosure]]

== Related issues in the tracker ==
* TODO: all the issues with installation and backup

== (Optional) Further information / Sources ==
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]
* http://ui-patterns.com/pattern/Wizard
* http://www.welie.com/patterns/showPattern.php?patternID=wizard
* http://uipatternfactory.com/p=wizard/
* http://en.wikipedia.org/wiki/Wizard_(software)

[[Category:Moodle User Interface Guidelines]]

Wizard

2010-05-15T15:38:01Z

Pilpi: /* Backup */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Wizard'''

== Problem ==
* Users need to perform a complex task, which which they are not familiar or lack needed domain knowledge
* 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

== Context ==
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.
== Forces: factors that affect selection ==
* Unexperienced users may get frustrated
** if too many choices, dependent on each other, are presented to them at once
** if they do not have all the background information related to a task
* Experienced users easily get frustrated
** if a task they know is split into too many phases
** if the order they enter data into the application is controlled
* 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)

== Solution ==

A Wizard, sometimes called an Assistant, is an interface that guides users through a predefined sequence of steps.

=== Elements of a wizard ===

==== Status display ====
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.

==== Navigation buttons ====
* '''Previous''': Whereever it is possible to allow the user to change the selections they have already made, a button labeled 'Previous' should be provided.
** 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.
** 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.
**Provide a Previous button whenever possible to maximize user control.
* '''Next''': Used for moving to the next step
** 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.
* '''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.
** 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.

=== Notes ===
The user should be capable of using the browser's back button normally in a wizard.
* After pressing the Next button, the user should end up in the step that was before the page
* After pressing the Previous button, the user should end up in the step that is after the current step in the wizard's sequence
* 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

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.

== Common mistakes ==

Moodle Wizards typically do not have all of the required buttons nor the status display.

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).

== Examples and implementation ==

=== Backup ===

[[Image:wizard-mockup.png|thumb]]
This mockup (MDL-20036) demonstrates the main features of a wizard.
* Status display and controls for controlling the wizard
* 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.

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.

* '''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.

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

'''Further examples and code samples: [[Wizard Examples and Code Samples]]'''

== Related guidelines ==
Another way of only showing unexperienced users what they understand is using [[Progressive_Disclosure|Progressive Disclosure]]

== Related issues in the tracker ==
* TODO: all the issues with installation and backup

== (Optional) Further information / Sources ==
* GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/windows-assistant.html.en Assistants]
* http://ui-patterns.com/pattern/Wizard
* http://www.welie.com/patterns/showPattern.php?patternID=wizard
* http://uipatternfactory.com/p=wizard/
* http://en.wikipedia.org/wiki/Wizard_(software)

[[Category:Moodle User Interface Guidelines]]

Page structure and types

2010-05-15T15:18:54Z

Pilpi: /* See also */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''

{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}

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]]).

== Basic page structure ==
[[Image:basic-page-structure.png||Image 1: Basic page structure]]

Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.

=== Header ===
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.

=== Navigation bar ===

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.

=== Main content area ===

In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.

The content of the page in the middle is controlled by the teacher.
* Teacher(s) can add and edit the actual content,
* The overall sequencing and organization of the content is controlled by the selected [[Course Format|Course Format]].

=== Footer ===

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.

=== Implementation ===
Note: May be obsolete from Moodle 2.0 onwards.

# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.
# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==== Page layout ====
# Print headings with print_heading, use the CSS hooks for IDs and Classes
# 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?)

== Page types ==

TODO: see [[Development_talk:Page_structure_and_types]]

== Who controls what? ==

(TODO: Perhaps move this section to moodle site structure or on a page of its own?)
=== Teachers ===
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.

The means for teachers to do this in Moodle are:
* in the center column of the content area (course index, containing mostly links to activity modules), and
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles).

The goals teachers have doing this, i.e. what it means to communicate a course's essence:
* Communicate what is expected of students
* Communicate the overall contents of the course
* The course itself: Give means/tools for students to learn (as described by social constructionism)

=== Students ===

Interact mainly with the activity modules placed in a course by a teacher.

== See also ==

Please add relevant links to implementation advice.

* [[Navigation_block]]
* [[Moodle_2.0_release_notes#Navigation]]

[[Category:Moodle User Interface Guidelines]]

Page structure and types

2010-05-15T15:16:03Z

Pilpi: /* Teachers */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''

{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}

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]]).

== Basic page structure ==
[[Image:basic-page-structure.png||Image 1: Basic page structure]]

Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.

=== Header ===
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.

=== Navigation bar ===

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.

=== Main content area ===

In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.

The content of the page in the middle is controlled by the teacher.
* Teacher(s) can add and edit the actual content,
* The overall sequencing and organization of the content is controlled by the selected [[Course Format|Course Format]].

=== Footer ===

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.

=== Implementation ===
Note: May be obsolete from Moodle 2.0 onwards.

# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.
# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==== Page layout ====
# Print headings with print_heading, use the CSS hooks for IDs and Classes
# 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?)

== Page types ==

TODO: see [[Development_talk:Page_structure_and_types]]

== Who controls what? ==

(TODO: Perhaps move this section to moodle site structure or on a page of its own?)
=== Teachers ===
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.

The means for teachers to do this in Moodle are:
* in the center column of the content area (course index, containing mostly links to activity modules), and
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles).

The goals teachers have doing this, i.e. what it means to communicate a course's essence:
* Communicate what is expected of students
* Communicate the overall contents of the course
* The course itself: Give means/tools for students to learn (as described by social constructionism)

=== Students ===

Interact mainly with the activity modules placed in a course by a teacher.

== See also ==

* [[Developement:How_Moodle_outputs_HTML]]
* [[Navigation_block]]
* [[Moodle_2.0_release_notes#Navigation]]

[[Category:Moodle User Interface Guidelines]]

Page structure and types

2010-05-15T15:15:33Z

Pilpi: /* See also */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''

{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}

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]]).

== Basic page structure ==
[[Image:basic-page-structure.png||Image 1: Basic page structure]]

Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.

=== Header ===
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.

=== Navigation bar ===

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.

=== Main content area ===

In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.

The content of the page in the middle is controlled by the teacher.
* Teacher(s) can add and edit the actual content,
* The overall sequencing and organization of the content is controlled by the selected [[Course Format|Course Format]].

=== Footer ===

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.

=== Implementation ===
Note: May be obsolete from Moodle 2.0 onwards.

# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.
# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==== Page layout ====
# Print headings with print_heading, use the CSS hooks for IDs and Classes
# 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?)

== Page types ==

TODO: see [[Development_talk:Page_structure_and_types]]

== Who controls what? ==

(TODO: Perhaps move this section to moodle site structure or on a page of its own?)
=== Teachers ===
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.

The means for teachers to do this in Moodle are:
* in the center column of the content area (course index, containing mostly links to activity modules), and
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles).

The goals teachers have doing this, i.e. what it means to communicate a course's essence:
* Communicate what is expected of students
* Communicate the overall contents of the course (curriculum)
* The course itself: Give means/tools for students to learn (as described by social constructionism)

=== Students ===

Interact mainly with the activity modules placed in a course by a teacher.

== See also ==

* [[Developement:How_Moodle_outputs_HTML]]
* [[Navigation_block]]
* [[Moodle_2.0_release_notes#Navigation]]

[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines

2010-05-15T15:05:01Z

Pilpi:

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]
* '''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines

2010-05-15T15:04:34Z

Pilpi:

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

The guidelines are also available at [[Category:Moodle_User_Interface_Guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
* Further development on Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]
* '''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines

2010-05-15T15:02:12Z

Pilpi: /* See also */

Talk:Moodle User Interface Guidelines

2010-05-15T14:53:27Z

Pilpi:

== Missing guidelines ==

=== Unwritten guidelines ===
* Moodle basics
** Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])
* Building blocks
* Hierarchy Browsing List
** [[Course Format|Course Format]]
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design)
** Filter
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)
* Dialog
* Popup Window
* Link lists (menus)
* [[Page Heading|Page Heading]]

=== Proposed elements ===
We will probably need a process to get these accepted across the community
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])

=== Guidelines that require further research/discussion ===
'''[[Major usability issues in Moodle]] (separate design projects)'''

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.

* [[Switch Button|Switch Button]]
* [[Add element|Add element]]
* [[Jump Navigation|Jump Navigation]]
* Move Element (Course front page model vs. quiz)
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)
* Further research required: Search
* Further research required: Editing modes
* Further research required: Data Listing
* Waiting for developments of Navigation 2.0: Tabs
* Command Popup Menu

== Todo ==
* [[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])
* [[Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])

--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)

----

Moodle User Interface Guidelines

2010-05-15T14:53:07Z

Pilpi: /* Elements */

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]

'''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Talk:Moodle User Interface Guidelines

2010-05-15T14:52:50Z

Pilpi:

== Missing guidelines ==

=== Unwritten guidelines ===
* Moodle basics
** Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])
* Building blocks
** [[Course Format|Course Format]]
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design)
** Filter
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)
* Dialog
* Popup Window
* Link lists (menus)
* [[Page Heading|Page Heading]]

=== Proposed elements ===
We will probably need a process to get these accepted across the community
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])

=== Guidelines that require further research/discussion ===
'''[[Major usability issues in Moodle]] (separate design projects)'''

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.

* [[Switch Button|Switch Button]]
* [[Add element|Add element]]
* [[Jump Navigation|Jump Navigation]]
* Move Element (Course front page model vs. quiz)
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)
* Further research required: Search
* Further research required: Editing modes
* Further research required: Data Listing
* Waiting for developments of Navigation 2.0: Tabs
* Command Popup Menu

== Todo ==
* [[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])
* [[Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])

--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)

----

Moodle User Interface Guidelines

2010-05-15T14:52:26Z

Pilpi: /* Moodle basics */

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]
* Hierarchy Browsing List

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]

'''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Page structure and types

2010-05-15T14:51:52Z

Pilpi:

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''

{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}

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]]).

== Basic page structure ==
[[Image:basic-page-structure.png||Image 1: Basic page structure]]

Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.

=== Header ===
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.

=== Navigation bar ===

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.

=== Main content area ===

In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.

The content of the page in the middle is controlled by the teacher.
* Teacher(s) can add and edit the actual content,
* The overall sequencing and organization of the content is controlled by the selected [[Course Format|Course Format]].

=== Footer ===

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.

=== Implementation ===
Note: May be obsolete from Moodle 2.0 onwards.

# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.
# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==== Page layout ====
# Print headings with print_heading, use the CSS hooks for IDs and Classes
# 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?)

== Page types ==

TODO: see [[Development_talk:Page_structure_and_types]]

== Who controls what? ==

(TODO: Perhaps move this section to moodle site structure or on a page of its own?)
=== Teachers ===
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.

The means for teachers to do this in Moodle are:
* in the center column of the content area (course index, containing mostly links to activity modules), and
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles).

The goals teachers have doing this, i.e. what it means to communicate a course's essence:
* Communicate what is expected of students
* Communicate the overall contents of the course (curriculum)
* The course itself: Give means/tools for students to learn (as described by social constructionism)

=== Students ===

Interact mainly with the activity modules placed in a course by a teacher.

== See also ==

* [[Developement:How_Moodle_outputs_HTML]]

[[Category:Moodle User Interface Guidelines]]

Talk:Page structure and types

2010-05-15T14:51:05Z

Pilpi: New page: == Page types == In progress: Once Moodle 2.0 is clearer, can be continued. TODO: This <s>should correspond</s> to [[Migrating_your_code_to_the_2.0_rendering_API#You_can_h...

== Page types ==

In progress: Once Moodle 2.0 is clearer, can be continued.

TODO: This <s>should correspond</s> to [[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.

* Editing page
* Site configuration page
* Module configuration page (Update this xxx)
* Organizing page
* Teacher content page
* Application/module functionality page
* Course page
* Data listing page
* Student content page
* Content accumulating page (views to forums posts)

Hm, on some pages several of these many may apply?

Page structure and types

2010-05-15T14:50:16Z

Pilpi: /* Page types */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''

{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}

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]]).

== Basic page structure ==
[[Image:basic-page-structure.png||Image 1: Basic page structure]]

Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.

=== Header ===
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.

=== Navigation bar ===

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.

=== Main content area ===

In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.

The content of the page in the middle is controlled by the teacher.
* Teacher(s) can add and edit the actual content,
* The overall sequencing and organization of the content is controlled by the selected [[Course Format|Course Format]].

=== Footer ===

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.

=== Implementation ===
Note: May be obsolete from Moodle 2.0 onwards.

# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.
# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==== Page layout ====
# Print headings with print_heading, use the CSS hooks for IDs and Classes
# 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?)

== Page types ==

TODO: see [[Development_talk:Page_structure_and_types]]

== Who controls what? ==

(TODO: Perhaps move this section to moodle site structure or on a page of its own?)
=== Teachers ===
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.

The means for teachers to do this in Moodle are:
* in the center column of the content area (course index, containing mostly links to activity modules), and
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles).

The goals teachers have doing this, i.e. what it means to communicate a course's essence:
* Communicate what is expected of students
* Communicate the overall contents of the course (curriculum)
* The course itself: Give means/tools for students to learn (as described by social constructionism)

=== Students ===

Interact mainly with the activity modules placed in a course by a teacher.

== See also ==

* [[Developement:How_Moodle_outputs_HTML]]

Page structure and types

2010-05-15T14:49:11Z

Pilpi: /* Implementation */

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Page structure and types'''

{{Work in progress|forumurl=http://moodle.org/mod/forum/discuss.php?d=126884|info=<br /><br />'''This is a guideline template for a [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread] '''}}

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]]).

== Basic page structure ==
[[Image:basic-page-structure.png||Image 1: Basic page structure]]

Most Moodle pages are divided in four parts: Header, Navigation bar, Main content area and Footer.

=== Header ===
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.

=== Navigation bar ===

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.

=== Main content area ===

In addition to the actual content of the page, this area can contain [[Blocks|blocks]] in the left and right columns.

The content of the page in the middle is controlled by the teacher.
* Teacher(s) can add and edit the actual content,
* The overall sequencing and organization of the content is controlled by the selected [[Course Format|Course Format]].

=== Footer ===

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.

=== Implementation ===
Note: May be obsolete from Moodle 2.0 onwards.

# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.
# 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...
# Pages within activity modules should call navmenu() to generate the appropriate navigation menu.

==== Page layout ====
# Print headings with print_heading, use the CSS hooks for IDs and Classes
# 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?)

== Page types ==

NOT FINAL TEXT, in progress.

TODO: Think about if a page type specific visual hierarchy could be devised?

TODO: This <s>should correspond</s> to [[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.

* Editing page
* Site configuration page
* Module configuration page (Update this xxx)
* Organizing page
* Teacher content page
* Application/module functionality page
* Course page
* Data listing page
* Student content page
* Content accumulating page (views to forums posts)

Hm, on some pages several of these many may apply?

== Who controls what? ==

(TODO: Perhaps move this section to moodle site structure or on a page of its own?)
=== Teachers ===
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.

The means for teachers to do this in Moodle are:
* in the center column of the content area (course index, containing mostly links to activity modules), and
* in the side columnd (blocks and course-specific features such as the question bank, grades, and course-specific roles).

The goals teachers have doing this, i.e. what it means to communicate a course's essence:
* Communicate what is expected of students
* Communicate the overall contents of the course (curriculum)
* The course itself: Give means/tools for students to learn (as described by social constructionism)

=== Students ===

Interact mainly with the activity modules placed in a course by a teacher.

== See also ==

* [[Developement:How_Moodle_outputs_HTML]]

Interface guidelines

2010-05-15T14:46:45Z

Pilpi:

{{Work in progress}}
This document is not authoritative, it is a collection of ideas and under construction.

==Keeping it simple==

Use the minimum interface required to get the job done.
Order the elements by contexts. Give the user a strong orientation where the places are to do several things.

==Standard pages==

See [[Address_Bar|Address Bar/URL UI guideline]]

==One script per major function/page==

...

==Page layout==
See: [[Page_structure_and_types#Implementation|Basic page _structure UI guideline]]

The information that was here has been included there.

==Form layout==

See: [[Form|Form UI guideline]]

==Dealing with tables==

Use the print_table function whenever possible.

==Standard navigation tools==

See:
* [[Page_structure_and_types#Basic_page_structure|Basic page structure UI guideline]]
* [[Link|Link UI guideline]]
* [[Button|Button UI guideline]]

The information that was here has been incorporated to those pages

==URLs==
See [[Address_Bar|Address Bar UI guideline]]

==Buttons vs links==

See: [[Button]] and [[Link]] UI guidelines.

The information that was here has been integrated to those documents.

==Language strings==

# 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.

==CSS naming==

* Don't add font, color or layout definitions in code. This belongs to CSS theme files.
* See [[Standards|theme standards]]

==Linking to help==

* Help buttons should be on the right of the thing (as an exception it can be left, if the thing is right-aligned)

==Related topics==

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

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.

==See also==

* [[Usability]]
* [[Moodle_User_Interface_Guidelines|Moodle User Interface Guidelines]] GSOC 2009 project

[[Category:Coding guidelines|Interface]]
[[Category:Moodle User Interface Guidelines]]

[[pt:Guia para interface]]
[[es:Manual de estilo de la interfaz]]
[[ja:インターフェースガイドライン]]

Moodle User Interface Guidelines

2010-05-15T14:46:03Z

Pilpi: /* Relevant guidelines from other sites */

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]
* Hierarchy Browsing List

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]

'''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Talk:Moodle User Interface Guidelines

2010-05-15T14:45:19Z

Pilpi:

== Missing guidelines ==

=== Unwritten guidelines ===
* Building blocks
** [[Course Format|Course Format]]
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design)
** Filter
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)
* Dialog
* Popup Window
* Link lists (menus)
* [[Page Heading|Page Heading]]

=== Proposed elements ===
We will probably need a process to get these accepted across the community
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])

=== Guidelines that require further research/discussion ===
'''[[Major usability issues in Moodle]] (separate design projects)'''

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.

* [[Switch Button|Switch Button]]
* [[Add element|Add element]]
* [[Jump Navigation|Jump Navigation]]
* Move Element (Course front page model vs. quiz)
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)
* Further research required: Search
* Further research required: Editing modes
* Further research required: Data Listing
* Waiting for developments of Navigation 2.0: Tabs
* Command Popup Menu

== Todo ==
* [[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])
* [[Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])

--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)

----

Moodle User Interface Guidelines

2010-05-15T14:45:04Z

Pilpi: /* Todo */

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]
* Hierarchy Browsing List

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]

'''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines:Help requested

2010-05-15T14:44:51Z

Pilpi:

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > Help requested

You can help by '''commenting on [[Guideline_template]] and on the [[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'''.

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.

=== About writing these guidelines ===
* Some pages use the [[Guideline template|Guideline template]], others are freeform prose

Moodle User Interface Guidelines

2010-05-15T14:44:33Z

Pilpi: /* About writing these guidelines */

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]
* Hierarchy Browsing List

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]

'''[[Using Moodle book]]'''

=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

== Todo ==
* [[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])
* [[Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Moodle User Interface Guidelines

2010-05-15T14:44:10Z

Pilpi:

__NOTOC__
<p class="note">

NOTE: these guidelines were produced as part of a student project in 2009, and are not official Moodle guidelines.

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.

</p>

These guidelines are to be used as a '''UI reference library''' by Moodle developers when creating user interfaces.

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. [[Moodle User Interface Guidelines:Introduction|More...]]
* [[Moodle User Interface Guidelines:Help requested|Help requested: comment on these guidelines]]

==Moodle basics==
* Hierarchy of a Moodle site ([http://moodle.org/mod/forum/discuss.php?d=115620 one attempt])
* [[Page structure and types|Page structure and different page types]]
* [[Roles and capabilities]]
* [[Groups]]

==Moodle UI library==
UIs are built of Elements and Interaction Styles (bigger wholes, which are built of Elements).
=== Elements ===
* [[Big Select List|Big Select List]]
* Hierarchy Browsing List

* [[Tooltip|Tooltip]]
* [[Link|Link]]
* [[Button|Button]]
* [[Address Bar|Address Bar]] (URLs)

=== Interaction Styles ===
* [[Wizard|Wizard]]
* [[Help Popups|Help Popups]] (See [[Interface_guidelines#Linking_to_help|Linking to help]] for now)
* [[Feedback page|Feedback page]]
* [[Form|Form]] (incomplete)
** [[Radio button|Radio button]]
** [[Checkbox|Checkbox]]
** [[Dropdown Lists|Dropdown lists]] (incomplete)

== General design guidelines ==
* [[Progressive Disclosure|Progressive Disclosure]]
* [[User Data Always Safe|User Data Always (Always) Safe]]
* [[Feedback (User Interface Guideline)|Feedback]] (Incomplete)
=== Relevant guidelines from other sites ===
* [http://library.gnome.org/devel/hig-book/stable/principles-people.html.en Design for People]
* [http://library.gnome.org/devel/hig-book/stable/principles-broad-userbase.html.en Don't Limit Your User Base]
* [http://library.gnome.org/devel/hig-book/stable/principles-match.html.en Create a Match Between Your Application and the Real World]
* [http://library.gnome.org/devel/hig-book/stable/principles-consistency.html.en Make Your Application Consistent]
* [http://library.gnome.org/devel/hig-book/stable/principles-feedback.html.en Keep the User Informed]
* [http://library.gnome.org/devel/hig-book/stable/principles-simplicity.html.en Keep It Simple and Pretty]
* [http://library.gnome.org/devel/hig-book/stable/principles-user-control.html.en Put the User in Control]
* [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]
* [http://library.gnome.org/devel/hig-book/stable/principles-direct-manipulation.html.en Provide Direct Manipulation]

== See also ==
Talk page: [[Development_talk:Moodle_User_Interface_Guidelines]]

'''[[Using Moodle book]]'''
=== About writing these guidelines ===
* Some pages use the [[Guideline template|Guideline template]], others are freeform prose
=== Usability in Moodle ===
* [[Usability|Usability]]
* [[Usability_FAQ|Usability FAQ]]

=== Implementation advice ===
* [[Developer_documentation|Developer documentation]]
* UI coding: [[Interface_guidelines]]

== Todo ==
* [[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])
* [[Moodle User Interface Guidelines:Glossary|Glossary]] (See [http://www.hillside.net/index.php/a-pattern-language-for-pattern-writing#E.5])

[[Category:User Interface Guidelines]]
[[Category:Developer tools|User Interface Guidelines]]
[[Category:Usability|User Interface Guidelines]]
[[Category:Moodle User Interface Guidelines]]

Talk:Moodle User Interface Guidelines

2010-05-15T14:43:40Z

Pilpi: New page: == Missing guidelines == === Unwritten guidelines === * Building blocks ** Course Format ** Block (not a technical guide but a guideline how what to take in...

== Missing guidelines ==

=== Unwritten guidelines ===
* Building blocks
** [[Course Format|Course Format]]
** Block (not a technical guide but a guideline how what to take into account when using a block as a part of a design)
** Filter
** Module (not a technical guide but a guideline how what to take into account when using a module as a part of a design)
* Dialog
* Popup Window
* Link lists (menus)
* [[Page Heading|Page Heading]]

=== Proposed elements ===
We will probably need a process to get these accepted across the community
* [http://uipatternfactory.com/p=edit-in-place/ Edit-in-place] ([http://www.google.fi/search?q=inplace+editing+ui+pattern more patterns])

=== Guidelines that require further research/discussion ===
'''[[Major usability issues in Moodle]] (separate design projects)'''

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.

* [[Switch Button|Switch Button]]
* [[Add element|Add element]]
* [[Jump Navigation|Jump Navigation]]
* Move Element (Course front page model vs. quiz)
* Quick Inline Help ([http://www.pilpi.net/software/moodle/2009/06/18/inline-help/] for now)
* Further research required: Search
* Further research required: Editing modes
* Further research required: Data Listing
* Waiting for developments of Navigation 2.0: Tabs
* Command Popup Menu

--[[User:Olli Savolainen|Olli Savolainen]] 14:43, 15 May 2010 (UTC)

----

Feedback (User Interface Guideline)

2010-05-15T14:41:56Z

Pilpi:

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''Feedback'''

{{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 [[Moodle_User_Interface_Guidelines|Moodle Interface Guideline]]. Comments: [http://moodle.org/mod/forum/discuss.php?d=126884 developer forum thread]}}
== Problem ==
In order to make it possible for the user to use an application meaningfully, the application must respond meaningfully to each user action.

== Solution ==

See: '''GNOME Human Interface Guidelines: [http://library.gnome.org/devel/hig-book/stable/feedback.html.en Feedback] '''
(for Desktop but still a great guide and mostly applicable to Moodle.)

== Examples and implementation ==
=== Feedback pages ===
[[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.

=== Wizards ===

TODO: [[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.

==== Installation ====
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.

== Common mistakes ==

== Related guidelines ==
* [[Feedback page]]
== Related issues in the tracker ==
* TODO: development of Moodle feedback away from the feedback page towards showing feedback on the resulting content page.

== Further information / Sources ==

* TODO: Test and create guideline for: MDL-18224 MDL-18225
* 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

[[Category:Moodle User Interface Guidelines]]

User Data Always Safe

2010-05-15T14:41:08Z

Pilpi:

[[ Moodle User Interface Guidelines|Moodle User Interface Guidelines]] > '''User Data Always (Always) Safe'''

<big>'''This is the single most serious usability flaw in Moodle. It also requires a lot of software engineering work to get right.'''

In all cases, the user's work is sacrosanct. Nothing your
application does should lose or destroy user's work without
explicit user action. - GNOME HIG: [http://library.gnome.org/devel/hig-book/stable/principles-forgiveness.html.en Forgive the User]

* [http://moodle.org/mod/forum/discuss.php?d=130005 Please comment in the related discussion forum] </big>

Every part in Moodle should commit to keeping the data user has entered, safe.

* In 2009 Facebook has several groups where users have spelled out their frustration when Moodle had lost hours of their work.
* 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.

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.

This issue requires further user research to find the exact issues involved, but there are also some generally well known mechanisms to employ.

As Moodle is a web application, keeping user data safe is not trivial.

==Challenges==
* Users may leave forms without submitting them
** Learning from some desktop applications (GNOME settings dialogs), users may assume their settings get automatically saved when they just enter them.
** Accidentally hitting the back button
** Clicking on a link on the form itself, assuming it is safe
** Pushing a button on their keyboard resulting in accidental usage of the back/next buttons
* Users may fill out forms "inappropriately"
** Missing data
** Session may have expired
*** 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.
** User may have logged out accidentally (browser crash; browser restores the browser session but not the Moodle session)
** User may no longer be capable of completing the action due to loss of permissions or other reasons
*** A forum post they are were replying to was deleted
*** The time to edit a post has passed while the user was editing the post
* Users may submit data when the server has gone down or network connection lost
* '''There is very probably a lot more: research required.'''

==Solutions==

=== Preserve submitted data or giving it back to the user to keep, until it can be saved ===
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.

If a user has posted something, but it cannot be saved, never ever just throw the data away (like for example, Forum currently does).
Design your application to request the user what should be done. This requires understanding the situations users may end up in. Examples:
* 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."
==== Giving the user their data back, for copying to the clipboard ====
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.

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.

* 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."
* 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.

=== Undo ===
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.
[[Image:gmail-undo-example.png|left|frame]]
<br style="clear: both" />

=== Autosave ===
Related forum threads:
* [http://moodle.org/mod/forum/discuss.php?d=74710 AJAX-like Autosave for quiz]
* [http://moodle.org/mod/forum/discuss.php?d=107073 Autosave for Forum Compose?]
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.
* 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)
** Autosaving can be implemented using AJAX or by just submitting the form in question in the background using javascript.
* 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
* 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.
** This is also probably the only possible strategy when the server has gone down or when the network connection has been lost

=== "Save as draft" button ===
Sometimes it may be appropriate to let users save their work, before it is finished, without yet publishing it.

=== Javascript confirmation upon leaving "dirty" form ===
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.
=== TinyMCE ===
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.

=== Browser-based solutions ===
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.

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.

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.

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).

== More information ==
* Discussion: [http://moodle.org/mod/forum/discuss.php?d=130005 Critical: Keeping user data safe]
** Linked threads: [http://moodle.org/mod/forum/discuss.php?d=130010] [http://moodle.org/mod/forum/discuss.php?d=130007]
* Directory of [[Major_usability_issues_in_Moodle|Major usability issues in Moodle]]
* MDL-18014 Tracker item for autosave (thanks Mauno Korpelainen)
* [http://code.google.com/p/tinyautosave/ TinyMCE autosave plugin] (thanks Mauno Korpelainen)

[[Category:Moodle User Interface Guidelines]]

MoodleDocs - User contributions [en]

Checkbox

Themes overview

User Data Always Safe

Quiz UI redesign

Quiz UI redesign

Quiz UI redesign

Usability

Usability

Moodle User Interface Guidelines

Moodle User Interface Guidelines

Moodle User Interface Guidelines

Moodle User Interface Guidelines:Introduction

Usability/Improve Moodle User Experience Consistency

Quiz UI redesign

Quiz UI redesign

Quiz UI redesign ­ what makes a scenarios interview?

Quiz UI redesign ­ what makes a scenarios interview?

Moodle User Interface Guidelines

Moodle User Interface Guidelines

Address Bar

User Data Always Safe

Wizard

Wizard

Wizard

Wizard

Wizard

Page structure and types

Page structure and types

Page structure and types

Moodle User Interface Guidelines

Moodle User Interface Guidelines

Moodle User Interface Guidelines

Talk:Moodle User Interface Guidelines

Moodle User Interface Guidelines

Talk:Moodle User Interface Guidelines

Moodle User Interface Guidelines

Page structure and types

Talk:Page structure and types

Page structure and types

Page structure and types

Interface guidelines

Moodle User Interface Guidelines

Talk:Moodle User Interface Guidelines

Moodle User Interface Guidelines

Moodle User Interface Guidelines:Help requested

Moodle User Interface Guidelines

Moodle User Interface Guidelines

Talk:Moodle User Interface Guidelines

Feedback (User Interface Guideline)

User Data Always Safe

Quiz UI redesign what makes a scenarios interview?

Quiz UI redesign what makes a scenarios interview?