Negative Results Part II: Owning your misconceptions

I had a nice long chat with my partner in crime on the KnowWiki, where we looked at the answers to the Ten Questions, and dissected what's happened since then.

One thing you might have noticed right off is that we didn't answer "what problem are you trying to solve".  Part of the reason was that I was only working with ten questions at the time. I didn't add the "plus one" until later.

The other part was that to us, it was obvious. The really cool stuff we were putting online wasn't being used or even found by people looking for it.  That was a bug in the software we were using at the time.  I wrote about our Evil Plans before: I wanted online collections to live, and Joy wanted the collections to be a part of the Semantic Web.

What I found out over time was that if someone didn't care if their material was accessible online, it wouldn't matter if it was or not. If they did care, they weren't going to tell us about it.  They'd share it with their own monkey-sphere and leave it at that.  Not everybody wants to be a wiki editor - or any kind of system editor, for that matter.

What Joy found was that the Semantic Web was happening in an unanticipated way, like most things do.  With the normalization of hashtags as the world's informal folksonomy, material we had available was becoming part of a semantic web-like thing, independent of any metadata that we'd entered.

We'd both fallen for the hasty generalization or unrepresentative generalization: if we thought it was cool for these specific reasons, so would others. And, it followed that of course other people would do what we thought they'd do.

That turned out not to be the case.  But if nothing else, doing something was better than doing nothing.

So we did something, and it turned out pretty cool, if not in the ways we expected.

Who publicizes negative results?

Some do.  I try to learn from others' mistakes so I can make original ones.  A year after the KnowWiki came into being it was time to re-evaluate things.

Some things were very successful.  Some things were not.

Good: Scanning homogeneous collections of stuff, running OCR and crowd editing transcripts turned out very well.  This was the one area where a true living collection came to be.

Bad: Collections of varied materials caused nightmares in creating metadata and in posting things online.

Changes in the environment: dSpace became a more viable solution with upgrades and custom programming; something that had not been available last year.

Feature vs. Bug: Wikis are very easy to edit and it's possible to create a system of categorization.  This means you can do nothing or you can do too much.  A few curators ran into the problem of too many options, or as the Fifth Wave cartoon called it decades ago: Toxic Option Syndrome.

Discussions about these things (and other observations) made me rethink what the questions are really good for.  Saying that they've helped me solved problems is good; others telling me the same is good, but I can't point to this and say "this is how you solve problems".

On the whole, the questions in their various contexts can be viewed as structured Active Listening.  The BRQ is a conversation starter (or stopper, sadly).

The Operational Questions are good for making you think about how something will work.  They don't help you determine how much work you're going to end up doing.  They are mostly good for risk management if used well.

The Directional Questions still tend to overwhelm people and are best answered in a backwards way: get someone else to do it for you.  Chances are you've already discussed your problem with others.  If you get someone to answer with what they'd think you'd say, you end up with a better picture than if you sat and stared at the screen for a few hours.

I'll post more on my rethinking later.

How to have a good failure

The other day I got an email about an old conference room I'd had set up in Exchange.  Nobody remembered how it came to be except me and the guy sending the email.  We'd both moved on to other jobs, so that's why we'd been asked about this thing.

If you don't use Outlook/Exchange, this is what I'm talking about: you set up a "user" that's actually a room or classroom.  They're called "resources" in Exchange, and when you're setting up a meeting with a group of people, you can list that room as your meeting room.  Depending on how the resource is set up, you're automatically booked, automatically rejected because of overlap, or a human reads an email and gets back with you.

Someone thought that setting up room schedules via Exchange was a better option than the shareware program we'd been using (and that was going away), and in some ways, that was true.  In other ways, not so much.

Our previous program was going away because it was insecure, out of date, and on a server going out of warranty.  We'd been working in SharePoint for a while, so the decision was made to do scheduling of rooms there.  At the same time, I and a few others looked into the Exchange option.

A lot of times there are more than one set of audiences or customers to consider.  As IT, my interest is in keeping the servers humming and the services moving their data around.  The end users wanted a simple way to book a room and to know that the room they're after is actually free.

The other customer to consider is the department actually responsible for the room(s). In this case our building manager.  He needed to know more than how many people would be at the meeting. He needed table set up information, video/projector information, and other specifics that would not fit on to the Exchange forms, but that could easily be added to the SharePoint calendar forms.  (Modifications could also be made to Exchange, but at a much higher cost in time and coordination).

So after a review, the building manager - the real owner of the service of booking rooms - made the decision that we would stick with the SharePoint calendars. If folks wanted to avoid overbooking, they'd have to check the calendars first.

I changed jobs not long after, and so I got the email, asking if it was OK if that old room was deleted.  I said sure, nobody's using it.

In the process he'd learned about customizing forms, I'd learned about customizing Exchange, and the limits of what's available to a single department in a large enterprise.  Even if we'd gone up a blind alley, we'd come out with more knowledge than we'd had before.  Failure isn't always a loss.

But like every other job, there needs to be a cleanup afterwards.