mRFC 0003: MidCOM AIS User Interface Guidelines
- Principles
- UI elements
- Eye candy
- Localization
This document outlines user interface guidelines for the MidCOM Authoring Interface System (AIS). This mRFC has been submitted to the Midgard Community for discussion and approval under the Creative Commons Attribution-ShareAlike license.
While usability of Midgard CMS lacks seriously in several other aspects like installation and website setup procedure, AIS is the main interface end-users see. This makes MidCOM AIS the primary target for usability improvements.
The problem with AIS usability improvements is that the interface is mostly built into the MidCOM components themselves. Because of this, there should be a clear policy on how to present the interface in a consistent and usable manner between the different components.
Principles
Smart defaults
The default configurations and layout templates of the components should be designed so that most users will be able to utilize them as is.
While the defaults cannot do everything for 100% of use cases, we should get the 80% covered. The remaining 20% can then utilize custom schemas, layout templates and settings.
Hiding complexity
The internal mechanics and all unnecessary choices should be hidden from regular users, but still made accessible for power users and developers.
Comment from Torben: Some "Advanced"-Button would be nice here
I'm thinking about some DHTML magic that just hides the form fields that are "more powerful" behind an invisible div. Showing it should be rather easy with some basic JScript on a hyperlink, which in turn makes the div visible showing the extra options without having the user to reload the form or something like that.
Status awareness
All components and UI features should be aware of the system's status, and only propose options that are sensible in that situation.
For example, when a new topic handled by taviewer has been created, it should only suggest creation of the index article to start with.
Task focus
Design your component UI around tasks user might perform instead of features you want to include.
UI elements
Welcome page
Welcome page of a topic should always follow the same format, and answer the following questions:
- Where am I?
- What to do next?
- How do I create new item?
- How do I configure the topic?
Where am I?
Some AIS implementations do not display the navigation and breadcrumb. Because of this, the topic administration UI itself should tell user where she is. This can be accomplished easily by displaying the topic title.
The topic title should be shown on the welcome page in the following way:
<h1>Topic title
(<abbr title="component name">component description</abbr>)</h1>
The topic title is the title attribute saved in the topic's extra field and the component description is the human-readable name of the component (for example, event calendar) in localized format.
Possible status messages ("Article XXX deleted" or "Settings saved") should be displayed under the topic title.
What to do next?
The component should tell user what actions can be taken next.
Creating new items (articles, etc.) is the main action for a topic. The item creation dialogue should be shown directly under the topic title.
Under the article creation dialogue there is space for 1-2 paragraphs of help text. The help text should be localized, and use status information from the component to determine what text should be displayed.
Comment from Torben: The L10n Editor needs some work here too
Editing larger strings in the current editor is a painful task, at it has rather small input fields. Enlarging them to something like a 4 lines with 65 chars each input field would make things easier I think. Also, some kind of alphabetical index to spread larger message collections over several pages wouldn't be too bad, as with something more then 25 strings the system gets both slow and difficult to oversee.
For example, if the topic is handled by the de.linkm.taviewer component, and the index article hasn't been created yet, there should be the help text:
This folder does not have an index article. Please create an article with URL name index to get started.
However, even while the help text is contextual and available, don't assume that users read it. In this case, the name "index" should be provided by the component automatically as the URL name of the first article being created.
The link to settings page, and possible content-related setting dialogues are in a separate box under the help text.
How do I create new item?
The "Create new item" dialogue is a visually highlighted box directly under the topic title and possible status messages.
In the box there is submit button "Create new XXX" where XXX is the item type for that particular component (news item, event, etc.), and possibly a pulldown for datamanager schema selection.
The datamanager schema selection pulldown should be shown only if there are multiple schemas to select from.
How do I configure the topic?
Under the help text in the welcome page there should be a Settings box. In this box there are form elements for the possible content-dependent settings, and link to the component configuration page.
Examples of content-dependent settings are the selection of current stable release in net.nemein.downloads and person to display first in list in net.nemein.personnel.
Configuration page
On the topic of the configuration page there should be title saying "Configure component type for topic topic title". The component type should be marked with <abbr /> element with the actual component name as title attribute. For example:
<h1>Configure <abbr title="de.linkm.events">event calendar</abbr>
for topic My Calendar</h1>
Under the title the available configurations should be displayed as a form. If necessary, the form can be divided into subsections using <h2 /> elements.
All expert settings like datamanager schema selection should be hidden from non-power users.
When saving, the settings should return user to the welcome page, and display a status message like "Settings saved".
The configuration page should also has a "Revert to defaults" button for removing all settings defined in
the topic.
Comment from Torben: There are several other things to note, I think
Component configuration is one of the larger problems in current MidCOM, as for one thing, there is no unified way to do this like there is for data editing through the Datamanager.
For one thing, this leads to a vast amount of different "ways" you configure a component. I for example usually revert to the styles the datamanager uses (because I wrote the datamanager and know what he uses where), but with a reduced program flow. I usually have only the "edit"-view available for topic configuration, clicking on save will update the config and return you to the very same edit form you just used.
While this is easy to implement, it sometimes confuses users on a fast link to the MidCOM server, as they don't realize that the page has just reloaded. (Of course, a status message might help here, but you know Joe Average's ability to read and understand such messages...).
Apart from this inconsistency, the whole problem has a technical side also: You end up writing the same stuff for each and every component again and again, usually in slightly different ways, which is a fact that I find quite annoying.
A starting point for help here, is the midcom_helper_configuration object. Until now it cannot do much more then reading configuration data and merging global data (defaults) with local data (topic-local) on request.
What I would like at this point, is a datamanager variant, that on one hand describes the configuration data through a datamanager schema, that is, on the other hand, aware of the fact that it holds configuration data, not object data. This is important, as the information managed here must not be stored within the parameter domain midcom.helper.datamanger, as it would be the default from the datamanager library, but instead it has to use the name of the component. (The whole framework is built around this, so no discussion here.)
This would give an easier way to edit the configuration data as it could be largly automated with the quite powerful abilities already present in the datamanager. Extending the datamanger for this should be an overseeable problem, many things have to be only slightly adapted (things like default values for example).
View and edit pages
The view and edit pages must display a document toolbar with the available action buttons on top of the page.
Under the toolbar the pages should display the title of the item being viewed or edited as <h1 /> element, the topic type, and the action. For example, "Edit event Developer Meeting".
The actual editing form or item details should be displayed under the title.
Delete page
The toolbar on the delete page should be the same as on the view and edit pages.
The delete page should display title "Delete item type item title?" as <h1 /> element under the toolbar.
Clicking yes should delete the item and return user to the welcome page. Clicking no should return user to the view page for that item.
Document toolbar
The document toolbar is a list of possible actions, or "pages" for handling the document in AIS. The buttons should include the following:
- Edit item
- View item
- Delete item
- Other possible actions (approve, etc.)
Comment from Torben: NAP could be some help here
Currently there are plans to extend NAP to provide more powerful back to site and back to admin interface links with it. (Thanks to Bergie)
In that respect I was thinking about two more things, that would prove valuable in respect of NAP:
First, there should be not only a simple link to AIS available (which should always be the view URL per definition, the taviewer currently breaks this rule btw.). Instead of a single AIS nav name, it should be threefold, naming the links "view" (the default we have now), "edit" and "delete", so that the automatic navigation interface can honor this. It will also finally make edit-this-page links feasilble. Note, that there may also be "create" links, that might only make sense for a topic though (although this is finally a problem of the actual component in question, if you want to have create links within a leaf or not). The view link stays mandatory, the edit link should also be there always; both delete and create can be optional though.
The second problem could solve a whole load of problems like approval, locking and the forth: Currently, there is no way to attach meta-information across all elements of a website like the way NAP provides you with revisor date and person id for example. The problem in implementing this is the fact, that there might not be an Midgard Object behind every leaf NAP provides you with; along with the fact that only the component can finally know how to locate the objects in question. Therefore NAP could be (rather easily) extended to provide an so-called metadata interface for its leaves and nodes. The components responsibility would be rather easy: They must be able to store string-based key-value pairs on each leaf they present (storing this data on the node is easy, as nodes are always topics). This will most of the time be simple parameters that should always be stored to the midcom.nap domain of the object. This will finally allow an easy, and constistent, implementation of approval schemes, object locking and the forth. Actually, even more crazy permission stuff for example can be handled at this point, as NAP is aware of many things the usual component does not know. Apart from the simple fact, that this will give an unified user interface across the whole website and the fact, that the components will get those NAP services for free.
The document toolbar items should be presented as "tabs", and the current page should be highlighted.
Next to the actual toolbar actions, there should be two short links. They should be presented as visually different from "action items":
- Back to topic
- Back to site
Comment from Tarjei:
IMHO one of the problems with current AIS is the reliance on the cancel button. AIS needs either some js-magic or some other way to make sure that locks, stale articles etc. are cleared if the user closes the window for whatever reason.
Eye candy
Localization
To make localization of MidCOM to different languages easier and more consistent, all MidCOM components should use the central MidCOM l10n repository for all the common strings.
This includes all terms like "Save", "Edit", "Delete", "View" and "Next".
Comment from Torben: There are some minor organisational details here
I found, that the current string databases, while quite correctly designed, lack an efficient distribution facility. I recently added some new strings I introduced for component configuration within the main MidCOM L10n library, resulting in the fact, that I needed to tell others "if you want the new TAViewer, please upgrade to the latest MidCOM core because of 2 L10n strings added there". Currently this is not too bad, although there some time might be a problem when users don't want to (or simply cannot) upgrade to the latest midcom.xml for some reasons only known to them.
This finally brings us back to the quite old packaging problem. Anybody here interested in implementing an apt-get for midcom? ;-)
References
Why Free Software Usability Tends to Suck