As typically happens in this type of Knowledge Transfer, the information flow always goes both ways - we learn from R&D on what the tool is expected to do while showing back to R&D how we expect it to behave under the blueprint abuse that we constantly put Tridion through.
And while it was clear that the tool is still in development (a couple of buttons were not enabled yet on the build we used) it was also clear that what is in place really works amazingly well.
I really don't even know where to start when it comes to SiteEdit, there's just so much being added and/or modified that it's hard to start.
So I'll start with the simple improvements I've seen.
- Defining Page Types (a prototype from which you can create a new page) is as simple as checking a box on _any_ existing page.
- Adding an image to Tridion's "content library" is as simple as dragging & dropping it into your existing library
- SessionPreview architecture shows changes to pages dynamically without the need to republish the page or any of component presentations (and avoiding any publishing queue bottleneck).
- The whole wording of this interface is much user-friendlier than Tridion's language in general, which tends to be very technical - Content instead of Components, "Edit everywhere" instead of "Edit parent"
- Ability to associate component templates with page templates - so that users will only see the options that make sense to use in any given page - and present these to the user as "Content Types"
Editing a "shared" component:
Selecting a page type for a new page:
Editing Content:
Selecting an image from the library:
Absolutely amazing and surprisingly stable and fast. Can't wait for it to come out.
3 comments:
Thanks Nuno,
Does SiteEdit 2012 allow to open and edit deeply nested components?
Context:
We are using SiteEdit SP2 and Tridion 2009. In our site we have few UserControls for Header, Footer etc (We our current not using Dynamic components for 'xyz bla bla bla' reason.). When we try to open this component in SiteEdit as a component it opens the first level component which has the code for UserControl and not the actual content component. This limits are business users ability to make content changes using SiteEdit. This e.g.: can also be extended in case of .asp includes or .shtml includes. Any options on this in SE2012?
[Optional :)] Any workarounds that can help us in our current implementation?
Hi Dheeraj,
The answer to your question will present itself to you if you open a page after it's been published to staging and inspect it's HTML.
In it you will see that a Template Building Block as added a serious of "instructions" using JSON notation to mark a given Component Presentation or field with the parameters needed by SiteEdit.
You can do this yourself. If you're using DCPs, make sure this markup is added to the DCP itself.
To me this seems like your content design was done without considering SiteEdit's behavior. The work around is (and always has been since SiteEdit 1) to add the markup yourself. Just poke around with those comments (directly on the delivery side at first) then once you're happy move that to a template building block. SiteEdit will deal correctly with "embedded" Component Presentations as long as the markup is correct.
Hope this helps,
Nuno
Nice preview. Thanks.
Good to see the 'wording' will be much user friendly as well.
Post a Comment