5 things to look for in a CMS interface

Editor's Notes

• #3: Our initial reason for creating a CMS was for accessibility reasons. I re-evaluated this in 2008, and still couldn’t find a usable CMS admin, let alone an accessible one.
• #4: This is really a plea to think of the users. How the CMS deals with content generally defines what interface model they can take. Also, whether they provide a universal or custom admin area will impact how usable it can be in your scenario. And now for an architectural metaphor...
• #5: - Focused CMSs tend to have the nicest interfaces, and the page model means the interface and the website match up in the users mind. Good from a UI point of view, but that UI tends to breaks down in more complex situations, such as multiple teams with workflow, or adding in other types of content (e.g. events). Less flexible. Building an extension on a cottage is ugly.
• #6: Wordpress (page model, universal interface). The interface is quite polished, and quite streamlined, for making posts or managing things related to posts (e.g. comments).
• #7: Immediacy (page model, universal interface), is/was a Windows based CMS with an office-like interface. NB: This is an old screenshot, they’ve been bought since, I’m not sure about it’s status but it’s a good example. It uses a page model, which is generally good for authors. However, that model also restricts the flexibility of what the site can do. News also becomes unmanageable with a lot of news items in a hierarchy.
• #8: http://www.slideshare.net/drewm/content-management-without-the-killing Blogs are (relatively) simple to use because the publishing model is simple - make a page, publish it. Things that are hard - other types of structured data, workflow, relating page and menu management. It isn’t just reliability, it is adding complexity to the interface in a way that is difficult for authors to understand. Wordpress starts simple, but adding a lot of functionality can move it into the next category…
• #9: Functionality oriented CMS tend to have quite modular functionality, but also modular interfaces. Makes things that interact together difficult to do well, such as workflow & panels, content & assets. For this to work, the architecture for UI needs to be at least as structured as the code architecture. Not actually sure if that’s possible.
• #10: Users have to know how functions map to the end website, e.g. what assigning a block to a region actually does on the live website.
• #11: An old example, but a goody. Where do you add the content?
• #12: If there are only a couple of you, it can take a while to get to the lawn from the bedroom! The larger the product, the more likely it is to create things you don’t want or need. (E.g. It’s own developer tools. In Reddot you edit CMS templates in a browser based editor. That feels like sculpting whilst wearing boxing gloves.) Tends to either: - Take a lot of work to match to your needs (de-constructing things) - Not have an admin, so you have to create that as part of the process (not as popular with clients?)
• #13: Squiz Matrix, where everything is an asset, even pages. Makes things like navigation really hard to understand. In the real admin, you have to know to ‘unlock’ things. EVERYTHING. Quite a few CMSs have an ‘object model’ of content, where headings, paragraphs etc are objects that are organised into pages. The object model puts a lot of perceptual distance between editing things and the live website. Although the direct interface (on the right) mitigates this to some extent, the complexity tends to leak through on more complex tasks.
• #14: Ruby on Rails, MS MVC, Django...
• #15: A lot of the frameworks have a data-oriented model, which is ok until you want to include workflow or relate thing together in the interface. Personally I like these, as you make exactly what you want, however, the lack of an authoring interface you can show in advance makes it a hard sell.
• #16: Page model (focused) tends to quick to be implement and quite usable, however, the more you pile onto it the less usable (and reliable) it becomes. Functional tends to be flexible and (relatively) quick to implement, but not very usable. Traditional (object) can go anywhere in the triangle, but are generally not usable without customising the interface, so are not quick to implement.
• #17: If you put a lot of the functionality in the interface level, you either reduce the flexibility of the system, or increase the complexity of the UI. How much it makes sense to complicate the UI depends on whether you have technical users or not. Personally, I think that is a mythical person. I prefer a clean separation and to use a framework where you create the admin features needed.
• #18: I cannot stress enough that authoring interfaces should be task-driven. Unfortunately they tend to follow the model of how they deal with content (e.g. page, object etc). There is no harm in making content types clear, but the process of starting a task should be the most clear. Two steps to publish is like Amazon’s one-click purchase button. Easy concept, hard to do. There are some common examples that tend to catch CMSs out. When you create a page can you: - Add images or other assets. - Place it in a menu (or do that automatically)
• #19: Overview - The CMS is part of the site, at www.domain.com/admin/ - The bar at the top is constant - Quick access to the most common things (drop-downs under add/manage for each content type) - The dashboard includes top-line information and task based short cuts Content types are visible, and use clear names that make sense for the website (rather than CMS) Manage pages is a hierarchical list of the pages, other content types are also represented in that, i.e. they have a place. For each page in the tree, there are several actions available, and you can select whether to show in the menu (which is based on site-structure) - In preview you see the draft page, and have all the workflow options.
• #20: Add a news item - Two step process: Add news (1 page), preview page (publish or send for review available there) - Important that you can complete the task in one go, for example, inserting an image should be possible inline (like in Wordpress).
• #21: Editing pages - Everything required is on the edit page, you can publish without setting any other options as we have pre-set defaults. - Panels (small areas of HTML content or dynamic listings) in the preview are shown where they would be on the live site. - Options on the left of the edit page (properties, layout etc) are not needed in order to publish, but are available to change. - The layout tab shows content and panel areas in thumbnails, to help people mentally-map to the live site. - Properties tab for hidden aspects, meta data etc. - Versioning is simple click through to see an old version (and make that the new version if required).
• #22: The more users can do with the interface (especially administrative tasks), the less usable the interface will be for content authors. A page model is simpler for people to understand, but if you are re-using content then an object model might be more suitable. When assessing a CMS, run through scenarios for typical tasks (adding/editing content), can you accomplish it in one go? If you need to have done something else before hand, it’s failed. There is some knowledge needed for any moderately powerful CMS (e.g. draft vs live, workflow), how does the UI make those aspects clear to novice users? If you look through the training documentation, does it go through features or tasks? How easy are the typical tasks?