On Sat, Nov 12, 2005 at 04:41:15PM +0100, Peter Rockai wrote: > A remark, what about limiting the search results to first say 50 and > providing a "show all matching packages" link? This would probably > speed up the start... (of course considering everything for all > internal purposes).
I've finally fixed the start to display a full-text search only. > Other than that, it seems a good idea, but maybe provide more starting > tags than the six, they seem to make a bit difficult start... Or maybe > start with a nonempty filter -- like preseeding unwanted tags with all > aux packages... Or maybe no, just a thought. Ehi, preseeding unwanted tags is a Good Idea! Implemented. More starting tags than six, uhm... try the interface again: I fixed other bugs in the search, and it might be not needed anymore. On Sat, Nov 12, 2005 at 11:50:39AM -0500, Benjamin Mesing wrote: > I think the idea is a good one - it might even work in practice :-). > I've tried a search starting with "package", "email" and "browser". > Package was a total failure (I wanted tools dealing with packages). Try it now. The search was case-sensitive, now I have made it insensitive. This, and the preseeding of unwanted tags suggested by mornfall, gives nice fine results. > Email required me to remove 5 of the 6 suggested tags (though the one > left was works-with::email which is good). Browser gave me some good > results (I only had to remove GTK-UI ;-). [email] Yes, we have lots of email stuff like small libraries and tiny tools. I've added made-of::* to the list of tags that don't concur in populating the initial tag selection: this should make things a bit better. Also, the sorting was not maintained in the tag lists, and they were shuffled by perl hashes. Now I maintain the sorting, and email shows up first. [browser] I've added uitoolkit::* to the list of tags that don't concur in populating the initial tag selection as well. It's getting cooler! > However I think the results could be improved by performing some kind of > scoring on the search results received by the full text search. Perhaps > adding tags which match the search expression, regardless wether they > appear often in the search results would be helpful too. The idea is interesting, but I'm not sure how to implement it. Suppose that someone looks for "debugger interface": then interface would match practically all of the uitoolkit tags, adding them all to the 'wanted' list, and giving an empty result (one package rarely has more than one uitoolkit tag). One other idea would be to count twice a tag which also matches the search words. This would still bias the results in an unwanted way in the 'interface' example above, but could be tried. However, after fixing the sorting order of tags, email is already the first hit so I don't know how this would be useful. It's implemented, but commented out: if you see some example searches where it could be tried, we can enable it and try it out. You can do it yourself even: # Checkout the alioth version of the web interface svn co svn+ssh://svn.debian.org/svn/debtags/central-database/branches/alioth/webfrontend cd webfrontend # Edit Engine.pm: in the function tagsForSearch you can see the code # commented out: some are the specialTags handling, some are debugging # messages. Uncomment what you need. # Commit svn commit -m "Enabled specialTags support" # Update Alioth with the committed version # Warning: you need to wait *minutes* if the LDAP server is still # borked. You could do the SSH login in another window before starting # the work, so that when you're ready for updating Alioth the login # would have succeeded. ssh alioth.debian.org [alioth] cd /org/alioth.debian.org/chroot/home/groups/debtags/central-database [alioth] svn up > Additionally I think that it must be possible to add tags which are > not proposed at one location (without bloating the UI to much there > could be a combobox, with autocompletion). This would be nice, although it's complex to implement in a web interface. It would actually be interesting to have such a widget ready (possibly with autocompletion working on the facet short description + tag short description rather than the name, since the name should eventually be hidden in favour of the short description). > Finally I would prefer to have the [Don't want],... entries small and > appearing underneath the tag. But this might be a matter of taste: > * Software development / programming: > Software Libraries > <small>[Don't want] [Ignore] [Remove]</small> Done. > Finally having the search box in the top right corner is not very > intuitive for the start page. Put it somewhere more visible. And done. > All this said I think its a good idea, worth being pursued. It seems to > be really useful to allow adding a proposed tag to: "don't want" which > helps narrowing the search results really fast to what you want. > I think this does also provide a really good approach for a real search > application (without the limitations of a web interface). Lets see if I > can use some of those ideas :-)) Do it! Do it! Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[EMAIL PROTECTED]>
signature.asc
Description: Digital signature
_______________________________________________ Debtags-devel mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/debtags-devel
