In my lessons-learned document I said that I'm more interested in the ideas from Rakontu moving on than the actual software surviving as is. Since then a few people have asked me to elaborate on that statement. So I've reviewed and thought, and I've come up with a list of six pieces of advice for anyone who would like to incorporate ideas from Rakontu into their own effort to support online story sharing.
1. Support sharing over performing
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.
Over about a decade of observing storytelling and story sharing on the web, I've developed a kind of loose metric for story sharing. I look at the comments posted in response to told stories, and I divide the number of comments that express gratitude or support (thanks, helpful, sympathy) by the number of comments that express value ratings (amazing, well put, ridiculous). From this I get a sharing quotient, or how much story sharing is going on relative to performance. The highest sharing quotients I've seen on the web have not been in the "tell us your story" collection sites, or the "I've got a secret" titillation sites, or the "budding novelist" self-expression sites, or the "I just had sushi for lunch" updating sites. They have been in the still, quiet pools where long-term, somewhat coherent social groups meet, and in which people help each other through difficult conditions and decisions.
The interactions in such high-sharing-quotient settings have a few consistent components. They are repeated many hundreds or thousands of times over periods of years as trust gradually accumulates. They are comparatively rich in content and context. And they are goal-oriented. Sites about everything or nothing, or about connecting for no reason except to connect, seem to lead to more story performing and less story sharing. The best story sharing seems to happen, at least on the web, when people know why they are talking.
How did Rakontu support this, and how well did it succeed? To begin with, I was not able to address this issue well enough to find out that much about it. Because of time constraints I had to make an "ugly" version of Rakontu first. It had almost no hover-drag-type interactivity and no support for the near-conversational elements I think would work best, like facilitated storytelling sessions using voice and chat, with story capture and question answering afterward. I was forced to use the standard, boring fill-in-this-form version of storytelling, which was pretty much guaranteed to produce performance from the start. I could find no way around this, and the outcome was predictable: even I, the staunch advocate of natural storytelling, performed most horribly. I found myself perfecting my prose on a daily basis. So any future efforts in this direction should make at least some attempt to get past the fill-in-a-box form of storytelling, in any way possible. Even something as simple as a drop-down box under somebody else's story (rather than a new page) would help make the exchange more conversational. In some ways I wish I had not even tried to use a basic fill-in-your-story form but had gathered stories only from chat sessions and the like. It might have been a better test of the ideas.
My other attempt to keep storytelling natural was to reduce rating by using a utility-based rating system. This failed miserably. The fact that I myself was the greatest failure at this is clear evidence that it could not work, because I was strongly motivated not to succumb to performance storytelling (and knew it when I was doing it). I've now realized that if you set up a rating scale, it doesn't matter what you call it. Your pitiful protests that it is all about utility, not popularity or quality, are simply lost in the massive explosion of instincts you have evoked. People evaluate everything, every minute of every day. It is what keeps us alive, and we can't stop doing it. It doesn't matter what you say about evaluating. It only matters if people can evaluate things and can see the evaluations of others. So, if I was to try this again, I'd keep the evaluation for utility, but I would remove it from view. I'd pull it deep down into the plumbing of the system and place it only in the questions about stories, which provide the same utilitarian mining capability but without the ranking capacity. If you want to use these ideas, my suggestion is to build in utility tagging (through questions) but build out visible ranking and popularity.
Even the Slashdot-like karma system I put into Rakontu didn't work out that well, because it just became another system of ranking. People could see who posted the most stories and comments and so on, and that became another form of evaluation. Don't get me wrong: for some online communities, doing some things, reputation and ranking are essential elements. They work great when people are sharing opinions and building encyclopedias. But for storytelling ratings are damaging because they draw attention to storytellers and storytelling events and away from stories. When attention is drawn too far away from stories, the experiences in them do not accumulate into useful aggregations. In some contexts, like the Olympics, experiences should separate and compete. But making a goal-oriented story sharing site work is more like building an Olympic stadium than using it. Everyone succeeds together or fails together.
2. Build a café in a library or a library in a café
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. Any software that supports storytelling needs to support both activities well, and it needs to support frequent and easy transitions between them. I had originally thought of this as a café and a library with lots of doors between them, but then I realized the metaphor was potentially damaging: there should be no wall between them to have doors in. The space should be multiple-use, and the café tables should sit among the library shelves, or vice versa.
In fact, 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. How do I know this? Well.... I guess it's an intuition gathered from years of watching people tell stories in person, in email, on the web, and now (for a short time) in Rakontu. In off-line (formerly called "normal") conversation, people are the cafés and the libraries in which stories live, and stories move fluidly from telling to remembering to retelling. When an old woman remembers a story she heard in 1923 and tells it to her great-grandchild, she doesn't type search terms into a web form or traverse a taxonomy tree. The passage of the story from memory to event is effortless and natural. In the online world, however, the wall between event and memory is high and strong. It's between your starred and recent emails and the rest of your massive "inbox"; between the "latest activity" and other stuff in your Ning group; between the first page of Twitter and the stuff you forgot about last month; between the context and the content of Wikipedia articles. These walls reduce the capacity of the collective narrative machine to churn its content, which is critical to useful story sharing.
I knew about this duality of event and memory before I created Rakontu, and indeed addressing it was part of the design from the beginning. In my 1999 presentation on the topic I included this quote from a 1993 paper by Masinter and Ostrom, which still applies:
The primary technology elements proposed for funding in the development of electronic libraries are in the areas of input (scanning, character recognition), retrieval, and presentation. The entire technology emphasis is on collecting material and making it available to individuals.
However, a library is more than just a pile of books. Libraries are also social spaces. Treating the 'electronic library of the future' as an information repository ignores many of the roles played by current institutions, where library users interact with their friends, colleagues, and professionals to [find] material that is relevant for them.A story sharing site cannot be just a pile of stories, but that is what I see happening on most sites that say they are for story sharing. What I see on the internet is either stories entirely absorbed in events and never transferred to memory, or stories stacked up in memory and never returned to the world of events. This is one of the central ideas of Rakontu and should be stolen as widely as possible.
One of the ways I tried to support intermingled event and memory in Rakontu was in my creation of roles as packages of commitment. I stole the idea from a 1996 paper by Richard Bartle, and it's still so interesting I'll repeat it here. The paper was about what people do in multi-user dungeons (MUDs), and it posits this framework to explain motivations:
 |
| (from Bartle 1996) |
The roles I designed for Rakontu (curator, guide, liaison, manager) deliberately populate Bartle's spaces. Managers are the achievers of the Rakontu world, configuring the story sharing environment and shaping the story exchange. Curators are the explorers of Rakontu, mining the collection for stories, finding patterns, fixing tags, keeping the museum in order. Guides are the socializers of Rakontu, answering questions, helping people get started, leading tours. Liaisons are the - well, let's call them the social achievers - in Rakontu, bridging the most difficult divides between online and physical worlds and running storytelling and sensemaking sessions.
Even though I was the only one who really used the roles in the beta testing of Rakontu, I did feel that they matched the activities I carried out while using it, the hats I put on, if you will. They helped me set a frame for whatever I was doing in the system as I approached it each time, whether it was cleaning up tags, answering questions, adding collected stories in batches, or asking people to tell stories. So I think this is an idea worth keeping and using.
This trial of supporting the event-memory duality has an impact on technological options for continuing work on Rakontu. One of my strongest technology lessons learned was that I spent way too much time reinventing wheels related to social media. I had to implement many things that already exist in many web platforms, such as groups, permissions, private messaging, notification, management control, removing offensive material and spam, and so on ad nauseum. So one possibility in doing more with these ideas is to start with a platform that already supports much of what is required for social media. However, that is only the café part of the equation. Few social media solutions give much support to library functions. For that you need semantic indexing, taxonomy and/or folksonomy, simple and advanced search, typed linking, and all the other things that make a library work. I have yet to find any system I can build upon that combines the café and the library in equal proportions. Everything I see favors one strongly over the other. Wiki and other collaborative creation software favor the library, and discussion and social media software favor the café. In any system you choose as a foundation you will most likely need to reinvent some of the wheels of the other system. My advice is to think about your strengths: what do you know well how to build? If a café is something you can build in your sleep, look around for pre-built library components. If your experience is in library building, see what you can find to complement it in café packages. I'm better at library building myself, which is probably why the café building parts were onerous for me.
3. Embody knowledge about narrative
One of my most important discoveries about storytelling is that people vary in whether they think they tell stories and are good at telling stories. (That discovery was the subject of this post a while back.) Another dimension to the variation is whether people understand why people telling each other stories matters, and how to do that. The thing I learned before I started Rakontu was not to try to explain any of that, or at least not to make explanations into barriers. Systems that force people to understand something before they can enter them are empty places. The better solution is to shape the experience itself so that it embodies knowledge about stories and storytelling rather than trying to spread it.
Probably the best successes of Rakontu so far have been in this area. For example, one thing that seemed to work well was the system of typed, annotated links between stories. In Rakontu, when someone sees a topic, they can respond to it with a story, and that link, and their annotated reason for it, is kept and can be reviewed and searched. When someone reads a story, they can tell another version of the events it recounts, tell another story it reminds them of, or explicitly link it to another story for any (annotated) reason. As we built a base of stories using Rakontu, I found these links an essential tool for "getting around" in the library we were building. I often found myself clicking through the web of connections among stories to follow a sort of thought-path around. I can see how this sort of web-building could be much more powerful as the story collection grows and its interlinkings intensify.
By the way, I got this web-building idea from Roger Schank's work on case-based expert knowledge databases. More specifically, I got it from this interesting essay by Jorn Barger, who worked on Schank's team and revealed in it more about how these story databases were constructed. When I read this sentence back in 1999:
All the links from story to story in the Ask-Tom casebase had to be 'hand-crafted' or hardwired, which ultimately meant looking at every possible pair of clips and asking whether either would make an interesting followup to the other, and which of the eight CAC-links it made most sense under.I realized that the human creation of such typed links (which the AI researchers working on expert systems found an onerous task and seemed embarrassed to admit was being done by clerical help) was a perfect sensemaking activity for people telling each other stories. Building a web of typed, annotated links helps people understand their stories as they tell them, and it creates something they can use later to explore the same issues when they have a need for them. That idea is a definite "keeper" out of what makes up Rakontu as it stands today.
Another keeper in terms of embodying knowledge is Rakontu's question-asking system. That part also worked out very well. When anyone tells a story in Rakontu, and when anyone reads a story, they are presented with several questions that capture their interpretation of the story. For example:
- How do you feel about this story?
- Why was it told?
- To whom did this story happen?
- How long will you remember this story?
One important component of the question-asking system, and this may be special to questions about stories, is that it has to be flexible. Many systems are available to attach metadata to collected items; but rarely can you change indexing schemes attached to live data. In Rakontu such after-the-fact redesigning turned out to be critical. When a group is forming, they can only guess at what questions will best serve their needs. Even in the small tests I did, I found myself mucking about with the questions often as the story collection began to form and newly obvious questions and answers emerged. Supporting flexible questioning means that it must be possible to modify existing answers - very carefully - to match a new indexing scheme. For example, if you find that people rarely choose the how-do-you-feel answer "stymied" but often choose "frustrated", you might decide that "stymied" is close enough and would make searching easier, so you may want to lump together the two answers. Or you might find that nobody ever picks "thwarted" and you have too many answers and just want to remove it. It also requires mechanisms for reviewing large numbers of answers and looking for gaps where metadata is scarce. This takes work, both on the part of the system builders and on the part of those maintaining the story museum. But it's worth it. I'd say that the ability to keep your questions relevant and useful as your storytellers and understanding and goals change is a requirement for a useful living story museum.
You might say that such flexible organization can be accomplished through tagging. Somewhat, and in fact I loved the tagging aspect in Rakontu and used it often. But tagging narrows the source of interpretation and reduces the utility of the story collection to support multi-perspective sensemaking. Few people (mostly curators) have the time and attention and willingness to tag stories. It's a nerd thing. Tags are tasks, but questions are conversations. Questions bring everyone in and increase the diversity of response and thus the strength of the story collection.
One thing I think Rakontu needs much more work on is diverse visualization of the collected stories and other data. The timeline view of stories I used as Rakontu's main interface was adequate for the café (though it had its problems, mainly related to point number one above). But 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. Granted, if I had been able to make the fancy high-mouse-interaction interface I had mocked up, some of these things would have been included. But still, I found that I wanted lots of ways to stroll around in the stories when I needed different things. So that is an area that would, I think, reward exploration.
But having said all that, and even though Rakontu strongly featured widget-based question answering and other methods of tagging and so on, I'm not sure it needs to be as idiot-proof as all this. Do you know those emails you get from friends where you get a page of questions about yourself, and you are supposed to insert your own answers? Those are essentially semantic indexing sheets. I've been amazed by how few mistakes people make in doing this. Even people whose eyes glaze over when you try to explain flexible semantic indexing can paste their answers over Uncle Joe's and send the thing round. It's possible that a motivated group could run an entire Rakontu-like story sharing system through email or in a discussion group. All it needs is somebody putting some time into pulling apart messages with hand-filled templates in them. It would be a pain, but it wouldn't require any special software at all. For example, say you send out an email to your group that says "does anybody remember eating at that old restaurant on the corner, you know, the one that burned down last year?". And then when people tell stories about it, they remember to take the list of five questions and paste them in at the end along with their answers. Then some long-suffering secretary of the group takes all the stories and answers and puts them into a spreadsheet, and at the next meeting of the historical society everybody looks at the bar charts they printed out. Or everybody takes the printed stories-and-answers and puts them into little piles, which is the same thing.
What I'm trying to say is that you don't need fancy software to do useful things with information, and you don't have to wait until you get the fancy software (or the creator of the fancy software gets a big grant) to do what you want to do. Fancy software helps, but you can do the same things with fingers and paper, and I think people might be starting to forget that. (If you don't believe me, look at old records from a church or factory or port. We had complicated metadata long before we had computers.) Computers are useful for managing metadata, but they are still the smaller part of the equation. The important thing in supporting storytelling is to keep the connective tissue of story sharing intact. When we speak through computers, our conversations get broken up and put into little boxes, and the connective tissues don't get laid down as they should. Story sharing, and especially the interplay between event and memory, depends on connection far more than other conversation does. You can maintain connective tissue using fancy software, but you can maintain it using norms and practices too. In fact, the best fancy software doesn't supplant human norms and practices; it gets its power from them. The great advance that is Google came from a realization that the way people link up their web sites - by hand - is a resource that can power fancy software. You can do that with stories too.
4. Build for commitment
In the 1999 presentation that held the idea that eventually became Rakontu, I said that "stories thrive in groups of people in frequent and persistent contact in a shared culture." I of course know that stories also live in other environments, like in vast marketplaces where people choose products and services, and in the shifting sands of coalition building in discussion and debate. What I probably should have said was "the types of stories I am most interested in supporting thrive in groups of people in frequent and persistent contact in a shared culture." I'm still interested in supporting the same types of stories, and I still think they live in the places where small groups of people come together often. That is why I built Rakontu for small groups of people who already know each other, at least a little. It's where the gear-turning stories, the change-making stories, the life-improving stories, thrive.
The tests of Rakontu bore this out. It worked best when it was being used by people who knew each other. With strangers such things as responding to one story with another story, interpreting the stories told by others, and looking at patterns in stories together ... didn't happen as much, or they happened in a high-school-dance way in which most of the people watched as a few people started to dance. Of course, this same thing happens on all discussion groups, which may form for months before the really interesting conversations take place. But with something created for the express purpose of storytelling, the most fruitful interactions might have to be put on hold until the necessary trust is established. I'm starting to think that a dedicated story sharing site like Rakontu can't work unless one of two things happen: the Rakontu is "seeded" with stories gathered from conversation or a special in-person or chat story session, or the Rakontu is used for an existing group who can jump into the commitment-requiring elements without hesitation. Even in the latter case it may be necessary to supplement lower-intensity fill-in-the-form story collection with higher-intensity conversational elements periodically.
I've seen many story collecting web sites go up in which complete strangers post stories, and I've never seen one of these succeed - in the ways I would like to see story sharing succeed. They do sometimes succeed in the sense that people looking for information find what they need. I myself have received much needed help reading stories of medical conditions and life challenges. But for working towards a common goal that will benefit everyone in a group, this sort of story collection lacks the connective tissue to build something larger. In general I think web software has been wonderful for people finding and meeting people. It has been wonderful for people trying to draw more people to a cause. It has done a dismal job helping people who already know each other do anything but bring the most basic information together. In my opinion, Margaret Mead's small groups of thoughtful, committed citizens trying to change the world are still waiting for their internet. If there is one thing I think could not be stripped away from Rakontu without ruining it, it would be its emphasis on helping small groups achieve common goals. Because it's unique, because it's needed, and because it's what stories do best.
The other side of building for commitment is to keep it centered on continuity. Since I built Rakontu several people have approached me wanting to use it for one-time story collection. This would be a legitimate use of any such software, and with a few tweaks Rakontu could easily become a story-oriented SurveyMonkey. But I'm not excited about that possibility and have sent people off to other solutions for one-time collection. Why? Well, first, because SurveyMonkey and a whole raft of other surveying systems are already out there, and they work fine for story elicitation. And second, if Rakontu, or something based on it, did survive and get used and get popular, the last thing I would want is for people to think, rightly or wrongly, that it was just a data collection device. The whole point of the work is to build story habitats, not story zoos or story cages. If it gets away from that, it's not the same work at all.
5. Decomplexify
I'm a nerd. I make things too detailed, too confusing. I write in a nerdy way, and I write nerdy software. I obsess over things some people don't even notice. If I was to ever work on Rakontu again, I'd hire some non-nerds to help me suck some of the nerdiness out of it. Even after a few weeks have gone by and I look at the Rakontu interface I've forgotten what some of the cryptic things mean. It needs better hiding of complexity for new users, and it needs much more eye candy. I used to think eye candy was just that, but I've come round to the position that at least some eye candy would be better named "learning curve smoothing devices." When icons are big and memorable, that's one less bump going up the curve, because you don't say "what the heck is that thing" after a week has gone by. When the available choices aren't always staring at you but appear only when you click on a Javascript arrow, that's one less bump going up the curve, because you aren't confronted with their complexity all the time. When you grab a Google map and it does what it would do if you grabbed a real map, and you didn't have to find the button marked "Shift 20 degrees to South" instead, that's one less bump going up the curve.
I skimped on eye candy and interactivity in Rakontu, and I believed I did it out of necessity. But after some reflection I wonder if I did it partly out of comfort with nerdy detail. And I wonder if I should have built something less powerful and easier to use. The functionality versus ease of use dilemma is always difficult, but it's useful to know yourself and know when you need somebody else to balance your natural proclivities. If you steal these ideas and you're a nerd too, watch out for over-nerdifying what you do (yes, this could happen to you). If you steal these ideas and you're not a nerd, do try to wade through the detail and find the good stuff mixed in. It's all in there, really.
6. Pay no attention to that man behind the curtain
My original vision for Rakontu was not just a web site where people would tell and store stories, like a Ning with stories in it. It was a suite of tools and educational aids people would use to support story sharing and sensemaking in both asynchronous and synchronous, on-line and physical sessions. In a way I regret using the little funding I had to build a form-based web application, because that is the weaker part of the vision, and I don't want people to think that is what Rakontu was supposed to be. I've come round to the view that my time might have been better spent writing small modular tools to support the interplay between event and memory.
For example, I could have written software that would help people take a thousand messages from an online forum, find the stories in them, collect answers about the stories (from their tellers and from others), and present the information back to the forum organizer in spreadsheet form so that they could report trends to the group and call up stories pertinent to future needs. Or, I could have written software that helped people take told stories and use them with sensemaking frameworks to come to new understandings about issues of concern. Or I could have written software that helped people copy stories found on the web (including in forums they participate in) to a personal storybase, with annotations and connections, and share that storybase with others in their group. Or I could have written an email add-on that highlighted stories in emails and popped up a "keep this story?" window with questions to answer. And so on.
The possibilities for supporting story sharing do not begin and end with creating story repositories and ways to fill them. There are many nooks and crannies where related tools could fit in the spaces between the ways we talk, online and offline, today. To anyone who is interested in pursuing these ideas, I'd suggest finding some of those. The point is, if you want to steal these ideas, which I hope lots of people do, don't look that hard at what I actually built. If you do look at it, look as carefully at my mistakes and regrets as you do at its architecture. And look at the ideas. Read the things I've written about why I wanted to build Rakontu, what gaps I'm trying to fill, what could go wrong, and what I'd like storytelling on the web to be like someday. These are the things worth stealing.
One more thing: if you'd like an accomplice in stealing these ideas, send me a note. I'll be your man on the inside.
No comments:
Post a Comment