Sitecore Best Practice #1: Home is where my buttons are

30 May 2011
Adam Najmanowicz
Frink_Cognifide_2016_HeaderImages_0117

Arguably, the strongest point of Sitecore is the brilliant on-page-editing experience. At every stage during the site's development, we strive for the author to not  be compelled in switching to the Content Editor mode as it immediately becomes apparent that Sitecore is so much more than just a simple Web CMS and suddenly, the author feels the training should have been more than the simple 1 hour "navigate here, then click edit and enjoy the WYSIWYG goodness". Admittedly, that is not always an option as you're not going to build a special editor page for every piece of metadata a user will needs to create. For example client testimonials, address database, promo modules, may best be managed from the backend.

You always need to bear in mind what the most basic function of a content management system is. The backend is used to create and edit content that you will later want to preview and ultimately publish. From that perspective, it is somewhat odd that by default, only two of the basic CMS actions (create and edit) have been displayed as a button on the “Home' tab in the ribbon, and even then, the “edit” function only shows in a limited backendish-edit-properties-way rather than giving us the world-famous-Sitecore-on-page-editing experience.

Default Sitecore Home Tab

If you want to preview, publish or go to the full page edit mode you will need to find the buttons on other tabs, whereas sorting (which you’re not quite likely to use a lot) somehow made its way to the “Home” tab. No problem though, because Sitecore being as flexible as it is, it does not even take a bit of coding to fix the problem!

Let's dive into the Sitecore Best Practice #1 then:

What is it about?

Buttons that are most relevant to authors should be on the first tab in the ribbon. This include the button that:

  • allows publishing the content
  • enables Preview tab (Episerver style if you're used to Episerver)
  • takes editor to on-page-editor for the currently selected page
  • takes author to full page preview for the currently selected page

Why should I do it?

Sitecore's strongest side is the on-page editing and nice previews. So in case of this CMS an author even if they navigate to a page in the tree will most likely be compelled to edit the page in a WYSIWYG manner. The default Sitecore Publish, Preview-tab, on-page-editing and full-page-preview buttons are all around the ribbon. Expecting the author to juggle between ribbon tabs for this basic functionality is unreasonable and the developers should not allow for the authoring experience to be compromised. The home tab is there for the most used buttons after all.

Demo Scenario

Sitecore Best Practice Ribbon

How do I implement it in my project?

 1. Login to the Sitecore Desktop

Login to Desktop

2. Switch to core database and open the Content Editor

Switch to Core Database

3. The Ribbon configuration is in /sitecore/content/Applications/Content Editor/Ribbons/, and we're interested in the Chunks subnode. Insert a new node using the System/Ribbon/Chunk template, name it Quick Actions.

Add Ribbon Chunk

4. Set the Header to Quick Actions and ID to QuickActionsChunk .

5. Copy Publish/Publish node underneath the Quick Actions node. Copy Preview/Preview node underneath the Quick Actions node.

Copy Ribbon Buttons

6. Under the Quick Actions node, insert a new node using the System/Ribbon/Small Button template. Set Header to Page Editor, Icon to Applications/24x24/document_edit.png , Click to system:webedit and Tooltip to Start the Page Editor.

7. Under the Quick Actions node, insert a new node using the System/Ribbon/Small Button template. Set Header to Full Page Preview, Icon to Applications/32x32/document_time.png , Click to item:preview and Tooltip to Start the Preview mode.

Big thanks to Leszek Ciesielski for his research and help on the Sitecore Best Practice #1.