Navigation

The Best Parts of SDL Tridon Experience Manager are the Easiest

[x] Use this Page as a Page Type. 

Many of my customers will attempt to implement Experience Manager (XPM) bottom-up rather than top-down.

I'd prefer Tridion-using organizations took the opposite approach, especially considering:

  • Authors find new content and page creation harder than updating fields
  • Inline editing or the ability to edit text on a page requires template updates for editable fields along with valid and clean markup
  • Experience Manager won't fix a challenging content model, even if you show every single field in context, but it will make getting started with the most complex pages easier

Make the challenging Tridion parts easier, then work down into the details. Ideally you'd wait to release the entire experience to your newer authors after you've tested the content model and create some Good Defaults.

Hard parts from tasks that lack context to fairly easy:
  • Hard:
    • Creation. Creating new content without instructions or context (especially wide-open text boxes)
    • Assembly. Assembling a page without knowing any hidden "rules" when making a page (regions, limits, or component presentation placement)
  • Medium:
    • Locating Items. Finding items without instructions or the context of the site (Where used, naming conventions, structure and taxonomy help)
    • Predicting Layout. Knowing what a template change will do to a component on a page (fields displayed? layout and placement?)
  • Easy:
    • Update Pages. Editing an existing page by moving component presentations up or down is fairly easy
    • Update Content. Editing content in its form view is also easy--we do this all the time outside of Tridion
Form fields are everywhere.
Creation is hard, especially without context. Edits are easier. This implies a natural top-down priority for Experience Manager:
  • Familiar navigation. Let authors find pages in the context of a website they know through a basic XPM install and minor template updates.
  • Good defaults and prototypes. Offer page variations with sample content (page type check box and content type settings as configuration changes). Add content types to handle variations and make best practices visible and explicit.
  • Fast changes. Set up Session Preview for a smoother authoring experience which is easy if structure groups and site structure map, though there are approaches for MVC setups (especially in SDL Tridion 2013).
  • Offer inline editing. Add or generate the Experience Manager script with your delivery-side framework by updating templates.
Start with the easy-to-implement, highest-value activities. Not necessarily the most impressive with the wow factor. Inline editing is a great feature, but start with solid, easy-to-implement benefits.

Blogs as an Authoring Example

I've used this example before, but look at familiar, "non-enterprise" sites like Blogger.

Form View is Perfectly Valid

I can click on a pencil to edit a post in Blogger which opens a form.
I can click on a open button in Experience Manager which opens a form. 

Blogger Layout is global rather than page-specific, but the drag-and-drop layout features have "regions" that aren't picture-perfect representations of the site. Guess what you get when you edit these blogger widgets? That's right, a form. :-)

Template Preview Helps Bloggers Choose

Changing themes (templates) in Blogger has a nice "real-time" preview and again this is for an entire blog. Experience Manager offers similar benefits at a per-page and per-content level.

Template Icons Help SDL Tridion Editors Choose

Experience Manager offers per-template customize-able icons as well as a page type preview. Just set these in a component template or page (type), respectively.

Getting a hint at what a template does visually offers context faster than a text description.

 Page Type Preview Helps SDL Tridion Editors Choose

A page type preview lets editors browse various designs before "committing" to a page.

With a few clicks, some icons, and no programming your authors get:
  • Familiar navigation.
  • Good defaults and prototypes.
  • Visual, in-context hints at what choices do with features that rival popular blogging platforms, but for your existing site.
So why aren't we seeing more page types? I'm guessing because of the (lack of) intersection in roles.


Making an XPM Page Type is not hard nor complex. But it takes editors making a connection with CMS admins to click on this checkbox:

[x] Use this Page as a Page Type. 

Update (2014/03/26): Having talked with product managers Alexandra and Nuno on different occasions, here options you might consider when using page types:
  • Some customers localize page types so they become specific to a given publication
  • Others create a non-public website to manage "global" pages and "placeholders" (component presentations that get localized in child publications)
  • Nuno pointed out (the now obvious fact that) you can mark a page to be a page type without needing to create the page type details up front--this gives authorized authors the ability to create and evolve a set of prototypes however they'd like

No comments:

Post a Comment

Feel free to share your thoughts below.

Some HTML allowed including links such as: <a href="link">link text</a>.