AskTog: Interaction Design Solutions for the Real World
 
Interaction Design Section   Living Section   About Bruce Tognazzini
NN/g Home > AskTog > ReaderMail > December, 1998 Ask Tog, December, 1998

Reader Mail

This month's mail:

The mail this month came in two flavors: Stuff about the Outside World and stuff about how badly AskTog sucks. I'm actually rather happy about the latter. I started AskTog so I could get a real feel for building an entire website, rather than just being the designer on a much larger team. I intended to and have experimented with different approaches, knowing I would have the best (and most vocal) professionals in the world, looking over my shoulder. When I do right, you let me know. When I do wrong, you really let me know.

The other reason I'm happy about the volume of mail this month is that it reflects what the log files bore out—the AskTog circulation has gone up another 10-fold, thanks to you folks getting the word around. Thank you for that.

I've made more foundational changes to the webzine this month than at any time in the past, all in response to your suggestions. (Even more changes are planned.) And now, on to the mail...

HCI Courses

In your November reader mail, Stu wrote, "Why aren't there more HCI jobs out there? I graduated from an HCI course 3 years ago...."

I'm wondering how I can find such a course? Even though I've been doing HCI stuff for a long, long
time, I can't help but think that maybe I can learn something new.

Fulko Hew
Canada

My old friend Ben Shneiderman and his students at the University of Maryland have come to your rescue. They've established a new Guide to Usability for Software Engineers site (GUSE) that includes a listing of colleges and universities offering degree programs in Usability Engineering and Human-Computer Interaction. You will find this site listed under Resources in the AskTog left bar menu from now on. You will find the University of Toronto listed in Canada.

Dave Barry

I've greatly enjoyed the story of your trip to Japan. I also recommend Dave Barry's Guide to Japan which you have probably seen already. Dave Barry is probably a large reason for my cheerfulness—if I am laughing out loud I'm probably reading Dave Barry.

Hugh F

Dave Barry has kept me awake long into the night on many, many occasions: I just can't sleep through my wife's cackling. Seriously, though, Dave Barry is probably the most consistently funny man alive. Check out a few of his columns, then follow this link to the Dave Barry corner of the AskTog discount bookstore.

Are frames evil?

I started my web site merely as way to manage my bookmarks and share them with my relatives. As the site grew, I added frames: an unchanging Table of Contents frame on the left and a changing content frame on the right. Then Jakob Nielsen and others persuaded me that frames are bad, so my site is now frame-free.

Of course, when I had frames on my site, the only pages I opened in my frames were my pages. I always opened other people's pages in their own browser windows. Opening someone else's page in your frame is more than "annoying"—I call it hijacking.

Anyway, I was wondering whether you are as dogmatic about frames as Jakob is.

John Huber
www.mindspring.com/~jrhuber/

Not quite, but close. Certainly on a personal site, frames are just fine. I would still avoid them on the home page, where people are most likely to bookmark your site. You don't want them bookmarking a sub-frame.

On a commercial site, I would avoid frames unless you absolutely, positively need them. Not only do people end up bookmarking subframes, they end up printing menu or title frames instead of articles, and those with small screens end up with 50% of their screen real estate given over to spurious scroll bars. Then, when they find something they really like and try to send the page to a friend, they end up sending your footer frame by mistake, an embarrassment for which they will not soon forgive you. (Maybe I am as dogmatic as Jakob.)

The most important advantage frames offer is that they let you keep variables around while swapping in new content. (While cookies can also carry out this function, they should be avoided for any sensitive information, as they can persist after the application has been exited.)

Historically, frames also offered the website builder an easy way to update content across web pages. For example, the left bar menu on AskTog appears, as of this writing, on more than 45 pages. Consider the work (and errors) that would be involved in manually updating each of those pages every single month.

With several of the new editors, however, website builders can gain this advantage without using frames. GoLive's CyberStudio, for example, has the concept of "components." You place a component object where you would otherwise have a frame. Then you create an HTML file exactly in the manner you would a frame-content file. In AskTog, the left-bar menu is such a file. Whenever GoLive sees me update the left-bar menu file, it automatically updates each instance of it's HTML on every page where I've indicated it belongs.

If you look at the source of this page, you will spot:

That's CyberStudio's code that tells it to place the "CyberStudio Object" (csobj) called LeftBar.html into place.

The only advantage that frames would offer over this scheme is that the left bar menu wouldn't scroll when this column was scrolled.

John Huber's site, by the way, is a really excellent example of a personal home page. I particularly enjoyed the humor section.

Are static tables evil?

Did you know that www.asktog.com cannot be comfortably viewed on a 14" monitor?

I was showing the site to a class I was teaching via an LCD projector that only does 640x480 and was surprised to find that it didn't fit on my projector.

I was kinda surprised.

Brett T Gross

Brett, I'm sorry to have embarrassed you. I have been trying to see whether it was possible, with Herculean effort, to actually control the look of HTML tables. I, unfortunately, chose to optimize for 800x600, assuming that all my readers would have large monitors. Not only did this assumption prove false, my efforts to control tables didn't work. (It doesn't really matter what you do in your source code, the various browsers will all display your tables exactly as they feel like it.)

I have now gone through all 103 files on the site and made every table dynamic.

Are type size styles evil?

Your column sounds like it would be an interesting read, but unfortunately the type is way too small! And worse, it's unresponsive to my browser's font-size controls, so I can't adjust it to suit my on-screen comfort level. Is that 12-point Times? Yuk! If you're going to force a font on users, at least consider Georgia, designed especially for on-screen reading by the great type designer Matthew Carter.

Your use of CSS is admirable in theory, but, in practice, I think that this particular application of it qualifies as CSS abuse. Why limit your site's usability for the sake of "designerly" control over the presentation of its content?

Mark

I was only trying to help! Really! Since the default font size on a Mac is different from that on Windows, and since the real font size on Windows depends on the resolution that user has set in the control panel, it seemed to me to be a good idea to specify 12 point type. That way, no matter what system or what monitor configuration, the type would always be readable.

Unfortunately, just as with table configurations, the browsers pretty much decide what type size they feel like showing today. Sometimes it's 24 points, sometimes it's 1 point. Therefore, I've stripped font size out of the body and <td> style specs. They'll stay stripped out until such time that setting a font size of 12 points results in a font size of 12 points.

My friend, Dave Eisenberg, wouldn't leave it at that, either: "You should be able to set your browser to say 'use my settings and ignore those in the document,'" even when the author has used style sheets.

Are <a> tag styles evil?

I always find something useful when I surf around your site, but for the last several issues it has been very hard to see the links in your text because the color contrast is not great between links and the black text. Not a good idea to make users wave their mouse around wildly waiting to see the hand indicator show a link!

Chris Lott

OK, I'm guilty. In the early days of AskTog, I left links the color God intended them—Blazing Blue. As the site grew, so did the links along the left bar, so many that the page became entirely too busy. In an effort to "calm it down," I followed the example of many sites in honoring the "underlined-text is always a link" half of the contract, while breaking away from making everything Electric Blue. I had rationalized that people would know that underlines = links without the color contrast. As Chris's letter indicates, that isn't so. The new rule, therefore, will be that links on the front page will be a color sufficiently removed from black as to provide contrast. Links on inside pages will be blue, but royal blue, not Psychedelic Blue.

To which Chris responded:

Actually there is another piece here-- there is a strange bug in IE 4 (what's new): Sometimes when you have been to a site with a stylesheet that instructs the browser to take the underlining off of links, the instruction remains even after you leave! At least it happens to me on some of the machines that I work with... I guess that's why there is supposed to be a color and a style indicator for links...

Bug fix: Always turn on the text-decoration: underline attribute for the <a> (link) tag, if you're going to use the <a> tag in your style sheet. I'm hard-coding the color now, rather than using the style sheet. That makes it easy to have followed links indicate they've already been visited, and it allows the user to override my choices in their browser's preferences control panel. (I understand you can set both new and visited link colors in the style sheet, but I assume if you do so, the user cannot override those decisions.)

The standards committee was remiss in enabling people to turn off link underlining in such an easy way. (If there's some fairly complex workaround, that will tend to limit nonconformance to people who really need it.) It's always easier to say "yes," to make every single feature in a system customizable. It avoids so many hard decisions. Unfortunately, its just wrong. People must be able to find links. The original rule was simple: "If it's underlined and in Glow-in-the-Dark Blue, it's a link." We can afford to relax that a bit to "if it's underlined and in a contrasting color, it's a link." We can't relax it to "scrub the screen until you find something," particularly since our studies at Healtheon show that a high percentage of users are not consciously aware that the hand icon indicates a link.


Representing link destinations (continued from last month's discussion)

Normally, I remove gushing-fan statements, being a person of extreme modesty, as those that don't know me well will attest. Timothy, however, presented his so charmingly, I couldn't resist leaving them.

Tog,

<OBLIGATORY-GUSHING-FAN-MODE>
I have read your books and columns, and loved them. OTOH, they always leave me feeling depressed at the sorry state of software in the real world. Thanks for writing them, and now for hosting "Ask Tog."
</OBLIGATORY-GUSHING-FAN-MODE>

I read your column suggesting that the HTML standard needs to be updated in terms of navigation, ie that links should be differentiated based on destination. I agree. I would also suggest another change to the HTML standard (and a fairly simple one, at that). HTML should support the concept of "Next Page," "Previous Page," and "Parent (or Content) Page" tags.

After all, many web sites offer that sort of simple navigational model, of picking a subject of interest, then following a series of pages relating to it. Unfortunately, every web designer implements them differently. Some do not provide "Parent" (or table of contents) tags at all. Some provide "Next Page" and "Previous Page" buttons, but often at the top of the page. Great. When I have finished reading the page, I must now scroll back up to the top, in order to go to the next page.

However, those web sites are at least better than those that provide no page to page navigation at all. And on this one, I am forced, in a small way, to take you to task. While I do love your left hand side navigation links, and the lack of frames, I would find your main columns far more easily navigable were I only able to click "Next Page" and "Previous Page" to walk through them in order.

Returning to my suggestion: If there were even a simple extension to the Anchor tags of HTML, such as <A HREF="www.mysite.com/page2.html" LINK_TYPE=NEXT>, the browser could then implement standard buttons and menu choices for those three common actions. I think this would (if adopted) clean up one of the most annoying parts of simple page navigation.

Anyway, that is just my 2.02 yen worth. Thank you.

Timothy Knox

Providing a standard for relative navigation is an excellent suggestion, and I also like the <OBLIGATORY-GUSHING-FAN-MODE> tag as well. AskTog and others like it might prove the exception, as it really has two simultaneous structures: First is the structure of the monthy issue, with one unrelated (except chronologically) article following the other. Second is the site structure, arranged by category, as represented in the left bar menu. Does clicking on "back" on this reader-mail column take you to last month's reader mail, or the next item up in this month's issue? Perhaps two buttons, with appropriate labels is the answer.

There was one aspect of your recent articles I found appalling: your apparent recommendation that web-page designers or web-page design software try to give links differing appearances based on their destinations.

This is not a function that belongs on the server side. It's a function Web browsers can easily perform in a consistent, unambiguous, and user-customizable way across all Web sites. It's not a function Web pages or Web sites can perform unambiguously or consistently, and without CSS of some kind, they can't even perform it in a user-customizable way.

Myself, I usually move my mouse over a link and look at the URL and do some processing to determine:

It'd be nice if my browser did that for me so I could see this without looking at the URL and thinking about it.

Most of the time, though, I already know this information from other heuristics:

These three heuristics cover the vast majority of the links I encounter most of the time. Most of the rest can be classified as follows:

You may notice that these heuristics generally classify whole blocks of linky-linky text as one kind of link or another. I suspect I generally know what all the links on a page are within 500 ms after I first see the page.

You may also notice that I refer to hierarchies a lot. This is because, in my experience, every web site that is even marginally usable is organized in a definite, clear hierarchy.

I probably spend 20-50 hours a week on the Web, and have done so relatively consistently since 1993 or so. (There have been a few times when I've taken a couple weeks or a month off.) So the link categories that are obvious to me may not be obvious to everyone. Perhaps we ought to do surveys and studies. Has anyone?

Kragen (who thinks that browsers ought to pop up a warning dialog when they leave a page with a partly-filled-in-form).

What I prefaced this subject with is:

The lack of a standard appearance for the three levels of destination is a major flaw in the HTML spec. The eventual cure must come from those with control over that spec. In the meantime, we are left with a vacuum. No individual web site can fill it....

I then went on to suggest that the major site editors could attempt to force the issue. That is the least favorable course, but in light of the standards committees and the browser designers failure to address the problem, it may be better than nothing.

What I have done this month is to add two icons representing within-page links ( ) and off-site links ( ). These are both variations of symbols currently being used by site editors to communicate to those building sites where their links lead. They are way too heavy, but when symbols are not in universal use, they have to be far more communicative.

Until real standards develop, are these symbols a good idea for an individual site, or are they too overwhelming?

First response

Maybe my eyesight is poor, but that icon looks like it has an anchor in it (either that or a sickle and hammer--I'm assuming it's not this last). To whom outside the HTML authoring community (and the sea-faring community) does an anchor have any meaning?

As for your offsite links icon: The purple color scheme is nice, but that round ball (which I presume is earth) doesn't much look like anything other than a sugary treat..

Nick Kallen

Both symbols are pretty silly. The earth one is apparently being used by several parties, including Microsoft, to indicate external links. The anchor one I made up, based on the earth one. I'm not pushing it as a universal symbol, but this site is frequented by a great many people who are HTML editors. However, I am really, really open to other ideas.

Adding help to links

As a way to know where we're going before we get there, I really liked the suggestion put forward by Jakob Nielsen in his column, "Using Link Titles to Help Users Predict Where They Are Going."

It's not going to work in every case, but it will help some. Of course, it doesn't work on all browsers, but then what does?

Bernard

Jakob's advice of adding meaningful titles within link tags is well-worth reading and following. (Part of that advice is not to provide such titles just to be typing something. In the above link, it's pretty obvious where you're going and what you're going to see.)

How do you present huge spreadsheets on tiny displays?

I stumbled onto your site while researching a problem I will now attempt to briefly describe: I'm a web developer working as a consultant to a large corporation. My task is to help them develop design guidelines for moving a variety of financial and productivity reports into a browser-based intranet. In a nutshell, the problem is that they're trying to cram spreadsheet-style reporting - dense columns and rows of numbers - into a 640x480 browser window. Needless to say, it doesn't work very well.

While I have been successful in establishing some useful overall design principles, I have been less successful in convincing them that what is necessary is a more fundamental shift in their approach to the reports themselves, i.e. smaller, discreet chunks of information; possibly a graphing solution instead of, or in addition to, numerical displays.

Any light you can shed on this matter - research you know of, your own insights, where else to look - would be greatly appreciated. Thanks for your time!

Mark McConnell

I have struggled mightily with the problem of presenting, on a 640x480 screen, the exact same large-scale, matrixed information that was traditionally distributed on paper. My conclusion is that it cannot be done successfully.

A 640x480 window has 307 thousand pixels. An 8.5x11 sheet of paper, printed on a 600 dpi printer, has more than 30 million  pixels. These hundred-fold pixels not only allow a lot more text to be displayed, they make that text far more readable.

We now, after 10 years of promises, finally have the first generation of the paperless office. However, it is being delivered on crude equipment that was originally designed for generation of information, rather than retrieval and reading. People are cramming information that belongs on high-resolution displays, such as paper or 20" monitors, onto cute little toy displays, such as 12" Macintosh screens or the equivalent pixel-count 15" Windows screens.

This too shall pass. 17" fine-pitch is quickly becoming the office standard, and 150 dpi/300 dpi flat-panel displays are waiting in the wings.

In the meantime, I would avoid raw numerical information except where absolutely necessary. Graphs and charts are a good way to communicate the gist of the information. So are summary reports. Back them up with the raw numerical data in easily printed-out form. If people must look at this raw information on the screen, open it up in a size suitable to the data, rather than the user's screen, unless you can be assured that chunking the information won't significantly reduce people's ability to understand what they are seeing. Better even the dreaded horizontal scroll than isolated islands of information leading to confusion.

Having to move from spreadsheeted numbers to charts and graphs is far from bad. Well-designed envisioning tools can help people gather meaning from data far faster than their pouring over columns of numbers. Edward Tufte's books on turning data into information can serve as the basis for corporate guidelines on this subject.

It doesn't matter whether you are composing an email, writing a book, or presenting the results of O-Ring damage on the Space Shuttle, it takes more time to concentrate information into a more compact, easily-digested form than to leave it raw. However, that new, more compact form is invariably better than the original. The discipline of a 640x480 screen is quickly forcing people to abandon their traditional "shovelware" approach of 200-page daily print-outs in favor of short reports that actually carry meaning. To that extent, today's keyhole screens are doing us good.

Programmer-responsibility

DC Stultz is not only a wise man, he's got a great sense of humor. Check out his webpage referenced at the end of his letter.

I question your comment to Charles Fox that "I think you are being too hard on the programmer."

I've been in the computer biz for 30+ years, mostly as a programmer. I grew up in the depression era of computing, when memory and storage space and computer speed were small and slow (read: core, punched tape and cards, overlays), and I've learned a few valuable lessons along the way.

If you give a kid a hammer, everything will look like a nail. Give a programmer new tools and programming languages and he'll use them whether a more simple solution is more appropriate or not.

Developers need to take some time before jumping off the bridge. You need to stop and consider whether the bungee cord must be tied to both the bridge AND your feet. A programming task is not a lake that you just dive into without regard to the water temperature, the hazards of shallow water, or the potential of sharks.

In your user manual piece, you said the writer needs to know the concept first. A programmer needs to do the same. Up-front time spent on design and simplification pays off big-time. An elegant, simple solution is harder to find, but it is a joy to code and to later support. It is worth the effort.

The keys are:

You'll understand the problem better when you have completed the task. Had you been armed with hindsight, you naturally would have done some things differently. In other words, good judgement comes from experience, experience comes from bad judgement

DC Stultz (the computer professional)
Sr. Systems Analyst
Raytheon

who is also....

DC Stultz (the computer player)
Creator of The Morning Message

Re: How to write a great user manual

Here are some points I would add to yours:

Writing is about Thinking
The real story behind powerful writing is not the choice of words, but the formation of thoughts. This is the difference between David Pogue's elegant prose and what went before. We may call it great writing. It is in fact great thinking. To achieve any trajectory, words must reflect value-added thought.

The Manual as a First Date
You can show up dishevelled and decline to respond to polite questioning (like FrameMaker1s on-line help). And there will be people who still persist in the search for your inner beauty. But it is not the way to bet. Once upon a time, Microsoft put considerable effort into its making its manuals a source of competitive advantage. It still shows, though less than before. There may be a message here.

Manuals Can Sell Products
The classic case in my view is Hewlett Packard's 12C calculator in the finance industry. The 12C was a superb product, but it had a problem: nothing is less intuitive than RPN logic. The 12C's power was accessible solely through its manuals, and these were superb. They were tutorials worthy of the name—lucid, courteous, but never lightweight. Great instructional material. Which brings me to my next point.

Technical Writers are Not in the Technical Business
Technical writers are in the education business. There is more than something for them to learn from other educational material, especially in how complexity is unravelled. Of course, a technical writer has to know a bit from a byte, and a lot more. The most common misconception is that technical writing is a descriptive, mechanical process. In reality the core function is to teach.

Kind regards,
Barry Martyn

Excellent points all. I had left out the dimension of writer-as-teacher, and it is an important one.

I received a great deal of mail on this column varying from confirmation that I know exactly what I am talking about to the suggestion that I am naive in the extreme (and after 20+ years of my writing and editing user manuals, no less). Please click for additional responses. Otherwise, click below to return to the home page.

 


Don't miss the next action-packed column!
Receive a brief notice when new columns are posted by sending a blank email to asktoglist-subscribe@yahoogroups.com.

return to top
---
 
Contact Us:  Bruce Tognazzini
 
Copyright Bruce Tognazzini.  All Rights Reserved