On Sep 1, 2008, at 06:20, Karl Dubost wrote:
Le 29 août 2008 à 23:04, Henri Sivonen a écrit :
Also, having more metadata leads to UI clutter and data entry
fatigue that alienates users. In the past, I worked on a content
repository project that failed because (among other things) the
content upload UI asked for an insane amount (a couple of
screenfuls back then; probably a screenful today) of metadata when
it didn't occur to system specifiers to invest in full text search.
More metadata isn't better. Instead, systems should ask for the
least amount of metadata that can possibly work (when the metadata
must be entered by humans as opposed to being captured by machines
like EXIF data). See also
http://www.w3.org/QA/2008/08/the-digital-stakhanovite
hehe. This was a-good-try-but-mischaracterization-from-the-ministry-
of-truth
That was uncalled for.
to associate this article with the rants on metadata :) Let's clarify.
It's an excellent article. Thank you for writing it.
What I explain in the article is not the volume of metadata, but the
volume of items and the context of usage.
1. Extract anything you can from the data itself (exif, iptc, xmp,
modifications, date)
Yes.
It's sad how some systems ask the user for a title when the title is
already in an HTML or PDF file but it never occurred to the specifiers
of the system that files can actually be parsed. It even sadder to ask
the user for keywords, because it never occurred to the specifiers of
a system that full-text search has been invented.
2. Give a possibility in the UI to modify or add data.
Even the *possibility* to add costs UI real estate, so specifiers of a
system should be very, very careful in what possibilities they offer.
In a business environment, you might have to give metadata about a
work. I do it in my every day job. I give titles to my emails, I put
comments in my cvs commits, etc. etc. These are all constraints. Not
adding the data would still work technically.
Sure. However, writing a string that appears in mailbox list view or
in a list view of commits is the baseline of user-entered metadata.
Everything else is something *more*.
Just because something happens in a business setting where people can
be fired doesn't mean that more metadata is better. I've seen metadata
fail even in the military where they thought they could *order* people
to enter metadata (and where they have a more elaborate punishment
structure than in an ordinary working environment).
Having a UI cluttered with fields to enter is not a failure of
metadata, it is a failure of the project in the social and business
constraints of the project.
It's definitely a failure of the project in the social and business
constraints. The reason for failure was a line of thought that went
something like this:
Metadata is good. Therefore, let's have more of it. Let's model what
can be said about the domain. We are in a position to require people
to enter the metadata.
The process didn't try to seriously find out what the real must-have
hard social and business constraints were.
My point is that "metadata is useful" isn't the whole story.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
