Tables get a bad rap—especially in the Web world where, once upon a time, Web developers misused them for HTML layout. But tables are still very useful for the purpose for which they were originally intended—a way to show relationships among discrete data points. From a user assistance perspective, we deal with tables in two contexts:
user assistance—Tables can present information or instructions in our documentation.
user interfaces—Tables can display information within a user interface itself.
In this column, I’ll review some of the basic principles of good table design from an information developer’s perspective, then discuss their visual design and interactivity. These principles and my examples provide the bare essentials of table design. When designing tables, a key information design objective is keeping them simple, so if you start needing more than this column provides, you might be making things unnecessarily complicated for your users. Read More
Many of us are more comfortable communicating in words than in pictures. For example, user assistance writers are by nature and training writers, so they understand words and are adept at using word processing and publishing tools. Writers use lexicentric tools not only for creating and delivering content, but also as cognitive tools—that is, tools that help them think more clearly and efficiently. Thus, a user assistance writer might create a user-task matrix or take advantage of a word processor’s outline view when creating or evaluating a document’s structure.
However, we could also use a number of visual techniques and tools—not only for generating content, but also as cognitive and analysis tools. Unfortunately, these visual methods and their respective tools do not get much attention, and many writers don’t use them with the same comfort level they do tools that let them manipulate words. As Figure 1 shows, some writers hold onto their lexicentric world view, sometimes to their detriment. Read More
One of the more interesting tensions I have observed—since getting into user experience design about five years ago—is the almost sibling-rivalry tension between UX Designers and User Interface (UI) Developers. At the heart of the tension between them is the fact that most UI Developers consider themselves—and sometimes rightfully so—to be UI Designers. The coding part is like Picasso’s having to understand how to mix paint. It’s not the value they add, just the mechanics of delivering the creative concepts.
When I worked on the Body of Knowledge Task Force for the Society for Technical Communication, the interesting question we wrestled with was: What value does a technical communicator add above what an engineer who writes well offers?UX Designers or UX Architects have the same problem to solve: What value do we add that differentiates us from a UI developer who is user focused? This question strikes to the very heart of what differentiates us, as UX professionals, from UI Developers. If we don’t provide a compelling answer, the only one left is that they code and we don’t. Hmm…, not the kind of value proposition I’d be comfortable with in this economy. Read More