|
Size: 4634
Comment:
|
← Revision 17 as of 2009-04-29 13:10:20 ⇥
Size: 4750
Comment: Migrated to Confluence 4.0
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma page-filename DEV/versions/14352697 | #pragma page-filename DEV/versions/7962631 |
| Line 3: | Line 3: |
| Consistency in user interfaces lets users make less errors and they feel more secure in what they do. | Consistency in user interfaces lets users make less errors and they feel more secure in what they do. |
| Line 5: | Line 6: |
| In theory all clients should conform to the following requirements. In practice mileage depends on what the client technology gives. |
|
| Line 8: | Line 7: |
| {{{ In theory all clients should conform to the following requirements.<<BR>> In practice mileage depends on what the client technology gives.}}} |
|
| Line 10: | Line 12: |
| Line 16: | Line 19: |
| Line 17: | Line 21: |
| Line 24: | Line 29: |
| Line 25: | Line 31: |
| When an owner logs in for the first time --( after list creation )-- a wizard is offered. The wizzard takes the user on a quick tour across all configuration options that usually are consulted after list creation. | When an owner logs in for the first time - after list creation - a wizard is offered. The wizzard takes the user on a quick tour across all configuration options that usually are consulted after list creation. |
| Line 30: | Line 37: |
| Line 33: | Line 41: |
| Line 36: | Line 45: |
| Line 37: | Line 47: |
| Line 38: | Line 49: |
| Line 73: | Line 85: |
| Line 88: | Line 101: |
| Line 104: | Line 118: |
| Line 107: | Line 122: |
| Line 108: | Line 124: |
| * account * create * list * subscribe * archive * read * admin * contact |
* account * create * list * subscribe * archive * read * admin * contact |
| Line 117: | Line 135: |
| Line 119: | Line 138: |
| * account * modify * list |
* account * modify * list |
| Line 124: | Line 143: |
| * modify personal settings * archive * read * admin * contact |
* modify personal settings * archive * read * admin * contact |
| Line 130: | Line 150: |
| Line 132: | Line 153: |
| * requests * modify |
* requests * modify |
| Line 135: | Line 157: |
| Line 137: | Line 160: |
| * account * modify * list |
* account * modify * list |
| Line 142: | Line 165: |
| * delete * moderator |
* delete * moderator |
| Line 146: | Line 169: |
| * delete * user |
* delete * user |
| Line 150: | Line 173: |
| * delete * member |
* delete * member |
| Line 153: | Line 176: |
| * unsubscribe * requests * modify |
* unsubscribe * requests * modify |
Global Requirements
Consistency in user interfaces lets users make less errors and they feel more secure in what they do.
In theory all clients should conform to the following requirements.<<BR>> In practice mileage depends on what the client technology gives.
Interface Architecture
Mailman makes a huge amount of configuration options available on its interfaces. MM3 will make orientation in easier:
- Main menu options will be ordered by usage frequency
- The interface will be task-oriented
- The homepage will list the most frequent tasks (and will show a statistic graph to give the owner a quick overview of the systems health state).
- Navigation will be completely reorganized (see Navigation principles below).
Navigation Principles
The following rules, ordered by priority, should apply:
- Separate options by their effect or purpose e.g. "configuration", "statistics" or "pending requests".
- Group similiar options e.g. "filter" subsumes filtering options for senders, recipients, content, headers, etc.
- Combine all simliar options in one page
- Within a page show only the most used options and hide the less used ones
- Unhide the less used ones upon user request
First Login Wizzard
When an owner logs in for the first time - after list creation - a wizard is offered. The wizzard takes the user on a quick tour across all configuration options that usually are consulted after list creation.
The goal is to give the owner an overview of the most important configuration options and their current settings as well as a chance to set basic list behaviour without having to search and click through endless configuration pages.
Accessibility
If a client technology provides means to make the interface more accessible, they should be followed.
Design Patterns
Operating systems have design patterns that describe how things should look and how standard processes should work. If we develop a client for a system that provides such a catalog we should follow it. Users will honour the consistency, feel at home and will make less errors.
Information Architecture
Navigation Structure
Role: Admin (owner)
See a commented administrator navigation structure.
maintenance
requests
options
General
Subscription Rules
Language
Non-Digest/Digest
Filter
Sender
Recipient
Spam
Message
Topics
Bounces
Archive
Gateways
Auto-Responder
Plugins
subscriptions
subscribe
remove
statistics
System
List
User
plugins
plugin 1
configuration options
plugin 2
Role: Moderator
See a commented moderator navigation structure.
requests statistics System List User plugins plugin 1 configuration options plugin 2
Role: Subscriber
See a commented subscriber navigation structure.
options
general
topics
plugins
subscriptions
subscribe
remove
modify
statistics
List
messages and notifications
We should provide a set of MM3 specific help messages and notifications. Any client should use these, so users get a consistent experience - no matter which client.
Permitted actions
Role: Anonymous
- account
- create
- list
- subscribe
- archive
- read
- admin
- contact
Role: User
- login
- logout
- account
- modify
- list
- subscribe
- unsubscribe
- modify personal settings
- archive
- read
- admin
- contact
Role: Moderator
- login
- logout
- requests
- modify
Role: Admin (owner)
- login
- logout
- account
- modify
- list
- create
- modify
- delete
- moderator
- create
- modify
- delete
- user
- create
- modify
- delete
- member
- subscribe
- unsubscribe
- requests
- modify
Comments
If where you write, "Main menu options will be ordered by usage frequency" you mean dynamic reorganization, I am concerned. I have found Microsoft's and Adobe's efforts to "streamline" their menus by hiding things that haven't been used recently and moving items to the top just after I get used to finding them elsewhere around to slow me down more often than it helps.
Adding a short "frequent tasks" list -- sort of like recently used files in Office would be useful, but I would suggest that it should be distinct from the main navigation structure. There is a real risk that dynamic reorganization will actually hinder users by frustrating them when features they're still learning move around. Dynamic menus definitely do not make me feel more secure in what I do.
(Unimportant: Is there a special meaning for "wizzard" with two "z"s instead of the usual one? I tried Googling and found a couple references to musicians...)