Comps/groups/tags-concepts [Was: FESCo Meeting Summary for 2008-10-29]

Jeremy Katz katzj at redhat.com
Mon Nov 3 17:24:19 UTC 2008


On Mon, 2008-11-03 at 11:42 -0500, Seth Vidal wrote:
> On Mon, 3 Nov 2008, Jeremy Katz wrote:
> > On Mon, 2008-11-03 at 10:36 -0500, Seth Vidal wrote:
> >> Let's take a step back. How do we group several thousand things such that
> >> they don't make the avg user lose his/her mind to look at them.
> >
> > Also, what are the circumstances in which people are using this
> > metadata?  What sort of interface are they expected to be working with,
> > etc.  We have tons of unstructured metadata (see package summaries and
> > descriptions :-)
> >
> > The current comps format came about from looking at "okay, what are we
> > trying to enable the user to do" and then working back from there.  The
> > same exercise but with the changed landscape that is present today is
> > likely to be quite helpful in figuring out the best approach.
> >
> Well, to start with I was thinking of the flickr/blogger larger-font-size 
> tag browser with the ability to drill down per tag for additional info?
> 
> So combining tagging with a tree?
> 
> For example: you browse the 15 most common tags then you click on one 
> which opens up the 15 most common tags at that layer? maybe? and/or a list 
> of pkgs below that?
> 
> Maybe that's crazy, I'm just playing with what it might look like based on 
> other interfaces I've seen.

It might make sense -- it depends on what the context is that they're
doing it in.  If I'm looking to play a certain type of game on my
installed box, yeah, I can maybe see that making sense.

But if instead I'm looking to install a system, I'm not as sure that it
does.  

And I do think that you want to have the same sort of
groupings/taggings/whatever for both cases... that or we switch to a "we
always install a large base set of stuff and then you can go in and
tweak to your heart's content".  But that suggestion tends to make
server-type people come after me with pitchforks and fire ;-)

Jeremy




More information about the fedora-devel-list mailing list