- From: ddailey <ddailey@zoominternet.net>
- Date: Mon, 1 Sep 2008 07:04:55 -0400
Sorry for joining in naively to a conversation I've not been following, but reading Karl's remarks on the facilitation of metadata entry for users, some discussions in the vicinity of the recent SVGOpen that concerned usability, accessibility, and metadata made me think the following (that I suppose is rather outside the realm of HTML): Suppose the user or author (since in an app the distinction is blurred somewhat) is building something like a graph (in the discrete math sense), an image repository, or even a diagram (though the categories of content here are heterogeneous, making the argument a bit more tenuous) using a guiwebapp (like inkscape for diagrams or http://srufaculty.sru.edu/david.dailey/svg/graphs30.svg for graphs). Let's say there are n basic entities (like graphs or images) for which metadata is required. Let us furthermore assume the metadata description language is of order 0 1 2 3 or 4 * and that the minimum number of user operations required to complete the metadata description for a single entity is bounded above by k. We then may plot a user performance function that estimates the probability, p, that users will actually succeed in entering data (as a function perhaps of not only n and k, but of the user's investment in the process). Clearly as n and k grow and as the user's investment in the process declines, so does p. We are interested, through, interface, in maximizing p. I have a hunch (in math it is called a conjecture, but in CHI it is more like a hunch) that not only how, but also when, this conversation between user and software takes place affects the probability. For example if an artist were using Inkscape to draw SVG, then mandating a conversation about metadata each time a curve or gradient is completed is likely to drive users to AutoCad for their diagrams, even if wine is served. In certain cases, it makes most sense to build that conversation as an "exit interview". If we will have k phrases to enter (using a grammar of graph theoretic phrases) for each of n objects, then we may wish to build a very comfortable GUI to facilitate that for all the affected entities upon closing the app: Dear user, you have just completed a schematic drawing for the Intel i-Chore 42x processor, would you now like to a) save b) enter appropriate metadata c) save and enter data d) drink wine. The notion is that a GUI enabling such, could if it were viewed as a stage or mode of development a) rely on the visualization of the opus as thus far created b) be appropriately rich to the order of the metadata description language and c) make the data entry process unbundled from the creation process, hence allowing diversification of the assignments of tasks to workers (e.g. the familiar phrase of the assessment revolt of 2028: "let the bureacrats do the bureaucracy!"). That isn't to say that we should not also facilitate the entry of data at each stage of the drawing process, with a sub-interface of the master metadata editor, but given the complexity that some metadata editors may have to convey, the nature of the conversation between user and software may not be allowed to remain entirely casual (that is, wine may need to be upgraded to tequila). /fwiw David (by the way, an Intellectual Property/provenance description language such as the library and visual rights communities work with might be an interesting overlay for the web, provided both free and corporate models (together with ample graph theory) are included) * define the order of a metadata description language as 0 if it consists of simple non-delimited strings, 1 if it consists of delimited strings (with a single delimiter), 2 if the delimiters are parentheses (required to match), 3 if the delimiters act like parentheses of multiple flavors as in XML, and 4 if the language is fully graph theoretic (parenthesized strings plus cross linkages -- footnotes). ----- Original Message ----- From: "Karl Dubost" <karl@w3.org> To: "Henri Sivonen" <hsivonen at iki.fi> Cc: "Ben Adida" <ben at adida.net>; "Paul Prescod" <paul at prescod.net>; "Ian Hickson" <ian at hixie.ch>; "WHAT-WG" <whatwg at whatwg.org> Sent: Sunday, August 31, 2008 11:20 PM Subject: Re: [whatwg] Creative Commons Rights Expression Language 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 to associate this article with the rants on metadata :) Let's clarify. 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) 2. Give a possibility in the UI to modify or add data. 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. For my own personal photo, I don't (want/have) time to put plenty of metadata. And that's fine. I do though bulk metadata at a regular pace, for location (ex: all these selected photos have been taken in Taiwan with the help of GUI tools. Yes tools save my life). 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. -- Karl Dubost - W3C http://www.w3.org/QA/ Be Strict To Be Cool
Received on Monday, 1 September 2008 04:04:55 UTC