Development:Interface guidelines

Note: This page is a work-in-progress. Feedback and suggested improvements are welcome. Please join the discussion on moodle.org or use the page comments.

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

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

One script per major function/page

...

Page layout

1. Print headings with print_heading, use the CSS hooks for IDs and Classes
2. Print boxes around text using print_simple_box, use the CSS hooks for IDs and Classes

Form layout

1. Show the more important settings at the top
2. Each entry should have a label, and if necessary, a help file
3. If there are more than 10 options, split them into required and optional/extra/advanced parameters

Dealing with tables

Use the print_table function whenever possible.

Standard navigation tools

1. 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...
2. Pages within activity modules should call navmenu() to generate the appropriate navigation menu.
3. Links should include associated image (if available). For example, looking at an assignment in a course displays the assignment pic and then the assignment description as a single link; however, most of the blocks like the activity block exclude the image from the link. This is important as some folks are more graphically rather than text oriented and click on the picture and do not understand why it is not working. We need to be consistent (see MDL-6820).

URLs

1. URLs should be as short as possible.
2. No underscores in parameter names or files names
3. Never use two words when one would do.

Buttons vs links

This is a hard one to define ...

The Google Web Accelerator issue definitely provides some pointers here:

1. Actions which can modify the state of Moodle (data files, database, session information) should be performed through buttons
2. At the very least, such actions which are implemented as links should forward to a confirmation page which *does* use buttons

Language strings

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