Sunday, September 23, 2007

It's all about the context...

So I spent the weekend driving. It was the usual stuff; kids soccer games, a trip to South Jersey, a ride to Costco, play dates, sleep overs, pizza etc etc.

But we had Daniel with us. I call him that because he is called that by his maker, the Garmin Company. At least that is the name they give the voice that my testing has shown to be the easiest to hear over all the noises in the car. Daniel speaks the Queens English, in a sort of Mid-Atlantic way. He has a few problems with some abbreviations not in use in the UK but overall he does a good job.

Yes, Daniel is my new Garmin 'Nuevi' GPS unit recently purchased after another blistering white knuckled disagreement with the dim-witted planners of New Jerseys road signage was soto voced in the drivers seat of the minivan such that the wee ones could not hear it. By gosh what a relief to finally have a fool proof way to get from A to B and C all the way to Z.
Or is it Foolproof..?
My experience so far has been that, if you know a route from A-B through several trips, you may already know more than Daniel does about the best way to get from point to point.

I have, on a few occasions, found myself regretting that I trusted a reasonably-known route to Daniel as I find myself losing time (I think anyway) following his directions. However, he has often found a few shorter ways through difficult routes that I have in the past been reluctant to trust myself navigating so I guess it all comes out in the wash.

The software works pretty well overall but, it has one major point of failure, it cannot easily navigate to a region. For example unlike Google, which can give you a route to a town name; Daniel needs an actual address to do his thing and, often this is just not available.

Based on this I began thinking about the sorts of navigation we really try and achieve. They seem to fall into one of these categories:

a) Home to point with exact address

b) Random location to another random location, IE out driving and need to find the nearest Starbucks

c) Some random point to Home

d) Point to point to point....

In terms of a & c Daniel does well. With d the work becomes a bit onerous but you can create a route with via points that will do the trick.

For item b which is a very spontaneous sort of trip the problem Daniel has is limited resources.

He simply does not have the flexibility to find things by any number of different ways. In a long winded preamble then, we are once again back at the holy grail of Knowledge Management but from a very different route. How do we build things such that anyone can find what they need..?

We have many answers to this in the strictly controlled environment within our place of work but, for the vast majority of other cases in every day life, Google seems to have found a good middle ground and has managed to make a lot of money out of it.

Ideally a GPS unit, like a good search engine, could locate a business by name, type of offering, general location, or even by product. It would be logical that the next level of service for such a system would then allow you to find say, "cheapest tableware in this zip code" or "nearest movie theatre showing 21" or even "closest place to get a triple machiato".

The key thing in all these cases is the assumed context, your current location. This parameter along with the question give the query structure and, when processing our KM search queries we are in the same position of wanting as much context as we can possibly get before providing the answer as this will make the answer valid.

The value of the answers is intrinsically tied to context which, considered in a professional setting may be described in a number of dimensions. For example region, business unit, department and role.

Having these components available at the time of processing a query will help boost the value of the result set so it is no longer just interesting but actually useful.

Finding a uniform model to use in doing this is the challenge of developing a good KM search system.