Following on from yesterdays post on checking out the eZ Admin Interface prototype I've created an extension that can be easily downloaded, installed and enabled.

1. Download the extension from here
2. Copy to your extension directory and untar:
   
   tar xzf admin2prototype.tgz
   
   
3. Enable it in your admin siteaccess by editing settings/siteaccess/site_admin/site.ini.append.php and adding:
   
   [ExtensionSettings]
   ActiveAccessExtensions[]=admin2prototype
   
   
4. Clear the cache
   
   

To disable, simply remove the settings from step 3 above and clear the cache.

Note: If you enable the extension via the admin interface (Setup -> Extensions) this will effect all site accesses including your front end ones. 

Things to check out in the prototype:

1. Lack of Shop and Design tabs - these are disabled by default in eZ Publish 4.3
2. Hidden right menu. Click on the [+] to expand
3. Content menu (Left Hand side under Content, Users & Media Tabs) can be variably sized. Grab the bottom right hand corner and drag to desired size
4. Different context menu when left clicking on items in the content menu (I'm not a fan of how sub items cover the top menu items)
   
5. Drag and drop block ordering (When editing a Front Page in eZ Flow)
6. Full screen editing
7. Edit action buttons (Send for Publishing, Store Draft, Discard) replicated at top of edit page

The Admin Interface Refresh project has had a concept implemented that can be reviewed live with an eZ Publish install. This is a guide on how to get things working.

The new Admin Interface design is a prototype and it's constantly being refined so don't try this on your production servers.

Starting from a clean install of eZ Publish 4.2 with the the eZ Flow package (with content)

1. Change into the design directory
   # cd design
2. Checkout the design
   # svn co http://pubsvn.ez.no/nextgen/trunk/design/admin2
   
3. Edit settings/siteaccess/admin_site/site.ini.append.php and change the SiteDesign to admin2
   [DesignSettings]
   SiteDesign=admin2
4. Grab new menu.ini - this is required to display the left hand menus under Setup and My account.
   # cd settings/siteaccess/admin_site/settings
   # wget http://pubsvn.ez.no/nextgen/trunk/settings/menu.ini
   
5. Clear the cache

You should now be able to view the new interface and it should look something like this:

To revert back to the original interface:

1. Remove the menu.ini from the admin siteaccess
2. Set the SiteDesign back to admin_site
3. Clear cache 

Updates are occurring on a regular basis so you can update the design with svn:

1. Change directory into the new admin design
   cd design/admin2
2. Update from subversion
   svn update
3. Clear the cache
   

The eZ Publish winter conference is a free conference being held in Geneva on 21^st and 22^nd of January 2010, with the Community Day being held on the 22^nd.

If you are like me and can't make it there is some exciting news! eZ Publish's Community Manager Nicolas Pastorino has setup a Ustream account for the eZ Community and scheduled a event for the community day.

That's right the Community Day will be streamed live!

Show your support of this wonderful initiative by signing up to Ustream and RSVPing to the event! (Note that two events for they day one for the morning session and another for the afternoon one.)

The Ustream interface allows for a twitter channel as well as inline chat allowing participation throughout the day.  The twitter hastag is #ezwintercf.

If you know anyone interested in eZ Publish get them to RSVP as well.  It will be great to have as many people as possible participating!

If you have any experience producing an live event like this or can help out on the day please contact Nicolas and let him know what you can offer.

Photo Credit: http://www.flickr.com/photos/mathplourde/3727973992/

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:

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:


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!

JVMonitoring is a simple monitoring extension allowing you to check your application health through HTTP.

I have noticed in the past few months an explosion of new media sites built using eZ Flow. What is eZ Flow you may ask? In short, it is an extension created for the eZ Publish Enterprise Open Source Content Management System. The eZ Flow extension enables editors to build complex page layouts and pre-plan the publication schedule to ensure a constant flow of rich content. eZ Flow brings modern portal management possibilities to eZ Publish.

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 dashboard but basically there are 2 parts the gadget consumer/container (dashboard) and the gadget producer (the gadgets themselves),

Atlassian use the Apache Shindig software to provide OpenSocial functionality in their products.  This is a good match as it's a Java application as are the Atlassian products.  The good news for eZ Publish is that there is a PHP implementation.

While it's probably beyond the scope of the the current Admin Interface redesign I believe that this is technology that would fit nicely with eZ Publish. OpenSocial is based on Open Standards and has wide industry support from the likes of google, linkedin, yahoo!, myspace, saleforce and ebay.

Another benefit is that the gadgets are easy to write as they are based on HTML, CSS, Javascript and REST.  Each eZ Publish module could have a number of gadgets that provide views of information that could be displayed on the dashboard. Examples may include: Items requiring workflow approval, a search, number of new users,  new content since last visit or number of active sessions.

Using OpenSocial not only solves the eZ Publish Admin dashboard problem but opens up eZ Publish to many new opportunities. I can see this as a killer feature for Intranet or Extranet sites.

Paul Forsyth started an OpenSocial project page when it was launched in November 2007. The project doesn't seem to contain much at this stage but perhaps this can be used as the basis for a proof of concept project? Sound interesting?

It's been a while since I first posted about the Admin interface redesign that will be part of the eZ Publish 4.3 (due 30 March 2010).  Since that time there have been some great input (here, here, & here) from the eZ Publish community as well as a transparent and inclusive design process from eZ Publish.

I'd like to congratulate eZ Systems on their approach with this process and encourage any eZ Publish users to have a look at the specification and the prototype of proposed layout changes and add their voice to the process by commenting on the blog post.

In moving forward with any changes I believe that it's important to understand the users of the system and the tasks they are attempting to carry out. This allows for suggestions and potential changes to be "tested" against a rule of "How does this help [ROLE] complete task [TASK]?"

In my experience users of the Admin interface can be split into two broad groups:

1. Content editors, whose role is to use the Admin interface to accomplish a number of tasks that largely revolve around creating and editing content.  These are the day-today users of the Admin interface, but utilise a small subset of the functionality.
   
2. Developers, who work extensively with most components within the Admin Interface (including those that a Content Editor would use) while a site is being built. However once a site is live will visits to the Admin Interface are only to resolve issues or add new functionality.
   

I believe that the most important group of the two are the Content Editors. They are (usually) our clients, pay the bills and use the system extensively once it's live. They are also the ones who talk to others (potential clients) about the system.  So as well as adding your comments to the blog post, ask your clients what issues they have and improvements they'd like to see.

Continuing on addressing more care and dedication to its community, eZ Systems created a dedicated portal for all community-related activities around eZ Publish: http://share.ez.no

I’ve just published an article that explains how a PHP-based product can gain a good position in the market and be made appealing to customers by using marketing communication. The focus is on products licensed under an Open Source license. Yet, most of the recommendations also apply to proprietary offerings. The article has initially been published [...]