dubuntu-team team mailing list archive

[Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>]

Hi Jay

There's only two issues I would like to highlight here:

> > an experienced user will know what particular ide/compiler he needs
> so
> > he'll be using 'ide's' and 'compilers'. inside compilers/gcc we can
> list
> > several categories with platform-specific packs containing all
> related
> > libs and headers. e.g.
> > 
> > /compilers/gcc/gnome/gtk+
> > 

I have two issues with treeviews:

1. Number of sub-branches

To me it is critical that a treeview does not have more that about 3
levels... ever!  Simply because it becomes hard to keep track of what
you are doing.  If you want to make it difficult for newbies this would
be the wrong approach:

/desktop/gnome/compilers/gcc/gtk+

I'm not saying that this is what you are actually proposing, but I would
like to ensure that we don't go that route.

2. Parent-child relationship

Tree views are best for parent-child relationships where sub-branches
are subgroups of the parent and not an independent concept, e.g.

desktop/gnome is parent-child since gnome is a subset of desktop, same
wtih compiler/gcc

gnome/C++ is not parent-child and could therefore also be C++/gnome.
Everybody would have there own way of arranging it.  I know you
suggested exactly that, that each guy can build the tree the way he
wants, but when you are reviewing someone else's stuff, this will become
an issue.  Also, your'e adding a new step - building the tree.

I prefer a set of "flat" branches from root with only parent child
relationships.  It eliminates all possible confusion, e.g. 

/root
 /target env
   /gnome
   /kde
   /cli
 /language
   /c++
   /java
   /python
 /tool category
   /IDE
     /Eclips
     /Anjunta
   /Compilers
     /gcc
     /townsend
   /Debuggers
     /gdb
     /valgrind

* You don't have to build the tree, everything is already there
* There is no confusion on the order of branches, everyting is
parent/child
* You can hide some of the branches from newbies if you need, or simply
preselect defaults, especially in the "tool categories" branch.

And there probably is a better name for "tools category"

> when
> > starting the installer user will be asked to select his level. we
> can
> > introduce these levels (just an example):
> > 
> > newbie
> > experienced
> > advanced
> > pro
> > high pro

I have again two issues here:

1. novice/exerience only

I don't believe in having more than these two levels.  It is yet another
choice a user have to make to which he does not understand the outcome
unless he actually tries it.  And its just too much!  It adds to
confusion.

2. simple manipulation of user interface

Taking my proposed interface as an example here (just to illustrate).
There are only three things that you can change from "extreme novice" to
"experienced":

- hide/show of search branches
For a novice you might want to hide/pre-select/disable(gray) some of the
branches to eliminate complexity

- enable/disable categorisation of search results
This effect only the way in which the search results are displayed.

- minimise/maximise package details window
Experienced users will be interested, but for a novice it might
overwhelm.

All of these should be easily accessible on the window and not only via
the menus, e.g.

- "Novice" / "experienced" radio button above the "search category"
window
- "Show Categories" tick box above the "search results" window
- "minimize" button on most windows, but still showing there header bar
with a "maximize" button to reinstate.

So even if you have selected "novice" mode and the system configures the
the windows in a certain state, the user can still see all the options
available and turn any one of them on or off.

Regards
Charl