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.
- 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.
- 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.
- A technician handles all computer-related issues. Like guides they answer questions, but they help people set up, maintain and understand the software itself.
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.
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 ...
Very fascinating. But why would small groups need software to analyse stories? And you talk about more than several dozen, which isn't small groups of stories anymore I think, right? So my question is about the scale dimension of Rakontu.
Irene, thanks so much for the comment! My answer is: Small groups DON'T need software to analyse stories. I don't need a washing machine to wash clothes either. But these things can still be useful. I'll see if I can explain why I think this is true in this case.
First, I never advocate analysing stories. Stories don't like it. Meaning, stories are multidimensional constructs replete with far-reaching resonances and complex internal structure. They demand sensemaking, not analysis. I prefer the term "catalysis" whenever I work with stories, because catalysis opens up thought and discussion while analysis nails down answers. So, NOBODY should be analysing stories, in my opinion, not in the way they analyse data.
Second, I have written massive amounts of text in answer to this question. See especially
I would say the main benefits of using software to augment human endeavors in story work are four.
1) Computation speed. People have been making lists and totals and calculations for thousands of years, but once you've seen a spreadsheet update a thousand complicated calculations in the blink of an eye, it's hard to think of going back to pencil and paper. The same thing can be true, not of stories themselves generally, but of metadata about stories. A large part of the practice I have developed consists of looking at interpretations of stories - that is, data collected by asking people about the stories they and others have told. How did you feel about that story, how long will you remember it, why did you tell it, do you think the person in it acted honorably, etc. When I receive these interpretations (typically hundreds of them) I ask the computer to generate several thousand graphs and statistical comparisons that reveal relationships among them that provide useful insights to my clients. Creating such a city of statistics and graphs myself would take weeks. I plan to incorporate the software I use to do this catalytic work into Rakontu so that everyone else can use it on their own interpretations of stories.
2) Memory aids. People have been making to-do lists and written records of stories for thousands of years, and have been handing down the important stories orally for tens of thousands of years before that. We don't need software to remember, but we sure do use it for that. Everybody I know uses the computer to augment their memory, both in terms of their personal life - photos and such - and in terms of what the world knows through the internet. Communities can use software to help them remember their stories so they can use them to understand the past, negotiate the present and plan for the future. And if it's designed well, software can help us remember more than just the stories themselves. It can help us remember why we told them, how they sounded and felt to people with different views, how they connected to other stories, and many many other things. In the same way that a spreadsheet can help us keep track of our household finances, a story database can help a community keep track of the things it wants to remember about its stories, including far more than just the stories themselves.
(PART TWO COMING IN NEXT COMMENT)
(CONTINUED FROM PREVIOUS COMMENT)
3) Knowledge embodiment. One thing I've learned in my efforts to help people learn about stories is that tools can be as instructive as instruction. This is especially true when it comes to learning something you need to DO to learn how to do. So Rakontu embodies knowledge about story work so that as people use it they will learn more about how to work with stories with and without software. In many communities today people don't spend the time together that is needed to build connected webs of story and meaning in a natural, organic way. So you could say we need story software because we use software, not because we tell stories. I've written a whole string of blog posts about the decline of natural storytelling (see the topic in the "By Topic" list) about why people are not telling stories to each other in communities as they did and how story workers need to help reskill everyone in doing that. Rakontu is part of that reskilling effort. In the same way that Meetup said it wanted to use computers to help people meet in person, I want to use software to help people share more stories - with and without software.
4) Mediation devices. People have been using mediation devices to share stories for many thousands of years. Stories are mediation devices themselves: packages in which we wrap our feelings and beliefs in messages of negotiated sharing of experiences not intended to claim truths. People use rituals to mediate their storytelling: places, times, totemic objects, ritual means of opening stories and asking for the floor and for safety to speak freely. Software can offer mediation devices as well. It can offer means for people to say to each other "I want to tell you what my experience has been. I don't mean to tell you what is, or what you should think, or what should be. I want to tell you what has happened to me." If the environment is well constructed, people can use it to build a library of stories together that can enrich their community's ability to know itself, cope with its problems, and build on its assets.
As to scale, I WOULD call several dozen stories a small group of stories. I am talking about what I call "raw stories of personal experience" - meaning anecdotes, what Shawn Callahan calls "little-s" stories. These are not metanarratives but the little things we trade every day. I think people are often unaware of how many little stories we swim around in. If you watch yourself and the people around you for one day, you will see that there are many little stories around. So I can see it as conceivable, even expected, for a small group of people to share hundreds of stories in a short time.
I've seen transformative insights emerge from group sensemaking with collected stories many times, but there does need to be a critical mass of stories to work with. I've seen results with as few as 30 stories, but that's slim pickings. Sixty is better, 100 is better yet. When you get above 200 stories you start getting into diminishing returns for simple goals. But when people in a small group are working with stories together, they are not likely to use all of their stories at once. They might for example gather 50 stories on the topic of town planning, another 50 on the future of the town fair, and so on. Or they might just tell stories about anything that's happening, then choose stories for a sensemaking workshop based on tags or answers to questions.
Hope that is sufficiently explanatory! And please respond if any of this doesn't seem right to you. People tend to get fixed in their views of the way things are, and I'm sure I am no different. I'd be glad to hear another view.
Great! I'm ready again to contribute as I had for Rakontu 1.0
Thanks Stephane! Everybody, Stephane nearly finished a complete French translation of Rakontu 1.0 and should be able to make use of it in the next version to help bring Rakontu to wider use. For us, knowing we are working together on something we all care about is part of what makes us keep doing it. :)
I'm adding one more comment to the discussion with Irene. I mentioned my washing machine metaphor to my husband (I'll copy it again so you don't have to find it: "Small groups DON'T need software to analyse stories. I don't need a washing machine to wash clothes either. But these things can still be useful.")
He made such an insightful reply that I wanted to write it here so you could enjoy it. He said, everybody has clothes that are so precious they don't put them into the washing machine, but that doesn't mean washing machines aren't useful. In the same way, everybody has stories that are so precious they would never put them into software - which may be some part of trepidations about software and stories - but that doesn't mean we should never use software to work with stories. Besides, maybe the washing machines we are used to are overly brutal with our clothes, and maybe they could be designed to be more gentle and aware of our needs. The same could be said for software.
Hi Cynthia, many thanks for your detailed response. Clear enough for me for now. Greetings, irene
Post a Comment