[Debtags-devel] Re: Recent progress

[Benjamin Mesing]

Hello,

> > 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.
I didn't mean that the single application has to be a webbrowser but it
is strongly related to a webbrowser and thereby it is natural to select
the web::browser tag when searching for something to manage bookmarks.
But perhaps I am wrong here, this is my way of thinking, but who knows
what the users might think.


> > 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 currently
> > this example does not work well, because neither gnobog,
> > egroupware-bookmarks, or sitebar was tagged with web::browser -- I found
> > 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).
And here I disagree, I think tags should be used for a rough selection
and full text search can be used for the finetuning. That allows to keep
the complexity of the vocabulary low.


> > 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 involved
> > this would be the way to go -- we need something with the focus on "easy
> > 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.
The user has to learn which tags are available - but you are correct
this complexity can be reduced by a UI carfully designed. However you
can't arbitarily simplify a complex system even with the most
sophisticated UI. 

Searching a package can be split into two steps, first searching the
correct tags and second searching the packages in the result. And the
more complex the vocabulary will become the more time the first step
will take - and the less the second step.

So in the end it comes down to what we consider to be more important -
exact search results or a vocabulary with a low complexity reducing the
complexity of the first step and the tagging process.

You vote for the first, me for the latter and I don't know who is
right :-(

> > 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).
Sorry for that. It is hard for me to drop the UI thoughts because this
is what I write.

Greetings Ben