Recently a colleague of mine shared a sketch of a “better admin template.” While it had merit, I responded that no improvement to an admin template will satisfy me. Either it will be too simple and limited for integrators or it will be more complex than what our clients want. I feel a “better” admin template will never be as good as a dedicated “client” template can be.
What is a client template? Technically, it is still an admin template – installing as an admin template and providing backend access. But it differs functionally. The user of a client template is the client, not the integrator. The client needs an interface that is simpler and one that is tailored to his capabilities and workflow needs. Hence, a well-designed client template will differ in design and features from the traditional admin template.
I began building client versions of the backend nearly two years ago as Joomla 2.5 emerged. My admin template of choice was RocketTheme’s Mission Control because I found it to be relatively clean, simple, and configurable. During site integration I myself might use Bluestork, but all my clients’ users are assigned to simplified and tailored version of Mission Control as their backend template. Using Role-Based ACL I am able to tailor the backend so that any given user sees only the links, menu items, and features he/she is authorized to access. Expanding beyond the client template I often would override admin forms to display just those fields a given user should access. By leveraging JCE profiles I could tailor the editor’s toolbar to each user and control what directories a user could access for images and documents. My client’s backend experiences are noticeably different from the backend interface we integrators get out-of-the-box.
This approach served me well when I built a county website where nearly 20 different departments needed to manage different content on the website. The screen shot below shows what one department sees when one of its users logs in. Each department has a similar short set of quick links tied only to the tasks they need to complete, and each link leads to just the categories of content to which they are authorized to access. As you can see, the interface is simple, in layment terms, and tailored.
But necessity is the mother of invention. Mission Control is not being continued beyond 2.5. The admin templates of 3.x are more complex than what I was delivering in 2.5, and that kept me from being satisfied with my 3.x deliverables. I experimented with what I could do and built my own client template.
Because I was coding my own backend template, I have been able to design it more specifically for the client experience. For instance, my client template does not display the default admin menu. This, of course, required that I develop a mechanism for creating client-specific navigation – either as a client menu bar or as a dashboard of custom-grouped quick link items. Likewise, I developed a forms manager that allows one to simplify and tailor component forms in the backend based upon that user’s role (or group membership). Remember, it is about tailoring to our users’ needs as well as simplifying the experience.
When I first proposed the term and concept of a “client template,” I was sharing how to code these solutions. Responses from attendees quickly alerted me that most integrators want solutions that are installable and configurable, not requiring coding. As a result, I am refocusing my efforts to see how these solutions can be encapsulated into installable extensions.
Deploying a client template is not the traditional approach to backend management of a website, though it could become one. It is about making the client’s experience simpler and tailored. What are principles for making the client’s experience simpler? How do we make effective decisions when tailoring the client experiences per user? This is an art that goes beyond simply installing and using a client template. We improve through experimentation, practice, and dialog.