dubuntu-team team mailing list archive

[Ryan Macnish <nisshh@xxxxxxxxxxx>]

Yes Jay it is called a treeview in GTK. I havent thought of doing it that way before now, but it does seem logical to have an advanced user mode with the treeview, as well as a basic user mode with charls idea, maybe we also include your idea of being able to install whole categories.

> From: jay.27182818@xxxxxxxxx
> To: charl.wentzel@xxxxxxxxxxxxxx
> Date: Fri, 10 Jul 2009 16:54:58 +0300
> CC: dubuntu-team@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Dubuntu-team] GUI design principles
> 
> 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
> 
> 
> _______________________________________________
> 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

_________________________________________________________________
Looking for a new car this winter? Let us help with car news, reviews and more
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%2Ecom%2Fcgi%2Dbin%2Fa%2Fci%5F450304%2Fet%5F2%2Fcg%5F801459%2Fpi%5F1004813%2Fai%5F859641&_t=762955845&_r=tig_OCT07&_m=EXT