When a user is logged into the CMS, they needed to accomplish a number of tasks from the CMS admin page preview without costing them time or losing context. Here are some of these tasks:
- View the page they are editing as end users see it
- View one of the 22 localized variants of the page they are editing as the end users see it
- Preview the same page as it is on production
- Send the current page for translation for one or more languages
- Quickly edit supporting assets in the CMS like images, add widgets, etc. to be used on the page they are editing (in a new tab)
- Upload files to the Box CDN, then add them to the page
The CMS did not support extending the existing sidebar, therefore, we had to add this functionality ourselves. In addition to this, we needed to allow for provision of any future tasks from the same CMS admin page preview. Also to consider, there are three server environments that developers and/or content authors will be using, which meant the domain and API translation calls needed to be dynamic.
The user experience suffered to say the least, and this is when just using the out-of-the-box CMS Admin UI. For instance, any time I walked through creating, editing, and publishing a page, I found myself needing functionality like previewing the page in a new tab outside of the CMS admin preview or viewing the localized content of a page.
It is all about context, it was clear to me and others using the CMS that we lost track of what we were trying to do as soon as we had to leave the CMS admin page preview to do something.
In an effort to setup a go to place for, I came up with a content author’s toolbar concept. It could be extended as we needed it for launching dialog boxes, triggering REST API calls, and so on. The only screen area it occupied when collapsed was a small icon’s worth of space on the right side of the page.
A framework and defined approach for integrating the much needed content author functionality while being platform agnostic.
Through the CMS build project, many of the software engineers needed to provide content authors with a button, link, or dialog box to trigger server side calls to APIs or other endpoints within the CMS. They quickly adopted the content author’s toolbar as a logical place. Each of the additions went through several iterations after API changes and contextual inquiries with end users.
The result is a user interface for content authors to quickly carry out daily tasks. They are able to send the page for translation, preview the page in a new tab as an end user can see it, preview the localized page to check different regional sites (such as .de, .co.jp, and 20 others), preview the page on production, QA the meta tags, as well as having several quick reference links at their disposal.
As a developer, engineer, and end user on this project, I quickly realized how many of the CMS or applications I was accustomed to using provided a framework for which to extend. When the platform does not provide a framework to build on, look for a different one. That being said, a framework should also provide a preferred approach that keeps development from going down a dangerous path that may require major refactoring or a complete overhaul. Somewhere between opinionated and sensible.