I was lucky enough recently to get my hands on a QA build of the up and coming Sitecore 6.4. And I’ve got to say, very nice. The improvements made in this release are very apparent and it shouldn’t take a great deal of persuasion to get your clients to upgrade, especially if they’re currently using the page designer.
So here’s a highlight list of the improvements in Sitecore 6.4.
Cross Browser Support
The very first notable improvement is when you navigate to the login page in a non-IE browser such as Firefox, Safari or Chrome. The desktop is finally available in all (well, those I tested anyway) browsers. This is fantastic news for both devs and users. Not only because you’re now not forced to use a lesser browser when you want the desktop, not only because you no longer must have a PC to use the desktop, but mostly for the performance. Sitecore has a very rich UI which contains a lot of javascript and pretty much every single javascript engine in every non-IE browser is faster than the engine in IE. Chrome has long touted being the fastest javascript engine, and now you can take advantage of that capability in the Sitecore desktop.
The login page in Chrome. Note that the desktop option is available (no hacks!)
The desktop, in all it’s glory, inside Chrome.
This cross browser support has come at a cost though, we’ve lost support for IE 6. But you know what? Let it go. I applaud Sitecore for dropping support for possibly one of the worst browsers to pollute the web space for so long. If you still use IE 6, then you don’t deserve a good browsing experience. Just let it die.
Updated WYSIWYG editor
The WYSIWYG editor has also been updated from the previous Telerik ASP.NET RAD editor to the latest Telerik ASP.NET Ajax RAD editor. This is definitely good news for both developers and users. I say developers here cause it was normally their job to go and fix any suspicious markup the WYSIWYG editor was producing.
Having said that, the previous editor did a pretty good job especially when compared to any of the other editors out there on the market. But the new Telerik RAD editor, also sometimes referred to as the Telerik “Promethius” RAD editor does an even better job.
Why is WYSIWYG so important? On every single tender I cast my eyes over there are always requirements to do with the WYSIWYG editor, which is kind of funny seeing as though the editor is an external 3rd party component. But this is how business users are going to express themselves. And don’t marginalise the importance of a good WYSIWYG editor. WYSIWYG is an extremely difficult feature. If it weren’t difficult we’d have had perfect WYSIWYG editors on the market years ago.
And there’s also the issue of compliant output. More and more clients are aware of the importance of having a site with compliant markup. The new editor does a better job at this than the previous editor.
Unified Page Editor
The Page Editor and Page Designer have also had an overhaul and been merged together. This new page editor is called the “Unified Page Editor” but is still referred to in the CMS as the “Page Editor”. This feature was originally demoed at Dreamcore this year. Unfortunately I didn’t make it to Dreamcore, so I hadn’t seen this merged interface before I started playing with Sitecore 6.4.
The ribbon displayed at the top of in-page UIs (page editor, preview editor, debugger) has also had a makeover to give it a much more clean feel. I never thought there was anything wrong with the previous ribbon displayed in-page, but this new ribbon just looks…better.
You can still edit content in the page editor as you used to; hovering around the page would reveal editable content by placing a border around it. But this has now been taken a step further by combining all the designing features into this view as well, so whilst hovering you don’t just get borders around editable content, you also get borders around placeholders and controls you can interact with. Of course these features are security enabled so if you don’t have editing or designing permissions, then you wouldn’t see the relevant borders or be able to edit / interact with the relevant content / controls. If you do have permission, you may still want to turn off one or the other (content editing or designing) so you can focus on the task at hand.
When you want to insert a new control (rendering or sublayout), clicking the rendering button in the new chunk on the home tab will reveal the placeholders in the page where your new control can be added.
Clicking on the appropriate “add here” button will open a selection dialog where the user can select the control to insert. Only the appropriate controls are displayed in the dialog, according to the relevant placeholder settings which have been configured for the placeholder. The controls in the selection dialog also now support being displayed in a thumbnail view where user defined thumbnails for each control are displayed. (a little more on that later).
There is also now an option to configure the control to request a data source be defined by the user when they add the control to the page. This is done through another dialog which allows selection of an existing item or creation of a new item.
This dialog can also be configured to only allow selection of items based on specific data templates.
Delta Presentation
Now all this page designing used to lead to a big problem. When an item’s presentation was designed using the page designer the presentation was saved to the item being designed. Best practises are to specify item presentation on the data template’s standard values. In this way all items based on that data template will inherit the same presentation and will appear the same. But with presentation defined on an item directly, any update to the standard value will not be reflected in the item.
Incidentally this is also the case with some other Sitecore modules such as the WebForms for marketers module; when a user adds a form to a page the presentation is updated to include the WebForms interpreter control, thus any changes now to the template standard values presentation are not inherited.
Sitecore 6.4 has solved this issue. When a user designs a page and clicks save, only the changes to the template standard values presentation are stored in the __renderings field of the item. This field is merged with the template standard values at runtime to give the overall presentation for that item. This is fantastic! This means even after a user has designed a page changes to the template standard values presentation will be reflected in the designed items cause they no longer store the complete presentation for the item.
All this magic is done under the covers. So if you update the presentation of a content item programmatically, as long as you use the LayoutField custom field to access the __renderings field and set your updated presentation through the Value property of the LayoutField custom field, Sitecore takes care of generating the delta presentation and storing that against your item. Hopefully this means any existing modules (WebForms for Marketers, etc) will gain this feature when used in Sitecore 6.4, and if they don’t it’s quite a minor update to allow it.
I know this is a new feature and Sitecore are just focusing on getting it out there, but one thing I’d like to see is full support for delta presentation through data template inheritance, which would finally fulfil a feature from my Sitecore wishlist that I blogged about a while ago: http://adeneys.wordpress.com/2008/12/17/my-sitecore-wishlist/.
There doesn’t appear to be an option in the page editor to store the presentation in template standard values but you can quite easily in the content editor use the “copy to” link in the presentation dialog box to copy the delta presentation back to the template standard values. Luckily this copy doesn’t just copy the delta, but the complete definition with the delta changes merged into the presentation from the template standard values.
This also means you can’t use the “copy to” link to copy the delta presentation between items. So if a user designed a particular page and wanted to repeat that presentation on several but not all pages, they would have to design each item in turn. I would love to see Sitecore provide some more tools to support this kind of thing.
Thumbnail Creator
Sitecore has always been quite a visual system in the sense that they understand the power of icons. People can recognise icons and pictures much quicker than they can read text, so when scanning through a list of items it helps greatly if you have different icons displayed next to each option than just plain text or the same icon.
Sitecore 6.4 adds a “thumbnail” field to all items which is displayed in place of the item’s icon in particular lists. One example is the rendering selection dialog shown above. Sitecore also understands that the process of generating thumbnail images for a large number of items can be quite time consuming and cumbersome. So in Sitecore 6.4 they added a thumbnail creation wizard.
Now this feature almost feels superfluous. It’s like the powdered sugar on top of the cherry on top of the cake. This wizard allows selecting an item from the content tree or specifying a URL, taking a screenshot of it and presenting it to the user to allow them to drag a cropping square around the page and define which portion to use for the thumbnail. OMG! You would never expect something like this in a web application.
Here’s what the new thumbnail field looks like (which is of field type thumbnail).
And here’s the thumbnail creation wizard in action.
Item Clones
A brand new feature in Sitecore 6.4 is item clones. These are provided as a replacement for proxy items and are used to share content around the content tree. They make use of the standard values architecture to inherit their field values from the original item.
Item clones are created inside the content editor and are very straight forward to create. You can even clone clones.
An advantage to using the standard values architecture for item clones is that you have the opportunity to override values from the original item on the clone item. So we now have an extra link in the standard values inheritance chain, from base templates, to item’s template, to item to clone. And when the original item is updated those updates are flagged on the clone item and must be accepted before the clone item takes on those values. Clones also work on subtrees, not just single items.
Note in the above screenshot the notification in the quick action bar indicating the clone items and also the warning in the fields section that the original item has been updated.
Clones can also be broken by using the unclone command on the ribbon. When this button is clicked the cloned item becomes a real normal item. It will simply no longer inherit it’s values from the original item. And if you try to delete the original item the same thing happens; the clone items become real items with their current field values.
I think item clones will open up a while new box of tools for content sharing strategies. But don’t fret about losing proxies just yet. They are deprecated in Sitecore 6.4 but haven’t been removed just yet.
Conclusion
Although the CMS 6.4 release only contains a few extra features, they are quite high value features that will add a lot to any site and make the lives of the developers maintaining them much easier. I for one am quite excited by this release and can’t wait to start building sites with it.
