dubuntu-team team mailing list archive

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

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

it's a 'relation' (in mathematical terms) and yes it can be viewed as a matrix so basically i agree.
on the left - paths to packages/normal categories, on the top - search categories. but i think it's better to treat search categories
exactly as normal one's.

something like this:

          [pack 1] [pack 2] [pack 3] ...

[path 1]     X        X
[path 2]              X
[path 3]     X                 X

actually there's no principal difference between search categories and normal categories. for every normal category in fact we define
a requirement - items inside it must be related in some way. when we create a normal category 'c++/ide's' we actually define a requirement
that all packages in that category must be ides and support c++.

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

i meant that you will show only those categories that contain some items
that match requirements and hide those that don't but both visible and
invisible categories will make up the same tree. you can put all web
related packages in 'Web server' but after this you cannot add some of
them also to say 'Web client' but normally you would need it caz there
will be some common packages. of course you can create categories:

web/
  web server
  web client
  common

but a newbie would like to see only 'web server' and 'web client'
because the role of common packages can be understood much easier inside
a more specific context (web server or web client). for example you can
add some javascript related packages to 'common' but what a description
will you attach? 'this package is about javascript programming language
that's used both clientside and serverside'? i would place such packages
in both 'web client/scripting' and 'web server/scripting/asp'. it makes
much more sense because when a newbie first looks at these packages
inside 'web client/scripting' he already knows that javascript is used
for clientside scripting because it's mentioned in description of this
category. when he looks at the same packages inside 'web
server/scripting/asp' he already knows that javascript is one of the
languages supported by asp technology. this makes much more sense. but
anyway we will have to add the packs to exactly one normal category so
we may need to have that web/common but we can hide it from the user
(without hiding any packages as you see).
> 
> 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.
> 
right, you are not hardcoding search categories but you are hardcoding
the way you represent data to user. let me explain. let's imagine you
have these two cats:

- web development
- gnome development

netbeans can be used to do both things so as these are normal categories
you will have to put netbeans into a separate category - say 'ide's'.
it'd be just incorrect to put it into web development or gnome
development.

normally i'd be nice if you could see netbeans both inside 'web
development/ide's' and 'gnome development/ide's' but as you are using
only normal categories you can't. so when user tells the installer that
he wants to do some web development it shows him 'web development' and
'ide's' and hides 'gnome development'. but it's not good as user may not
know what ide's are and of course he will expect to see all relevant
stuff inside 'web development'.

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

no, these things really differ. in your approach you filter the same
tree of normal categories so if you have two categories - 'ide's' and
'debuggers' - after filtering you will see them both but they will
contain only relevant debuggers and ide's. so you will see the same tree
but with only relevant items made visible. for 'c++ development' i would
like to put ide's into 'ide's' and debuggers into 'debuggers' but for
something else i may need to arrange the same items differently. using
my approach i can define a search category named 'a small set of tools
for c++ development that every newbie can use' and put only 4 packages
into this category:

- gcc
- g++
- dbg
- eclipse

see the difference? in my approach items are grouped together - in your
approach you will anyway have eclipse put into 'ide's', gcc - into
'compilers' etc. when user will see this cats he will think - oops, i
don't know what ide's are! oops, i don't know what compilers are! etc.
so he will have to learn something about compilers, debuggers and ides.
but my user will only see these four packages and the category
description will give him a brief info about this packs and how they
work together but he won't need to have a good understanding of what
compilers are, what ide's are etc - the description will just tell him
how to launch eclipse and what buttons to press to build and launch his
programs. this way user will concentrate on learning the language
without understanding the basic concepts behind compilers and ide's - he
doesn't need to know them yet. for example when i started learning
'basic' at school i had no idea about compilers or interpreters - i only
knew how to write some code and how to execute it - i didn't need to
know that 'basic' is actually an interpreter and when i launch my
programs he parses my source code, performs some actions based on
expressions he finds in it etc.

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

right. but you make user define all his requirements in one step.
there's no step-by-step approach. it can be very hard for him to define
all his requirements at once. i think it's more psychological - it makes
a pressure on user when he has to do it all in one step. lets split this
task into more steps. actually every such task will need different
number of steps as some requirements can be very complex while others
can be very simple.

> 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.
> 
taking your categories as a basis i would have this:

gnome / ide / c++
      / compilers / c++

and

      / language specific tools / c++

first user realizes that he wants to do some gnome development so he
goes to 'gnome', then he can select only c++ tools but maybe he's more
advanced and he wants to browse all supported ide's for example. your
user would have no such freedom at this step - he'll have to go back to
step one and rearrange his requirements. it can take him a while to
understand what he needs to adjust but my user will have enough freedom
at any level, he will think less and switching back/forth between the
two steps is just annoying.

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

simply. user will go to say 'web development/languages' and select
HTML/PHP/Python/etc. 'languages' can be implemented as a search
category. so it's basically the same approach but it's MUCH MUCH easier
to navigate through a tree like hierarchy then to switch back and forth
between a filter and results. remember that user may not know what he
needs when he launches the installer. after my user has selected say
HTML editor and realized that it'd be nice to have a Python editor also
- he just goes one step back (from /web development/languages/HTML
to /web development/languages) and then goes to /web
development/languages/Python. your user will have to go to requirements,
find where he can select a different language, select it, then go back
to results, find where he needs to select an editor and finally select
it. my approach allows him to do it all in one place thus i don't make
user think more than he needs.

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

i mean that my user needs to perform explicit searching only when
existing search categories are not enough but your user uses filtering
explicitly all the time - he does have to specify at least some
requirements as it's silly to install every package that we have in our
database.

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

he needs to add a search category only when he's not satisfied with our
classification (with those search and normal categories that we have
added for him). remember that with search categories you can create
several classifications that can overlap. when he really needs to
perform some pattern-matching he opens a 'search' dialog and specifies
his requirements - be it a couple of words that must be present in a
package description or something else. we could even tag packages - e.g.
eclipse would have these tags - ide, java etc. this will simplify
searching.

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

you misunderstood me. by 'visible difference' i mean something that user
can see like you can see this letter. if you take say ten audio files
and make a copy of them and put the original files into 'By Date'
directory and the copy into 'By Artist' directory will you see any
difference? both directories are just directories - they are displayed
the same way but their actual implementation is hidden from user and in
fact can differ. this is what mean.

normally you will put your music files into directories by artist like:

music/
  red hot chili peppers/
  scorpions/

this is similar to normal categories. then you can create a directory
'by date' and populate in will links to files from /music directory.
this is analogous to search categories.

in fact it can be even desirable to see which category is 'real' and
which was created by applying a search criteria however you don't always
need to know it.

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

using my approach you combine refinement with navigation. when you go
into /sbin directory you in fact specify a requirement that you want to
view only administrative tools. see what i mean? navigation ==
refinement. in your approach you first navigate thru the tree of search
categories and the navigate thru the normal categories - too much work.

> > 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.
> 
not a good solution. if he goes to

desktop development/
  ide's/
  compiler's/
  ...
  language specific tools/

and he doesn't know what ide's or compilers are he will probably go to
language specific tools where he will select his favorite language and
only then hit [add recommended/apply defaults].

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

when user will navigate to 'desktop development/language specific tools'
he will see a list of categories named after languages so if he needs to
select ide's for several languages he'd better go to 'desktop
development/ide's'. we can add as many different classifications as we
need to represent all the most popular requirements but you can always
perform some pattern-matching like you do it in your file system. in
your file system you can create as many links as you need and you can
group them into any hierarchy. we can define only the most popular
classifications and leave the rest to the user.

ok. lets have a break. as i've got a solid vision of how i'm gonna
implement the database and the backend/cli front end i will go on with
development and when i'm done with the basic features i will show you
some actual code and you will tell then whether you like it or not.

regards,
jay