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/

Comments

  1. Anonymous7:10 am, December 16, 2009

    I couldn't agree more. This isn't just an eZ problem though: just about every CMS seems to suffer from the 'you users are just going to have to learn this' syndrome - and users respond by avoiding updating their sites. In a lot of organisations the job of editing content on the website seems to get dumped on those who are unable to say no, HR assistants, work experience kids...
    So, and ideal CMS admin interface would allow any irrelevant stuff to be hidden - 'Object States' are really useful, but for a casual editor seeing stuff like that is likely to cause mild panic. And it should allow object labels to be customised easily to suit the organisation, it should be easy to label 'articles' as 'stories' if the user organisation is a newspaper or TV company as that's the terminology they are used to.

    ReplyDelete
  2. Farheena12:23 am, January 28, 2010

    Its useful information.

    ReplyDelete

Post a Comment

Popular posts from this blog

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. Download the extension from here Copy to your extension directory and untar: tar xzf admin2prototype.tgz Enable it in your admin siteaccess by editing settings/siteaccess/site_admin/site.ini.append.php and adding: [ExtensionSettings] ActiveAccessExtensions[]=admin2prototype 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: Lack of Shop and Design tabs - these are disabled by default in eZ Publish 4.3 Hidden right menu. Click on the [+] to expand Content menu (Left Hand side under Content, Users & Media Tabs) can be variably sized. Grab the bottom right hand corner an
Read more

eZ Publish Admin redesign - Dashboard = OpenSocial?

Image
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 o
Read more

eZ Publish 5 Virtual Machine

One of the most common issues of newcomers to eZ Publish is the setup of a system suitable for running it. Without a correctly configured system in place they usually do not get beyond the installation process and abandon their evaluation before having experienced the product.  The eZ Publish puppet module is an attempt to codify the requirements  for running eZ Publish and provide a means for automatically creating a system suitable for running it - no more following a checklist of "setting up eZ Publish on XYZ". The eZ Publish 5 Virtual Machine can be found on github at  https://github.com/brucem/vagrant-puppet-ezpublish .   It combines Vagrant, VirtualBox & Puppet to generate a VM with the current eZ Publish community version (2013.4) installed and ready to be configured. The README.md  provides details of the requirements and how to use it. Vagrant is a system that  orchestrates the automatic creation and configuration of systems. It has been used to d
Read more