Oct 23, 2019
One of my favorite tech presentations is Rich Hickey’s Simple Made Easy. The premise of the talk is that simple and easy are not the same thing. In fact, you often sacrifice simplicity in pursuit of easiness. As Rich says, we consider something easy if it is “at hand.” Like the Staples Easy Button. Simplicity is something totally different. It is the absence of complexity - lots of moving parts entwined together in intricate ways. If an “easy button” really existed, it would be supported by a complex network of solutions that could take care of any problem.
Rich was talking about programming and how to keep code maintainable. Simple code is easier to understand and extend. But I apply this perspective to lots of things. For example, a bicycle is a simple machine. A quick glance reveals how it works and what every part does. But pedaling up a hill is not easy. A modern car is complex. There is a lot of stuff going on under the hood and nearly all drivers accept that they have no hope of understanding it all.
In building software, I have come to realize that users only value ease. A user wants the features he/she likes “at hand.” In a mature, multi-featured application, UI design is mainly focused on hiding some features to make the frequently used ones stand out. Users don’t want simple. Take away any feature and there will be complaints.
Developers want simple. They want to work with code that is understandable and behaves predictably. They realize that every new feature is supported by hundreds of lines of code that need to be tested with every modification. Much of Rich's talk deals with programming styles that unnecessarily create complexity. But some requirements will force even well designed code to become complex. Ironically, these requirements are often driven by a desire for a "simple and easy" user experience (personalization, natural language inputs, voice control...).
Why does this matter?
If we don't acknowledge that "simple and easy" are in conflict, there will be unmet expectations that lead to friction between stakeholders. Users can become impatient discussing complex details about their "simple feature." Development teams can feel under-appreciated for the effort required to do a "simple thing." The time taken to wrestle with ignored complexity can look like incompetence.
Take, for example, the Google search box. It is easy to use... just type in some text and click the button. But it is anything but simple. There is an art to constructing effective queries and a whole industry (SEO) dedicated to manipulating what comes back. There is also a set of features that makes the search box like the command line for the web. I can't tell you how many times I have heard "I just want something simple like Google." Google isn't simple. But it is easy. What makes Google search feel easy is that the core functionality is obvious and it gives useful feedback to help you get what you want. You may not get what you want on the first try, but it is easy to refine your search to hone in on your target. Voice assistants aim for the same level of ease but I find the trial/error loop to be more frustrating. That is probably because the system can return only one response and the feedback loop takes longer.
I know how annoying it can be for someone to pick at language and I am not advocating to constantly correct people on their word choices. But I do think it is important for everyone to understand what they are asking for and what they are giving up when they get it. We can do that by probing into what the user means by "simple." That question is reasonable because both "simple" and "easy" are subjective terms that require elaboration. When we document requirements, we should avoid all subjective language. After all, most of the work to achieve the perception of ease and simplicity is through iteration and refinement. These qualities are not intrinsic to the feature but rather to the sentiment of the user.
Oct 15, 2013
"Adoption." For years that word has been on the top of the list of critical success criteria for any web content management initiative. "This project will fail if we don't achieve sufficient adoption." The goal of adoption instigated the CMS industry's usability crusade that brought us improvements like better rich text editors and in-context editing. Still, as I have written in "The Myth of the Occasional CMS User" (and Jeff Cram took one step further with "Step letting people use your CMS"), people don't clamor to use a CMS no matter how usable it is.
The truth is, most successful websites are managed by a proportionally small team of dedicated professionals. Gerry McGovern makes this point very eloquently in "Decentralized publishing equals amateur web management."
In most situations, the decentralized publishing model has been disastrous. The people trained tended to be relatively junior staff, for whom publishing to the website was just one more responsibility. The result was lots and lots of poor quality content that was never updated or reviewed.
Does this mean that we should give up on adoption? Hardly. But I do think our thinking about adoption has been all wrong. Most people measure adoption as the number of users who consent to using the platform. The more people using the system, the greater the adoption. I call this "horizontal adoption" and, like Gerry says, it is a recipe for failure.
Forget about horizontal adoption and focus instead on vertical adoption.
"Vertical adoption" is a measure of how much the CMS is used. High vertical adoption means using advanced features of the platform. Vertical adoption has always been pathetically low in web content management. Back in 2006, Lisa Welchman nailed it with her post "The Six Million Dollar WYSIWYG Editor." Nothing has changed. Most of those flashy features that you see in a software demo are hardly used and the problem is getting worse, not better. Most CMS customers are simply not ready to handle today's advanced Web Experience/Engagement Management functionality. I can't tell you how many customer references I have talked to that only use the most basic features. And the software vendors are as concerned as I am about this. At least they should be. If vertical adoption doesn't improve, customers will migrate to cheaper, simpler software.
Of course, vertical adoption isn't just about protecting license revenues for enterprise software companies. If we don't improve vertical adoption, we will never achieve meaningful digital marketing goals. The best that we can do with horizontal adoption is to have more people to fix spelling and grammar errors (and Gerry would argue that outcome is unlikely). If we want to truly engage an audience, we need power users that can get the most out of personalization functionality and uphold the company's side of the conversation.
How do we improve vertical adoption? That is the billion dollar question. There is certainly a usability component to vertical adoption but it is different from usability aimed at horizontal adoption, which focuses on reducing training by making things intuitive and point and click. Usability for a power user assumes expertise and focuses on power and efficiency. Look at an expert in any software. They use keyboard shortcuts. The user interface appears to dance in response to the slightest movements of the operator. But to the novice, these user interfaces can be inscrutable. Remember the Saabre terminals back when we went to travel agents to book our vacations? Is anyone else that old?
Achieving this level of expertise requires training and specialization. You need guidance from other experts and you need a lot of practice. This means that your marketing operations program has to have reached a critical mass where you are doing these initiatives more or less continually. Advanced functionality (like personalization or lead nurturing) is not something that you get right in the initial deployment and then put on auto-pilot. You only get results when you actively use them. Incidentally, most systems integrators are primarily focused on content modeling and template development. They are not very good at the using advanced functionality within the context of a real content strategy — like looking at the full lifecycle from planning to analyzing the results.
Most organizations are really far from this level of operational maturity. They probably know these truths to be self-evident at some level; but they are all too willing to suspend their disbelief when a software vendor tells them that, with their solution, advanced digital marketing is so easy that even the CEO could do it. On the other side, I can see the temptation of the software vendor. A lot of these customers are still justifying budget for software with an ROI based on cost savings. Better tools equals less effort equals smaller team. Would you risk being the only vendor in a selection saying that your solution will raise operational expenses by needing to hire more staff?
As an industry, I think we would all benefit if we focused on promoting vertical adoption by:
Until we improve vertical adoption, the CMS industry will continue to run around in circles and customers will never get the results that they hope for.
Oct 30, 2006
Lisa Welchman has a great post on CMS Watch Trend Watch that describes the phenomenon of Web Content Management System buyers seeing a CMS as just a wrapper around the WYSIWYG editor. I can't even begin to say how true that is. Recently, a client was having his first look at the WCM system that we were implementing (after not participating in any of the prototyping or reviewing the incremental builds that that we had been doing over several weeks) and he left me a voicemail saying "the administrative interface is all wrong. We have major problems." As you might expect, I was very concerned. Anyway, it turned out that all of his issues were around the WYSIWYG editor. To him, the WYSIWYG editor was the CMS. It turned out that it was misconfigured and everything is OK now. Phew! That would have been bad.
Way back when, I remember the debate over WYSIWYG editors between the CM purists and the user facing pragmatists. The purists didn't want any markup (formatting) in content and the pragmatists were trying to appease users who wanted to make web pages with as much control as writing a document in Microsoft Word. The compromise was to give users free control over small portions of the page. However, given the attention that the editors are getting, it appears that the balance is shifting.
I think this is natural as WCM goes "down market" to run small web sites that had at one time been just static HTML. Small websites have fewer authors and less content so they do not need as much centralized control or content reuse. Strict adherence to content management best practices is less critical. All that is needed is a reduced dependence on the HTML literate webmaster. The CMS becomes more of an HTML editing and deployment tool. Ironically, the HTML savvy webmaster that managed the static site frequently becomes the sole user of the CMS. I would argue that this is not true content management. But maybe not all CMS buyers need to manage content. They just need to manage their website. Still, if you are spending hundreds of thousands on a CMS, presumably you have real content management needs and you should be looking at more than just the WYSIWYG editor.
Aug 15, 2006
I am going to stop using the word "intuitive" when I am talking about software and I think that everyone else should too. Judging from a Google search on my blog, I seem to be doing a good job of not abusing the word so far. But I want to use "intuitive" even less. The problem is that when people say that something is "intuitive", they are implying that it makes intrinsic sense to any rational human being. However, what they really mean is that it makes sense to them based on their own frame of reference. This is, of course, irrelevant to anyone who does not have the same exact frame of reference. So rather than say something is intuitive, why not say that it would probably make sense to someone that is used to using software XYZ and not be so egocentric?
I understood this point at some level for a long time but it became really obvious to me recently when someone I know was having a really hard time learning to use a Mac after years of being a PC user. I am not naming names because it is so uncool and potentially socially alienating not to gush over the Mac UI. The Mac and Windows are similar in some ways and, in others, they are very different. Those differences are extremely disorienting and frustrating when all you want to do is move around the computer with the instinct that you have developed over the years from using another platform. You learn to use a computer. You are not born with the instincts to use one. Therefore, it is not intuitive. Duh.
That is not to say that a software program cannot make itself become more learnable by behaving consistently across its different functions. I think that is what people sometimes mean by the word intuitive - a user can infer how one feature is going to work based on behavior of another feature that the user has already learned. For example, if the application always has right-click context-sensitive menus, a user trains himself to right click when trying to execute a function. However, there is no innate, primordial instinct to right-click. The user is must making logical assumptions after getting over an initial learning curve.
Despite claims of intuitiveness and user-friendlines, usability is probably the single most vexing issue in the content management industry. Most people don't like their content management tools and undermine their employers content management efforts by working around them. So what can be done to solve this problem? If you let go of the intuitive myth, you can go in two general directions: you can accept that people will need training on software; or you can try to mimic things that you know your users are familiar with (in other words, piggy back off of someone else's training). Both of these have their issues and chances are, you will have to do a little bit of both.
Over the past few years, we have been conditioned to expect that software can be deployed without training. Years ago, when I worked for relatively large companies there were regularly held training sessions on how to use critical business applications. I see less of that now because of standardization on suites like Microsoft Office. If you don't know how to use MS Word, you probably wouldn't get past the first interview. There is also now a critical mass of experienced users so that a newbie can "groundhog" over his cubicle wall and ask - so training is happening, just not in the classroom. Public facing web applications are even harder to train people on because new users arrive totally spontaneously. Online help somewhat solves the problem but people seem to be reading this less and less.
The mimic strategy is in tension with the software industry's culture of innovation. Companies want to differentiate. They want their customers to upgrade to new versions. Software designers and developers like to be clever. Users don't want to be clever at all. They don't want to think about the tool. They are totally focused on their business task.
Back in the early days of the web, things were really chaotic with web designers actively trying to break conventions and build something unique. This was when you had all those websites with tiny text and icons meant to be cryptic. For a little while, that was OK because the web was recreational and users were into exploring and appreciated the reward of finding hidden gems. Now that the web has matured into a business tool that people need to use to get their job done, websites look a lot more uniform: tabbed or left side navigation, a footer of informational links, search and help on the upper right. While not truly "intuitive" these designs are familiar to someone that is used to visiting websites. Designers have learned to focus their creativity to solve specific problems within a uniform framework.
Both of these practices can and have been applied to content management interfaces up to a certain point. You see contextual help and you see user interface patterns modeled after familiar business applications such as Office. You even see content management software using familiar external tools as work environments - for example, authoring in Word, Outlook integration, dragging and dropping files like in Windows Explorer. However, these strategies tend to break down when dealing with concepts specific to content management. For example, versioning is totally beyond the physical desktop metaphor on which most desktop applications are based. Most users don't get versioning because it deals with a fourth dimension (time) that is not well represented in a three dimensional virtual space so they create multiple copies of the document with different file names. Workflow state is another concept that is difficult to represent with familiar tools (although a common hack is to use folders). So are the concepts of metadata and single sourcing. CMS that embrace the familiar tools strategy tend to under-deliver or under-emphasize these content management features.
Here are some adjustments that I think that the content management industry needs to adopt rather than go on believing they can independently innovate away the usability issue.
-
Accept that content management is a discipline with some skills and concepts that practitioners need to learn. This is why CM Professionals was created. Vendors have to stop training these concepts just within the concept of their toolset.
-
Participate in User Interface standards that address content management best practices and theory. Someone started a working group on OpenUsability. It is probably not going to go anywhere unless the commercial vendors get behind it.
-
Create a standard CMS enabled UI. This is the idea behind the Apogee Project. There are also extensions to Windows Explorer that add additional right click menus for content management tasks. For an example of this, check out the Tortiose CVS and Tortoise SVN projects.
-
When selecting a CMS, take into consideration tools that the intended users are used to using right now. Show them the UI. It will either resonate with them or not. This is why there are so many different CMS out there. Each one is the result of someone (or a group of people) solving a problem from their own frame of reference.
-
Do not give every user group the exact same tools and expect them to be equally happy with them.
-
Accept that you will need to customize t
he user interface to make it work within the users' business context.
A couple of trends make me think that these adjustments are within reach. The rise of open source opens a number of possibilities: the ability to experiment with different solutions, the ability ot customize, and the value that the open source community places on standards. Also, content management functionality is being pushed down into the infrastructure layer where it can be more ubiquitous. Eventually, features like versioning, metadata and workflow state will become better integrated into the baseline computing environment that everyone is familiar with. I know that there will be compromises between purist theory and practical implementation, but it is a step in the right direction.
People don't make intuitive user interfaces. Someone's frame of reference makes an interface appear intuitive. Software makers need to pick a target audience and leverage what these users already know. Users need to expand their frame of reference to include content management concepts. Consultants need to really understand where the users are coming from and use that as a starting point for designing the solution. It is just intuitive. DOH!
Sep 08, 2005
While catching up on my Blog reading, I noticed this post on CMS Watch which links to an InfoWorld case study of a project that was almost ruined by lack of user testing. I very much agree with Tony Byrne's point that usability is one of the biggest issues in the CMS industry and I am happy that Tony is being so vocal (one article, another article) about defining the problem and challenging the industry to fix it. James Robertson, of Step Two Designs, has also added his respected opinion to the discussion with a fine article on the importance of simplicity in large CMS deployments.
A CMS is one of those applications like a word processor where many users, often non-technical users, need to become proficient with no little or no training to get their job done. Frequently CMS users are under time pressure and, if it is quicker to misuse the tool than to use it properly, the tool will be misused - or, if possible, not used at all. Content Management is a very broad term but I think this applies to everything from this blogging software that I am using right now, to a Web CMS, to a document management application. A CMS user wants to publish what needs to be published with as little overhead as possible. As a matter of personal pride, author's want their content to read well and look good. But other than that, the less time spent with a CMS, the better.
Producing content is also a creative process and content creators don't like to feel like data entry people. CMS users don't like to waste time tagging their content with metadata. They frequently rebel when forced to fill in structured forms and give up the artistic license to determine how their content will be displayed.
But on the other side, are the consumers of the content. They are important users too. They want to be able to find the information they need (which requires good metadata) and get in a format that is accessible to them. The latter requires separation of content and layout so that content can be re-purposed to different formats. As Yair Dembinsky eloquently put it in a post on the CM Professionals mailing list:
Our main focus should be the target audience - how they want to consume the content: In some cases - they want a well written article, and in others they want to be able to retrieve small but relevant chunks of information. Writers and editors must adapt to supply the specific need of their target audience.
So, the CMS is stuck in the middle between the content contributors and managers and the content consumers. Both sides want their jobs to be easier and simpler. Some of the answer lies in automation adding information (metadata) and structuring a content asset for better reuse. But that only takes you so far. We don't want to rely on the system too much to interpret our content and make false assumptions. Workflow helps too by creating an opportunity to divide responsibility between those who create content and those who organize and classify content. However, companies typically under-invest in this area and do not dedicate editors to this task
At the end of the day, the CMS will always be a compromise between the efficiency of creating content and the utility and re-usability of the content. Content Management is a challenging problem. So what can we do to make it better?
One initiative that is just starting a new project on Open Usability called CMS User Interface Guidelines. I hope that this project gets some traction because I think there is a lot of potential here. Unfortunately the cards are somewhat stacked against it because usability is such a nebulous thing and people are more likely to complain about usability than to do something about it. I think success will lie in the ability to set down some common metaphors and idioms that users are familiar with so that they can quickly get their bearings in the application.
Like Microsoft Windows or hate it, there are some conventions that make all Windows applications familiar enough so that a new user does not get totally lost. For example, the File Menu is always on the left, Help is on the right. Ctrl-C is Copy, Ctrl-V is paste (except when you are using Intuit Quicken where they are "Categorize" and "Void". Grrr. How can you people call yourself Intuit!?). Microsoft also achieved high level of adoption for its Office applications Word and Excel by copying the UI functionality of then market leading applications WordPerfect and Lotus 1-2-3. Consistency is the key. An application does not have to be intuitive if all the users are familiar with it. Remember going to a travel agent not so long ago and watching him or her zip around the SAABRE terminal with two character codes?
Another area where things can be improved is the standardization of terminology. Different CMS products have different names for things. For example, in response to another CMS list request for different names for sub-components of content, Tony Byrne of CMS Watch listed the following:
-
Elements
-
Snippets
-
Objects
-
Placeholders
-
Pagelets
-
Styles
-
Chunks
-
Briicks
-
Parts / Fragments
-
Nodes / Fields
-
Components
Standardization in naming, design, and behavior will not only help CMS become easier to learn; it will also create a community that crosses organizational boundaries and includes both developers and users that can work together to solve this very difficult problem.
While standardization will help improve "out-of-the-box" functionality and the underlying framework of the application, in reality, CMS are usually heavily customized to work within the business context (perhaps more than they need to be, but that is another story). This is where the CMS is not a build vs. buy, it is a build vs build AND buy. Most CMS projects spend 2 to 3 times the license cost on integration. To get these customizations right, I would say usability testing is an understatement.
The worst thing you can do is spend a lot of time on gathering abstract requirements and creating abstract designs, then select a product, then do detail design with the users, then implement it, then test it and finally run it through usability testing. Any issues found that late in the process will be too expensive to fix - too expensive because you are at the end of the project and you are out of time and money. When you test this late in the game, you are basically just hoping that the users just rubber stamp what you did. And if that is the case, why test at all?
What I would recommend is have usability testing drive the design rather than validate it. Select a product, install it and show it to the users in its out of the box state. Ask them what is wrong with it. Prioritize a bunch of modification requests, implement them, then show the application to the users again. Repeat this cycle until the benefit of the modification is outweighed by the cost of implementing it. This approach, which, for lack of a better name, I call "change driven development" (a nod to Peter Coad's "Feature Driven Development"), gives business users a chance to experience the default behavior which may not be that bad - especially if not modifying the feature leaves more budget for improving another feature. In
addition to helping business users make better choices in design, involving the users at this stage of the project builds their comfort level and ownership of the application and leads to less complaints after it is deployed.
Business users know their job. They know the tools that they use. But one of the things they have the hardest time with is imagining something new and thinking abstractly. They are too immersed in the concrete of their day to day to think outside of their box. They are even worse at understanding the scope implications of their requests. So the result of waterfall approach to CMS customization is that we force users to think blue sky and, just when they get comfortable, we slam them down with admonitions of scope creep. Then we ask them to test the application for usability and we ignore their feedback. This is a recipe for failure and disappointment.
Nov 30, 2004
I just just read Jeffrey Veen's essay Making A Better CMS and was struck by his intentionally provocative claim: “Most open source content management software is useless. The only thing worse is every commercial CMS I’ve used.†In the essay, Veen admits that his sample is limited to the out of the box installs that he was able to try on OpenSourceCMS which, although he does not say, is limited to a few LAMP based community CMS products.
I will refrain from my impulse to Fisk this article because I feel like people who make a living by complaining about software do have something to add to the dialog. I do have issue with calling a whole category of software “Useless†because a couple applications do not meet his vision of how software should work. CMS is a hard domain because these systems are used in such different ways by such different users. There are constant trade offs between "ease of use" and complexity, "out of box" and flexibility. I can see why Jeffrey is frustrated by everything he has not written himself. On the bright side, with Open Source, we have the ability to change what we don't like.
Here are some valid points that Jeffrey raises:
-
"Write task-based documentation first." A couple of products do this really well. For example, Plone's How Tos are excellent. However, some products have almost no documentation at all. I think this is a great area where business users can contribute to the OSS movement. We have all these excellent writers using content management systems. Rather than complain, ask questions and write documentation.
-
"Why do you insist on Web sites that have 'columns'?" Layout and positioning with CSS is relatively new. Most websites don't do it. There are some incompatibility issues with older browsers. Still, I think this technology makes leaner and easier to manage pages and newer software has a great opportunity to use it.
-
"Make it easy to install." One of the great things about OSS is that it allows people to freely download and demo it (without even filling out a form and getting hassled by a salesperson). Creating a simple and bullet proof install routine is critical to driving adoption. Some products are better than others. However, my experience with most commercial systems (CMS, and other server based software) is that they don't even try to be easy to install. In fact, most big software vendors have installation engineers that go on-site and install the software for their paying customers (not for free either). They rationalize this with the argument installing is a one-time thing and varies from environment to environment.
-
"Users of a public Web site should never, never, be presented with a way to log into the CMS." Good point, I see that Jeffrey can write his “own templates, and even dip into object-oriented Perl and Python.†He should be able to take care of that.