Mac OS9 Packages: A good idea?
Should you use Descriptive Terms on Buttons?
Programmers Controlling the User's WIndows
Nav Bars and Email Madness
Wow, I had no idea you had a web site! Luckily, there is such controversy over the Quicktime Player UI that a link to your article showed up on MacInTouch. Im so excited to find this site that I have to ask the three questions that follow.
Thanks very much
Question 1: Mac OS 9 Packages.
You probably know all about the new OS9 package. Its a folder with a bit set to tell Package-aware applications that this is a package, not a regular folder. Its based on NeXTSteps similar feature for folders. Some feel that packages are very dangerous and nothing but a UI hack. They fear that novices can easily damage a package. Im just curious what your take is on packages.
The idea of packages is not new to me. In fact, I proposed it way back in 1985, about the time the engineers started thinking about aliases, an approach that absolutely, positively guarantees that you will have more objects on your screen, rather than fewer.
What I liked about my counterproposal was that users would typically see fewer objects on the screen. It would also simplify the system folder which, at that time, was bursting with literally dozens of objects.
Of course, todays system folder has an object count approaching that of a small star system and most of us have lost all possible control over it.
Under my proposal, clicking, dragging, and double-clicking a package would do exactly what these actions normally do. Only by option-double-clicking would the interior of the object be displayed. The purpose of that was to keep novices from accidentally rooting around in there, damaging things.
It is unclear from Apples engineer-centric document you cite as to what the behavior of these new packages is. For instance, if I double-click a package, does it launch the application or open the package? If, indeed, something that looks just exactly like an application all of a sudden is acting differently, big trouble lies ahead. Such a design will break the most cardinal rule of consistency in human interface objects.
Question 2: Should you use Descriptive Terms on Buttons?
I recently joined the Apple Human Interface Developers mailing list for one reason. Someone at Apple decided that the log out dialog for Mac OS 9 should include two buttons, Yes and No. I am so strongly opposed to Yes/No and Yes/No/Cancel (whats the difference between No and Cancel?) dialogs that I get mad every time I see one. I would love to know what you think about dialogs with Yes/No buttons. My belief is that buttons should be verbs. Save tells me what I can expect from the button. Yes tells me nothing.
Yes and No are generally a setup for error. Particularly since different designers, under similar circumstances, will pose questions in the opposite way:
What you are about to do will cause total destruction. Do you want to go ahead?
What you are about to do will cause total destruction. Do you not want to go ahead?
Rather than Yes, and No, under such circumstances, use text such as:
You have spent 23.7 hours building an elaborate data base. Before you close it, would you like to save all your work or wipe it off the face of the earth?
Then add buttons labeled Save, Destroy, and Cancel. (You may elect to use slightly less inflammatory language; I've never been given to subtlety.)
Question 3: Microsoft's Experimental Mouse
Microsoft has a new touch-sensitive mouse
Without intending to slam Microsoft, my feeling is that this mouse is a reaction to the plethora of toolbars that permeate Microsofts applications. The real solution would be to eliminate most tool bars and let the user easily hide them as they see fit.
The new mouse is a reaction to the plethora of toolbars, and the plethora of toolbars, in turn, is a reaction to the severe limitations of the mouse. Namely, all you can do with the mouse is click, the equivalent to the cavemans single grunt. If the caveman wants food, he must point to his belly and grunt. If the caveman wants you to climb a tree, he must point to your feet, then point to the tree.
The mouse is obsolete. It is time we move on to devices that support both gesture and voice commands fluidly and accurately. The longer we hold on to 1960s technology, no matter how much we spiff it up with fancy wheels and sensors, the longer it will be before we can go back to simplicity of design.
Programmers Controlling the User's Windows
Andrew Sedelnikov asked about closing windows under GUIs other than Windows. The main reason I spend much more time closing windows at work (under Windows) than at home (under MacOS) is that at home I can option-double-click a folder to open it and simultaneously close the parent. Now I know I can also do this under Windows, but the difference is that under Windows the child window is resized and moved to occupy the same area of screen that its parent had. This usually results in a completely inappropriate amount of screen space being used, and also causes it to be exactly covered over if I reopen the parent. Very annoying.
Considering that it is called, Windows, Windows is remarkably clueless about windows and the objects therein. The size and location of a window is the users business, not the programmer's. The layout of icons within a window are the users business, not the programmer's. I have little idea where anything is on my Windows machine because I have found it futile to organize anything since, five minutes later, Windows will reorganize it in some incomprehensible fashion that the programmer apparently thought was better.
The Mac Finder is extremely sensitive to the users rights in this regard. It does move windows around when you select the auto-open feature, which is one of the reasons, along with the fact that it is triggered by a time delay, that I avoid it. The only thing the Mac does window-wise that is profoundly stupid is that, if you tell the finder to create a new folder inside an existing window, that folder will initially open up to the same size and location as the parent window. Now, once youve moved/resized the new folders window, it will. never again mimic the parent, but it is still stupid, for the same reason that Microsofts non-solution is stupid: There is only one size and location that a child window should never, ever be (unless the user has specified it so) and that is the size and location of the parent. When they are the same size, people will get them confused and drop things in the wrong window. When they look different and occupy different locations, the odds of this happening plummet.
Nav Bars and Email Madness
Why have you chosen to put the navigation interface on the left side of the window. What good reasons (if you have any) lie behind that selection?
One of my points that I hope to make in an upcoming essay is that people tend to do what other people do and do not stop to consider the implications their actions will have on their site. Perhaps it would be better for the site to have its navigational interface on the top instead of at the left side.
Student at the department for Computer Science, Linköping University
In the case of AskTog, I chose a left side menu bar because I assume most of my readers will have at least 800x600 displays most of the time and the 800 size allows for such a menu plus a well-sized text column.
I have designed other sites and weblications where I chose top menus and bottom menus.
I tend to avoid right side menus because people are not as familiar with them. Consistency with user expectations is, after all, the most important form of consistency
Of course, slavish copying can indeed get you in trouble. Consider the horribly broken email system. How many times a day have you pressed send only to realize that you forgot the attachment? So you got to send out an Im an idiot; heres the attachment mail.
How many times have you responded to one email, only to find another from the same person that says, never mind, or adds some detail that causes you to have to reformulate your reply?
How many times have you sent a flame and thought better of it, a lot better of it?
Ever wished you could call that email back or cancel it? Why cant you? Well, at least one reason why is that the postal service doesnt allow you to unmail a letter, and they must have a good reason. They do: If they allow everyone access to the mailbox, people will steal each others mail. Thats the sole reason, one that has nothing to do with email.
Some email systems, such as AppleLink, were built with the ability to retrieve email. It worked well and saved a lot of people a lot of embarrassment. It is about time such a feature became a standard part of Internet mail systems.
And while were on the subject, how about allowing people to set an expiration date? Why do I care that fresh tomatoes were left in the lunch room on Tuesday when I return from my trip the following Monday morning?
Contact Us: Bruce Tognazzini
Copyright Bruce Tognazzini. All Rights Reserved