Re: A couple suggestions to improve debian installation (long)
Ian Jackson:
If anyone meets the following criteria, or could meet them, I'd like
to hear from them:
* Hot-shot C/C++ programmer.
* Good understanding of user interface design especially for new
users.
* Thorough understanding of dselect's structure and Debian's
conflicts and dependencies arrangements.
* Has a significant amount of time on their hands.
I fail on points 2 and 4.
I suspect that many of us fail on point 4. However, maybe we can help
you out on point 2. Personally, I've still not mastered all of
dselect's features, so perhaps I can pretend I'm a new user.
First and foremost, dselect falls into the category of program where
every keystroke is an action. Ideally, this means that each key
should always have the same kind of action (so there's less things to
memorize), and that the mapping between key strokes and actions
should match those of similar programs.
For example, the "space" character is overloaded with multiple
meanings in dselect -- and these meanings change significantly in
different areas of dselect. This is should be changed. [Currently,
this behavior tends to be on keys like '.' or ' '].
In my opinion, similar programs include things like info, gopher and
lynx (which display lots of information and allow you to select
various options). These, in turn, build on the basic browser design
of `more`. Thus, 'space' should probably mean the same thing as 'page
down', and 'enter' should probably mean something like select or
activate of whatever item the "cursor" (or "focus") is currently
positioned on. Note that this implies that there should be exactly
one user-positioned highlighted point on the screen. [pine/pico/ae is
another interesting model, but more oriented towards entering large
bodies of text -- this isn't really necessary for dselect.]
Here's the significant tasks that I typically want to do with dselect:
advance to the next screen of information
position my cursor/focus on the next/previous package
search for a specific package
get more detail on the current package
add packages to my selection list
delete packages from my selection list
mark certain packages so that dselect won't automatically select them
look at the list of packages which have been selected but not installed
look at the changes introduced in this session
look at the list of installed packages
look at the list of selected packages
look at the list of locked-out packages
look at the list of base packages, ...
finish -- keeping changes
finish -- abandoning changes
Um.. I'd also like a "beginner (verbose)" and "advanced (terse)" way
of presenting the information. Here's how I might design them:
----------------------------------------------------------------------
Beginner mode should present everything about the current package as
one big virtual document. There should be specific on-screen buttons
for common actions (next, previous, select, de-select, done). Upon
selecting a package there should be a "dialog" popup in the middle of
the screen (making it visually apparent that the user is still in the
process of selecting this package). Options here should be: ok,
cancel.
Intermediate mode should be relatively close to the current
mechanism -- a line=package display.
Advanced mode should have the top line with
? for help x disabled n of m selected
The rest of the display should be organized along the lines of ls -CF
-- a multi column display, listing only package names, with a single
character indicating status. Note that there should be a distinction
drawn between packages selected from earlier sessions and packages
selected in the current session. And, for packages selected in the
current session, a distinction between an autoselected status and a
manually selected status. Ideally, an autoselected item would become
de-selected if all the packages which brought it into the session are
dropped from the session. Presumably, hitting return on an item would
bring up a fuller display of information about the item (perhaps along
the line of the beginner's mode -- except that the options would be
mildly different).
----------------------------------------------------------------------
Then again, I'd seriously think about a presentation mode which is
basically an html form -- anchors with hrefs to lead to the various
parts of the system, button default status indicating whether the
selection is currently selected or not, etc. I don't think that radio
buttons are up to dealing with dpkg conflicts, so there'd still have
to be a conflict-resolution mode. This style of design would have to
be "state free" so there'd have to be some final commit step that
actually puts the changes into the system. [Note: I'm not sure I'd
implement dselect this way, but I find that thinking about system
design alternatives gives useful insight into what's going on. Also,
"state free" is a nice paradigm to keep in mind.]
I'm sorry I don't have a more concrete design proposal (and that I
don't have the time to tackle the project myself). I hope some of
this is of use.
--
Raul
Reply to: