[Debtags-devel] New web interface

[Enrico Zini]

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 <enrico at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20051114/bd55773b/attachment.pgp