We gathered our "best practices" but needed non-technical descriptions for the business user communicating their preferences to the creative design agency (if you really want the technical details take training and/or read this post by Frank M Taylor).
So let's look at some user stories for those using an in-context CMS editor:
"As a CMS user I need the ability to add content to and from the page. I should be able to add, re-order, or remove content in the in-context or form-based editing interfaces."
This translates into movable elements. Lists and “flat” markup are preferred where possible—especially on a page. This lets editors add, move, or remove in the Content Manager and Experience Manager.
You don't need markup to see which is easier to manage. Here's an example from our CMS Design Principles training: perhaps your presentation looked like a box of sorts:
A B C
D E F
G H I (that's the end of the training example, the rest is my metaphor)
If you figured it out, enjoy the following metaphor.
|Flexible item presentation. Add, move, or swap easily. Maybe even offer a time-sensitive special in any row or present a different type of item. Enough structure to work for those presenting the options and those consuming such options.|
Or would you prefer a more strict, nested structure?
- Row 1
- Row 2
- Row 3
|Quick, pick your favorite. Though optimized for transportation, you can't easily re-arrange or promote items in this rigid box. Crate-makers love crates, but is this the best way to present and enjoy such items?|
"As a CMS user I need the ability to manage text, links, and possibly navigation. My language my vary such that words may be longer or shorter than their source equivalents."The (HTML) design should accommodate varying length text. Individual pieces of text and items in lists may shrink or grow, which impacts translation, navigation, and presentation of content. The business might want 3 links in the global for one site, but five in another. Text size may vary, but images might have consistent sizes, except...
"As a CMS user I want the images that I upload to work as well as ways to make the site easier for my visitors. For images that change based on context, automate the size variations for me but also let me choose different images when appropriate."
|Maybe all items are the same height and width. But maybe the containing elements should be able to accommodate items, descriptions, and imagery of various heights and even widths.|
Final story, with a different metaphor:
"As a CMS user (or even for my developer colleagues), I want to easily recognize fields."
Same elements should be the same, at least structurally. When content modeling, it really helps if the same content type has the same markup or content structure across different pages. Ideally a matching heading, description, and image would have the same heading, description, and image structure (down to the HTML) in different places. This can be good for editors, developers, and users.
Variations in types of content (banner, promo, article, etc.) are definitely welcome, but it’s harder on editors (and content modelers) when the same type of content varies in terms of markup everywhere it’s seen.
|Sometimes it's worth being different to stand out or maybe you prefer consistency. Maybe the previous metaphors were better?|
I have seen customers prefer automatic cropping of images across devices. But sometimes they want to upload different images. Automation is possible to the extent that you can define the rules and/or be consistent. With a CMS like Tridion, you can make variations before the Content Manager, on upload, during publish, or in delivery.
If it's worth it, break all the rules and practices.
|A million dollars says this didn't need a CMS.|
Sorry, I broke the metaphor. Let's go back to expensive items, which may have different values to different audiences.
The final design of how you manage and display items depends on the intersection between:
- The designers of the experience
- Those that manage and present the items
- How thirsty the visitors are