| |||||||||||||||||||||
| |||||||||||||||||||||
AskTog ReaderMail January, 1999
Y2K: Deja vu all over again
Context-(In)Sensitive Menus
Who's in charge: Reader or Writer?
Mice: One Button or Two?
I enjoyed browsing your web site. Looks great. You might want to include a Y2K column for the safe and sane "Little Pig"—you know, the one with the brick house.
-Al Haimson
We've already had a pretty good dress rehearsal for Y2K, namely, the Millennium. The Y1k problem arose when everyone in Europe simultaneously decided that the world would come to an end exactly 1000 years after the birth of Christ. (As if it weren't bad enough they were wrong about the whole end-of-the-world thing, they were also suffering an off-by-1 error, since 1000 was really 999 years after.)
Since they felt wouldn't be needing a lot of material possessions after the world ended, they carried out the first major urban renewal project, laying waste to most of Europe's infrastructure and all of Europe's civilization, ushering in the Dark Ages.
The Y2K problem could no longer depend on ignorance and superstition. Instead, we substituted greed and shortsightedness, all gussied up in the guise of leading-edge science.
The problem began in the 1950s, when the most profit to be made in the next 90 days from computer operations would be accrued by not allocating expensive bytes of memory to storing the then-repetitious "19" of the year for every transaction.
Over the ensuing decades, the cost of bytes approached zero, while tradition grew ever stronger. Somewhere long about the late '70s, however, someone looked up and said, "Hey, some day the century is going to click over, and we're going to be in a lot of trouble if we don't fix this stuff!" That was the day that greed and shortsightedness really kicked in.
The job of Western CEOs is to make investors happy just for this quarter. Next quarter will be time enough to worry about next quarter. This is the phenomenon that led Apple management to decide, quarter after quarter, that they could make more money this particular quarter by not permitting cloning, even though they knew it would lead to reduced market share in the long run. They kept it up until it was too late.
Similarly, the CEOs ignored the advice and entreaties of their engineers, putting off addressing the Y2K problem until Y2K was all but upon them. Now, they are paying through the nose to hire the few experts available who can do the job, hoping-against-hope that the work will be done in time.
Against this backdrop, what is likely to happen during this brave, new year of 1999? It's difficult to judge exactly where and how serious the failures are going to be, since it is not in the best interests of any business to take out full-page ads in the Wall Street Journal to proclaim, "Boy, are we messed up!"
We will certainly be seeing some businesses fail completely, particularly financial institutions. This will be unlikely to happen on January 1, 2000, however. The Feds will move in much sooner.
As for the rest of the business world, we'll have a much better idea where they stand once September 9, 1999 has passed. This will be our harbinger, because, for the last 40 years, whenever businesses had open-ended contracts, instead of typing "open," which would have required an extra line of code and a few more bytes of storage, they've been having people type a date that was easy to key, but which seemed impossibly far in the future: 9999 or September 9, 1999.
When the magic date has passed, if half the businesses suddenly get flaky, it will be time to sell your stock and invest in kerosene lanterns and a horse-drawn carriage. On the other hand, if the date passes uneventfully, things may be in better shape than we deserve.
And what of January 1, 2000 itself? For the survivalists storing up bottled water and solar-powered can-openers, I have some disturbing news. While we've been working long and hard on the Y2K problem for at least six months now, a certain second-world country has scarcely begun. Most of their computers are riddled with Y2K, and most of their computers are dedicated to the delicate task of launching of nuclear missiles in our direction. Instead of the bottled water, survivalists might be better off stocking up on lead-lined long johns and sunblock with a protection factor of around 850,000.
Fortunately, in one of those many ironies of the postwar era, their defense department experts are now working with our defense department experts to eliminate Y2K problems from their systems.
Hi Tog,
Nice to read the design articles. I've a peeve with Netscape Communicator (Navigator 4.x) that I find particularly annoying.
Clicking the right button pops a menu with "Back..." as the first item of the menu. It is very easy to go quickly back up a page by right-clicking and selecting the first item. But, if the pointer in the page is on a link, the right-button popup menu looks different. The first item is now "Open in new window...". "Back..." is the 3rd item. I cannot tell you how many times I've right-clicked-and-selected-first-item and had a new page show up in a new window, when I had wanted to simply go back up a page.
You'd expect a popup menu to look the same every time it is invoked, wouldn't you? I except their answer might be that they're providing a context sensitive menu. But then how often does one invoke the "Open in new window..." as opposed to "Back..."? At the least, wouldn't you want to put the much-used Back... as the first-default item.
Navigator 3.x and below don't have this bothersome "feature".
Prashanth Kuchibhotla
Context-sensitive menus, whether they are pop-ups or a rapidly changing menu bar as occurred with OpenDoc, are always a problem unless the user is fully aware of the context. They mess with one of the most fundamental principles of interaction design: Don't change your interpretation of the user's behavior. Like most rules, one does have to bend this one a bit in order to provide the kind of power users need. Context-sensitive menus, by definition, need to change from one context to another. The secret to avoiding user-confusion is first to ensure that the user has changed context, not just the program. Context-shifts need to be visually and behaviorally apparent, so users can predict the result.
Second, when the same item appears across a great many menus, put it in the same place.
Who's in charge: Reader or Writer?
Dear Tog,
Which works better: making an optimized, consistent site, or letting the user's preferences stay in place?
Many sites (yours included) have their own colors for links. This would allow coding for local and distant links, for example.
BUT... users would have to learn your coding, which is completely different from that they see in every other site.
(On your site, you're not using my preferences, and I can't see how to tell which pages I've already visited. But the problem is hardly limited to your site.)
BTW, I'm inordinately pleased to see your slam on Acrobat -- I was beginning to think that I was the only person in the universe it didn't work for. About 40% of the time it not only crashes, but damages itself such that I have to not just delete the preferences file, but reinstall the application. (For some reason, Acrobat, at least on the Mac, alters itself each time it's run.)
David Dunham
A natural tension exists between the author and the viewer of web pages. Who should be in control, and how much control should they have? The early browser designers, being anarchists, gave the power to the people, and now the designers, naturally enough, want it back. Ideally, web designers would have to pass a test in each aspect of design, after which they would be given a secret code that would allow them to override user's default selections. This would prevent bumblers from screwing up reader's sites.
Such a test (sadly) is unlikely to become popular any time soon. In its absence, it becomes the responsibility of those building authoring tools to make it easier to "do things right" than to "do things wrong." That was perhaps the biggest secret of the Macintosh interface, which provided a wealth of free tools to coders, tools that made their lives easier, but also ensured that users would see a consistent interface. Only the extraordinarily talented—along with a handful of the extraordinarily foolish—went to the extra work of building their own fundamental tools. When good fundamental tools appeared, they were adopted by the community and later acquired by Apple for inclusion in the toolkit.
This scheme, when properly played out, ensures continuity and true innovation.
The current style sheet implementation does not embody this philosophy. For example, it is supremely easy to change the color of links and, in doing so, turn off color differentiation for previously followed links. David's parenthetical comment is the result. I've gone back to hand-coding link colors just so followed-links will contrast. I should not have had to do so. (I understand there is some esoteric method of maintaining link-differentiation while still using stylesheets Whatever it is, it is obscure when it should be obvious.)
Dear Tog,
Enjoyed reading Tog on interface ! I'm working on a paper for my HCI class regarding the Macintosh mouse design. Primarily to explore why Apple chose the one button mouse. I know the argument of pull-down menu's versus contextual menu's. But with increasing complexity of tasks on a computer. Is it time for Apple to switch to a multi-buttoned mouse?
Since you were an Apple HI evangelist, I was wondering if you could tell me of some of the design criteria in choosing a 1 button mouse. Since the days of early Mac some of the design constraints such as a 9" monochrome screen no longer are valid (especially in the days of 19" screens and dual monitors). How well does the one button scale?
Also, on a separate matter, what is your opinion of the OpenDoc menu system with constantly changing menu bar?
Sandeep
The one-button mouse is beyond obsolete. Why Apple sticks to it I cannot possibly understand. It made perfect sense in 1981 when we brought out the Lisa, with an unproved interface targeted at busy executives. We wanted an interface that could be learned in 20 minutes, and you can't do that with a mouse festooned with buttons.
Now it is almost 20 years later. The GUI interface seems to have caught on, and people recognize the advantage of learning it, even if it does take longer than 20 minutes.
I've been using a two-button mouse on my Macs for a couple years now, and no one could pry them away from me. The Kensington two-button mouse allows me to use the second button for System 8's context-sensitive menus, and even lets you set a third code for both buttons pressed simultaneously.
This two-button mouse, when coupled with the four standard modifier keys pressed with the left hand, offers users a far more expressive device than does Windows.
In principle, I'm not against adding more buttons, but only if some clear definition exists for each, so the user can predict what might happen were one pressed.
|
|
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. |
 |
| Contact Us: Bruce Tognazzini Copyright Bruce Tognazzini. All Rights Reserved |
