Date: Thu, 10 Apr 2003 07:34:27 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Jakamara Bruce Jensen <jakamara@web.de> Cc: +FreeBSD en advocacy <freebsd-advocacy@freebsd.org> Subject: Re: Brilliant and very useful for FreeBSD, IMHO Message-ID: <3E9580F3.D5FF8FCD@mindspring.com> References: <C251D185-6A71-11D7-B7EF-0003939BCCF2@isy.liu.se> <3E93F627.95F34FCD@mindspring.com> <3E956C60.20700@web.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E9580F3.D5FF8FCD>