Inside Out

I like shy people. It could be some of that old stuff about still waters and their relative depth, or maybe it's just because I'm so extroverted that I seek out a yin to my yang. In any case, I often forget that many of my friends are shy until someone remarks how arrogant they are. I used to think this quick misjudgment occurred because these friends also happened to be pretty females, but I found that the same nasty remarks would be made about male friends and those with less intimidating appearances. It seems that when shy people are slow to smile, respond, chime in, etc., their reticence is often misread as snobbishness. Go figure.

I won't go into book cover-judgment platitudes here; rather, I'll suggest thinking a bit about the whole what-you-see-is-what-you-get proposition. In life, it usually means that just wanting something (or someone) to be one way or another won't make it so.

The problem with the assessment phase, I find, is spin. Like cars: one person's standard is another's option—and software's no different. Despite thorough research, testing, product comparisons, and all the requisite hoop-jumping, every purchase and installation brings with it unexpected, even unwanted, attributes, features, challenges—problems by whatever name. Sometimes what you saw is what you ultimately do get—but only if you are willing and able to pay stiff fees for continued consulting services or IT support.

We review a fair amount of software and information products here at EContent; we like to have a hands-on understanding of the tools of the content trade. In the past few months, I've used five blogging apps, two enterprise wiki tools, an out-of-the-virtual-box site builder, a collaboration tool, and a number of fee-based information services. (This does not take into account product demos and the applications I use to do my day-to-day work.) I'll wager that my recent experience ranks right up there with many of those making purchase decisions for tools like those covered in the pages of EContent.

One of the things I found in my recent forays into software testing is that those tools almost universally represent efforts to broaden customer base by improving ease of use. To accomplish this, they incorporate a remarkable—and confusing—breadth of variation in the use of WYSIWYG features. I read this particular acronym in zillions of press releases, so I know that it has become somewhat of a given in terms of user expectations: If I want to bold text, I will be able to highlight it and click the B. For italics, same process, only with the I; U for underline . . . and so on. Only it seems that there isn't really a standard for the implementation of said WYSIWYGedness. In one tool, style menus work just like Microsoft Word (for better or worse, the familiarity-breeds-contempt standard). In another, the symbols are subtly different and I have to play around to figure out what will do what; in another, I click and it inserts the HTML code that causes bolding, for example, to appear on a Web page.

This last, to me, runs counter to the whole WYSIWYG precept. The point, I thought, was to avoid requiring the user to have technical knowledge of things like HTML. With this last variation, highlighting the word Bold and clicking that B might result in the text looking like this: *Bold*, and not actually looking Bold until I save, or even until it goes online. A small issue, maybe, but extend it to every other aspect of formatting, and you get some formidable strings of HTML on your novice user's screen. While it is true that they don't actually have to know HTML to make things happen, the mere sight of it is enough to drive the true beginner away.

Frankly, you can stick to selling cars to mechanics (and those willing to employ full-time professional help dedicated to automotive care and feeding) or you can make machinations blissfully invisible to those who'd rather not have to think about them and thus broaden your user base to seriously successful levels. I'm here to say that somewhere in between is nowhere, man. And while you are making tools perform fundamental tasks simply for the user, don't fear a bit of standardization. Making basic functions work the same way as comfortable, familiar tools doesn't make you ordinary (and, conversely, coming up with your own spiffy jargon and icons for every little thing does not make you special). You've heard the one about reinventing the wheel, right? Not only is it a waste of time, but most buyers don't want to have to be bothered to learn the physics of your brand new bag, particularly if it does not, in fact, do something different and better. If it makes text bold, call it bold and mark it with a B.

Where I see a charming shyness, others see aloofness, but software does not benefit from the mysteries and ambiguities that color our interpersonal relationships. Many users aren't going to take the time to really get to know your tool if it is intimidating on the surface.