eZ Publish Admin redesign - Some suggestions

I've covered two larger topics in other blog posts (Admin interface users & Dashboards) so in this post I'm going to cover a number of smaller suggestions I have for the Admin Interface refresh. 

Some of the items have been suggested by others and been added to the specification - I hope I've noted these.

Improve underlying HTML

Damien has already mentioned linking labels with their related input via the for attribute.  I wasn't aware that there was already an issue for this but I made a start of adding a Accessibility & Usability Improvements project that currently "associates labels with specific form elements, adds "required" class to required input elements to allow attachment of javascript validation".

The project looked at "fixing" the datatype edit templates and the modifications can be viewed in the CHANGELOG.

Specific changes I'd like to see in the underlying HTML are:

• Labels linked to input fields
• Labels only used when associated to an input field
  
• Fieldsets & legends used to group associated input fields
• A class applied to input field that are required
  
• A class applied to input fields based on datatype
  
• Size attributes removed from input fields and CSS used to set the size

These changes will not only improve the accessibility of the admin interface but also improve the front end as well.

Javascript validation

I'm not sure there is any Javascript validation of forms in eZ Publish. Adding required input validation is relatively easy especially based on the suggestions above as this would allow for simply selecting input elements with the "required" class and ensuring they contain content before the form was submitted.

While maybe not exactly matched to eZ Publish needs the JQuery validations plugin is a good example of how this can be done.

The eZUser datatype is a great example where both Javascript and AJAX can be combined to improve usability. The validation rules ( from when I put together the Accessibility & Usability Improvements project¹) is:

Password: If [UserSettings] GeneratePasswordIfEmpty = true empty passwords are allowed and one will be generated if the password is blank.
Password Length:  Stored in [UserSettings] MinPasswordLength or default to 3 if not present (in ezuser datatype)
Password cannot be set to "password"
Passwords must match

Email: Must be valid email
Email: If the email can be used for Authentication the email address must be unique

Login: must be unique
Login: cannot be empty

This is a perfect opportunity to utilise Javascript to ensure the validation rules are followed and that Email and Login are unique using AJAX.

Primary and Secondary Actions

Luke Wroblewski begins the "Primary and Secondary Actions" chapter of his book Web Form Design:

Labels provide the questions that forms ask people. Input fields give people a way to answer those questions. Neither of these items, however actually lets people complete a form.  That singular responsibility rests with actions.

Many pages in the admin interface have lots of form buttons. Currently they are either:

Colour	Meaning	Examples
Blue	Main Function	Send for publishing, Store Draft, Discard draft
Dark Grey	Supplementary Function	Add object, Disable Editor
Light Grey	Disabled	Remove Object (Related Object attribute where there's not an existing association)

By default a content edit page has (at least) 5 main function buttons, all coloured blue.  This makes it extremely difficult to scan for the correct path to complete the task.

Most forms have a primary and secondary action. The primary action being the "save", "continue" or" "I'm finished here, what's next?" button, they enable completion.  Secondary actions are those where the user wants to do the opposite - "Cancel", "Go Back", "Get me outa here!".

For example when editing content in eZ Publish users are most likely to complete the form by clicking on either "Send for Publishing" (primary) or "Discard Draft" (secondary).  These buttons need to stand out on the page so that they are immediately obvious and the user doesn't have to search for them.

Suggestions:

• Ascertain and clearly differentiate primary and secondary action buttons on each page
• Apply consistent styling to primary and secondary buttons through out the site
• If there is no obvious primary and secondary actions don't use them (e.g. cache management )
• Use existing colour scheme (or similar) for all other buttons.  These are less used and it's OK for users to have to scan the page to find them.

Damien has a similar suggestion:

Buttons in the admin interface should be of a different colour depending on the action they trigger. For instance cancel buttons can be orange, publish buttons blue, remove buttons red, ... The main key here is to be consistent over all the interface.

This was also added to the specification (#1 as a "Could").

My concerns with this is that some pages may end up looking like some has dropped skittles over it. Some pages contain too many actions that may be coloured. I believe that this would limit the ability of users to quickly find and complete their desired action.

Ability to add help text

The ability to add help text for each attribute of a content class will be a major improvement.  This not only allows for better interfaces for users but will save an incredible amount of time for developers who currently have to customise each form to include this type of information.

Note: This has been added to the specification but I'd like to see it a little higher up the list. Much more important than any drag and drop functionality IMHO!

Setup tab

The setup tab is the dumping ground of functionality that doesn't fit anywhere else. There are functions located under this tab what don't have anything to do with "Setup" e.g. Search statistics, Collected Information and URL Management.  I suspect that new users may have some trouble finding this functionality.

The Setup Tab also contains mix of functionality that Content Editors may require access to (the non setup one listed above are a good start as well as URL management translator and wildcards, and Global settings ) and others that they should not e.g. Cache management, Classes etc.

In fact unless the Content Editor has the ability to clear the cache (setup -> managecache) they'll see an error when visiting the setup tab.

Thinking about who is using the interface I'd suggest that the functionality that is available under the Setup Tab is split into Development setup tasks and Editor configuration tasks. Another way of thinking about this tasks that are performed during development and those that are performed during the day to day running of a site.

Suggestions:

• Only the options that the current user has access to should be displayed (This is in the specification #1.5)
  
• The Setup Tab link should go to a landing page that lists the tasks with a brief description of the functionality provided.
• Group related functionality (put the URL alias management,  workflow links together)
  

Ability to use old interface

Pain of some level usually goes hand in hand with the introduction of change of any kind. I'd hope that along with the new interface there is  the ability for the old Admin interface to be used. The interface is one component of eZ Publish 4.3 but one that have a very big impact. 

The use of the new interface should not be a barrier to upgrading and taking advantage of the new features and bug fixes.

I know of at least one site that is still on eZ Publish 3.4 because the cost of retraining staff in the new interface was a significant project in itself! (The current interface was introduced in eZ Publish 3.5)

Christmas reading

I can't recommend enough Luke Wroblewski's book Web Form Design: Filling in the blanks. It's a must read if you are creating forms on the web.  It won't tell you how to create the perfect form but presents a number of best practices all backed up with research.

¹ Since I reviewed these additional checks on the Login are allowed.