Cognitive load in content management systems

What is my job?

Content needs for websites have drastically changed since I've started building sites. For all but the basic sites, if you technically are not able to have a solid modular content approach you're starting out behind. As such, I started testing out new content management systems to try and find a solution that overlaps with the type of work that I am doing and want to do more of. I thought extensively about how this decision affects my clients. My work often comes from referrals or reoccurring work. It's important to choose something that reflects the quality I want to achieve. Choosing most of my tools is a simple process. I test them out by spending a couple weeks using them extensively. I learn every short cut that I can, shaving a few minutes off here and there. This investment could save days' worth of time over the course of a year. After evaluating them, I will fully adopt the tool if it helps my process. Much like the mechanic who plasters their shop with "Snap-On" branding, I become very attached and at times defensive about the tools I choose since I have so much invested in them. One of the most important tools that I choose is a content management system. What is unique about this type of tool, it doesn't squarely fit into this evaluation process. Sure, I will work with it a lot. But ultimately I hand it over to someone as a solution. This person or group will then live with this decision for years. Complicating matters, frequently clients have had technology (or bad implementation of technology) forced on them. Fighting the system along the way and reluctant to start from square one. With most of my clients they will use this tool weekly or more to manage an important part of their business. Unlike me, they will most likely not use it for hours on end.

Looking past my needs

Approaching the evaluation process from the client's perspective (that the system will be important and used frequently but rarely fully mastered) has helped in choosing a tool. I need a system that is focused and with low cognitive load. Having worked at a company that develops a CMS, I've spent a lot of time thinking about cognitive load and how layering complexity applies to a tool that usually spans two drastically different sets of users. Even with the importance placed on UX/UI, comparisons of these systems still tend to be very heavily based on the feature list and technical capabilities resulting in products designed for the top few percentage of users, not the client. ##### OK, not completely looking past me The first user is, me, the developer. As in almost in any trade/job, they will likely favor efficiency over initial ease of use because they have time to learn it. This is not to say that a specialized tool should have a complex UX, but it does mean that in cases it should expose more functionality at once, increasing the cognitive load. The system can be learned through extensive repetition. This allows "power users" to do their job quickly. It is why I love Sublime Text but would never expect or recommend a client to write markdown in it. For these power users, the CMS should allow quickly accomplishing a task without fighting against their process. After a year of using this tool they will most likely be able to navigate to any part of the system utilizing repetitive memory. ##### Clients The second user group for the CMS is my client. Clients obviously differ, and each person has a different type of niche that they go after. For me, most of these users are part of a small marketing group. Their site is a small but important part of their daily efforts. They will use the system frequently...frequently enough that some complexity is allowed. They likely won't use it enough to memorize all the nooks and crannies of the system. Their experience would be much better if it was simple enough that they could largely rely on their intuition and their short term memory. The short term memory is key, which underscores the point that it is important to simplify the UX, with few options and a linear process. The task is to keep the cognitive load low.

So is there a silver bullet tool?

Of course not. Not only are there two drastically different groups this tool needs to serve, me and my client, but each client is different. The client could be a publication company, and their need may be better served by a UX that is far more complex in order to achieve efficiency on a day-to-day basis. If I were to pick a tool, that would solve most of my client's needs. I would choose to focus on Craft. Craft has been getting a lot of coverage lately. Many articles cover the features, the templating language (Twig) and specifics on why it is so good. I'm not going to repeat them here.

Past CMS experience

I've used MODX and ExpressionEngine almost exclusively in the past. Each system has its strengths. MODX is a great tool for developers and, being open source, a lot of developers have contributed to shaping it. When most of my sites were brochure type sites, I liked the document tree layout and how accessible it kept all the elements. However, the amount of options presented and the general editing flow always favored the developer. On any given screen the cognitive load was high for users who use the system on a less-than-daily basis. ExpressionEngine is friendlier in certain situations, but I ended up heavily relying on third party add-ons to present to clients in a way that was understandable. While the add-ons, most commercial, were highly polished and usually well integrated with the core design they still lacked a singular vision and at times felt against the grain of the core system. Many tasks were unfriendly for me as a developer, particularly regarding the process of building out channel fields.

Craft

Prior to this exercise, I've been following Craft since it was announced that P&T (Pixel and Tonic) were working on a CMS (Blocks at the time.) At the time I was working for MODX so it was more from a research perspective. From P&T's ExpressionEngine's add-ons, I knew Brandon had that rare talent as a developer, having empathy for client's need while being able to boil that down in a streamlined solution. It is relatively easy to implement feature requests, but it is much more difficult to implement solutions for the shared problems. The first thing you notice from a blank Craft install is how lightweight the UX is. This may give the impression that it's feature light, but digging in deeper it is clear that it is not. #### Less is more. More is more. ##### Less As a designer myself, I realize that creating a simple design for something complicated is difficult. When P&T mentioned they went through [31 redesigns](http://pixelandtonic.com/blog/craft) before the beta, I was impressed that they achieved it that quickly. So far, although admittedly I have used it on a limited number of sites, this focus and limited UX has been great for my clients. The amount of frustration on hand-over has been limited. The attention to detail contributes to this: [Matrix's abilities](http://buildwithcraft.com/features/matrix), subtle animations, neutral color palette etc. But the largest contributor to this is the restraint and focus the features of UX. Removing complex menus, persistent document trees, numerous tabs, unnecessary visual rules and action buttons to cover every bit of functionally keeps the straight forward – friendlier for short term memory. The complexity is very smartly layered. By that, I mean "[Don't make me think](http://www.amazon.com/Dont-Make-Think-Revisited-Usability/dp/0321965515/ref=sr_1_1?ie=UTF8&qid=1402064825&sr=8-1&keywords=dont+make+me+think)" principles are applied well with more complex functions are nested under buttons or labels. Features that are more advanced are available under icons or other learned short cuts (for instance double clicking Matrix headings.) Once you know they're there it is easily remembered if used frequently. All of this while not making the UI more complicated than needed. While some of these features are nice for people who use the systems for 20-40 hours a week, my client needs a solution to help them learn the system and feel confident in using it. Adding features and buttons that scratch a single itch is easy. Distilling these down to features without adding an inordinate amount of complexity is difficult. ##### More If I designed a CMS, I always wanted to favor the client. In my world, a happy client equals a happy designer/developer. I would gladly trade additional frustrations on my end to alleviate theirs. This is partially why I think WordPress is used so frequently. What I wasn't sure of was how to resolve making it a good system for both user types. After all, developers and designers need to sell themselves on a solution before using it for clients. Enter Twig. I knew of Twig while I worked at MODX but I didn't fully understand it. Twig seemed like something that would be over my head and not friendly to the front-end developer. The great thing about how this ties in to Craft is, that I rarely find myself needing to access the admin interface to do my job. As one person [mentioned on Twitter](https://twitter.com/cityzenllc/status/460852035236429824 "Twitter Link"), it is a strength that the templates are *not* in the CMS. I can spend almost all my time outside the admin interface, comfortably in my text editor of choice. In my case Sublime Text, which as I mentioned before I spent hours learning/memorizing shortcuts to save a few minutes here and there. So I think the brilliance here is, rather than create a UI that needs to accommodate both users instead implement a system allows developers to spend as little time as possible within the UI.

Try it

While no system is perfect, choose the right tool for the job. If your projects sound a lot like mine and you work with similar clients try a project build on Craft. The templating language has a bit more of a learning curve than MODX or ExpressionEngine but its benefits quickly make up for this. And while the UI is not perfect (it is quickly improving) the interface has been a great fit for my clients. I think P&T been doing a great job of slowly and thoughtfully implementing features requests rather than just including specifics as they arise. I could see this limited interface posing a problem if used for a huge publication. A target audience I think the much talked about interface for Typo Neos could do a really good job of providing to. For the vast majority of my real world projects Craft is just about perfect straddling the line between the two types of users. Oh, and did I mention [how awesome the Matrix field-type is?](http://buildwithcraft.com/features/matrix)