Scalability
Interface Scalability
by Jeff Freund
16-Jul-2003
>
When it comes to web content management, what's the first thing that comes to mind when you hear the word "scalability"? For most, especially those like me who are of the technical persuasion, it probably conjures up images of servers -- lots of servers -- along with bandwidth, rack space, and all those other critical components of building a reliable infrastructure.
This type of scalability is undeniably critical when implementing a web content management system and certainly a topic worthy of much discussion. However, this article is about a different kind of scalability -- something I call "interface scalability". Just as your content management infrastructure must scale to meet your growing web publishing needs, the interfaces to your web content management system must scale to meet the ongoing needs of your organization and editorial team.
Scalability problems in your CMS technical architecture will lead to slow page loads, errors, and disgruntled readers. Problems in the scalability of your CMS interface, in contrast, will lead to editorial process bottlenecks, dissatisfied users, stale content, and ultimately, dissatisfied readers.
Engineers tend to think only about technical infrastructure, but both types of scalability directly contribute to the success or failure of your content management system.
So, what exactly is "interface scalability"?
The easiest way to understand interface scalability is to think through a simple question about your content management system: what happens to my job and the job of the editors and authors when the amount of content in the system increases two-fold? How about five-fold, or ten-fold, or fifty-fold? It's a question not many think to ask before making a CMS purchase, but it's a revealing one. Many interfaces work very well with small amounts of content, but begin to break down when the amount of content in the system increases.
The concept of interface scalability is especially critical in content management systems where web browser-based screens predominate.
Web-based interfaces offer all kinds of benefits, like enhanced ease of use and removing the need to install additional software on the client-side. However, browsers are extremely limited in the types of interface controls available when compared to an installed client, and these web interfaces must also work well despite the constraints of network-based application data transfers. This is not a trivial challenge, especially when it comes to providing a clean and intuitive interface that allows non-technical users to navigate massive amounts of data.
Oh no! My interface failed...
Interface problems are often hard to identify, and can progress slowly over a long period of time. The symptoms tend to be more subtle than the systemic slowdowns associated with technical scalability problems, but they can become just as insidious.
Interface bottlenecks typically result in creeping inefficiencies in editorial processes. Maybe it takes too long to find content because, while the system response time is fine, there's simply too much stuff to wade through. Perhaps some operations you would like to make in bulk can only be conducted one at a time. Or maybe there isn't an easy way to see who is working on what, so sorting out the week's responsibilities takes editors several rounds of the kind of off-system emails and face-to-face meetings that the CMS was meant to obviate in the first place.
Below are four of the most common types of interface scalability problems, and some tips on how they can be solved.
1. I have to do this again, and again, and again.
Doing operations in bulk (like deleting content, moving it to a new section, or copying a website) is one of the biggest interface scalability pitfalls of CMS applications. Browsers are extremely limited in the interface controls available, and the basic browser-server web architecture presents some significant challenges in designing application flow models.
Due to the design challenges inherent in creating intuitive controls for bulk operations, many applications opt either to limit bulk operations or instead design manual, cumbersome interfaces that get the job done, at the expense of intuitiveness.
As a simple example, if you are working on a browser based CMS system that allows users to import images into its repository, it is most likely very straight forward to import a single image. [See an "Add-Image" screen from Midgard 1.4, Ed.]
However, is there a mechanism for importing multiple images at one time? One possible work-around here is to by-pass the standard interface, and rely on another tool like FTP to move multiple files at once. However, in doing this, one has removed the user from the standard interface, making him rely on outside technology. A more elegant solution might be the inclusion of a simple applet or ActiveX control that fits into the standard flow of the application but allows for the more powerful bulk operation.
Such bulk operation issues are a classic example of an interface scalability issue because they typically remain invisible to everyone until large amounts of data need to be loaded into the system. This requirement often emerges belatedly, after the initial version of the CMS application proves its worth on modest amounts of incremental content additions and changes. .
A perfect example of this comes from an application many of us have used: Microsoft's Web Outlook (the web based version of the standard Outlook Exchange server client). In the desktop Outlook client, it is very easy to move a bunch of emails from one folder to another. You just highlight them all and drag them to the appropriate folder. However, in the web-based version, one must open the email itself, and then assign it to a new folder. So for every email you want to move, you must open it, click the move button, select the destination folder, click move, close the email, and then move onto the next.
All these repetitive steps could be solved by simply allowing the same check boxes for deleting multiple items to be used for moving those items as well. These types of problems abound in web content management systems.
2. Please only show me what is mine
The "show me only my stuff" concept materializes in two distinct areas:
- first, the content a user is supposed to be working on, and
- second, that collection of all the things that the user is allowed to work on.
Without such controls built into a system, users are likely to spend a lot of time wading through content they don't care about to get to the content that they need to get their job done.
The good news is that most web content management systems have tackled this problem in one way or another. It is very difficult to find a CMS on the market in the last 18-months that does not have at least simple workflow (which allows for currently assigned tasks to be visible) and permissions (which allows unnecessary features to be hidden).
How systems implement these conventions, though, can have an enormous impact on interface scalability.
With regard to the first problem, a workflow mechanism is an absolute requirement to provide structure and ensure that everyday users interact with the content management system efficiently. If Bob is currently assigned the tasks of editing ten articles, then these ten articles better be organized somewhere where he can act on them quickly without clicking through all the other items waiting to be edited by Sue, Bill, and the rest of the editorial team -- even if these articles are on diverse topics and ultimately scattered across the website.
If great care is not taken in developing the interface for even simple workflow features, though, creeping inefficiencies can result. Some CMS packages, for instance, introduce the concept of informal, intrastate collaboration, which allows multiple users to collaborate on a piece of content regardless of its state. As the number of participants here grows, the interface can grow unwieldy quite fast (interface scalability). The solution in this case: make sure to thoroughly test all of the "advanced" features to see that they do what they're supposed to do and don't end up introducing more trouble than they're worth.
The second part of this "show me only my stuff" concept is that your content should be segmented (just as your company or team is segmented) into separate functional units.
Permission and security access should be effective in providing guidelines as to what a user can see and do based on his role within the organization. Likewise, permission and security-based access should be equally effective at preventing a user from seeing those things which they can't do or don't have access to.
Unnecessary controls (or content that the user does not have access to change) not only clutters a user interface, but I believe can actually impede a user from getting her work done by providing too many options (think the feature creep in late-model Microsoft Products like Word).
As in the previous case, even rudimentary CMS's tend to do a reasonable job here. Permissions-based restrictions on interfaces and filters on content is not new (a strong case could be made, in fact, that many systems go overboard in this regard, giving customers much more granularity in assigning permissions than they really need).
But, these conventions have still not completely eradicated one of the most serious CMS interface scalability issues. Permissions can only get you so far in presenting the content you're likely to need in a system, and there is often a substantial amount of hunting that must go on even with permissions-based filtering in place (especially for the power user). Something called behavior-based filtering can get you quite a bit further.
Behavior-based filtering takes cues from how the user or group interacts with the system to help get them to what they need to quickly. For example, a "recently-opened" list is a very simple convention that can save enormous amounts of time. A "most-accessed" list, by group or individual, is also particularly handy.
3. Next page, next page, next page, next page
Let's consider a basic CMS interface display that can also be found in a broad range of applications, namely the presentation of a list of items. Maybe it's your email client's inbox or maybe it's a list of "news articles" in your content management system. When displaying only 10 items, everything is viewable at one time. You don't need anything else for this display function to be 100% effective.
If the interface is speedy displaying 10 items, it will likely be nearly as fast when displaying 100 items. But will it be as usable? If there is one particular item you seek, chances are good that it will not be in plain view as soon as you open the display.
This is the point at which simple sorting and navigation features are most effective. Make sure that your CMS control panel can sort on the basic attributes like titles and authors, so that subsequent scrolling through a few pages will make it much easier find a particular item.
Specific features that provide help in this scenario are common place in most of today's desktop and web applications. A user should be able to sort on all columns of basic list displays, not just the "primary" one. In a desktop application, scroll bars allow a user to scroll through lots of data, but in a browser based interface, I think that the data is best split into discrete "pages" that then allow the user to quickly jump from one page to another through the use of "next" and "previous" buttons -- or better yet, the ability to select how many list items a query will return (e.g. 25,50,100), like the major Search Engines allow. Consider this example.
At some point, this process will become over burdened -- think of what would happen if you slack off on your diligence in sorting your emails and let your inbox reach a few thousand items. Even with sorting, and the ability to jump through pages, you could still be ten clicks from finding the email you are looking for. While the rudimentary interface tips listed above can help here, something else is needed.
Enter the fourth interface scalability challenge: search and retrieval.
4. Where are my keys?
I spend approximately 17 hours a year looking for either my wallet or my keys. I don't have a short-term memory problem, live in a huge mansion, or carelessly scatter my possessions around. It's just that in the rush of daily life, I frequently forget the specifics of when I threw my keys where, or what pants I was wearing the last time I had my wallet. It's not like I ever lose them completely - they always turn up, sometimes the first place I look, sometimes the 40th place I look.
You don't want finding that one piece of content in your content management system to be the same frustrating, time-consuming process as looking for your keys. An effective retrieval system is an absolute must when it comes to a scalable content management system application interface.
Retrieval is actually a tricky proposition when the skills and knowledge of your user base span from very technical system administrators to less technical authors and editors. Each user will have preferences about how to go about finding what he is looking for. Some users will prefer the process of searching for keywords in titles, other will like to find things by ID numbers. Some will like to do broad searches and then scan through the results, while some will like to perform a sequence of iterative searches until only 3 items are in the results.
To be an effective tool, it doesn't matter how the user searches -- only that she finds what she is looking for quickly. To accomplish this, a user should be able to search on a broad range of attributes:
- Keywords in titles and summaries
- Full text searching in the content
- Metadata or categorization information
- Workflow status
- Content types
- Published site location
- System ID numbers
- System actors (e.g. individual authors, reviewers, etc.)
- Date ranges
See an example of this.
Additionally, there will almost always be some users who need to perform the same set of searches over and over again (for example, perhaps they are in charge of looking at the content that expires the following week). Sound interface design would dictate that something be done with such repetitive searches to help this person avoid having to repeat the same searches every week.
The most common solution here is to allow users to save searches and use them again, or perhaps (even more elegantly) to turn saved searches into customized views that are presented as standard and personalized navigation items for each user. (Check out this example.)
Conclusion
No software vendor or development team can envision every way in which a content management system will be put to use. After all, a good content management system is essentially a framework on which to build a unique application, to facilitate (not dictate) existing processes. Good systems provide structures and guidelines, but you never know exactly how a system is going to be used.
As a result, CMS interface designers expend significant effort to ensure scalability of the product's interface in terms of both the expected and the unexpected. I submit that this effort is well worth it.
If you are evaluating CMS products, see if the vendor can show you the interface performance in an implementation comparable to where you believe your needs will be several years from now (or better yet, 10 times where you believe your needs will be several years from now). Also talk to someone who uses the system every day. There is no greater source of information regarding the performance of your interface than those who use a system daily as part of their primary job function -- whether they are interacting with a system that helps them manage 100 or 100,000 pieces of content.