Improving UX with Umbraco 7

Umbraco 7 logoOn November 21st Niels Hartvig announced the release of long awaited Umbraco 7 (codename Belle). The new version runs on the same engine as Umbraco 6 but sports a completely new backoffice. Here are my initial thoughts on the topic + a little introductory tutorial.

In this post I’ll:

  1. be really excited about the new look of Umbraco 7 backoffice (I mean, have you seen the skin on that?!)
  2. explain a bit more seriously why I think Umbraco 7 will be a revelation for editors and will take this CMS to a whole new level
  3. show you a quick tutorial of how to build Umbraco 7 custom property editor and leverage the new secret powers to improve editors’ user experience

Umbraco 7, codename Belle indeed

So, have you had a look at the sparkling beauty that is Umbraco 7′s interface yet? No more feeling like a bum when working on your Umbraco installation in a crowded hipster coffee shop, right? Ok, that really isn’t the point. The point is that the new backoffice, while looking nicely minimal, also follows many of the basic interface design patterns that the old version gleefully ignored.

Some examples include improved workflows with “save and publish button at the bottom of the page; animation and self-healing pattern on deleting items from content tree; or additional information appearing on hover. When adding media items to RTE, the editor will be able to use drag-and-drop functionality or upload new files in the same tab sliding from the right which makes the process faster and more intuitive.

The new interface is also much faster than the old one, which makes a great difference when you work long hours curating content.

Improving editors’ experience with Umbraco 7

However, the best feature of Umbraco’s new backoffice is that it is built with HTML5 and AngularJS. This means that it is relatively easy for developers to create custom property editors. Why is this relevant? Don’t we already have all the properties we might want? Well, kind of. But with Umbraco 7 we can combine properties to create new ones or slightly adjust them to fit better with editors’ needs. An example that springs to mind is a property editor that allows editors to arrange content by dragging-and-dropping content boxes.

But mainly I see Umbraco 7′s advantage over older versions and other CMSs in that it allows developers to adjust interface to improve user experience. Here is what I mean with this:

Imagine you are building a website for an airport. It is a large and complex site with many content items and functionalities. On the frontpage of the website there is a small box that displays the status of the airport (“All is well”, “There are long queues, make sure to come in advance”, “We are snowed in and all flights are cancelled” etc.).  The editor would also like to be able to choose whether the message is “not important”, “important”, or “critical”. The status is used to decide two things: whether the message should be emailed to employees and how it is displayed on the website (i.e the css styling). The property editors are a textbox and a radio button list with labels denoting the importance of the status.

In a complex, large installation it is easy to imagine that editors forget exactly what each status means in practice. Of course I am choosing a “very important” for a status about longer queues but does it mean that the text is displayed in red? And will the employees be emailed? Any developer worth his money will instantly describe all the options in the property editor’s description field. Fair enough, but think of the volume of tiny text that you need to use to describe in details just these 3 options. And what if there are 5 or 10 of them? Scanning through this text is simply not optimal when the editor wants to perform a simple task of choosing the importance of his content.

Enters, Umbraco 7. With HTML5 and AngularJS, it is a question of about 30 minutes to build a new property editor that will deal with this clatter in the best UX style. Instead of having one long text, the developer can ensure that hovering over each option will cause a hint box to appear, describing the consequences of this particular choice. No clatter, only the information the editor needs, delivered in relevant small chunks.

This way of delivering content is in keeping with hover-reveal contextual content UX pattern. It reduced the noise and delivers only relevant information. Keep in mind though that for mobile devices this interaction would have to happen on click and not hover!

Building your first custom property editor with Umbraco 7

Disclaimer: This mini tutorial is based on and extends this tutorial so you might want to have a look at it as well.

Required files

To begin with, in your App_Plugin folder you will need to create a folder for your property (RadioListEditor in my case). The new folder will include the following files:

  • package.manifest
  • radioList.controller.js
  • radioList.html
  • toolTipsStyle.css

package.manifest is a json file that describes the property editor and binds all required files together.

    propertyEditors: [
            /*unique alias*/
            alias: "My.RadioListEditor",
            name: "Radio List Editor",
            /*html file (view) to render the editor*/
            editor: {
                view: "~/App_Plugins/RadioListEditor/radioList.html"
    //array of files we want to inject into the application on app_start.
    //In this case a controller (necessary) and stylesheet (optional)
    javascript: [
	css: [

radioList.controller.js is, as the name suggests, your AngularJS controller that does all the heavy lifting of passing data there and back. In our case the controller doesn’t actually need to do much other than pass data to the model so it will be limited to a bare minimum:

        function (){}

It is not important that the function is empty, but it still have to be there.

The last required file is radioList.html which is an html snippet used to render the property editor in backoffice (a.k.a your view)

    <ul ng-controller="My.RadioListController">
        <li class="radio-option">
            <input type="radio" value="1" ng-model="model.value">
            <label>Not important</label>
            <div class="radio-tooltip">The color of the status message will be black</div>
        <li class="radio-option">
            <input type="radio" value="2" ng-model="model.value"/>
            <div class="radio-tooltip">The color of the status message will be green</div>
        <li class="radio-option">
            <input type="radio" value="3" ng-model="model.value"/>
            <div class="radio-tooltip">The color of the status message will be red</div>

As you can see there is not much magic here either, except for ng-model=”model.value”. This is an AngularJS directive (easily recognized by the ng- prefix) that takes care of passing the value your editor chooses to the model that handles content in Umbraco. There is probably a whole other article to write about how you use model.value and what it actually does. For now, just know that you need it in the input fields so that the editor’s input is saved and accessible when you want to display it.

And lastly, an optional file that takes care of displaying div tooltips on hover – the css file

.radio-tooltip {
  display: none; }

.radio-option:hover .radio-tooltip {
  display: block;
  width: 150px;
  margin-top: -22px;
  padding: 10px;
  border: 1px solid #fff;
  background: #F2E994;
  position: absolute;
  left: 410px;
  z-index: 9999; }

Note that if you want this functionality to be available for mobile-device users, you might want to cause the behavior with JavaScript or do some media-query/wurfl magic instead. If you choose to use JavaScript you will need to include your script in the same way you included the .css file in package.manifest

Once all your files are created all you need to do is restart your application to make sure that the new property editor is registered (you might need to restart the application every time you change something in the controller code).

Next, go to the developer section of your backoffice and click on the 3 dots next to the Data Types option. Create a new Data Type and give it a name of your choosing. From the dropdown list choose the Radio List Editor (or whatever name you gave your property editor in package.manifest) and hit save. Now the property editor is available to your document types as per usual. Add it to your document type, create content node of that type and see the magic.

tooltip on hover - screenshot

This is a very simple example of how Umbraco 7 gives much greater control over backoffice interface to developers, and how this control can improve editors’ experience. There is much to be gained from this control and I am looking forward to exploring further.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>