Brilliant and very useful for FreeBSD, IMHO

[Terry Lambert]

Jakamara Bruce Jensen wrote:
> Terry Lambert wrote:
> > Michael Josefsson wrote:
> >>Hear, hear! Well spoken. If we consider the system as a tool, then let
> >>someone set it up and let the users use it. Full stop. It's a militant
> >>mode but ...
> 
> > Too militant.  This is like saying you should need a sysadmin
> > for your TV in order to set the SAP, Brightness, Contrast, and
> > other software settings on the TV.
> 
> I don't see it that way.
> Every user can fiddle around with own his settings for the look of his
> wm and other things and settings.
> But if he breaks it, he only has to switch back to standart, and he has
> a running system back agein.
> And no user has to care about the visual etc 'tunings' an other user has
> made.

The scope of the "fiddling" with software settings is too large;
I guaranteed you, I can break things in such a way that it's very
had to get back to default settings, when it comes to software.

The point of user interfaces is to abstract complexity; it always
has been.  Whether or not this is possible, or the extent to which
it is possible, if it is possible, really defend on how well the
parts fit.  Basically this comes down to normalization.

One of the big strengths of FreeBSD is the rc.conf system; it is,
if we are to be honest with ourselves, a "registry".  But it is
also a weakness: configuration data for sendmail is not applicable
to postfix, and configuration data for either one is not applicable
to qmail or exim, etc..  In other words, the pieces don't fit very
well, and this drives up abstract complexity, which in turn drives
up interface complexity in exposed interfaces.

The only really effective approach to this is manual abstraction,
which is difficult and time consuming -- and tends to lose features
for users.  It works by abstracting common functionality out, and
then providing translation between a normalized model of the abstract
functionality, and then applying any configuration changes to the
normalized model, instead, and then using the abstraction model to
generate configuration data based on that for the underlying objects
doing the actual implementation.

If you want to cast this in C++ terms, the abstract model is a pure
virtual base class, and each possible application that fulfills the
role for the component is an implementation class, and you only get
to talk to it via the member functions of the pure virtual base class.

The problem with this approach, apart from spackling over any feature
that's not shared between all implementations, is that there is a
coupling latency between the abstract and implementation(s), and
there is also, potentially, a cache coherency problem.

The only way to deal with the former is to make the applications
operate directly from the configuration store (as NeXTStep did with
their "netinfo" database), and to internalize the normative model
into the applications themselves, so that they do the work of taking
the data from the common abstrct form, and interning it or externing
it (e.g. in the case of statistics gathering).

Now ignore the fact that this is nearly an impossible task for things
like "sendmail" and "postfix", and concentrate on something simpler,
like window managers with comparable functionality.  And then look at
the outcry when RedHat did *exactly* this, and spackled over the
differences in "look and feel" between KDE and Gnome.

The RedHat effort is actually the tip of the iceberg; both of these
window managers allowed a user to select the other, as a "user option";
but suppose the user selected "twm" from "KDE"?

The answer is that there is no reverse process.  The abstract set
of features that maps the intersection of functionality between the
window managers, at that point, is small enough that the idea of
switching back and forth is no longer reflexive.  If you consider
it as a grammar, you would say that "the available command set in
twm is Turing incomplete".


And *this* is why you must restrict user choices, if you wish to
increase usability.

I recommend:

	Context and Consciousness: Activity Theory and
		Human-Computer Interaction
	Bonnie A. Nardi, editor
	MIT Press
	ISBN: 0262140586


	The Humane Interface: New Directions for Designing
		Interactive Systems
	Jef Raskin
	Addison-Wesley
	ISBN: 0201379376


	Designing the User Interface 
	Ben Shneiderman 
	Addison Wesley Longman Higher Education 
	ISBN: 0201694972


	The User Interface Hall Of Shame
	http://www.iarchitect.com/mfame.htm [Note: currently down]


Note that many UI designers, who are not Computer Scientists, have
no idea about the normalization process, and generally "wing it".

-- Terry