R&D has done an impressive job at simplifying "SiteEdit" for multiple roles.
- Infrastructure consultants (IC) can focus on the install and content delivery setup
- Technicals and functionals have access to settings within the CME for content types, page types, and even color settings
- Authors will get a smoother experience, with terms and a process that fits their model of the content management system (CMS)
- SiteEdit settings are more configurable in Tridion's Content Manager Explorer (CME)
Color picker controls + AppData-stored settings = awesomeness.
I'm going to need to dedicate a post on border best practices,
it will be too easy to change now!
- AppData-stored settings mean quick changes, little-to-no SiteEdit XML config files
- The GUI offers a familiar Content Manager Explorer (CME) look and feel, but simplified process and "paradigm" for authors
- Author-friendly features!
Authors can now choose from content types, which can place "dummy" text on the page based on some default settings. Content types (formerly Component types in SiteEdit 2009) are roughly a component presentation plus a (default saved) location for you technicals. For business-minded folk, a Content Type abstracts and consolidates components, templates, and component presentations. By giving authors good defaults, you reduce the Paradox of Choice and let authors focus more on their content and less on how everything's wired up.
|The Component Title Preview setting dynamically updates in the beta version I currently have.|
So there's love for both the authors as well as the CMS admin (lucky you, in my day I had to...).
|Drag and drop within the CME. But also drag and drop media from the desktop!|
That gives you 4 ways of loading media files (can you name the other 3?).
ConsIt's not out yet! Which is actually good thing because it gives Tridion-using organizations time to prepare. Which leads us to the other major drawback; sorry but...
Tridion-using organizations need to really understand their content author requirements to get the most out of inline editing (or content management for that matter).Here's what you need to do to prepare.
Understand and Validate your DoctypeUnderstand your HTML doctype (valid markup) and validate! Why? Robots (bots). Your browser is a bot. SiteEdit is a machine as well. If you don't validate, your browser might guess your markup and it can confuse any parsing software, including SiteEdit. Remember Terminator and the Matrix? Keep the robots happy and please validate.
Want a classic SiteEdit 2009 example? A <div> is a block element. A <span> is an inline element. You can put inlines inside blocks, but not vice versa. Also, if you're seeing a tiny 1x1 pixel content border, you've likely picked the wrong element (hint: change that span to a div).
Make that Image-Handling Component Template!Once your authors see the demo, they will want to click and drag an image onto a page (I did, then remembered I didn't have a component template set up!). Start investigating component templates that allow you to do so. It can be as simple as the following (DWT example).
<!-- TemplateBeginIf cond="ComponentType = 'Multimedia'" --> <!-- TemplateBeginIf cond="(MultimediaTitle = 'Jpeg image') || (MultimediaTitle = 'Gif image') || (MultimediaTitle = 'Png image') || (MultimediaTitle = 'Bitmap image')" --> <img src="@@Component.ID@@" tridion:type="Multimedia" alt="@@Component.Title@@"/> <!-- TemplateEndIf --> <!-- TemplateEndIf -->
I visited the Amsterdam to help collect SiteEdit functionality and was impressed by the current build, the team, and the freezing cold. It was well worth the trip.