[Debtags-devel] Facet restructuring - Proposal/Idea

[Peter Rockai (mornfall)]

On Monday 25 July 2005 13:23, Benjamin Mesing wrote:
> Hello,
>
[snip]
>
> We could assign all facets and tags (or perhaps only the tags) a
> priority marking the importance of the relevant tag. This would allow
> two improvements:
>      1. show most significant tags first
>      2. move very, very important tags up one level the hierarchy (So
>         tags located directly beneath a facet would be displayed on the
>         same level as facets). E.g. if we move devel to use::devel and
>         it's priority would be say: 0 it would be displayed as
>         use::devel in the next to the facets including use.
>
> There are some things that need to be considered.
> I think the scoring should be done manually, or at most
> semi-automatically. Here the number of packages tagged with a given tag
> might give an indicator regarding its relevance. Or even better a
> weighted score based on the popcon rating of all the packages that are
> tagged with a given tag.
> Another question is, if the facet where a tag originally belonged to
> should be shown in the name in case the tag was moved up. But this is
> only a UI issue (and I would vote for 'yes' :-)
>
> 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 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 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?

>
> Greetings Ben
>

Yours,
    Peter.

-- 
Peter Rockai | me()mornfall!net | prockai()redhat!com | +421907533216 
   http://blog.mornfall.net | http://web.mornfall.net

"In My Egotistical Opinion, most people's C programs should be
 indented six feet downward and covered with dirt."
     -- Blair P. Houghton on the subject of C program indentation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050725/3d0395fa/attachment.pgp