[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Dselect novice mode proposal

Lee Olds writes ("Re: Dselect novice mode proposal"):
> I finally got a chance to take a good look your dselect proposal today.
> I think it is a very big improvement.  I think this "novice" mode might be
> powerful enough to replace the existing dselect.  Is there anything that
> the existing expert mode offers that the proposed novice mode doesn't?

Yes: examining the status of all packages at once; seeing the exact
status of the package (the state of the various flag bits); the
teleport-you-to-a-new-screen dependency resolution (which is alarming
for new users but IME good for experts).

I'm not saying that all experts have to use the old interface, just
that I don't necessarily think it should be removed.

> Here are some of my opinions, comments, and recommendations.  There are
> four of them.  Shoot em'down or praise them...  ;-)
> 1) The program should ask the user to confirm any action that starts the
> actual download, check, un-pack, install, or remove process.


> If the user chooses not to proceed, give a message something along the
> lines of:
>  [ telling them requested changes are remembered ]
> This implies there will need to be something like a "commit" or "do it"
> menu item somewhere.

No problem.

> 2) When selecting by Priority or Section, put in another menu layer,
> rather than requiring the user to cycle through all the options.  This
> would be especially useful when people want to upgrade, install, or
> remove just a few packages.
> Something along the lines of:
> +------------------------------------------------------------------------+
> |  Install and/or upgrade package(s) or system                           |
> |  Which section do you wish to upgrade ?                                |
> |  +------------------------------------------------------------------+  |
> |  |  * base            Base system                                   |  |
> |  |    mail            Mail utilities, etc..,                        |  |
> |  |    x11             etc...                                        |  |
> |  |    etc...          etc...                                        |  | 
> |  +------------------------------------------------------------------+  |
> |        Press <Return> to choose section,   <Esc> to Exit               |
> +------------------------------------------------------------------------+
> Where the "*" could indicate that changes have already been requested
> in the base section.

What if they miss a section out ?  Don't install or upgrade anything
in that section ?

> 3) My screen style preferences:
> I think that a dialog box style without a mouse is not as intuitive
> as other options.  Namely, tabbing between screen sections doesn't
> seem obvious.  Assuming that a mouse is not required, I prefer another
> style of interface.
> Here is my prefered style:
> <Esc> always back's out of the screen. (Except for the top level menu,
> which should have a Quit menu item.)
> <Return> always activates the selected menu item.
> Select the menu items with up and down arrows.  Also support vi, emacs,
> and other popular cursor movement keys for traversing menu items.  And
> where appropriate support the Page-up, Page-down, Home, and End keys.
> This style requires that the user remember just a very few simple
> concepts.  These concepts can be described on each screen with little
> use of screen real-estate.
> To conform to this style, the Individual Package selection screen
> could place "Go Back" and "Concise List" on the menu,  And the
> "Concise List" could make the "OK" or "Done"  action Accessible
> with a Hot Key, and putting the followin message in place of the
> dialog buttons:
>   Press <D> when done,  <Return> for details on a package,  <Esc> to Exit.

That sounds reasonable.

> 4) It would be nice for the startup screen to display the access-method
> information as well as the other information.  I still like having a
> separate menu item for selecting the access method.

This might well be possible.

> Over all, I like very much what you have proposed.  I think it will be
> a big improvement.
> (I just started reading debian-devel a couple of weeks ago.  Ian, you
> must be putting in tons of time on this!  Thanks to you and many others
> for the time and excellent work that you are putting into project!

Thanks :-).


Reply to: