dubuntu-team team mailing list archive

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

hi charl

first of all i'd like to note that your 'requirements' correspond to my
'search' categories and your 'categories' to my 'normal' categories. a
'search' category looks like a normal but can contain only links to
'normal' items or child 'search' categories. adding a search category is
like creating a new filesystem subtree on top of an existing one.
once you put a package into a normal category you can include it into
any 'search' category.

i can see at least two problems with your model. first no matter what
user specifies as requirements he will be presented with the same
categories. but the same set of packages can be arranged into a tree in
many different ways so it is not flexible to 'hardcode' only one
possible layout. in my approach for items inside any category (including
the root category or a search category) a new layout can be defined
using search categories.

second, user may need to apply additional requirements at any level not
necessary at the top one. but your approach doesn't contain such option.
if it would you'd have to attach a list of possible filters to every
category but it's too complex for user and in fact is analogous to my
search categories.

one thing almost all newbies do right is file system navigation. it can
be done just by clicking. user doesn't need know anything about filters
etc. why not to let him do the same thing in our manager? instead of
asking user to enter his requirements we can present all possible
requirements as 'search' or normal categories so he won't need to enter
anything - he will just make a click. when user has an additional
requirement that we have not added yet he can use search function and
create a new 'search' category from this requirement (like you create a
new search folder from your search criteria in evolution).

a dialog between user and the installer can be displayed as a tree.

          [root]
            /\
           /  \
          /    \
    [req 1]    [req 2]   ...
       |         |
    [opts 1]   [opts 2]

if user specifies requirements [req 1] he gets a list of options [opts
1]. if he thinks that this list is too general he can specify additional
requirements.

          [opts 1]
            /\
           /  \
          /    \
    [req 3]    [req 4]   ...
       |         |
    [opts 3]   [opts 4]

when user understands that he doesn't want to go any deeper he can hit
[add everything/recommended] at his current level. or he can go even
further. i hope now you see that your idea of questions-answers has a
direct mapping into my model but my model is much more flexible. so my
user will always have a possibility to specify additional filter at any
level but he can live without it if he's satisfied with those filters (i
mean 'search' categories) that we prepared for him. on the other hand
your user *must* use a filter in order to take advantage of filtering.
in my model filtering is implemented underthehood so user doesn't need
to know about it. search categories don't have any visible differences
from normal ones. modifying current set of filters means
adding/deleting/modifying a search category. it's as simple as creating
a directory and populating it with links or constructing a search
criteria like you do it in synaptic.

another note. in your scenario you show user a set of 'questions'. but
what if he doesn't understand/like your questions (even after reading
all descriptions)? ok, you can provide him with a long list of possible
sets of questions but he will have to look through at least some of them
to find a set that he likes. too much work for a newbie. users don't
like using dropdown lists, textboxes, radio buttons, checkboxes - they
like clicking on buttons/icons and it's better when these buttons/icons
make up a tree-like structure.

lets imagine that we have a category 'development' with this items:

- desktop
- web
- embedded
- ...

what if user doesn't understand such classification and is too lazy to
read approp. descriptions (or maybe his level is too low to understand
them). maybe he just started learning his first language and doesn't
know what 'desktop development' means. in my approach i can add a search
category e.g.

- desktop (normal category)
- web (normal category)
- embedded (normal category)
- ...
- language specific development (search category. subitems: c++|pascal|
java|etc)

in my approach i can add a search category next to any normal category.
i can add them everywhere. i can create deep subhierarchies using only
search categories and can extend 'normal' hierarchies with them.

in short you separate requirements from categories but i place them
together and it looks much more simple to a newbie.

regards,
jay


On Tue, 2009-07-07 at 15:24 +0200, Charl Wentzel wrote:
> Hi Jay
> 
> As you said I don't think our ideas are far appart, so let's find that
> common ground.
> 
> I have both "requirements" and "categories" where you seem to have only
> "categories".  I have both and here's why...
> 
> a. Requirements
> This is the "natural language" filter, if I can put it that way.  When
> you want to do development you have a "kind of/sort of" idea about what
> you want to achieve.  
> 
> E.g. I want to do develop a C++ application for the Gnome desktop.  At
> this point you haven't even considered that you might need an IDE,
> compiler, etc.  This is pretty much the starting point of a newbie.
> 
> When you go into Synaptic with this idea, you'll be absolute
> overwhelmed.  There are thousands of packages out there, which of them
> applies?  *&%$#@
> 
> So the purpose of requirements is to pre-filter all the possible choice
> to only those that are relevant.  So instead of having 1000 options you
> know have 50.
> 
> In other words, if you want to do php/web development then Kdevelop
> might not be relevant under the IDE category, so it won't be shown.  In
> stead Quanta Plus and BlueFish will be listed.
> 
> If you're not interested in specifying requirements you could just click
> "select all" and go to the next phase.  But then you'll get everything
> in every category.
> 
> b. Categories
> This is now where you start to categorise the tools for the user into
> logical classifications, e.g. the IDE, compiler, etc.  Note that he will
> have to make at least one or two choices, e.g. he'll have to select the
> IDE, but there could be defaults for the compiler and debugger.
> 
> Like you indicated, this where the user will now have the option to
> drill down as deep or as shallow as he wants to.  (I didn't want to put
> it in my original e-mail to keep it simple for now.)
> 
> Note that this in a way is also "training"!  For each category there
> will be at least one or two paragraphs explaining what the items from
> this categorie is, e.g. An IDE is a...., a compiler is necessary to...,
> etc
> 
> What you are doing is is teaching him about the things he need and how
> it all fits together.  (He didn't know he needed and IDE or a compiler)
> It is his choice to read/learn.  He could let the system make the
> default choices for him, but if he wants to learn he could read about
> each choice and make a concious decision.
> 
> I don't think this is too complex for a newbie.  Afterall if you don't
> know what an IDE or a compiler (or at least want to learn what it is),
> you should be doing programming in the first place!!
> 
> SUMMARY:
> Hiding too much of the "complexity" from the user is not a good thing.
> Rather structure it for him and help him understand what it is that he
> needs.  Now you are "teaching him to fish".
> 
> Note that any element could be linked to more than one requirement but
> only to one category, e.g.:
> 
> Eclipse IDE:
> Requirements - Language: C++, Java, Python - Platform: CLI, Gnome, KDE
> Categories - IDE (Sub-categories would also apply)
> 
> In the end you are always presented with the same categories, but the
> items listed in these categories is based on what you are trying to
> achieve instead of a vast sea of options.
> 
> If you skip the Requirements step, you will be presented with IDE
> options that may not apply to what you are trying to do.  And you'll
> have to make "requirement" choices later any way.  But it is your
> choice!!
> 
> We could even break requirements up into sub requirements, e.g.
> If you make a selection on the target enviroment, e.g. Web application,
> you may only be presented with HTML/PHP/Python as language choices
> instead of C++/Pascal/etc...
> 
> In another e-mail I'll explain how I seen this being laid out in a gui.
> 
> That's a mouthfull!  What do you think?
> 
> Charl