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.

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 project1) 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

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:

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.

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.

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.

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)

In the preface to the current Admin interface specification the last paragraph caught my eye:A overview of user task need a dashboard, where she can follow here own content, approval and other tasks she might do on a regular basis.I recently saw a demo of the latest version of the bug tracking system JIRA 4.0 by Atlassian. It used an OpenSocial dashboard to allow users to customise their homepage to access and interact with information that was important to them. The system not only displays JIRA widgets but any OpenSocial widgets (and those from other Atlassian products). You can check out a video of it in action here and more information on how Atlassian is using OpenSocial here.

What is OpenSocial? From the official site:OpenSocial defines a common API for social applications across multiple websites. With standard JavaScript and HTML,
developers can create apps that access a social network's friends and update feeds. Google personal home page is an example of an OpenSocial da…

The following presentation was given on 24 July 2012 to the DevOps Brisbane group. Some of the technical detail about Vagrant is outdated but I think it provides a good overview of why moving to a "Infrastructure as code" setup makes a lot of sense.