We had active folders, so we had to have passive folders; the folder that wasn't active was passive. Now look at the bottom. Who has ever seen Mac OS8? And when you drag a window to the bottom of the screen it just kind of pops, and becomes just a tab, and then you can click it and it will slide open. Guess what? That was in the original design, in August 1980, that we were going to do on the Lisa. And it only took 17 years to implement. [Laughter] [Comment: Microsoft's doing a similar thing.] Microsoft did something sort of similar, but not really the same, in between. There are some differences, but I won't comment right now.
So what happened if the window was narrow? Well, if the window was narrow, this shows that the menu wouldn't fit; it would stick out. And if it was over on the right, it couldn't stick out on the right. It would stick out to the left. If it was too close to the bottom of the screen, then it would do this. And so, Bill showed all the cases, and a lot of us weren't too happy with this. So I went back to Bill again, and I said, "Bill, the top of the screen -- top of the screen!" None of us liked the idea of a two-line menu, which is the way Microsoft solved it, in some version of Windows. Here's an example of a menu item being selected. Notice that he's now got highlighting of the menu title, and he's got highlighting of the menu item. Bill had a long night one night and came back with that. And we had the help menu in here. The way we operated was, that Bill spent every night programming, and the next day we would do testing and arguing. I don't know when he slept, actually. Did he sleep? And then he would do it again, every night. Here's a memo from Gail Pilkington in Publications. The people writing manuals for the Lisa were key in commenting on the user interface design, had a lot of suggestions and a lot of good criticisms. And Gail actually had been at Xerox before. So, she said, "I don't like pull-down menus. [I] think they're ugly, and they cover things up." So, you know, I'm trying to cut something, and the first thing that happens is the menu comes down, and covers the thing I'm trying to cut. No good. And then Bill had this feature, that you could -- which he still has -- you could drag the mouse along the menu bar, and the menus would pop up one at a time. And we thought this is great: the user can see all of the available commands in one swoop. Well, she thought it was terrible, that you had to do that to see all the commands. I didn't understand, because in UCSD Pascal you had to hit keys for 10 minutes to see all the commands. So, I didn't quite get that. She also didn't like the idea of dim highlighting. She thought we should just suppress the items altogether. So we had dissent in the group. And we always had dissent in the group. I just chose that because it's a memo that I had, illustrative of dozens of people who had dissent over every issue. Nothing specific about Gail. In particular, she said, "Last version the spec, I thought we only had one issue, which was when that little menu bar at the bottom was full, we didn't know what to do about it, and you should have just solved that, instead of moving it to another place, adding drop-downs, and all these other things. You over-designed to solve the problem. And besides, I don't like Z for Cut and X for Paste." She had her own proposal that was mnemonic. September 22nd. It was now a month after I first said, "Bill, why don't you try at the top of the screen?" Bill had a very long night, and came back with the menu at the top of the screen, with command keys, check marks, everything -- he had everything. In one night he invented the entire mechanism of the menu bar at the top of the screen. To me it was just a place to put what he already had, but once he realized it was there, he could do a lot of other things. And he implemented an amazing amount in one night. So he wrote a memo to justify it, and said, "There are some problems with it. You have to go way further to reach the menu, that's a problem." But we decided, since there were command keys, and he made it very easy to have a single-stroke command key in this version, this all-night version, that okay, if you really wanted to go to that menu item a lot, you could hit the command key on the keyboard instead and you wouldn't move the mouse at all. So that solved that problem. The other problem was, that if there were a lot of windows open, you wouldn't really be sure which menu applies to which window, and sure enough, that's still true today. But, tradeoffs, you know. Why was it good? It was good because you got rid of all those ugly cases of sticking out menus, and also, the dialog box that came up when you had a command with parameters, could always go in the same place. And we had a problem before, with the dialog box coming up and covering up the menu, half the window, and so on. And so we could put it in a standard place under the menu bar. So this was all the result of his long night of invention. And then, a couple more examples, we could put some global commands in the menu. Before, we didn't -- we hadn't figured out yet where to put the global commands. They didn't really go anywhere, because every menu was in a window, but now having a menu at the top, we could have global commands like shutting down or whatever. And then we could widen the title tabs, because the menu didn't take up room at the top of the window. Now we're in February '81, so we've leapt ahead now several months, where all the programmers are busy implementing stuff. They're designing an operating system, telling us that we're holding up the project when they're still designing the operating system. I was in charge of the Applications Group, and we're the reason the project is behind schedule, even though they still were designing the operating system. So I wrote a memo for other people who were going to help out with user testing. I made guidelines for user interviews. So, never argue with each other in front of the interviewee. After they leave, you can shoot each other, it doesn't matter, but not while the subject's there. Don't patronize the subject -- don't show off your knowledge. I wrote this because I would be bringing engineers into the room, and I'd sit them in the back. And the user would struggle to do something, and the engineer would run forward, jump out of the chair and run forward, grab the hand of the person, and say "It's easy. You just do this." [Laughter] And I'd go, "Naw, naw naw. You don't get it." So, we tried gags, we tried all kinds of things. [Laughter] Finally I said, "Look, I'll let you in the room if you observe these rules: Don't plant the answer. Take turns asking questions, if there are several of us there, so we get different -- we may each see different things. And mainly, try to get them to do the talking. This is not a lecture by you, this is a test of them, and you want them to verbalize all they possibly can." [The] typical thing that would happen is, we'd bring somebody in, to prove that the user interface thing they put in was absolutely right and we were totally wrong, and then the end user would usually prove we were both wrong: both the things were hard to use, and then we'd have to go back and redesign it. Or, half the time, the user would say, "Well, why doesn't it just work this way?" And we'd look at each other sheepishly, and fix it. Now here was an interesting one, for those of you who do user testing. You don't -- if you don't name things, you don't just say, "What would you call this?" People paralyze, like "Oh, you're asking me to invent a name." They just get totally paralyzed, they can't thing of any. But if you say something like "If someone were to bring you this, if you wanted someone to bring you this, what would you say? Bring me the ...." And then people would come up with something. It actually worked pretty well. People have similar techniques, I've heard, for other things. April 3rd, '81. Well, at this point they were starting to get very nervous about the schedule. The operating system design was done, I think, and so we were holding things up. And they decided the problem was that these engineers, instead of just writing code like good sheep, were going and worrying about whether it was usable or not. So they decided to take all power away from us, and put all the decision making into a council. So who was on the council? [The] first person was the Division Comptroller, from Finance. Second one was the V.P. of Sales, who was always on airplanes. Third one was head of Publications for Lisa, which was a good idea. Fourth one was kind of the architect of the group; that was a good idea. And the fifth one was somebody in Product Marketing, who you saw had made comments before, that were pretty good ones. So, I was looking at this, going "Umm, okay, maybe we can live with this." But the main thing they did that was very good is, we instituted a process for what to do if you had a user interface issue. Don't spend eight hours arguing with each other. Write it up, make your points, get back to work. And then we have a process for dealing with it. But, the council would rule by majority vote. So, I think, "What a way to design a user interface, by majority vote of the Comptroller, the Sales V.P., okay." [Laughter] -- LisaList is sponsored by <http://lowendmac.com/> and... Shop buy.com and save. <http://lowendmac.com/ad/buy.com.html> Support Low End Mac <http://lowendmac.com/lists/support.html> LisaList info: <http://lowendmac.com/lists/lisa.html> --> AOL users, remove "mailto:"; Send list messages to: <mailto:lisalist@mail.maclaunch.com> To unsubscribe, email: <mailto:[EMAIL PROTECTED]> For digest mode, email: <mailto:[EMAIL PROTECTED]> Subscription questions: <mailto:[EMAIL PROTECTED]> Archive: <http://www.mail-archive.com/lisalist%40mail.maclaunch.com/> iPod Accessories for Less at 1-800-iPOD.COM Fast Delivery, Low Price, Good Deal www.1800ipod.com
