Spring and new life for Rakontu

Every year I forget about spring, and it's such a wonderful surprise to find it all happening again. I can't get enough of sitting on the ground beside the withdrawing snow and just looking at the dirt. It's still there, and there are still things growing in it. What are seasons but a story that gives us hope?

I am happy to report that Rakontu has emerged from its long snooze and is scampering about again. Meaning, we have new documents on the architecture and visual design of Rakontu 2.0 for you to look at. Please send feedback and suggestions.

For those who have no idea what that means, here is the elevator speech on Rakontu:

Rakontu is about small groups sharing stories for a reason. Rakontu communities are private spaces where people share personal experiences about something they all care about and in the process build something they can all use. Usually people in a Rakontu community will have something they want to do together, some common goal, and they will be interested in collecting and working with their stories as a means of getting there.

You could call Rakontu groupware for story sharing. I think that gets the point across better than anything related to social media, because social media has taken on a sort of Seinfeld-like nothing-about-nothing tone I'd rather avoid. Not that there is anything wrong with that.

So I thought what I'd do here is use this space to go back to a previous blog post about Rakontu, Steal these ideas, and use it to explain (and test by explaining) changes and improvements in the new version. (If you haven't read that and want to understand this, you might want to go back and read it first.)

The most exciting thing about Rakontu 2.0, to me, is that I am not building it. My husband and I have been building software together for nearly twenty years. Our skills and interests dovetail so perfectly that we work much better together than alone. Where each of us fears to tread the other rushes in confident of success. So this time around, his will be the legs you see sticking out from under the chassis when you visit, and I'll be priming the body panels.

This time we are building a rich thick gooey client in a Java desktop application that communicates via mediated something-or-other (here we see the efficiency inherent in the system). This gives us the ability to move far beyond the straitjacket of web forms and "view next 25 items" links. I am very excited about this movement to the rich client, as the new visual design surely shows. (And yet I also eagerly await the inevitable embarassment when the real thing makes these designs look ridiculous.)

One thing that has not changed and will not change is that Rakontu is free and open source. It will remain so. We have made and will continue to make a substantial investment in developing Rakontu. Our business model is to sell our (hopefully very useful) services, as a subject matter expert in the area of story work and as a technical expert in support of the software, to organizations who want to use Rakontu. I always say that people who make open source software are like those old-time doctors who took payments in money or chickens. If you have a budget, we will be overjoyed to help you make Rakontu work for you. If you don't have a budget, here it is (will be), and if you have any spare chickens, that is, good word of mouth, feedback, bug reports, icons, connections ... then by all means drop in and say hello.

So, on to those improvements.

1. Support sharing over performing

From Steal these ideas:

One of the biggest challenges in supporting online story sharing today is countering the performance problem. The web has developed into a grand marketplace for self-expression and self-promotion, and people shape their behavior on it accordingly. There is nothing wrong with self-expression, and surely all storytelling contains an element of performance. But I'm interested in supporting the kind of storytelling that leads to conflict resolution, perspective-taking, mutual learning, strong communities, and effective decision making. I call this story sharing to distinguish it from storytelling in which performance is a larger force.

Rakontu 2.0 will have some features that I hope will increase the ratio of sharing to performing in story exchange: embedded utility ranking, preservation of context, social translucence, and synchronous story sharing.

Embedded utility ranking means that it will be impossible to rate a story for quality or give it a "thumbs up" or any other measure of popularity. Why? Imagine a group of programmers building software together and voting each other's code up and down based on how cool the indenting is or how clever the variable names are. Or imagine a group of engineers building a bridge together and voting their designs up and down based on the fonts and colors they used to draw them. It would be useless information that would get in the way of building something useful together. In the same way, when people want to work with their stories to achieve a shared goal, a unidimensional rating of stories based on their resemblance to Hollywood blockbusters or Shakespearean tragedies is a distraction from the task at hand. So the "nudge" system I built in Rakontu 1.0, which was a grand and lovely mistake, will move underground in 2.0 and become a question about contexts in which each story could best be useful to the group. It will still be possible to rank and sort stories, but questions of utility will be just that: questions, whose answers have meaningful uses. Not ratings, not badges and not popularity contests.

Preservation of context means that Rakontu 2.0 will keep the context of story exchange in sight as new stories are elicited, told and linked into the story museum. One thing I realized the last time through was that "out of sight out of mind" applies strongly when it comes to story context. We don't close our eyes when we tell a story, and software that helps us tell stories shouldn't close our eyes either. So when a person is telling a story they should never lose sight (literally) of the context in which they are telling it: who they are telling it to, why they are telling it, what they are responding to, and so on. You should see some indications of this when you look at the new visual design, but I will be keeping it in mind as we build the working version.

Social translucence is a wonderful term coined by Wendy Kellogg and Tom Erickson at IBM Research. I think sometimes people have misunderstood this term and built systems with social transparency instead of translucence. The reason healthy social relationships are translucent and not transparent is that people constantly negotiate boundaries and partially share information. That's the necessary opacity in the translucency that makes things work. As many people are painfully aware of at this point, nobody wants to know everything about everybody all the time.

One thing I've thought a lot about is the impossibility of channeling social translucence into a unidimensional measure or score of activity and behavior such as karma and buzz systems. My husband pointed me to what Clay Shirky said about trying to engineer social negotiation (sorry - don't have a particular link to give you; just look at his stuff, it's all good). What Shirky said was that people already know how to be aware of each other. We've been doing it for a long time. If you try to give people a "better" way to do that you will just get in their way. It's like giving a dog an electronic sniffer that can identify ten smells. I like what he said and it rings true based on what I've seen in other social software and in my own attempts with Rakontu 1.0. So I'm getting rid of all attempts to summarize or package social awareness and just letting people see what other people are doing. In other words I'm now concentrating on creating a portrait of activity rather than a measure of it.

Synchronous story sharing means that Rakontu 2.0 will have a much stronger emphasis on people sharing stories in real-time conversation. People will still be able to enter a story into the system in the same way people make posts to online forums, but it will be easy and natural - I hope - to complement asynchronous posting with chat-type conversations in which stories naturally flow, are noticed, and are tucked in to the story museum as they appear. Of course I'm waving my hands around furiously as I type this (metaphorically) because this part will depend very heavily on strong testing, in which I invite everyone who is reading this to participate and contribute.

2. Build a café in a library or a library in a café

From Steal these ideas:

Possibly the most important things I learned by designing, building and using Rakontu are that online story sharing is both a verb (storytelling) and a noun (stories); and that neither matters more than the other; and that they must intermingle for story sharing to work. I picture these as a café where people meet and recall their experiences, and a library where people browse through experiences previously recalled.

This part I am super excited about. In fact two of the menus in Rakontu 2.0 are going to be "café" and "library." I have essentially divided the user experience into two main spaces: those where you ask what is going on here and those where you ask what is in here. Here is a quick look at the café timeline (non-working mockup which will appear nonsensical later).

As before the timeline shows time on the horizontal axis, but the disastrous popularity axis has been replaced with categories of activity, to supply the "what" that is going on here. Of course power users can manipulate the categories to explore nuances of activity such as word usage, answers to questions, fiction and fact, and so on. This design also removes the need to remember what a lot of little icons mean which is a hindrance.

I came up with this design, by the way, after taking a stroll through the periodic table of visualizations at visual-literacy.org. I took each of the hundred or so visualizations shown there and tried it out with stories and people and comments and so on in the slots provided. This "swim lane" diagram won the competition for best fit for purpose.

Everyone in a café should see the same café so they can use the same language when they talk. But the best way to look at a library depends on who is looking at it and why. So the basic view for the library in Rakontu 2.0 is a simple one based on the old Smalltalk browser, which I still miss every day. It was just a great way to drill down and up and sideways through a mass of related information very quickly. Using the Smalltalk browser always reminded me of riding the elevator in Willy Wonka's chocolate factory: it doesn't just go up. This is Rakontu's version of the browser:

Here we see the user looking through polls (sets of questions) about stories and finding stories people said they would remember for a long time. Under each story the drill-down continues to explore the comments and things hanging below it like catkins on a twig.

I also said in Steal these ideas that, "as soon as we got up over a few dozen stories I found myself wanting to see many other views of the data: link maps, bar charts, tables, sorted lists, and so on." We are creating a plug-in interface for visualizations of Rakontu data so that other people can write fancy bubble charts and whatever kinds of insightful navigation and pattern detection devices they would like to add. That's kind of a no-brainer.

You may be wondering why I keep talking about a distinction between café and library, since in Steal these ideas I said, "I'll be so bold as to say that any story sharing system in which the telling and the keeping are not intermingled will not succeed." The great thing about software is that if you design it well you can create tools that provide distinctions between and passages between at the same time. How? By encapsulating each activity within the other. I've seen many well-meaning pieces of software that enforce modality where it is not necessary simply because their developers failed to imagine passages through the walls of their conceptual constructions. The normal laws of space and time do not apply in software. Say you are in your kitchen, and you remember you forgot to clean out the fish tank. You have to go into the living room, right? But not in software. You can just extend your magical arms and reach anywhere in the house.

I love contextual menus. You know, those right-click-on-everything-in-sight menus? They provide secret passageways through many otherwise impenetrable software fortresses. One I have grown to love is in PowerPoint. You can click on any number of objects on the screen, then right-click and choose "Save as Picture." PowerPoint will write a PNG file with exactly those objects, even if they were five out of a hundred on the page. That is a passageway. So even though we are building café and library areas, they will be so criss-crossed with passages that it will be more like a café-library and a library-café. Which passages are best kept open and which are best left to heal closed is a matter of testing, testing and then some testing.

Who does what

There was another element in the café/library section in the Steal these ideas post. It was about roles people could take on to help make the community work: curator of the story museum, guide to help people engage in story exchange, and liaison to bridge gaps to off-line members. I still love the roles, but in hindsight, because I wanted them to be volunteer and easy to take on without approval, I put too much work onto the managers as a result.

In the new design I've changed that in two ways. First, managers can choose whether each role is open (anyone can take it on at any time), agreed (anyone can take it on, but they have to agree to some terms and must commit to a time frame), or moderated (a manager must approve members taking on the role). In this way the software can better accommodate a range of groups with varying degrees of trust built up before the software is in use. This is similar to how people run real storehouses of memorable items. If the museum is grandma's attic, all the family members can come in and poke around. But if the museum handles a city's treasures, measures must be taken to safeguard the collection.

Second, I've designed some new roles that delegate some of the tasks previously given to managers.

1. A facilitator takes responsibility for planning group workshops for story gathering and sensemaking, and they maintain any fictional characters for anonymous attribution. Facilitators are like guides in focusing on the people-parts of the community, but they have wider and deeper responsibilities in that context.
2. A researcher explores the collected stories to look for patterns that can be used in sensemaking workshops. They also manage the polls of questions about stories, observing which questions are most useful and which are misunderstood or ignored. Researchers are like curators in focusing on the data-parts of the community, but they have wider and deeper responsibilities in that context.
3. A technician handles all computer-related issues. Like guides they answer questions, but they help people set up, maintain and understand the software itself.

With these delegations the manager is only required to provide governance for the group, that is, setting policies and resolving disputes.

Now you may have noticed that the facilitator, researcher and technician roles require expertise that may be beyond the capacity of many people who might be using Rakontu. This reflects two realities. First, I want to expand Rakontu to cover a wide range of storytelling and sensemaking activities so it can fully support people who are working with stories for a reason. And that is going to involve some learning by somebody. People may grow into the knowledge, but somebody has to learn to carry out those roles.

Second, we can't continue to develop Rakontu forever without any funding, so I need to design some way I can help people use it for a fee. I can't do that from the outside, so I need to build myself into the system, and it only makes sense to build in other people like myself who can help people work with stories. Much of my work in the past several years has concentrated on helping everyone learn how to do what I do, but it is always reasonable to charge for useful work. If you happen to be a person who facilitates story work and would like to be involved in using and improving Rakontu, by all means let me know. I would love (in time) to be able to point to a network of facilitators, researchers and technicians available to help people with story projects using Rakontu. You know that story about heaven and hell, right? About the long spoons? We can feed each other and eat well or feed ourselves and starve.

3. Embody knowledge about narrative

Looking back at the Steal these ideas post, I said about embodying knowledge, "Probably the best successes of Rakontu so far have been in this area." I still feel that way. I feel pretty confident that Rakontu will help people share stories and use them to do useful things even if they know absolutely nothing about stories.

And while I'm at it, let me repeat what I said back then in this part, which is that nobody needs Rakontu or anything like it to share stories or work with them. Why am I building software then? Because people use computers. If there were no computers, after I recovered from my three day celebration I would set about helping people work with stories without computers. But here they are, and here we are. So let's get to work.

4. Build for commitment

Yep. No change there. I still think the web needs this, more and more in fact, and I'm still committed to it. I know that much story sharing happens in casual settings, and I do not claim that by designing for people with a shared goal I am building the only reasonable or even best story sharing support. It is just what I care most about, that's all.

5. Decomplexify

This is where I will need your help. I can never be anything but a hopeless nerd, a detail lover. You will always find me mucking about in the viscera of any system I use or build. I will need the help of many friends to rise up and have a look around to see how things look different from up there. All criticisms will be gratefully acknowledged, even if with a snarl. (Joking...)

6. Pay no attention to that man behind the curtain

This part of the post was about how you should not build what I built, but build other things I didn't think of. I am still thinking of this as well. We plan to include a few different interfaces for both plug-in and exchange connections between Rakontu and other software, and we would love to exchange ideas with anyone interested in pursuing ideas similar to these.

So: that's the plan. I'll say it again: We have new documents on the architecture and visual design of Rakontu 2.0 for you to look at. Please send feedback and suggestions. By next spring ...