3 min read
Not all dreams are oniric. As I was half-awakening today, I saw myself in a work situation where I was helping a policy maker and his team design the information system they needed. Their initial inclination was to pile up features, mimicking what they thought other information systems looked like, and hoping that it would, by some magic, solve their problems. But they did not know how, and they had doubts about the whole endeavor; that is why I was advising them.
In my dream, I told them that they should focus on some key, quality content, and how to present it. My message was that even if you have a good database and a nice front-end, your system is only worth the data it contains, assuming that one can make sense of it. I encouraged them to stop thinking of technical features as a list, and instead pick a practical case as a benchmark. Assuming that you know the data and its interpretation already, does the system help you tell the right story? Storytelling is all about context. Your system is not just about data, but also practices around them, everything you need to interpret them. This thought exercise helps shifting the design discussion away from data-centric features to the profit of user-centric features. For instance, annotation, metadata, data care (cleaning, formatting) and quality control.
In my dream, the team was very receptive. They knew it already, and they needed a confirmation. Now their next step was clear: pick data on a topic they know well, process it through the current prototype, and check which features are useful to tell the right story. They were satisfied.
Then I added: storytelling is only half the picture. Because most of the time, your system will contain half-baked, dirty data that you don’t know how to interpret. While you focus on telling stories with good data, the system allows bad data to talk by themselves. It frames them a certain way, it changes how you think of them. If you do not pay attention, you will circulate these unintentional stories. So the other half of the picture is to ask yourself: what story am I telling with the system when I am not trying to tell a story?
I thought: this should be called storyletting. And I woke up. The brain is a mystery.
Storyletting is the act of publishing data or a data visualization while pretending that it tells no story, or framing it as something that is external to the story currently told. It is the act of letting certain inscriptions tell freely their own stories.
The concept assumes that all inscriptions tell stories: that is its purpose. It aims at making you aware of the narrative side effects of elements you do not see as parts of the story you tell. We know that visualizations can be manipulated. But we tend to overlook that the same effects can arise unintentionally, in our own practices, because we wrongly assume that certain inscriptions do not have their own voice. For instance the unprocessed (“raw” data, “source” code) or things we frame as side content (screenshot of a tool, appendix). It is good to be able to name their narrative effect.
Cite this blog post
Mathieu Jacomy (2020, July 11). Storyletting. Reticular. Retrieved March 1, 2024, from https://reticular.hypotheses.org/1783