Kary
28⟡194
Zea Pou
1316
Gregorian 2024-07-20
Khayyamian 976/04/30
Shamsi 1403/04/30
Quotes & Excerpts

One of my longstanding pet hates is to have them behave anything like their physical counterparts. For example, as they existed in Officetalk, Star, Lisa, and Mac---like real folders—there is only one icon for a document application and it can be in only one folder. This drives me crazy, because the probability of not finding what you are looking for by browsing has just been maximized! It is trivial to have as many icon instances for a given doc or app in many folders as one wishes. They should be near any place where they might be useful. (Dragging a a singleton out on the desktop is not a solution to this problem!) But even if that were fixed we have to ask: why a folder? Instead of passive containers, why not have active retrievers that are constantly trying to capture icon instances that are relevant to them? Let's call them bins. Imagine having a "memos" bin that, whenever and wherever you make up a memo, captures a copy of the doc icon. You might have a "memos ot boss" bin that automatically captures only those icon of docs sent to your boss. Folders kill browsing. Bins extend their useful range.

It is not surprising, either, that many people who are "figurative" have extreme difficulty getting anything finished—there is always something new and interesting that pops up to distract. Conversely, the "symbolic" person is good at getting things done, because of the long focus on single contexts, but has a hard time being creative, or even being a good problem solver because of the extreme tendency to get blocked.

My main complaint is that metaphor is a poor metaphor for what needs ot be done. At PARC we coined the phrase user illusion to describe what we were about when designing user interface. There are clear connotations to the stage, theatrics, and magic---all of which give much stronger hints as to the direction to be followed. For example, the screen as "paper to be marked on" is a metaphor that suggests pencils, brushes, and typewriting. Fine, as far as it goes. But it is the magic—understandable magic—that really counts. Should we transfer the paper metaphor so perfectly that the screen is as hard as paper to erase and change? Clearly not. If it is to be like magical paper, then it is the magical part that is all important and that must be most strongly attended to in the user interface design.

While the magic is being designed, the very idea of a paper "metaphor" should be scrutinized mercilessly. One of the most wonderful properties of a computer is that no matter how many dimensions one's information has, a computer representation can always supply at least one more. One result is that any seeming distance between items in our world of limited dimension can be completely "disappeared."

This Is something that Vannevar Bush and his chief prophet Doug Englebart noticed immediately, and hypermedia was born. In a world of Dynabooks, information will not be printed---it would destroy most of the useful associations---and something much more than superpaper will emerge. The notion of hypermedia is much more a "user illusion" than a "metaphor."

The contrastive ideas of Bruner suggested that there should always be away to compare. The flitting-about nature of the iconic mentality suggested that having as many resources showing on the screen as possible would be a good way to encourage creativity and problem solving and prevent blockage. An intuitive way to use the windows was to activate the window that hte mouse was in and bring it ot the "top." This interaction was modeless in a special sense of the word. The active window constituted a mode to be sure—--one window might hold a painting kit, another might hold text---but one could get to the next window to do something in without any special termination. This is what modeless came to mean for me---the user could always get ot the next thing desired without any backing out. The contrast of the nice modeless interactions of windows with the clumsy command syntax of most previous systems directly suggested that everything should be made modeless. Thus began a campaign to "get rid of modes."

The object-oriented nature of Smalltalk was very suggestive. For example, object-oriented means that the object knows what in can do. In the abstract symbolic arena, it means we should first write the object's name (or whatever wil fetch) it and then follow with a message it can understand that asks it to do something. In the concrete user-interface arena, it suggests that we should select the object first. It can then furnish us with a menu of what it is willing to do. In both cases we have the object first and the desire second. This unifies the concrete with the abstract in a highly satisfying way.

Day's Context
Open Books