Fw: Interface Article in ACM

[Alexander Bostrom]

Usually the Be developer m.list is filled with boring stuff, but sometimes
there is something that seems to be interesting.

>To: Be Developer Discussion List <bedevtalk@be.com>
>Subject: Interface Article in ACM
>Date: Mon, 05 Aug 96 11:50:19 -0500
>From: Talin <talin@dreamersguild.com>
>Reply-To: bedevtalk@be.com
>
>-- [ From: Talin * EMC.Ver #2.5.02 ] --
>
>This month's issue of _Communications of the ACM_ is about new computing
                        ^^^^^^^^^^^^^^^^^^^^^^^^^
                        What's that?

>paradigms. There is an interesting article called "The Anti-Mac Interface".
>The authors, who are actually devoted fans of the Mac interface, are trying
>to go beyond the windows-icon-mouse paradigm. They way to do this, they
>state, is to examine the basic assumptions set down in the Apple Human
>Interface Guidelines, and see if violating those assumptions can create a
>viable, consistent and self-reinforcing interface. Here are some excerpts
>from the article:
>
>        "At recent user interface conferences, several speakers have
>lamented that
>the human interface is stuck. We seem to have settled on the WIMP (windows,
>icons, menus, pointer) model, and there is very little real innovation in
>interface design anymore.
>        "Physicists and mathematicians often stretch their imaginations by
>considering what the world would be like if some of their basic principles
>were violated...This has led to new concepts such as non-Euclidean geometry=
,
>positrons, antimatter, and antigravity...
>
>(Here is a table listed in the article that compares features of the Mac UI
>with their opposite)
>
>            Mac                   Anti-Mac
>            ~~~                   ~~~~~~~~
>          Metaphors               Reality
>      Direct Manipulation        Delegation
>         See and Point       Describe and Command
>         Consistency             Diversity
>           WYSIWYG            Represent Meaning
>        User Control           Shared Control
>     Feedback and Dialog    System handles Details
>          Forgiveness         Model User Actions
>      Aesthetic Integrity       Graphic Variety
>         Modelessness            Richer Cues
>
>The article goes on to list some of the problems with each of the Mac
>guidelines. For example, direct manipulation can become a tedious chore if
>you have to directly manipulate a whole bunch of similar objects.
>
>Here is another quote:
>
>        "Many recent interfaces have tried to overcome the limitations of t=
he
>desktop metaphor by extending it to some other room or building metaphor (e=
.
>g. Bob or Magic Cap) or to a village metaphor (e.g. eWorld). These 3-D
>designs try to emulate virtual reality on a flat screen but often seem to
>introduce a level of clunky indirectness in achieving common user goals.
>They are navigationally cumbersome, asking users to go to the 'other end of
>town' to pick up their email from the Post Office, and interactionally
>cumbersome, overloading users with additional windows and other interface
>elements necessitated by the metaphor but not by the user's task."
>
>        I suggest that the Be UI folks get a copy of this article. It
>seems to me
>that if we are in fact attempting a "fresh start" with a new operating
>system, it makes sense to look at as many new ideas in interface as we can.
>The BeOS represents an invaluable opportunity to popularize some new ideas,
>rather than just making minor incremental improvements to old interface
>paradigms.
>
>        Admittedly, not all of the ideas given in the article are doable
>at this
>time. However, some of them are fairly straightforward. For example, there'=
s
>a section called "A richer internal representation of objects" which speaks
>almost directly to the type/creator discussion we've been having:
>
>        "Current interfaces have access to very little information about th=
e
>objects the user deals with. For example, the only information known about =
a
>file may be its name, size, and modification date; the type of data it
>contains; and the application that created it. In order to deal more
>effectively with these objects, the computer needs a much richer
>representation of them. For a document, this representation could include
>its authors, topic matter, keywords, and importance; whether there are othe=
r
>copies; what other documents it is related to; and so forth. The list of
>attributes is similar to what would be needed by a good secretary who was
>expected to handle the documents intelligently. It is not necessary for the
>secretary to fully understand the document's contents, but he or she must
>have a general sense of what the document is about and of its significance.
>If a computer interface is to handle documents intelligently, it must have
>the same sorts of information.
>        "Much of this information does not require natural language
>understanding.
>We already have techniques in full-text search systems that could be used t=
o
>automatically extract this information from the document. As we move to tex=
t
>systems with tags based on meaning rather than a WYSIWYG system, much of
>this information will be available in the document itself. Furthermore, if
>we allow the computer more control over the interface, it could monitor wha=
t
>we do with the objects and change their representations accordingly. For
>example, if two objects were almost always used together, the computer coul=
d
>create a hypertext link between them."
>
>        It seems to me that the underlying Be database provides a perfect
>foundation for this kind of interface innovation. And I would think that it
>would be relatively straightforward to build some sort of background daemon
>that sifts through files and documents, analyzing their content, and making
>cool hyper-indices, which could then be used in Be's live query feature.
>
>
>--
>-- Talin   | Director of R&D              | "We are all
>           | The Dreamers Guild, Inc      |  soldiers in the war
>           | http://www.dreamersguild.com |  against entropy."
>