dubuntu-team team mailing list archive

["Jay I." <jay.27182818@xxxxxxxxx>]

hi charl

> > 2. Consider experienced users
> > Remember that you don't stay a newbie for long.  As you grow you want to
> > learn more and want to get into more detail.  So far your proposal does
> > not work for an experience user.  

i do consider experienced users and my previous emails in fact show it.
i just made more accent on newbies to show you that your proposal is too
complex for them. lets consider this subtree:

development/
  /desktop
    /ide's (anjuta, eclipse)
    /compilers (gcc, ...)
    /platforms (gnome, ...)

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+

'gtk+' will contain everything an experienced user will need to install
in order to start writing apps for gnome.

but a newbie will only need development/desktop/platforms/gnome (a
search category), because everything he knows is that he wants to write
gui apps for ubuntu and ubuntu uses gnome by default.

there's one little thing that i haven't touched yet. when user will see
all the cats under development/desktop he will first read descriptions
provided for 'ide's' and 'compilers', figure out that he doesn't
understand anything and only then he will read the description for
'platforms'. not very good. this is where our 'levels' come in. 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

when a 'newbie' will navigate to development/desktop he will see
'platforms' listed first in normal color and all the rest grayed out
like inaccessible menu items. he'll still be able to navigate to 'ide's'
but most probably he'll stick with 'platforms' until he becomes more
experienced.

a pro in web development may know nothing about desktop development so
when he starts the installer he will select 'pro' but when he steps into
'development/desktop' he will probably need the installer to treat him
as a noob so at every step user may need to specify his level once
again.

after working for some time with his user the installer will know that
e.g. he's generally a pro but in desktop development and 3d graphics
he's nothing. this knowledge will allow the installer to treat his user
right wherever he goes.

a couple of notes about installation. as i mentioned earlier we will let
user install entire categories. so if he wants to write his c++ programs
inside eclipse ide he will be able to install the entire search category
that contains eclipse itself, cdt plugin, related docs, examples,
templates - everything he needs to start programming in c++. so he won't
need to understand how eclipse works, what docs cover c++ specific
topics etc. i think we are very close here but i don't need to introduce
any new concepts like 'package groups' - my 'search categories' provide
all needed functionality right out of the box.

second, if we go synaptic way then after user is done with selecting
packages/categories we will show him a list of packages/categories he's
going to install. they can be grouped like this:

<<<
Development | Desktop | Gnome | C++ :
  [a list of packs/cats selected in gnome/c++]
Development | Web | ... :
  [...]
<<<

this can be ok. but do we really need to wait for user to finish
selecting before we can start actual downloading/installation? when user
selects an item for installation we can ask him whether he wants to
install it right now or not. if he says 'yes' we will start
downloading/installing immediately and he'll be able to go on with
selecting another packages/categories. i think this approach can save
user his time especially when he's got a slow connection and needs to
install a lot of packages. at any moment he'll be able to see what's
going on in a dialog similar to 'Downloads' in firefox. if he needs
something synaptic-like then when selecting a package he will chose [add
to installation queue] instead of [install]. in this case the
package/category will be added to the queue but the installer won't
start downloading until user explicitly tells him to.

a note about gui. for advanced users answering questions (like in my gui
design) can quickly become annoying so for experienced users it'd be
better to display a treeview (or how it's called in gtk?) on the left
and let him navigate through the hierarchy the same way he does it in
nautilus.

ps. i've got a deadline in 5 days so i'll be working hard on another
project and won't be active for a while. in the meantime i'll try create
a detailed explanation of the database layout.

regards,
jay

On Fri, 2009-07-10 at 09:47 +0200, Charl Wentzel wrote:
> Hi Guys
> 
> Ok, so I thought long and hard about Jay's comments. And are willing to
> concede on a few issues, but not completely.  So instead of trying to
> design a GUI, I thought we should rather agree on a few principles first
> and let that be our guide...
> 
> 1. Simplicity
> On this one, your design was better.  I agree that my proposal could be
> overwhelming to a complete newbie.  Just remember that this is a
> two-edged sword.  
> 
> You need to consider simplicity of the back-end as well.  Often when you
> create a very simple frond-end you add complexity to the back-end.  If
> the back-end is too complex, you scare of contributors and that could
> kill a project.
> 
> Not saying that it is the case here, but we need to consider both sides.
> I'll settle for a good balance between the two even if it requires a few
> compromises.
> 
> 2. Consider experienced users
> Remember that you don't stay a newbie for long.  As you grow you want to
> learn more and want to get into more detail.  So far your proposal does
> not work for an experience user.  
> 
> An experienced guy would like to give a few basic requirements and then
> look at everything that comes out.  But you don't want to simply give
> him a list of all the packages that match his criteria, then you're no
> better than Synaptic.  Hence my categorised display which at least sorts
> the packages in logical/manageable chunks.
> 
> So maybe an option where you can turn "categorisation" on and off.
> Maybe be put the packages in the same tree as the categories.  Then you
> can choose to see just the packages in a long list or grouped in a tree.
> This could in fact remove at least one window from my design!
> 
> And of course to limit the results (like you said), category/application
> type could be a search category/requirement as well.  But it doesn't
> negate the necessity of showing categorised results. 
> 
> 3. Linux is Choice
> This is very important!  Be carefull of making too many choices for a
> newbie, this goes against one of the core philosophies of Linux.  E.g.
> if a newbie enters Gnome / C++, you can't simply provide him with
> Eclipse as the answer...
> 
> a. You'll get flamed by the Anjuta and Kdevelop guys for not giving them
> a fair chance and you'll make them unwilling to contribute to this
> project.  
> 
> b. Even a newbie will have to choose something!  Of course you don't
> want to overwhelm him, so forcing him to understand and choose compilers
> and debuggers right from the start is a bit much... conceded! But he
> needs to at least choose an IDE for himself... even if he chooses to
> take them all!!
> 
> c. It's our responsibility to teach them.  In Linux it is best if you've
> done your research before you ask a question.  We want newbies to "grow
> up" with this in mind, in other words: Equip him to make a choice, but
> don't choose for him.  
> 
> So what we're after here is a balance, not an extreme.  We'll have to
> make it flexible so you can choose the level of detail you want.
> 
> I don't think these principles should be too hard to agree upon.
> 
> To be honest, I don't either one of our proposals currently match all of
> these requirements... or at least not in what was explained about each.
> 
> Regards
> Charl
> 
> 
> _______________________________________________
> Mailing list: https://launchpad.net/~dubuntu-team
> Post to     : dubuntu-team@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~dubuntu-team
> More help   : https://help.launchpad.net/ListHelp