Sam Holden Sent: 25 Aug 2004 13:14:43 +1000
>
>  "Suresh Govindachar" writes:
>>
>> Hello,
>>
>> I defined the concept of an Editable User Interface (EUI)
>> on www.sonic.net/~suresh/eui and illustrated it with
>
> I find the following paragraph a little bold in its claim:

But the counterexample, Acme, provided to dispute the claim
actually reinforces the claim.

>     The graphical user interface seeks to replace actions
>     by widgets (such as icons and items in menus) that can
>     be pointed to and clicked at. The specificity of the
>     actions represented by the ultimate widgets and the
>     impossibility of dynamically combining the ultimate
>     widgets leads to the proliferation of widgets in any
>     moderately complex application's graphical interface
>     (widgets can be combined statically into a new widget,
>     but one cannot form mega-widgets as and when needed,
>     dynamically, the way one forms commands from
>     keystrokes). The graphical interface is very good for
>     beginning users of applications who execute a few
>     simple actions.  However, the atomicity of a widget's
>     action (minute graphical action unrelated to the
>     application-related action of the ultimate widget) and
>     the static nature of the widgets necessitate several
>     point-and-clicks to achieve the ultimate goal; which
>     binds the user to the perceptual level.
>
> Acme is an example of a GUI which allows the things you
> claim as an "impossibility". You do exactly "form
> mega-widgets as and when needed, dynamically, the way one
> forms commands from keystrokes".
>
> There are only 3 "widgets" in Acme (that I can think of
> right now anyway):
>
>  * "layout boxes" which allows the manipulation of windows
>  * scrollbars which allow the scrolling of windows
>  * any piece of text which allows executing commands
>
> Since you can manipulate text (it is a text editor after
> all) you can "dynamically" manipulate that last widget to
> your hearts content.

So it is the text-editor aspect of the interface, not its
graphical aspect, that gives it its power.

> Also Acme seems to fulfil your "Editable User Interface"
> concept. In fact in a 1994 usenix paper [2] Pike describes
> it as a "User Interface for Programmers", as opposed to a
> "text editor". It is by design not just a text editor, but
> also a window system and shell. Being a plan9 program it
> communicates with other processes by being a file server,
> but the unix clone (Wily) does so via unix domain sockets,
> the paper describes what can be done via that interface.
>
> Of course anything that uses vi must be good, so please
> don't take this as criticism, just as pointers to a body
> of similar work.
>
> [1] http://www.cs.bell-labs.com/magic/man2html/1/acme
> [2]
http://www.usenix.org/publications/library/proceedings/sf94/full_papers/pike
.pdf

To quote from pike.pdf [2]:

    A deeper comparison is that the Macintosh uses pictures
    where Acme uses text. In contrast to pictures, text can
    be edited quickly, created on demand, and fine-tuned to
    the job at hand; consider adding an option to a command.
    It is also self-referential; Acme doesn’t need menus
    because any text can be in effect a menu item. The
    result is that, although a Macintosh screen is certainly
    prettier and probably more attractive, especially to
    beginners, an Acme screen is more dynamic and
    expressive, at least for programmers and experienced
    users.

The mechanism to activate a piece of text (mouse clicks) is
not the essence of the interface -- its editable-text nature
is.  So Mr. Pike endorses my claim.

Simulik from www.mathworks.com gives an idea of what a
dynamically-combinable graphical interface would be:  it
involves creating graphs using icons.

And thanks for bringing [2] to my attention -- it was
interesting to read.

--Suresh



Reply via email to