Interconnected

All posts made the week commencing Sunday 3 Feb., 2002:

Nice. Words that don't have counterparts in English [via marginalia].

Matt o' blackbeltjones makes a response about conversation interfaces, and: "the resurgence of popularity of what amounts to the command-line interface, especially amongst younger people, due to SMS and instant messenging."

They're two quite different things I think. I could see IM being used in both command line and conversational capacities, at seperate times. (Come to that, are there any good command line equivalents available by IM? How about piping information from bot to bot?)

The command line, because of its context, is very obviously an abstraction onto a computer, and it's critical to learn a new grammar to communicate. An IM client, because of it's context, is at face value only an abstraction to a human/human conversation. There's a difficulty here in that people expect a greater level of intelligence and understanding -- but there's also attributes that make the job easier. For example, it's okay to say "I don't understand". Also, people are familiar with scripted conversations, from telephone callcentres and the like. I can see a command line being extremely useful over IM, but I can also see a conversational interface being something different and useful in it's own way.

I was thinking earlier about how to storyboard conversations. If it's a standard flowchart, or graph: A node, or state, can be a point at which the bot returns information or asks a question. Arcs are various user responses. So far, so www. What the conversational interface allows is arcs to shortcut nodes by giving more complex responses. [I'm modelling all of this internally with maps, according to the sameness of interfaces.] And this allows for long-term more complex interfaces. As the landscape is explored and more keywords are learned by the user, shortcut arcs from what were ostensibly simple nodes can be discovered. This is something that can't be done on the www without altering the pages and disrupting the familiar interface. Another difference is that obvious unambiguity can be used in the interface to hint at shortcuts -- on the www, the hierarchy is not a beast easily disturbed.

Splendid Upsideclone today by Kevan: Litter: "The litter drone pedals its ten woodlouse legs against the sky, slower and slower. It is a piecemeal twenty-sixth-generation Model Twelve-C, constructed from fragments of the refuse it has been programmed to collect; a functional copy of whichever twenty-fifth-generation Model Twelve-C assembled it."

Very Philipkdickian today.

If you send an AIM to twatcaller, it'll call you a twat. Does exactly what it says on the tin.

Comic. Fantastic. Red Meat.

Walking through London, I've seen symbols carved into the kerbstones. Crosses with a dot in each quadrant. Triangles. What do they mean? Who put them there? Are they the marks of an urban landwar operating below usual sensory levels?

Hierarchies I have known and loved. Where previously mentioned in this weblog, original reference is in brackets.

Do you have any favourites? Mail me and I'll add them to the list.

Brilliant Upsideclown this morning from Dan: Text Only.

(You can get articles on Monday and Thursday by email. Send the word subscribe to upsideclown-request@historicalfact.com.)

I've been writing AIM bots recently. It's an interesting interface exercise.

A conversational interface is so different to web, to gopher, or mobile phones. Because of the context you're inclined to assume more intelligence in the bot than there actually is. And a hierarchal interface just doesn't work. More than ever here the user path has to be short -- I suspect I get frustrated more quickly because I'm used to working around deficiencies in websites, but not in my friends. For instance, the IM bot SmarterChild does a lot of the things I'm interested in, but I always forget about it. Why? Probably because it goes to the portal approach. It's because it does so many things the interface is harder -- more choices, even if I go there just to check out the movies.

So I've come up with principles and ideas.

Principle | Use any method whatsoever to shorten the user path. This means making the decision of choosing to IM the bot a navigation decision. Instead of one bot, have several that perform different tasks.

Principal | Behave in a conversational manner. Because the user will expect intelligence, don't put the bot in a situation where difficult-to-parse answers are possible.

Concept | How about looking ahead a step in the navigation, and making sure as many options as possible are identified by different names? That way the user can skip ahead a step and as long as it's unambiguous the bot can jump ahead too.

I think the coolest thing these bots to is refer do each other. "No I'm sorry I can't tell you that, but I have a friend who can help". And then, from another bot: "Hi there. You can type X to find out about Y". And then in the future the user can go straight to the second bot, if that's what they want.

Conversational interfaces are hard. But then I realised that all the bot should be doing is following Grice's maxims for conversation. Everything else should follow from there.

The Jack Principles. The game You Don't Know Jack simulated a gameshow plus host. The principles used to make the host converse naturally were strict and surprisingly effective.

[Warning: Viewers who do not want to see an extremely geeky post, look away now.]

Colour me impressed with POE. POE is an event-based object environment for Perl. It provides a framework to handle messaging between different processes, and allocation of processor time -- so, for example, it's very good at doing server based things. And the interfaces are designed really well. I managed to hook it into a different event handler, and effectively deal with incoming requests quite happily with my first script, in one attempt. That's after only one evening browsing through the documentation.

Resource to peruse come down to two. A Beginner's Introduction to POE covers the introduction and some sample scripts (it's essentially the POE manpage). For more in depth information, check out the POE Wiki for documents (POE::Kernel and POE::Session is probably all you'll need), and Cookbook scripts. For multiuser, interactive Perl applications, I reckon this is where it's at.

[Viewers, you may now open your eyes.]