Interpreting user-specified metadata

The problem with allowing users to specify metadata when they file a request is it doesn’t always mean the same thing to them as it does to those who handle the requests. Even if you supply definitions, users won’t necessarily read the definitions, and even if they do, interpretation differs. For instance, urgency: something may be incredibly urgent to that user in the sense that they feel dead in the water until that issue is resolved; however, if that issue affects only them, it’s probably more important to take care of an issue like a downed research group server first. (Even that is fraught; like most organisations, we have a few users generally deemed to be more important than everybody else, even if we pretend that everybody’s equal.)

Our own silly take is allowing an urgency of “24 hour”, along with “not”, “urgent”, “emergency”, and “by date”. For instance, I see a request outstanding in our system right now that is essentially a user asking for some education on the use of the rm command; it has the urgency flag set to “24h”. What does that mean? I don’t know, but the user set it. Looking at the item, I see she probably set it because after 24 hours, the answer no longer really mattered; she’d already taken care of it herself. However, it will become an issue again next term (she was cleaning out course accounts). So now what? We’re discouraged from changing urgency flags ourselves – the user set it, after all – but clearly, the matter is no longer very important (until 2 January 2008 or so, at which point it will again presumably attain “24 hour” urgency again).
Our documentation states:

The “Urgency” field in the Create Request form provides an indication of how urgent the request is to the person for whom the work is being done. It is used to determine a rough starting position for the work in the “Upcoming Projects” part of the work queue, unless of course it’s an “Emergency”, in which case it’s added to the “Emergency” section at the top of the queue.

Clearly our documentation needs to be updated, as it doesn’t include this 24 hour notion, but I suspect it would go something like this: “An item which, if not resolved within 24 hours, ceases to be important, and so may get done on an ‘as time allows’ basis, or not at all.” Neither of these outcomes are generally satisfying to the user; in fact, the former is often a synonym for the latter, and not just in our organisation.

In any event, without reading a request in its entirety, this particular flag is meaningless, and due to differences in interpretation, it may actually impede communication.
We like to allow our users to feel “in control”, even if they’re really not – but how far should we go in so doing?

Update on Mind Maps

Since making a very vague post regarding mind and concept mapping, I did very little to actually explore them, being rather busy with work and personal matters. However, I saw the perfect opportunity to jump in with both feet when I had to start writing some documentation – from scratch – regarding our clusters. Being cheap and still unsure of the utility of mind mapping, I grabbed a copy of FreeMind. It works quite nicely on my various Mac machines, and when I was one day forced to use my Linux box as my main workstation (my G5 was busy thrashing backing up a faculty member’s Powerbook) that machine ran it quite nicely as well. I played around with it a bit in order to learn a bit about its interface and how it liked to do things, then got to work actually using it.
However, being an old-fashioned and tactile kind of guy, I have a large blackboard in my office, so I started there first. FreeMind seems to like to start from a central node, so I wrote down Clusters and worked from there. Soon I had a list of the various “chapters” I wanted to cover roughed out on the board, and I transferred that to FreeMind. For a while I worked back and forth, duplicating effort on both mediums, until I was relatively satisfied with the concepts that I needed to cover.
FreeMind has an export to HTML option, which produces a fairly nice list – collapsed or not – of the various nodes. I expanded nodes one level deep, exported that, and printed it out (see above, I like reading dead trees). Working with the printout, I created a series of text files, each covering a single concept or group of concepts: Administration, Compilers, User Accounts, Hardware, and so on.
I’ve not yet completed the documentation, but I can say for sure that this sort of mind map was invaluable in getting it started and in keeping me organized during writing. User documentation lends itself well to this sort of thing, so work is rapid. I have yet to try writing an essay outline with it – oddly, while an undergrad I was never big on essay outlines before the fact – but I have one coming up Real Soon so I might give it a go there. I can also say that the map was useful when creating my cluster presentation, as it allowed me to see at a glance which bits were likely to be important to my users so that I could ensure they were all covered in detail – no more and no less than they deserved. Since the presentation seems to have gone well, I will praise mind mapping for allowing me to get the whole thing done up in far less time than I would have thought.
Individual mileage may vary, but I’m definitely enthusiastic about the utility of this class of program for myself.

Mind Mapping

Mind mapping has fascinated me for years. I almost hate to admit it, but after reading Hannibal (Thomas Harris) I became enamoured of the idea of a mind palace. I even went out and found a bunch of promising links, bookmarked them, and never really took it up, mostly because I’m lazy.
Nevertheless, the idea is in my head and won’t go away, so I expect I will eventually try both out. Merlin Mann asked about Mac mind mappers, and as before, I bookmarked a few of these ones and never really got back to them.
Some day, after I invent the perfect mousetrap…