Rule sets

Rule sets address patterns and exceptions. They improve productivity of implementation and they ensure consistency, which improves usability.

Calendar

Priority sequence

  1. Day of the week
  2. First hour block
    1. Courses of first hour block
  3. Second hour block
    1. Courses of second hour block (on any available space non occupied by the courses of the previous hour block)
  4. Third hour block
    1. Courses of third hour block (on any available space non occupied by the courses of the previous hour block)
  5. Etc.
schedule

"Automatic" sequence

According to the above priority sequence, courses would populate each time block in alphabetical order.

  1. Courses populate each time block in alphabetical order
  2. Courses placement is affected only by the previous time block(s)
  3. Courses placement is not affected by the following time block
The course blocks are listed alphabetically and numerically

This rule set doesn't make the best use of the space.


"Logical" sequence

These rules maximize the available space within a time block and improve the readability of courses by reducing visual inconsistency.

  1. Courses populate each time block in alphabetical order
  2. Courses populate each time block in order of length
    1. Courses with the greater length are placed as last within each time block
  3. Courses placement is affected only form the previous time block(s)
  4. Courses placement is not affected by the following time block
The course blocks that follow this new rule are highlighted in "Sequence 2"

  • Dropdowns are used for the selection of 3 or more options
  • For two or less selections, use checkboxes or radio buttons
  • Note that interfaces like toggle switches are stylized radio buttons
Detail of the selection and input forms in the left panel of Schedule

When selecting a link, users expect to "jump" to content different than the current one (even though contextually the same).

Use icons with text labels or as links only when they helps to clarify ambiguities. Otherwise the context and descriptive text are sufficient.

Links are used to connect content areas:

  • Relative pages of content (same directory, project)
  • External pages of content
  • Content within the same page (anchor links)

Detail of the tab and drop down links in Schedule

When selecting a button, users expect for some programmatic activity to take place and eventually display its results.

Buttons should not to be used to emphasize links.

Use icons as buttons or with buttons only when it helps to clarify ambiguities. Otherwise the context and button label are sufficient.

Buttons are used to "process" information or to trigger changes of the content

  • Submit or cancel a selection or input text
  • Reveal hidden information*
  • Change the aspect of content (courses schedule)

* - It's open to discussion whether this should be an icon with the function of a link, since modals or side navs just reveal previously hidden content. But not in all cases.
Ultimately, these are "visual rules" based on "superficial" usability; the user is exposed to the same experience whether the action of one button streams data from the back-end and doing all kind of processing to finally display the result, while another just un-hides static information.
Detail of the Settings left panel of the Course interface
Detail of the show/hide buttons in the Schedule interface
Detail of the "Create new user" button in the admin Mange Users interface