dubuntu-team team mailing list archive

[Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>]

Hi Jay

I said we shouldn't, but I couldn't resist.  This is just such
stimulating debate...

> first of all i'd like to note that your 'requirements' correspond to my
> 'search' categories and your 'categories' to my 'normal' categories.

Great!  So we agree on something.  

Search Categories / Requirements:
  Question: "What does this apply to?" / "What do I want to do?"
  Answer: "C++, Gnome, etc"
This relates to the the end-goal, what you want to do/achieve.

Categories:
  Question: "What is this?" / "What tools do I need?"
  Answer: "IDE".
This relates to what I'm going to need for the job.


>  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 agree that each item must be assigned to a normal category.  This
defines much clearer what each item is.  Apt only devides it into
subjects at most, e.g. "programming". That is far to vague, so we're
already improving the idea.

One way of seeing the problem is a subtree classification of items under
the normal category.  If you have a language "layer" in the subtree,
e.g. C++, Python, Java, then the Elcipse IDE will be present under each
of these branches.

I think its actually more of a matrix!  Categories/pacakages on the
left, Requirements (search categories) on top.  Refer to my initial
e-mail.  This is the ways a "spec sheet" is normally presented, e.g.
when you are comparing different cars/computers/programs with each
other.

> 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. 

NO!  The categories you'll be presented with will be determined by the
requirements you select.  E.g. if you select Web development as a
requirment, you'll have a "web server" category, which will allow you to
select which (or whether at all) you want to install a web server.  The
same does not apply to doing Gnome desktop development.

> 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. 

I'm not hardcoding "search categories".  Step 2 merely presents the
packages that meets the specifications in there categories.  This step
is actually "package selection".  To avoid giving the guy all the
packages in one long list, the are grouped in categories.  

At one glance you see all the different types of things (RELEVANT to you
requirement) that you can install, i.e. IDE, compiler, web server, etc.
You also have a choice how deep you want to dig or into which categories
want to dig at all.

> 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.

I don't see how this really differs.  You insist in doing it a tree, I
insist in splitting it up into two steps.  We achieve the same.

> 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.

Actually the requirements is linked to all the categories.  You simply
define it in the frist step.  The categories and packages that match
these search categories are then displayed in step two.

Remember step one is: "What do you want to achieve?" - Filter everything
available accordingly.
Step two is: "Make your selection of tools based on this requirements" -
packages selection (logically organised in smaller categories)

The reason for splitting it is to prevent you from having to make the
same selection over and over, e.g.
Gnome / IDE / C++ 
      / compiler / C++

Now you had to select C++ twice because you didn't do it from the start.
Search categories must be applied in the beginning.  Categories is the
last step.  

If you're going to do C++ and Gnome development you need to specify at
the beginning, hence it is a requirement.  Categories is merely a nice
grouping of all the "things"/packages you must select from.

> 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. 

I don't expect him to enter anything.  And if you look at my proposal he
is simply clicking items from an available list.  The reason why I'm not
presenting it in a tree the way you do is because 

a. you may want to select more than one option for each search, e.g. you
might want to do web development and do HTML + PHP + Python + CGI with C
++.  How do you put that in a tree?

b. not all things are related, e.g. Programming Language may be affect
by you're target environment (Gnome/web/CLI/etc), but whether it is a
database application is completely independant of that.  So which is
first and which is second.

> 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).

This might actually be more complicated as the user must add search
categories manually.  He doesn't know what the search category is about
before he inserts it and sees the available options.  What if he skips a
search category that he doesn't think is necessary and it gives him a
lot of irrelevant options?  

That's why I present the whole list of requirements/search categories up
front.  Many of it will have default answers so he doesn't have to think
about it if he doesn't want to.  But he can browse quickly to each
category see a description of what its about and look at each choice.
He get's a much better idea of what he must consider before he steps
into development.

Your approach may present a simpler approach, but it is "hiding" to much
from the user.  By forcing him to select the search categories he want
to apply manually assumes that he actually knows what he wants up front.
A newbie will actually find it harder to "filter" the packages down to
what he actually needs.

> 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.

Same applies to my approach.  Click on "step one: requirements" and add
something more.

> 
>           [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. 

In my approach you can also delve in as deep as you want but the search
categories are presented in parallel instead of layers.  You can see
everything but you choose which you want apply.

> i hope now you see that your idea of questions-answers has a
> direct mapping into my model 

Absolutely agree, only our approach is different.

> but my model is much more flexible

Not so sure.  I think it is actually more difficult for a newbie.

>  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. 

Same applies to my approach.

> on the other hand
> your user *must* use a filter in order to take advantage of filtering.

No, you can simply leave the default, e.g everything.  You choose
whether you want to change it.

> in my model filtering is implemented underthehood so user doesn't need
> to know about it. 

I don't get it.  If he needs to add search categories, filtering is a
very "above-the-hood" process.  I would rather say that the guy might
step into the trap of forgetting to apply a filter or not understanding
the relevance of a filter, because he has to add it manually.

> search categories don't have any visible differences
> from normal ones. 

I dissagree.  A normal category defines what something is, e.g. an IDE.
A search category applies to what applies to, e.g. Gnome, C++, etc

> 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.

Agree, but I'm sticking to my point that haveing all search categories
visible up front but chosing which ones you want to refine is much
easier.

> 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)? 

Then he skips it and simply stick to the defaults.

> 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. 

No, he chooses what he want to read and what not.  And we are not
talking about an endless list here, only a handfull.  We can use
highlighting to indicate to him the critical requirements he must
complete.

> 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.

But not everything can be presented in a tree, e.g if you want to choose
multiple languages and not just one.  That's like haveing to choose
multiple branches.

> 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)

That's why you have defaults.  You can assume that he wants to do
desktop development as default.  If you going to do web, cli or embedded
then you would actually be experienced enough to know the difference.

But also remember, that hiding too much or making things too flexible is
giving a guy a longer rope... to hang himself with.  It may look
easier/nicer but the end result might be completely wrong.

> 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.

Ok, so we understand what each of us are trying to do, but we disagree
on each others approach.

Regards
Charl