dubuntu-team team mailing list archive

[Charl Wentzel <charl.wentzel@xxxxxxxxxxxxxx>]

Ok, let's take a break from this.  I think it's time I see it in action.
I would however like to seem you're ideas on the database first.

Charl

On Wed, 2009-07-08 at 16:39 +0300, Jay I. wrote:
> > 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
> 
>