[Debtags-devel] Re: Recent progress

Hervé Eychenne rv@eychenne.org
Sun, 6 Mar 2005 01:48:15 +0100


On Sat, Mar 05, 2005 at 05:38:14PM +0100, Benjamin Mesing wrote:

> > > More tags => more work => less adoption
> > 
> > Haha. So let's reduce tags to the very minimum. User utility reduced =
to
> > almost nothing, but developer adoption garanteed!
> > Sorry for being sarcastic.

> I agree with Erich here. If the number of tags get too bloated tags
> itself might become unusable. No one will know the whole vocabulary tha=
n
> and this will make using it a time consuming way, because you would hav=
e
> to browse hundreds or even thousands of tags. This is nothing I want to
> do!

Anyway, most of the time, that wouldn't be a problem at all:
- for already tagged packages, you only have to review new tags
- for new packages, in 90% of the cases, you can rely on 
  similar packages that already exist

And browse through tags doesn't mean reading the description of each
tag. In practice, you can pass quickly on most of the tags, if their
facets are not interesting for the package (or if you already assigned
an exclusive tag in the facet).

So I'm really sure the number of tags is not a problem by itself, but
probably I'm not convincing.

> If I want complete freedom I use a full text search entering
> whatever I like. In fact this is the way I do most of my searches now.
> Additionally you will scare of the package managers if they have to sca=
n
> through a huge vocabulary to tag their packages.

This is an user interface issue, not a design issue. You can perfectly
imagine (I do) a "full text search" command line tool, or a GUI
allowing to type anything you want and dynamically present you the
best corresponding tags, and the related packages.

> My opinion is to make the vocabulary not too detailed. If you have
> something very specific in mind, for example a tool to manage your
> bookmarks choose e.g. "web::browser"

Wrong. If most of the Web browsers allow to manage bookmarks, you
could perfectly imagine a tool just for that (that is absolutely not
a web browser, I mean), as the task is complex enough to deserve some
application(s) of its own (check their validity, convert a bookmark
file format into another, associate... tags (!) to them, etc.).
But that was just an example.

> combine this search with a full
> text search for "bookmark" oder "manage" or even both and most likely
> you will have what you are searching for (I just tried it, but currentl=
y
> this example does not work well, because neither gnobog,
> egroupware-bookmarks, or sitebar was tagged with web::browser -- I foun=
d
> those packages by performing a full text search for bookmark && manage)=
.

> I know that a lot of you will disagree with a vocabulary being not to
> much detailed and combining it with a fulltext search.

For me, both things are orthogonal (and can be combined in a user
interface, then).

> The whole point
> of a vocabulary is to speak in common terms so to avoid inconsitent
> data. And I think you are right -- as long as professionals are involve=
d
> this would be the way to go -- we need something with the focus on "eas=
y
> to learn" in opposite to "easy to use".

Learn? But there should be nothing to learn... Users would use the
search tool from time to time, and we cannot expect them to have to learn
something to use the search tool. So the user interface must be easy
to use (nothing to learn), and the tags are the backend, so it should
be as expressive as possible. That's my point of view.

> A search for tags might help to cope with a complex vocabulary

Yes. Again, this is a UI issue, let's not confuse it too much with the
backend (tagging).

 Hervé

-- 
 _
(°=  Hervé Eychenne
//)  Homepage:          http://www.eychenne.org/
v_/_ WallFire project:  http://www.wallfire.org/