(any UI
that's suitable to most of pretty much any market has an
excellent chance of being somewhere between unpleasant and unsable
for me)
Well, since I personally wrote the GUI for KryoFlux, I'd be very
interested in what would work for you, even if you don't intend to
use whatever changes we might make.
Well, the first thing is that (a) it must be possible to get it out of
reverse video and (b) it must be usable in that mode. Large areas of
bright on the screen are not something I can get along with. ((b)
seems self-evident, but there are a depressing number of interfaces
that satisfy (a) but end up breaking somehow when that's done,
typically by displaying important things black-on-black or some
operational equivalent such as very-dark-blue-on-black.)
The next most important thing (in your case, see my next paragraph) is
that the GUI must not be the only way to do things. GUIs are pretty
much useless as components and mostly demand a user to drive them.
This makes it impossible to, for example, script operation with input
and/or output redirected.
You write that the GUI "just uses the existing software supplied", so
this is mostly a non-issue in your case, at least provided that
existing software is documented (which I wish I could assume it is but
have far too often run into cases where it isn't; what you've said
elsewhere makes me think this isn't an issue in your case either).
Third is that it must not force me to bounce back and forth between the
mouse and the keyboard. I can deal with - indeed, I've written -
interfaces that are entirely, or almost entirely, mouse-driven. Ditto
keyboard-driven. But interfaces apparently written under either the
assumption that I have a third hand for the mouse or the assumption
that I type with only one hand kill whatever productivity I might
otherwise have had under them.
The last of the things that bother me is substantially vaguer: it must
not give me the impression that it's dumbing things down for me. Being
able to see that there must be $THING lurking underneath which might be
useful or even just interesting, but keeping me away from it, is a sure
way to have me swearing at, rather than by, the software. (This is
probably related to my insistence on open-source OSes; while I don't
want to be, for example, poking device registers routinely, not being
able to do such things even experimentally upsets me.)
The GUI was designed to be extremely easy to use, even
for
non-technical people such as those in libraries and archives.
This may be an issue. Easy to use for novices usually means crippling
for experts. (Usually. I'm sure there are exceptions; indeed, I think
I've seen a few, though I can't think of any offhand.) Again, perhaps
it's just me, but, historically speaking, I usually find it takes
fairly little time for me to become expert enough to be frustrated by
"you don't need to know that" (or, more accurately, "we don't think
you
should want to know that") interfaces.
It would be nice to document it completely as you
want, but we have
very limited resources, and unless there is much demand for
something, we would find it hard to prioritise it. I think you might
agree that your requirement is a little unusual... :)
Oh, certainly. I'm not under any delusion that my ideal system is
likely to be forthcoming anytime soon!
But, you did ask. :)
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at
rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
