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