Re: Interface Extensions

[Roger Gregory <roger>]

>From bobp Mon Sep 25 13:55:53 1989
	Subject: Interface Extensions
	
	Actually, I'm not really worried about featuritis 

I am.

        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.