There was a great workshop this week at the Tridion Developer Summit, where we discussed Experience Manager implementations. Here are a few tips taken from that:
1. Implement XPM from the beginning, your very first template/view… If possible, try it out on the HTML design when its being developed… solving design issues early and at origin will save heartache later on when its too late…
This is the most important one: Many many implementations I have seen has XPM implementation in Phase 2 and this is going to bite you in the backside – plan to use it from the beginning. Its not that hard to test the HTML without even creating a template – just inject the HTML file with comment/JSON markup and put it on your staging server.
2. Think XPM when designing your content model. Non-visible stuff should be metadata (so its editable in the metadata editor) and have a good think about those multi-level embedded fields – these can be a big mess in the inline editor.
3. Page Types are great, but remember you have to be an Administrator – Editors will not be able to create or change them.
4. XPM uses Z-index 100 for its overlays
So make sure your HTML design doesnt have stuff that goes on top of this.
5. Do you have something important in the top left of the screen? If so this could be obscured by the “SDL Tridion” button.
6. Multimedia components have a preview image, which makes it easier to see what you are selecting (You Tube as a MM comp?) in the selection panel.
It could be a useful option to create some non-MM components as MM components to give a visual clue (for example a component which references a YouTube video – upload an image related to the video subject and add the youtube id as metadata).
7. Use the Navigation Panel and sites list – its useful to switch between XPM and Content Explorer.
8. Did know that any container element can be used for a field (not just <span>)?
This means you can use the semantic structure of the HTML to contain your XPM markup and don’t have to add extra “layers” of spans or divs – But you need to write own helper functions to write out XPM syntax, the OOB TBBs cannot do this.
Yes!
1. “Implement XPM from the beginning…”
A plus for developers is that Session Preview lets you see most Template changes without republishing. Change. Save. Update Preview. Rinse and repeat.
2. Think XPM when designing your content model. …multi-level embedded fields – these can be a big mess in the inline editor.
Good/bad news is as of Tridion 2013 SP1, is at least the embedded part has been updated to let us add/move sets of embedded fields. I’d still look to “flattening” a content model (at least a little) not just for XPM, but for targeting and other dynamic displays or queries (via CD API, SmartTarget, CMA/PnP/Context Expressions, SDL Mobile, etc). It’s harder to mix, match, and query individual component (presentations) if they’re not components.
3. Page Types are great, but remember you have to be an Administrator.
Nuno’s trick: have an Admin check the page type box before-hand to let editors set up the content. Good point on the other (content type) settings though–an admin does have to come back to set those.
6. Multimedia components have a preview image…
Nice, Bart also uses Multimedia components for “widgets” in his “Having Fun with XPM” post. I think there’s a case to get (ask Nuno and Alexandra for) more visuals in the library panel. We have page type preview and template icons. The next could be maybe Schema icons (or jump straight to dynamic CM-side rendering on Component content, but fast)? 😀
7. Use the Navigation Panel and sites list – its useful to switch between XPM and Content Explorer.
Great option! The Slide Out menu is extendable to include any (“iframable”) page as well.
8. Did know that any container element can be used for a field (not just )?
I see browsers refuse to put block elements in spans (I think they’re not supposed to?), so “inline” divs and other elements have worked better for me with XPM.