New Comps Groups

[Toshio Kuratomi]

On Thu, 2006-11-30 at 21:21 -0500, Jeremy Katz wrote:
> On Thu, 2006-11-30 at 09:29 -0800, Toshio Kuratomi wrote:
> > On Thu, 2006-11-30 at 10:52 -0500, Jeremy Katz wrote:
> > > The "problem" is that if you do something like this, you _really_ don't
> > > want to be using the current UI.  
> > 
> > There's an assumption here of what the current UI is.  From your
> > background and the background of comps I would assume that "current UI"
> > means anaconda's interface.  However, comps.xml has been proposed as a
> > replacement for the rpm group tag in general.  Repoview already attempts
> > to do this (with a horrible number of entries in the uncategorized
> > listing).  apt/synaptic and smart currently use the rpm group tag and it
> > was proposed that they should be ported to use comps instead of
> > rpm::group.  I would say that apt and smart's UI would not suffer from a
> > migration to comps provided that comps lists all the packages in the
> > repository.
> 
> And that _used_ to be anaconda's UI and anaconda used the group tag.
> That was changed so that:
>   a) the grouping information could be changed by third parties without
> requiring the packages to be rebuilt

Exactly.  The group tag is a bad place for this information above and
beyond the UI that exposes the information.  Currently we have the group
tag and we have comps.xml as the two places where this information can
live.  So the information would better live in comps than the group
tag... or we could invent yet another place to keep the information.

>   b) browsing through every package in the distribution wasn't
> interesting when it was < 1000.  browsing through 4000 packages is even
> worse
> 
No.  Browsing through packages using this UI is uninteresting.  Browsing
itself is still interesting.  Browsing can allow you to find things you
didn't quite know you were looking for.  It can allow you to explore a
new subject.  It can help you break a piece of information up into
managable bites for learning.  It can help you see the relationship
between two areas you thought were separate.

> > > Rather than focusing on the question
> > > of "how do I fit this in comps" or "how do I list every package because
> > > oh my god, how else do I find something", the _real_ question is trying
> > > to figure out what the user experience we're trying to get at is, get
> > > some mock ups and then figure out what the "right" implementation path
> > > is from there.
> > > 
> > User Experience
> >   Objective
> >     Allow a user to view a subset of packages in a set of repositories
> > that matches categories of software that they are interested in
> > installing.  This allows the user to more quickly discover a package
> > that fills a need for them.
> 
> While a good high level description of what's wanted, it's not a very
> good place to start for designing a UI.  Things really need to be far
> more focused.  Use cases are one common approach; there are others.
> 
> >   Interface1
> >     1) Select a group from all groups valid for the repository
> >     2) List all packages which match that group.
> >     3) Allow the user to select another group from the groups that these
> > packages have.
> >     Repeat from 2 until A) the list of other groups would have a single
> > entry, B) there's only a single package in the package list. C) User has
> > left this interface
> 
> This is actually a direction that we (pnasrat, clumens, myself and a few
> others) were looking at when we got to the current package selection UI.
> The problems started coming in around how to sanely handle a native UI
> where you want to allow multiple selection of packages, and then viewing
> even more details without too many levels of nested dialogs.

You are talking about what you wanted from the installer.  But that's
not necessarily relevant to what you want from a graphical package
manager.  Or from a web based package lister (a la repoview).  repoview
doesn't need to worry about multiple selection of packages, for
instance.

> >   Interface2
> >     yum groupsearch Development Python Cryptography
> >     Finds all packages in the repositories whose group information
> > contains all of those patterns.
> 
> Search is *definitely* something that's incredibly useful and important.
> Realistically, it's probably more interesting than browse for most use
> cases.  Can the search that's currently there be improved, yep.  Was
> easiest to just start with 'yum search' and then improve from there.  

search and browse are very different.  I would say that browse is at
least as useful to get right as search, possibly more.  Search works on
the principle that you know what you are looking for, you just don't
know its name.  Browse works on the principle that you sense what you
are looking for, you just don't know how to express what that is.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061130/11e8c218/attachment.sig>