Recently, I’ve been working on the design of a new software tool. Or more accurately, the refactoring of a current tool into something new that we hope will better match how our users think about software and data. It’s prompted me to think about the triangle of connection between software and user, developer and software, and user and developer. It’s a strange relationship. Each part influences and can blend with the other, and yet the individual parts have limits. This has also prompted me to ask what the boundary objects are between these parts, and in what context do these parts blend and separate.
I’ve taken a framework from my Data Storytelling class, which I’m calling the *story-teller-audience* relationship, and attempting to map it to the *software-developer-user* relationship.
*Image from Dr. Kate McDowell (https://ischool.illinois.edu/people/kate-mcdowell) whose work on data storytelling has inspired this post*
I think we can translate the story to be the software, the teller to be the developer, and the audience to be the user.
As it was noted into my Data StoryTelling class, even though there are three icons in the triangle, there are actually six parts, including the lines that connect them. The story/software is the vehicle that creates and mediates a connection – something is being imparted through this entity. An idea. An emotion. An image. The teller/developer is the architect between the story/software – they build the structure, choose the language and sequence of events and functions. The audience/user is receiving and absorbing the information from the story/software, as constructed by the teller/developer. As they absorb the information, they make their own version of the story/software; that is their own internal representation of what this imparting information means and how it was constructed.
We often operate as all of these parts at once. We tell ourselves stories we create or learn and act on the information we get – the importance of our work, where our families come from, what our futures hold. We also perform all sorts of functions – we calculate how much something is going to cost, what to say next in a conversation, and plan our route to and from locations. We learn to do this when we’re young, and it becomes the map from which we connect with ourselves and each other.
Our story/software can land wrong. A sequence of events may be jumbled, or the wrong language or emphasis may be used. The flow of data or configuration of functions may not make sense to others. Our brains makes mistakes too – we can misread a social cue, or make a math error. A connection is strained or missed.
As I continue to dwell on the *software-developer-user* parallel to the *story-teller-audience* paradigm, I’m finding similar that patterns underpin them both. I’m beginning to apply the same questions that aid the *story-teller-audience* connections to the *software-developer-user* relationship.
– Who is the audience? What will speak to them?
– who are the users? What will they do with the software?
– How will my story impact my audience? What message am I’m trying to communicate, and what mechanisms support that message?
– what am I (a developer) trying to impart through my tool to the user? What structure, emphasis, and tension (and resolution) can be employed to create a connection?
– What relationship does the teller and audience have? Whose story is the teller presenting? Is it their own story? Is it the audience’s story?
– What is the nature of the relationship between the user and the developer? Is there a power dynamic? A language barrier? How will the software handle this?
– Will the audience remember and re-tell my story? Will they change it? Who do I want to re-tell my story?
– Will user’s “re-tell” a developers software? Can users become the developers themselves? Which software tools get re-used, re-purposed, and re-made? Why?
Of course, the mapping isn’t exact. Software usually has clear inputs and output such as numbers, files, images. Stories don’t seem to have this pipeline, or if they do, it’s less obvious. The exchange of information, the connection, lies under the surface in storytelling. That is the boundary object I want to introduce and explore with this framework – open source software development as a form of connection and exchange of cultural information that goes beyond the code.