Wednesday, December 23, 2009

eZ Publish Admin Prototype extension

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) Apparently this is eZ Flow 2.0 (included with eZ 4.2)
  6. Full screen editing (this rocks)
  7. Edit action buttons (Send for Publishing, Store Draft, Discard) replicated at top of edit page
If you have issues with the extension let me know.

Comments on the prototype should be made here. Remember that this is a prototype!
    I'll attempt to keep the download up to date with the latest changes.

    Tuesday, December 22, 2009

    How to install the eZ Admin Interface prototype

    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/
      # 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
    Note: If you are attempting to add this to a an existing site make sure you have the ezjscore extension installed.

    Let me know if this doesn't work for you via comments and I'll check it out and update the post.

    UPDATEI've created an extension version to make it even easier to check out.

    Thursday, December 17, 2009

    eZ Publish Community Day to be streamed live!

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

    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/

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

    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.

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

    Tuesday, December 15, 2009

    eZ Publish Admin redesign - Dashboard = OpenSocial?

    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?

    Monday, December 14, 2009

    eZ Publish Admin redesign - Think of the Editors!

    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.

    Photo credit:  http://www.flickr.com/photos/sybrenstuvel/2468506922/