[Debtags-devel] Facet restructuring - Proposal/Idea

[Thaddeus H. Black]

Benjamin Mesing:

> One advantage of such a system would be that it would not break any
> existing applications (only a priority field needs to be added to the
> vocabulary). As I admit that it might lead to some work (and probably
> some controversies) to priorities all tags, and it would also require
> some efforts on the UI end, I suggest this to be a post-etch issue (in
> case it is considered to be a good idea at all).

I think it a good idea.

Peter Rockai (mornfall):

> I don't like it too much. This is kind of admitting defeat. We really need to 
> generate the visible tag set from the actual database, since it changes etc. 
> Manual scoring is going to be biased. Popcon would be about as bad, since it 
> would prefer to make packages that more people use (and thus are probably 
> better known and you wouldn't need to search for them in the first place) 
> even easier to find. I think.

The insight regarding popcon is well taken: popularity != significance.
However, if bias means judgment, then is bias inherently bad?  A major
reason I have spent hundreds of hours ramifying Debian packages is that
there are far too many undifferentiated "Priority: optional" packages in
the archive.  Benjamin has shown that AI package sorting can help a lot,
I think, but also that AI alone is not the answer.

> The more useful approach IMO would be to show a tags such that number of tag 
> instances (of the presented tags) present in the current package set is 
> maximum and all of the packages have maximal number of tags representing them 
> in the shown tag set. This would lead the user into picking the broad 
> categories first, which would limit the amount of tags present in the shown 
> package set, which in turn makes place for the more specialized tags.
> 
> Together with an intelligent full-text search, that would work along the lines 
> of: grep the tag vocabulary, OR all the tags found and limit the presented 
> package set to that. For a query like "mp3" or "http" this should cut down 
> the number of presented packages significantly and probably make space for 
> all present tags in the menu. Possibly include results of full-text search on 
> descriptions in the OR group, too (to account for imprecise tagging, mostly). 
> Even for a general query like "web", i get ~1500 hits with apt-cache search, 
> which is about tenth of the current archive size.
> 
> The idea is, people probably can roughly guess some keyword(s) to start the 
> search, but from there on, they will need helping out with choices (thus we 
> present the facets and their tags). In my other mail, i drafted how i 
> envision UI for my package manager project. This scheme would fit in pretty 
> well, i think.
> 
> Btw, a somewhat related thing, i thought about having a combobox with 
> different sort types for the displayed result set, and that would be at least 
> alphabetic (no comment) and score, which would sort packages based on "how 
> well" they fit the current filter (yeah, something like google). What do you 
> think?

Good plan.

-- 
Thaddeus H. Black
508 Nellie's Cave Road
Blacksburg, Virginia 24060, USA
+1 540 961 0920, t at b-tk.org, thb at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 240 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050726/71c1d85f/attachment.pgp