Amazon’s Turk: a disgrace to knowledge work

January 26th, 2006

When I was 9, workers at my Mum’s library went on strike or on vacation, and I stepped in to cope with the extra workload. She put some blank stickers, a rubber stamp and a stack of books in front of me and demonstrated the procedure: peel - stick - stamp. I repeated a million times until an innovative - which means a desperate - impulse kicked in and I changed the procedure: stamp all stickers first - iterate [peel and stick.] Procedure 2 is better because it’s quicker (about 50%) and tidier (no ink bleed on book). My mum was floored and procedure 2 was the talk of the community for a week.

What do you make of this scenario from a knowledge management point of view? Is there some knowledge I exhibited that the regularly scheduled masters of library and information science didn’t have? Uhhh… Is it worth investigating what organisational structure or what lucky confluence of circumstances in the library’s environment prompted the inspired change of procedure? Duhhhh…

No. Unlike the regularly scheduled crowd, whose job it was to follow a procedure, my job was to solve a problem. Being 9, unpaid, unsupervised, and ‘in’ with the management, my circumstances afforded me the audacity to suppose that my insight was valuable and the license to design my work.

Managers inclined to nurture knowledge work in a mum-like way, are strongly supported by management theory since the 50’s. The Japanese production industry is buzzing with methods for coaxing luscious and lucrative ideas out of the cogs. Meanwhile, Amazon, like anyone with any sense, is clawing the walls to see what new modes of exploitation are enabled by service-oriented software.

Artificial artificial inteligence. What’s artificial about Amazon’s brand of artificial intelligence? It uses humans.

This makes good exploitative sense. Turing, Gödel, Chomsky, etc. prove that there are some things that humans can know but that computers can’t. Things that are uniquely knowable to people often represent inspired discoveries or feats of creativity - like the double helix or a symphony. There are other things that people can know but computers can’t that are dull and low-level, like CAPCHA tests - when you have to decipher letters and numbers from those images that online services use to prevent automated subscriptions. So guess which kind of knowledge Amazon’s leveraging?

Right! It’s the “Is there a pizza parlour in this photograph?” sort of knowledge that you can aspire to cultivate if you want to join Amazon and its customers in the neurotic scurry map and serve location-specific information.

While spacial coordinates are fixed and bounded, their coffee-serving, film-projecting and petrol-dispensing occupants are not. To maintain its status of trusted referrer, Google maps doesn’t really have a margin of error - if it buggers you with enough, or even one false positive (yessiree, there’s a circus right over yonder. Round up the kids and get the engine croaking…) they compromise the credibility of every single bit of information they have about what’s where. And while machinery can monitor fluctuations in space, only its human components can tell you weather some conglomorate of matter in a space constitutes a pizza parlour.

Reply to e-greeters

December 27th, 2005

I’m delighted to see your name in the to field of a service-generated message, and I would even read the contence of the greeting with interest if I didn’t have to click the link below to declare my address live and spammable.

Even though I’ve only resorted to it once, I can understand that mass-messaging makes life easy, and maybe there is something about 16 pt Comic Sans MS that heightens the tenderness of your written wishes. It’s ok, my love for you is not contingent on your personal e-attention. But you are testing my love by precipitating spam.

Read the privacy policies (lurking, in very uncelebratory 9 pt arial at the bottom of hyperactive e-greeting pages) before you divulge my address which I try hard to safeguard from vile precipitators of info overload.

To be honest, I am enraged by your greeting approach. Here is my usual (but highly personalised) treatment of the sticky issue:

“Thanks so much for your holiday wishes. It’s great to hear from you, and makes me curious about life and new developments.” [I remain curious because you’ve put me in a situation where I have to expose myself to danger in order to get the details.]

…Specific questions about recent travel, happy or contentious family matters, business initatives… [I love you enough to consider happenings that are significant to you.]…

“Oh - P.S., my suspicion about those e-greeting card services is that they are sneakier than they seem.” [I’m not a know-it-all, just sober and downtrodden by spam.]

…Then I breifly describe what I think the greeting card pimps are up to…

“Not sure if spam is as much of a problem for the rest of the gang, [Make no mistake: you are causing malaise for everyone on your mailing list] but speaking personally, it’s such a thrill to hear from you, that plain text more than does the trick!”

Sometimes what I think is fantastic diplomacy comes out as blazing sarcasm. Tell me if my message seems harsh in the context of furry graphics and fonts. Maybe someone should build an e-greeting response site: Choose a color scheme, cute animated things, and a public service message: “You meant well but did you know…” that’s neutral and impersonal so just as unlikely to offend as its trigger message is to heartwarm.

Plain language

November 21st, 2005

Usability is a virtue of literature not just websites.

A client and friend once told me that he is plagued by systems that are well-conceived but ill-understood.

The applications he built were rich in the functionality that his users ached for. To his perpetual distress, however, they continued to ache long after the application was delivered.

If, like him, you paid my bosses 90 Canadian dollars per hour for my usability sermons, I�d churn out insight that�s purely intuitive and that could easily have come to you in the shower. I�m sure I�d attack your navigation scheme. In particular, I�d ask why you chose to put terms or phrases on navigation links that make sense to you and your work cronies, but that give users no inkling of what they could expect to find once they clicked.

Websites, if they�re to persuade us to divulge our credit card numbers, need to take every opportunity to instruct. It would be nice if academic articles did the same.

Digesting academic information systems literature, the usability witch in me rages �quit hogging bandwidth and get to the goddamn point.� I probably need a new line more suitable for paper journals, but I think line for scholars is the same as for web designers: use plain language.

Being hospitable to technology

November 19th, 2005

You might suppose that hospitality is just a warm impulse that kicks in when a foreigner walks onto your turf. But if you’re one of these astute folks whose hallways I’ve been loitering in lately, you might see it instead as “an institutional device to cut down the time needed to merge cultures and to integrate alien mindsets.

Let’s recognize that that companies (unless they’re clueless) are polygamous opportunistic beasts. They meet, mate and morph quicker than you can say ‘strategic partnership’ or ‘outsource.’Long-term visions are out. Seduce me with a promise of a stable future and there might be something charmingly retro about your approach but mostly it’s tacky. Like a smart woman, a smart organisation won’t bind itself to a marriage contract with its technology. What if my interests change? What if we become incompatible? What if it stops generating revenue? and starts draining my revenue? So if we can’t do business by committing to a particular vision of the future, then how do we propose to implement the information systems for which we expect to bill mercilessly?

Claudio Ciborra urges us to consider an institution more appropriate to relationships in “the age of dynamic efficiency” i.e. hospitality. Let us not harness technology but invite it in for tea. As our guest, we can’t know or decide exactly how it will interact with us, but we can introduce it to our customs. “Now, now technology, in this organisation we don’t automatically publish reports, we wait until approving officer clicks a button. But I can see that you want to keep information flowing. Perhaps you might generate a signal to alert approving officer that the report is waiting in a repository.”

Moreover, if we relax and give technology some leeway to be itself, we might discover some thrilling quirks. “Would you look at that Jim, if you pull this lever, before cranking that chain, technology will sort these reports by approving officer. How foolish of us to have been sorting them by authoring team all these years.”

Technology, let us be enriched by your visit without entitling you to stay indefinitely. Let us reach into and cultivate one anothers terrain without dissolving the border between us. Let us negotiate an interaction that draws from our respective traditions and let us generate new heat together.

Main gig

November 11th, 2005

My main gig at the moment is to be a student in the information systems department at the LSE. As far as I can tell, the department is essentially a gang of nihilist comp sci types who’ve gotten together to teach swarms of students that information system development is an un-orderly ritualistic activity whose outcome turns on the alignment of planets or the flapping of an insect’s wings in just the right place at just the right moment. (Or, at the wrong place at the wrong moment if you’re a victim rather than a beneficiary of an information systems project - which you probably are.)

Unsent emails to people who dump you

October 5th, 2005

3 out of 3 fellows surveyed think I’m a wonderful person and dump me after 3ish years.

The truth about 3Here’s one for the third:

Dear 3,

I don’t miss feeling how expensive it is for you to call me.

Once when I mentioned how much money you save on not having to buy me beer regularly, you joked “not necessarily.” Why was your reaction to compare long distance fees with beer prices? Why wasn’t it that you long to buy me beer on a regular basis? or that the sound of my voice justifies the harshest long distance phone charge?

Why was the reason you hesitated to suggest I move to Swindlerzland that you “didn’t want the responsibility.” Why wasn’t it because you were worried that I wouldn’t be fulfilled or feel at home there?

(Do I strike anyone as the sort of person who would delegate responsibility for decisions about my life??)

Why did you once take the pain to tell me not to come to a ski trip with your family? I haven’t yet in my life intended to go on any ski trip with any family. But let’s say I were the family ski trip type, your reason had something to do with a small chalet and your parents not being comfortable. But you were speaking to me. So why didn’t my comfort concern you?

You said it. You don’t love me.

Join the queue. Billions of people don’t love me. The 4 or 5 people who do don’t want you in their queue anyway.

I’m not angry that you don’t love me. I’m angry that my hopes of cultivating love with you gave rise to tolerance where none was due.

3, you are a reminder to know my threshold of tolerance. I promise never again to have hopes so high that I ignore it.

I’ll take from you 3, glimpses of sweetness in your eyes, memories of how, cities ago, you rested your head or limbs on me but made them weightless - even while you were sleeping. I’ll take a lesson about when to speak and when to do. I’ll even take a healthy bit of arrogance. But I won’t use it on anyone who cares about me.

I wish you many lessons too.

Maya

Why bother hiring an information systems lady?

July 26th, 2005

…when you can squeek by with software engineers alone

Because understanding a problem and implementing an information system to to solve it are not the same thing. As AntonyWasserman puts it in an IEEE software article, “the cognitive leap from understanding a problem to implementing a system is enormous.” “Writing code isn�t the problem”, argues Bill Curtis, in a Communications of the ACM article, “understanding the problem is the problem.”

The move from understanding to implementing can be full of expensive guesswork and technical bias (when ‘the ultimate’ platform for the project is the one developed by the software engineer’s dog’s startup). Information systems analysts are forced, by their mandate, to go through the trouble of disguising their guesses and biases in the language of customer requirements. Is that slimy? Who knows - but it’s worth doing because it promotes integrity.

Even if ulterior motives sneak into a technical decision (that dog really is charming), going through the exercise of justifying that decision has a purificatory effect. And this is just the sort of excersize you should expect from your information systems lady.

A good IS analyst should consider it her business to know:

  1. The nerve-wrecking mess of problems that a company handles. She should know this business as if it were her own - because it is.
  2. The expertise and sensibilities of the people who handle these problems. She should know what it’s like to solve problems in their shoes, at thier offices, on their train-rides, in their bathtubs, see what they see on their screens, hear their phones ringing and witness the flood of emails that they cope with as they do their work.
  3. Every significant or quasi-significant bit of technology news that adds to her mental store - and her company’s knowledge base - of features and functions that support problem-solving in her clients’ domain.

Think of all this knowledge that an information systems lady has, and ask yourself: is it really possible to derive a program from requirements? Not likely - at least not cheaply. Because requirements are so much more complex than what you can write, and because they change all the time, the specs are bound to be ambiguous. This means that a system under construction is vulnerable to the whims of its programmers. Programmers intuition can be a fantastic resource - but not if programmers are utterly blind to the reality of software use. So how do you fight programmer blindness to context of use: Hire an information systems lady.

An IA by any other name would not smell as sweet

December 1st, 2004

Get with the lingoYesterday was a high findability day. This is not to say that I’ve stopped getting lost on the way to the neighbourhood Tesco (sorry Dionisis.) It means that people who were looking for me found me.

I’ve been scoping out information architecture jobs in a few countries for a month or so. The tactic has been low-noise: For interesting jobs or companies, grab the hiring manager by the collar and see if sparks fly.

Still, I wanted to let in some noise to hear what it sounded like and feel what resonated. I called my Monster profile ‘Information Systems Analyst’ because

1. I wanted it to be vague enough to let in different kinds of response
2. That’s what the other kids in my class were doing

In 4 weeks, the profile, so named, generated 12 requests from recruiters and 52 hits. Unremarkable.

Meanwhile, off-Monster, the most exciting conversations I was having was about my old scene: information architecture and user experience. I took this as a sign from my soul and from the universe to roll with it and it feels right.

So, without altering the content of my CV- which is already all about IA and UX - I changed my profile title to ‘Information Architect / User experience Consultant.’ Within a day and a half, I got as many views and more requests than I’ve had in a month.

Peter Moreville, author of Ambient Findability, points to an obvious sense in which findability precedes usability since you can’t use a thing until you find it. Still, the relationship between findabilty and usability is elaborate. It’s not just than that the former is a precondition to the latter. These virtues are intertwined in the sense that a system is usable if it supports you in finding what you need to find.

Let me wade through the sea of chicken fat - job specs in which ‘arcitect’ is misspelled, unreadable web pages about my potential employers’ accessibility expertise and glam work-at-home schemes. I’ll keep you posted on the utility of my new found findability.