[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
Re: Interface Extensions
- To: <bobp>, <heh>, <marcs>, <ravi>, <tribble>
- Subject: Re: Interface Extensions
- From: Roger Gregory <roger>
- Date: Tue, 26 Sep 89 16:30:48 PDT
- Cc: <us>
>From bobp Mon Sep 25 13:55:53 1989
Subject: Interface Extensions
Actually, I'm not really worried about featuritis
In fact, bad extensions frequently
seem as though they were extracted from some kind of Interface
Construction Set: an icon here, a button there, but with no thought
behind the usage.
I agree. Actually the problem with mediocre designs is not so much really
bad features, as it is many random features that don't fit together into
a coherent whole.
Placing a disk icon in the trash to eject a disk,
on the other hand, is a really BAD, poorly thought-out "extension".
I got fairly excited about your idea of using inclusion lists
themselves to represent an historical trace, but apparently the
idea's been previously considered -- I hope we can pursue this.
I'd like to find out what the problems were, there might be a right way
to do this, even valid objections often just refute a particular implementation
and not the concept.
I strongly favor Roger's notion of some sort of graphical representation
(perhaps this is a 1.1, or even 2.0 addition). I'm not sure a
tree is the best way to represent the notion, but if it is, I
really like the way Terri's handled user-traversible trees in
her genealogical application.
A bit of history here. We have always drawn historical trace as trees, and
I had always assumed that the interface would be graphical. This nicely avoids
all the nomenclature problems and may be intuitive to naive users (or even mac users),
that is subject to test. The question of implementation difficulty,
I don't have a quick answer, but it might be simpler to code than to document
a hack. It certainly will be nicer to support.
Finally, although I was a badge-bearing deputy in Apple's Interface
Police for years, I'm not necessarily married to their Human
Interface Guidelines, particularly across product platforms.
Since we have a wider constituency than just Macintosh users,
it's important to consider the broader issues relevant to all
of our users, including Sun and Windows users (although I have
no idea what sort of standards exist in those communities). Greg's
suggestions regarding vi conventions, for example, seem quite
appropriate for vi users.
Conventions are important to understand and it seems foolish to gratuitously
flaunt them. My major complaints about the Mac interface is that so much
functionality is hidden with meta key stuff that isn't obvious (except to Johan).
Emacs hase the same problem but it does have everything documented online, and
the user population is different. So I would have to say that emacs does a
better job than Mac given its constraints. This is probably mostly due to
the lack of constraints on the Mac, which cause my expectations to be far
higher for it.
Vi seems a poor model to follow, even for vi users (I'm one though I don't like vi
I tend to use it 30% & emacs 70%).
PS (Questions for: Roger->what kind of interface do we expect
to be predominant among our Sun customers? and Ravi->are there
published interface guidelines for Windows?)
I expect that Sun interfaces will be in flux, due to the delivery of OpenLook.
I'm implementing for OpenLook, since it was invented by sun with no experimental
or psychological evaluation of its design, I'd be surprised if it is much
better/worse than the others. It certainly doesn't feel particularly wonderful/awful.