A Builder Redesign Sketch 1

[patternleaf]

A sketch of possible builder re-implementation to provoke thought/conversation. Main features:

• No separate viewer/builder (at least from user's point of view). When logged in, viewer has an "Edit" switch which reveals Edit mode chrome and features.
• Two main editing modes: Pages and Meta (names TBD of course)
  • Pages is a WYSIWYG view of story with in-place editing.
  • Meta is the "back-side" of the story: tags, narrative structure, data, etc.
• Some attempt at visual consistency.
  • Context-sensitive toolbar/inspector always visible.
  • Colors used for in-story tagging of narrative structure. (Bad for accessibility, though!)
  • Minimal Visual discontinuity in Pages mode.

Another thing shown here is an attempt at a primitive Narrative Structure editor. Not really sure how it should work, but the main idea is that you construct a graph of the main purposes served for every part of the story. Then, as you write the user-facing story, you can "tag" photos, paragraphs, and so on with those elements. During review, if presentational elements are un-tagged, or if the intentions seem not to match to the presentation in some other way, it may be that the story needs more work.

No idea why a graph would be a good structure for the editor's output. Maybe a hierarchy would be better than graph.

---

This mockup shows the two main mode switches. These are always visible (to a logged-in story owner, of course).

---

This image shows some of the tools in the Pages mode. Note also that the story title and attribution should be editable in-place.

---

This image shows the Meta mode and some representation of the Narrative Structure editor. Not sure if I got all the tabs we'd need. Maybe some consolidation would be appropriate?

If something like this works out, I'd really want to use a CSS3 page-flip effect to transition to /from the Meta mode "back-side".

Note that the toolbar is still a toolbar, and the mode buttons are still visible.

[jwirfs-brock]

I'm going to start posting some more inspiration/idea links here...

This latest design idea reminds me of mind-mapping software. But what makes it different is that the end goal is to present it to someone else -- rather than to organize your own thoughts. I haven't been that impressed with mind-mapping software in the past (I've used Freemind before), but just saw iThought, which seems kinda cool:

http://www.ithoughts.co.uk/iThoughtsHD/Gallery.html

(I don't have an iPhone or iPad, though, so I can't actually try it out.)

One thing I like about it is that you can have different content types (what we'd call assets) in your mind-map, and it looks like when you click on a thumb-nail of that asset, you can then view it (whether it's an image, video, etc.). That seems pretty applicable to what we're doing.

Also, it sounds like they have a feature that compressed your mind-map into a textual outline -- that seems somewhat similar to our discussion about flattening non-linear structures into a linear presentation.

I've seen some other interesting software that is designed to help writers organize their writing projects. I'm going to try to round up some examples to share.

[jwirfs-brock]

I put together an outline of how the narrative/semantic structures would interact with this builder re-design. It's in Google Docs: https://docs.google.com/document/d/156aus3sowa0hKFCAr766ToXyxwMOUxWm7Pz93a_fMUY/edit#

In this doc, I have... A. Some sample narrative structures (and diagrams of them) B. The commons building blocks of a narrative arc C. Prompts/questions that could help a user flesh out those building blocks via assets D. A description of how all of this would be represented in the new builder design

My next steps to develop this idea are to...

1. Make a diagram of how this would work
2. Map an existing Floodlight story onto this version of the builder to see if it "works"

I'd love any feedback as I'm doing this...

[ghing]

@patternleaf, in your proposed meta narrative editor, do the "Who", "What", "Actions" and "Effects" blocks correspond to "Pages", or are they something else?

[jwirfs-brock]

Ok, here's my very rough, probably incomprehensible, sketch. More detailed picture coming shortly...

[patternleaf]

@ghing No, "Pages" are like our current Sections. A page corresponds to what a viewer will see as a single page of the story. This is assuming a linear, page/section-driven structure, as opposed to some other structure.

The Who/What/etc represent elements of semantic/narrative structure: goals, devices, questions, or what-not. Just what these are needs to be fleshed out.

But the general idea is that Pages are presentational; reader-facing. Narrative elements are "behind the counter", and only author-facing.

---

In this mock-up I suggest one way a narrative structure could inform what a reader actually sees, based on the idea I mentioned in the call last week. The Who/What/etc from behind the counter appear as tokens in the upper-right box of the Pages view (the first few screenshots). Users can drag and drop those tokens onto assets, paragraphs, or other elements of the presentation to "tag" them as being related to that element of Narrative structure.

For example, a paragraph explaining who is benefitting from a foundation's program could be tagged with the "Who" element. A photograph of same could also be tagged. Of course tagging is many-to-many and non-exclusive.

The idea is to help authors identify what each part of their story is actually doing or failing to do. If a paragraph seems not to fit under any narrative tag, or if a narrative tag doesn't apply to any element in the presentation, the author might realize that either the goals of the story need to be revisited, or the presentation isn't quite there. Whether this is actually useful remains to be seen; but I figured I'd propose it.

[ghing]

@patternleaf, so the narrative structure functions somewhat like a checklist, where a storyteller defines their narrative objectives/components and then can easily see if the story they're building is matching up with their "plan"?

[patternleaf]

@jwirfs-brock that's cool and quite comprehensible. I wonder if there's a role for non-linear relationships, or if a linear arc structure of one sort or another is always sufficient?

Hm. Just ran across this paper: Narrative Visualization: Telling Stories with Data. Haven't read it but it looks like it may lay out some ways to think about questions like this.

In this paper, we investigate the design of narrative visualizations and identify techniques for telling stories with data graphics. We take an empirical approach, analyzing visualizations from online journal- ism, blogs, instructional videos, and visualization research. After re- viewing related work, we share five selected case studies which high- light varied design strategies and illustrate our analytic approach. We then formulate a design space constructed from an analysis of 58 ex- amples. Our analysis identifies salient dimensions of visual story- telling, including how graphical techniques and interactivity can en- force various levels of structure and narrative flow. We describe seven genres of narrative visualization: magazine style, annotated chart, par- titioned poster, flow chart, comic strip, slide show, and video. These genres can be combined with interactivity and messaging to produce varying balances of author-driven and reader-driven experiences. Fi- nally, we discuss the implications of our framework, noting recurring design strategies, promising yet under-utilized approaches to integrat- ing visualization with other media, and the potential for improved user interfaces for crafting data stories. By focusing on the graphical and interactive elements of narrative visualization, our approach gives less attention to the cognitive and emotional experience of the reader. We recognize the importance of these elements, however, and describe di- rections for future reader-centric research in our conclusion.

[jwirfs-brock]

@patternleaf That paper was pretty much the inspiration for this entire project. It's definitely worth a full read (and for those of us who've read it before, a re-read for sure). I think once thing we've realized through the first version of the builder is that the "Narrative Visualization" paper looks at presentation structure, and pre-supposed that whoever is presenting the stories has a good understanding of the narrative elements required to tell a good story (or, in a non-fiction story, the factual elements). With our users, that hasn't always proven to be the case. So we need to build the narrative structure into the presentation structure somehow.

On Wed, Apr 10, 2013 at 12:38 PM, Eric Miller notifications@github.comwrote:

@jwirfs-brock https://github.com/jwirfs-brock that's cool and quite comprehensible. I wonder if there's a role for non-linear relationships, or if a linear arc structure of one sort or another is always sufficient?

Hm. Just ran across this paper: Narrative Visualization: Telling Stories with Data http://vis.stanford.edu/files/2010-Narrative-InfoVis.pdf. Haven't read it but it looks like it may lay out some ways to think about questions like this.

In this paper, we investigate the design of narrative visualizations and identify techniques for telling stories with data graphics. We take an empirical approach, analyzing visualizations from online journal- ism, blogs, instructional videos, and visualization research. After re- viewing related work, we share five selected case studies which high- light varied design strategies and illustrate our analytic approach. We then formulate a design space constructed from an analysis of 58 ex- amples. Our analysis identifies salient dimensions of visual story- telling, including how graphical techniques and interactivity can en- force various levels of structure and narrative flow. We describe seven genres of narrative visualization: magazine style, annotated chart, par- titioned poster, flow chart, comic strip, slide show, and video. These genres can be combined with interactivity and messaging to produce varying balances of author-driven and reader-driven experiences. Fi- nall y, we discuss the implications of our framework, noting recurring design strategies, promising yet under-utilized approaches to integrat- ing visualization with other media, and the potential for improved user interfaces for crafting data stories. By focusing on the graphical and interactive elements of narrative visualization, our approach gives less attention to the cognitive and emotional experience of the reader. We recognize the importance of these elements, however, and describe di- rections for future reader-centric research in our conclusion.

— Reply to this email directly or view it on GitHubhttps://github.com/PitonFoundation/atlas/issues/704#issuecomment-16186123 .

[jwirfs-brock]

Ok, here's roughly what I pictured it might look like with the narrative structure incorporated into the drag-and-drop/open-canvas design. This shows the basic narrative structure in the center of the canvas. All of the elements are "greyed out" because the user hasn't filled them in with content yet, so they are just place-holders. The library of building block elements is at the left. (I pictured them being icons and labels -- I didn't make them all, obviously...)

When the user clicks on one of the building blocks, he/she sees a description (with the appropriate question/prompts) and has an option to add an asset of any type to answer the prompt.

Once he/she has added an asset to an element of the narrative structure, the building block is now "filled in" and represented with a thumbnail of the asset.

[patternleaf]

That paper was pretty much the inspiration for this entire project.

@jwirfs-brock Oh. Well then. :)

This all makes me think, by the way, of an architecture studio I took. I designed a kind of force-directed graph to try to map all the stuff we were working with: ginormous pdf.

The structure was hierarchical but leaf nodes were connected in individual arcs so you could follow a single thread from a sub-category of Concerns through to a specific Intervention we proposed.

Each of our interventions had a set of paths justifying it and we highlighted them graphically. For example:

To support The Good Life for the Collective Intersubjective (The We), we work against Inequity using the Urban-X model to enhance Neighborhood Connections by Burying I-25.

The big graph was pretty overwhelming, but individual arcs in the graph were fairly legible. Not sure if this will be of use here. Just spit-balling ...

[jwirfs-brock]

@patternleaf Yes, I do see this supporting both linear and non-linear structures. You could have a branching narrative structure, for example, that is best viewed on an image map. Or, you could flatten the narrative structure and view it linearly.

For the purposes of testing this concept, I'm thinking you could add as many building blocks as you want, but they would have to serve SOME purpose. That is, if you want to add something to your story, you need to know the narrative purpose it serves. This is a bit rigid, but I think it would be useful and help us answer some key questions: Is this something that people can actually do? Does this help them tell stories, or does it make it harder? Do they find it fun and useful, or annoying and naggy?

[jwirfs-brock]

@patternleaf Whoa, that's really cool!

[ghing]

Here's some sketches I did today, really they're an iteration on @patternleaf's sketches. Mostly it's variations of the chrome for different elements.

I think the real interesting work is in the story conceptualization interface, but I still need to give that some thought.

[bpawlak]

Jordan, your image that discusses the responsive grid is kind of the direction I was thinking about going with my ideas for a builder. Basically, we give people a canvas (screen, page, whatever we call it) and on that page the user can place any number of assets (images, audio, video, map, title, etc.) they want, but each asset scales appropriately and automatically, based on the sizing of everything else on the canvas. So, like DropTask, but the canvas itself is more constrained to be just one screen (instead of infinitely zooming in and out).

That way, if a user tries to put 5-6 images and text and a video and a table all on one page, they can clearly see that everything gets so squooshed (technical term) down in size that it's not readable. So it's kind of self-regulating as to how much stuff people try to fit on a page and how they size things. They can change font sizes and such, but at some point they'd run out of room.

However, it would allow for users to create layouts like this (or just about anything else they wanted):

That would give them enough creative room to make stories that were unique if that's an author's goal, or they could - through the use of smart guides - make a more standard layout for reporting on something like a grant proposal.

The one main difference I was thinking is that we wouldn't have to switch between "build" and "view" modes... what you place on the canvas is what you would see in a "view" mode.

[bpawlak]

Another thought I had was that instead of just letting users add "slides" to the left and right of any given canvas, they could also add slides above and below. If a user wanted to tell a straight linear story, they could by just simply starting with a slide and add another one next to it (or below it) and then - as you add more slides, keep going in the same direction.

However, if a user was building a linear (side-by-side) story, and wanted to provide supplemental information, they could add a slide(s) above and below any slide that would allow them to provide that extra info. Of course, we'd need a mechanism to allow a viewer to get back to the main story line (something along the lines of http://lab.hakim.se/reveal-js)

[bpawlak]

Then the final main thought I had was along the lines of separating out the builder tool from the "story constructor" tool. (similar to how we've been talking about moving all of the tagging and copyright and featured image functionality out of the builder and into Floodlight proper)

So if a user just wanted to jump into the builder b/c they had something in mind and are a seasoned storyteller, they can, just like today. But if they wanted to/needed to tap into all of the knowledge you've collected on how to build an effective story, they could access this other functionality - in a focused way (i.e., without all of the distractions of uploading images, etc.) - to help them create the narrative structure of the story.

Then, when it came time to actually populate the assets needed to build the story, they could click on something in the builder to present that story structure as a reference as they populate assets. Or even farther-out thinking: auto-generate a dynamic template set of slides that matches the structure they created.

[jwirfs-brock]

Has anyone ever used or played around with Scrivener (http://www.literatureandlatte.com/scrivener.php)? It's desktop software designed to help writers organize and outline long, complex projects, track their research, and then actually (you guessed it) write. Although we are aiming for quick hit stories instead of novels, longform non-fiction articles, or research papers, I thought some of their descriptions sounded applicable to us:

most writing software is fired up only after much of the hard work is done. Enter Scrivener: a word processor and project management tool that stays with you from that first, unformed idea all the way through to the final draft. Outline and structure your ideas, take notes, view research alongside your writing and compose the constituent pieces of your text in isolation or in context. Scrivener won't tell you how to write—it just makes all the tools you have scattered around your desk available in one application.

Write, structure, revise

Here's their list of features: http://www.literatureandlatte.com/scrivener.php?show=features#section-corkboard Note in particular the "cork board" and the "outliner."

Here are some screen grabs from their website:

Anyway, I haven't actually gotten into it and played around -- I may download the free trial today so I can see how it actually works.

[jwirfs-brock]

@bpawlak Your suggestion for,

separating out the builder tool from the "story constructor" tool

is really interesting.

Going back to the workflow interviews, I observed that...

• Some people conflate the outlining and the composition/writing process. That is, they do them at the same time.
• Some people always start with an outline before they write (or create).
• Some people almost never outline. It's only something they turn to when they get stuck.

There are a couple of things we could do. We could create a version of the Story Builder that supports flexibility between these different modes/workflows. Or we could force people into one mode/workflow.

Either way, I think this is probably something we should test out with users (or even just with ourselves and friends/family) by doing an exercise where we ask people to do the same storytelling task three different ways:

• By starting with an outline
• By writing and outlining together
• By writing without outlining

This gets back to a question I proposed earlier, which is how flexible are individual users when it comes to the creative process? Can they try on the different "hats" of other storytellers, thus adopting someone else's process with success? My hypothesis is that, even if people have a process they think works for them, they will benefit greatly from trying/learning a different process that might push them to think creatively in a different way.

[jwirfs-brock]

As we are having this discussion, two main questions/hypotheses keep bubbling up in my brain:

QUESTION 1: Can people read stories in non-linear formats? HYPOTHESIS 1: People will enjoy reading stories in non-linear formats, and it will keep them more engaged than reading a story in a traditional web-format because it is a more ACTIVE mode of reading.

QUESTION 2: Where and how does the process of OUTLINING (creating a narrative structure) fit in to the storytelling process? HYPOTHESIS 2: When people are asked to create an outline (before or during the storytelling process), their stories will be stronger (as perceived by them and by others), and will inspire more engagement from the reader.

I feel like these are central hypothesis that we need to test in order to redesign the story builder. To help pull apart these threads, I put together a little question/hypothesis/test strategy matrix: https://docs.google.com/spreadsheet/ccc?key=0As2exFJJWyJqdEhiMTE1UjhqRzMyakpyQjNKZUdIZ0E#gid=0

What do you all think? Are these the right questions/hypotheses to be tackling? Can we set up mini-tests of these?

[bpawlak]

Another question is if/how an outline is the best tool to create a non-linear story or if some sort of other mechanism (e.g., mind-mapping) should be used.

[jwirfs-brock]

I just got off the phone with Daniel Weinshenker of the Center for Digital Storytelling (http://www.storycenter.org/). He also has noticed that it's extremely difficult to teach people how to construct narratives. He had an interesting suggestion for our story builder based on the site http://oneword.com/. The idea is to start with a reflective prompt. That is, users would have to spend a minute, or two minutes, writing about a question (or a single word, in the case of oneword.com) before they move on to the rest of the storytelling process. This might deter some people, but the ones who stick with it will be in a better mindset to tell a good story, and the users who will create the type of stories we ultimately want.

[jwirfs-brock]

I put together a chart of some of the common story presentation types (as distinct from narrative structure) to help guide our thinking about the best way to show/display stories on Floodlight: I used a linear/non-linear and discrete/continuous scale, but we could visualize it a different way if it's more useful. The presentation types that I suggest testing to answer our first question (Can people read stories in non-linear formats, and does this make them more inclined to act after reading the story?) are highlighted in red.

Here's some more detail about them...

• Current Floodlight story viewer - pretty self explanatory; a series of slides/sections that progress in a linear order; readers can go back and forth or jump around however they want, but a linear order is still explicit
• Traditional article - this is how text is traditionally portrayed on the web or in print; long, linear strings of text, can be interspersed with other media (magazine style)
• Narrated presentation - This would be someone narrating a series of slides. So, something like the video in this story: http://www.floodlightproject.org/stories/the-importance-of-context-in-data-storytelling/
• Poster - A single canvas with all of the story's content. It could still be partitioned or have different sections.
• Node/force graph - This is like our earlier concept of a "spider" story.

Thoughts?

[jwirfs-brock]

Check out GlobalGiving's storytelling project, which Matt recently shared: http://www.globalgiving.org/stories/

If you click to actually view on a story, you'll see that they are highly templated -- which is nice because this is a project with 50,000+ stories, and it has built in tags for sorting and analyzing the stories. It's a cool way of turning qualitative data into quantitative data.

Here's the "toolkit" they use for collecting stories: http://www.globalgiving.org/img/stories/StorytellingForm.pdf (Similar to the more question/answer-based format we're considering for our Story Builder redesign.)

And here are some screen shots of how stories are presented:

[bpawlak]

It's definitely interesting, but much more emphasis seems to be placed on the tags associated with the story rather than the story itself. I looked at 3-4 different stories, trying to find a "view story" button or something only to realize that the single paragraph at the top is the story...

[jwirfs-brock]

Yes, that's true. The stories are short and concise (just a paragraph of text). The additional "data" is what is filled out on the rest of the worksheet.

On Mon, Apr 22, 2013 at 3:40 PM, bpawlak notifications@github.com wrote:

It's definitely interesting, but much more emphasis seems to be placed on the tags associated with the story rather than the story itself. I looked at 3-4 different stories, trying to find a "view story" button or something only to realize that the single paragraph at the top is the story...

— Reply to this email directly or view it on GitHubhttps://github.com/PitonFoundation/atlas/issues/704#issuecomment-16817216 .

[jwirfs-brock]

Ok, I did some doodling to try to capture a conversation Bill and I had on Tuesday about the story builder redesign. Essentially:

• There would be two major steps to building a story: (A) Planning, and (B) Composing
• (B) is essentially our current story builder
• (A) is a narrative structure/outlining process that then gets mapped into the builder for (B) (somehow...not quite sure how that would work)
• (A) is completely asset and layout agnostic. It just focuses on narrative elements, themes, characters, etc.
• (A) would offer several different narrative types/structures to choose from.

Here's what (A) might look like, without any content from the user plugged in yet:

And here is (A) with content plugged in (adapted from this story on Floodlight: http://floodlightproject.org/en/stories/a-hip-hop-class-paves-the-way-for-students-in-moti/):

Note: I plugged in all 8 steps, but they aren't visible in this view. You can see all the content at this link: https://docs.google.com/drawings/d/1UBoVURwkr9Tc0gbvzM8H2Y1b9VkG7wNRiVxL6um8Xs8/edit?usp=sharing

Once you are done with (A), you would hit "I'm ready to Compose" or something, and then you would launch the builder.

I created a story that has all of the elements from (A), each as a separate section, with the answers to the prompts pre-populated.

Here is the link to it in the builder: http://floodlightproject.org/en/build/0879d00dbbf1438dbaae3f45be2f8545/ And here's a link to the preview: http://floodlightproject.org/stories/0879d00dbbf1438dbaae3f45be2f8545/preview/#

I don't know if you will be able to see it, because I kept it unpublished. If I had been smarter, I would have done this on staging... But you all should have admin access, and so should be able to view it from the builder via the admin interface. Just in case, here's a screen shot that shows the gist of what I did:

Some observations:

• I chose to work with an existing story to see if I could fit it into Dan Harmon's eight-part story circle (http://channel101.wikia.com/wiki/Story_Structure_104:_The_Juicy_Details). It fit pretty nicely, but some of the later steps of the story circle were hard.
• After doing this, the next challenge is, "How do I illustrate each of these parts of the story" -- all of this happens in the builder. But if someone is coming to Floodlight with a pre-edited video (as in this story, which included an embedded video), you can't really break that apart and re-mix it to fit the story arc.

[bpawlak]

A couple of other things we discussed and thoughts I had:

• Need some sort of "how do I choose" table or decision tree for picking the "correct' narrative structure (there may be more than one for any given author's situation). I think this should be more than just an example story, it should be more like "if your story is about..." and "if your story has a main character..." etc. I think if we just present example stories, people will get lost in the stories themselves and not be able to see the forest for the trees, so so speak. Something like a flowchart to help lead the storyteller to the appropriate structure and/or even a pricing table (with checkmarks in various cells, based on criteria) might be helpful.
• We're showing the structures as visual representations, but the actual planning tool (where someone enters text) can be a pretty straightforward ETCN ("enter text, click next") type of wizard/form. At least initially. I'd like to see the emphasis put on getting as many different story structures supported, mapped and tested in the tool first, before we go trying to create a fancy UI for all of it.
• Why were some of the "later steps of the story circle" hard to complete? Is it that the story didn't map perfectly to the 8 steps? That makes sense b/c the original story may not have been created using that structure... Or, is it that the steps themselves are difficult to complete. One thing I thought of is that that particular story structure happens to be really good for telling fictional stories but may not necessarily fit with non-fiction or factual reporting stories. (e.g., if I'm simply writing a story about a community clean-up event in my neighborhood, then a statement like "The character finds what he needs, but at what cost? What is at stake?" doesn't fit at all. We may need to look into also adding more vanilla structures that aren't necessarily "stories" but more like "reports" (e.g., Introduction, summarized main findings, individual results discussion, conclusion, etc.) ... along the lines of our investor presentation discussions. Or Charlie Brooker's "How to Report the News" (http://www.youtube.com/watch?v=YtGSXMuWMR4)
• I think the way you've mapped it to the builder (taking each step and making a section for each) is as good a start as any, but I think we'll need to potentially figure out how to either break down or roll-up steps in the structure into a meaningful # of sections in the builder (e.g., if a structure only has 3-4 steps, they're likely to be pretty dense with a lot of things happening in each step, and that not translate well into only 4 story sections). That'll be a tough issue to tackle, I think.
• I think incorporating things like video, audio, etc. is possible, but we'll have to figure out how to add that to our "decision tree for story structures" as well as provide guidance/info on how to deal with assets/ideas that don't cleanly fit into any particular structure.

[jwirfs-brock]

Thanks for the comments, @bpawlak. I have some thoughts...

We're showing the structures as visual representations, but the actual planning tool (where someone enters text) can be a pretty straightforward ETCN ("enter text, click next") type of wizard/form. At least initially. I'd like to see the emphasis put on getting as many different story structures supported, mapped and tested in the tool first, before we go trying to create a fancy UI for all of it.

I definitely agree. I just made the story structures into visual layouts because that worked better for my brain. Before I did that, though, I wrote them out as lists of questions.

Here are the five story formats I've been working with (let me know if you think of more) as lists of questions: https://docs.google.com/document/d/1jPapFWmOZ3aRoh8AVvKccnDVXpn27JI5w8lPKdZi25g/edit?usp=sharing

We don't need anything fancier than this. The reason I used the more visual layout was to show that these structures are often cyclical. In fact, many stories are comprised of a series of mini-stories strung together (i.e., three story circles that combine to form a larger story).

Why were some of the "later steps of the story circle" hard to complete? Is it that the story didn't map perfectly to the 8 steps? That makes sense b/c the original story may not have been created using that structure... Or, is it that the steps themselves are difficult to complete.

I think it was actually because I didn't know very many details about the story, because I was adapting an existing story that I didn't write/experience. The point of the story circle is that all stories can fit this pattern. You shouldn't have to invent details (in a non-fiction story), but you do have to choose which details (among the infinite details of reality) to emphasize. Putting a story that doesn't seem to naturally fit into this structure is the whole reason to do this exercise -- it makes you think about your story in a different way. You may not have thought there is a "take," but forcing yourself to look for one may help you realize something new about the events that happened.

That said, one of the other story structures I used, "character, want, obstacle," is essentially the story circle but condensed. You still need to set up the beginning in the same way, but after that, the action and resolution doesn't need to be quite as formulaic. I like it better for both fiction and non-fiction writing, but perhaps the outcome isn't as satisfying to the reader.

I think incorporating things like video, audio, etc. is possible, but we'll have to figure out how to add that to our "decision tree for story structures" as well as provide guidance/info on how to deal with assets/ideas that don't cleanly fit into any particular structure.

The way I approached it was that this comes later, in the build step. During the planning/story structure step, I wanted to keep it as asset-agnostic as possible so that an author can focus solely on what happens in the story and how those elements relate to each other, not how he/she will communicate each element. But I agree ... in a lot of cases it's hard to severe those processes, especially if people are coming to Floodlight with assets already in hand.

I think the way you've mapped it to the builder (taking each step and making a section for each) is as good a start as any, but I think we'll need to potentially figure out how to either break down or roll-up steps in the structure into a meaningful # of sections in the builder (e.g., if a structure only has 3-4 steps, they're likely to be pretty dense with a lot of things happening in each step, and that not translate well into only 4 story sections).

I agree that this will be challenging. @ghing @patternleaf Any thoughts on this? It might be ok to initially have a one-to-one relationship between story structure elements and story builder sections, as long as we make it very clear that you can expand and add sections as needed to illustrate each element.

Need some sort of "how do I choose" table or decision tree for picking the "correct' narrative structure (there may be more than one for any given author's situation).

On the list, I added a brief description below each story structure type. It doesn't achieve what you brought up, but it's a start. I'm a little torn on whether we guide people to one specific structure based on what story they are trying to tell, because I like the idea of trying out multiple structures. The structures we have right now are all pretty universal. That is, you should be able to fit any story into any of them. And the act of doing that will uncover new insights about each story. That being said, yes, some structures could work better for certain types of stories. We could add in more targeted story structures. But the goal is to have whatever it is people are creating (a news story, a grant report, a data story) be more story-like by making sure that it has requisite elements like a central character, central theme, and action/motion/change.

[ghing]

A counter proposal.

tl;dr Story planning seems important, but it should facilitate users reasoning about their stories rather than forcing them into a particular process.

@jwirfs-brock's sketches are helpful in thinking about the future of the builder.

I'm on board with a two step, plan/compose process. I'm also fully on board with this comment:

But the goal is to have whatever it is people are creating (a news story, a grant report, a data story) be more story-like by making sure that it has requisite elements like a central character, central theme, and action/motion/change.

However, I worry that the planning stage, as envisioned in the sketches, is too heavyweight, both in terms of what it asks of the users and the complexity and rigidity of the implementation.

I also noticed that there are a number of common elements in the narrative structures, such as characters.

I really liked @patternleaf's suggestion from a while ago of making the planning a tagging exercise. In the planning step, authors would create a set of tags for different story elements, e.g. who/characters, action, question, etc culled from all the narrative structures.

For the example story, tags might look like this. I've given arbitrary category names to the tags.

• Who:Alvaro "Alvie" Cueto
• Who: Elementary school students
• Need:Connect with students through dance
• Action:Alvie teaches classes at elementary school
• Place: College View Elementary
• Action:Alvie and students learn new dance moves
• Outcome: Alvie and students learn from each other and build relationships
• Take: Dance is expression
• Outcome: Dance performance at school
• Outcome: Communities show power of dance

These would be imported into the builder with some kind of color coding and could be dragged and dropped onto sections or assets to visualize what narrative elements the content relates to. The builder could keep a tally of the number of times an element was used and provide a sort of check list so that people could see if they used all the planned elements or if their story uses certain things disproportionately.

If we wanted to incorporate the formal narrative structures, they could be implemented as a tag vocabulary in the planning step.

The important thing here is that the planning doesn't necessarily impose any kind of presentational structure on the user. They could start out with a blank slate but still have their narrative elements to reference. I wonder if we even need to map the narrative structural elements to the content structural elements, or if we could just provide documentation that shows how users could choose to order the narrative elements based on the structure types.

[jwirfs-brock]

@ghing I think the tagging idea is really interesting, but I am having trouble seeing how you would actually use it to construct a story. How would you go from the tagged list you shared above to a story? Would it just be a reminder if you didn't include a particular element? I'd really like to play with this because I've found it extremely helpful to use and play with the story structures.

However, I worry that the planning stage, as envisioned in the sketches, is too heavyweight, both in terms of what it asks of the users and the complexity and rigidity of the implementation.

One thing that I've observed, through the storytelling workshops we've been holding, is that people really like mechanisms that offer them structure and rigidity, especially if the process is new/foreign to them. It gives them a starting point and scaffolding they can fit their story into. The key to making it useful without being overly imposing is to emphasize that it's just a starting point -- the structures aren't actually rigid, but are flexible.

Here's another formula that one of the people I interviewed about the creative process shared:

Before even starting the project, figure out:

• Audience (who, and the context in which they’ll be seeing it -- at a presentation? online? etc.)
• Main message
• Theme
• How the theme is presented

Once you have these, figure out, “who is the best person to tell this story?”

It's a bit less rigid, and more focused on making sure there's a clear message, audience, and central character -- after that, anything goes, as long as they support those initial goals.

[ghing]

How would you go from the tagged list you shared above to a story?

@jwirfs-brock, I think the "tags" that the user comes up with would be available in a manner similar to the one suggested by @patternleaf:

The big difference would be that instead of general terms ("Who", "What", "Effects", "Actions"), the tags would be actual elements perhaps with a counter or a percentage of how many assets/sections the user has assigned the elements:

• Who: Alvie (10)
• Who: School students (3)
• Action: Dance performance at school (0!)
• Theme: power of dance (0!)
• Theme: building relationships (0!)

The users would drag the tags onto sections and assets (and empty containers?) to assign them to a particular piece of content, which would update the counts. Or, maybe the user is prompted to select a narrative element(s) when they add a new asset or section.

One of the biggest challenges I see is how to map the story plan onto the content structure. It seems that we've all struggled with this a bit. Does a one-element to one-section mapping make sense as a general strategy, or does it leave the user with an intimidating number of sections that they then have to deal with? I like the tagging because it doesn't make any assumptions about how the plan will relate to the final presentational structure but still has a clear mapping.

[jwirfs-brock]

One of the biggest challenges I see is how to map the story plan onto the content structure.

I totally agree -- this is the fuzziest part. In fact, going back to the interviews I did, this was also the part that the interviewees found the hardest to describe. This is the process that is different for everyone, and it's the "special sauce" of where you go from a plan to a real draft.

Often, people make the plan, then throw it away and never look at it again. Or, they consult it constantly. It really depends on the person. Which makes we wonder how important it is to do the work of mapping the plan to the story for a user. Maybe a first step could be simply offering a planning stage first, then offering the story builder as-is without explicitly connecting them. If people respond positively to the planning process, then we can figure out how to map it to the builder later.

[patternleaf]

Maybe a first step could be simply offering a planning stage first, then offering the story builder as-is without explicitly connecting them.

I think the tagging feature could be a non-invasive and optional part of this. If we wanted something a little flashier than just tag use count, we could provide an analysis tool that, based on the user's tagging, visually represents how the planning structure is mapped onto the presentation. A very rough sketch, for example:

At this level we're just seeing where the user has tagged any element (asset, text, etc) in a section with some piece of story structure. Here the user could see that Who, Need, Go, and Return are represented in the story, but other structural elements are not. So, maybe a different structure would be better suited for this story?

Or, the user would note that both Go and Return are present in one section. Maybe this isn't a problem, but it might be a signal for the user to check it out and make sure the intent of that section isn't muddied.

This analysis tool could be completely optional for those who want to use it. Of course if it seems that no one would use it, or it's too difficult or opaque in principle, it might not be worth building.

[jwirfs-brock]

I think regardless of how we map the planning process onto the builder, it starts with the user answering some simple questions:

• Who is the central character?
• What does the central character want?
• What is/are the major theme/s of this story?
• etc.

And that pre-planning process of answering questions is what I think we should be experimenting with.

But maybe I am not understanding this correctly...would the tags be pre-set/generic (character, want, theme, etc.), so that the user doesn't need to set them, just use them? And if so, how is that helpful? And where in the composing process would it come in to play? Would a user create a story, then do a "tag check"? Or would they pull tags in, then fill in the details that correspond to that tag? For me, the helpful part of using a structure is linking the generic up with the specifics of my story -- it's where I go from, "my character has to want something," to "My character Ursula the Sea Witch and she wants to rule all the other creatures in the ocean."

Sorry I'm so confused about the tagging thing. It's just that I'm having trouble incorporating it into my own workflow, so I can't really try/test it out. For me to understand how this would work, it would be useful if we could clarify the tagging idea into an activity/process/exercise - independent of Floodlight - that I could try out right now in my own storytelling process, or introduce to a group at a workshop. @ghing or @patternleaf, do you think you could describe it in that context? That way, we can ask users to try it out (or we can try it out ourselves). Writing out a series of questions that corresponds to the elements of a story structure accomplished that for me, because I can practice answering the questions during the storytelling process and then use the answers to inform the story I write. But maybe that process doesn't translate to other people's storytelling workflows. There are lots of other activities/processes out there, and I'd definitely like to try them. How can we turn the tagging idea into a method we can experiment with ourselves, or try out at an upcoming workshop?

[bpawlak]

I don't think I completely understand the tagging concept as it applies to spanning the story planning and building workflow steps, either.

Maybe a first step could be simply offering a planning stage first, then offering the story builder as-is without explicitly connecting them.

From a speed-to-market perspective, doesn't this make the most sense? Offer a planning tool that is primarily intended to just get people to think through the storytelling process and structure in the first place. They can reference it while using the builder if they want, but it wouldn't be required/integrated at all (at least initially). So even if an author only used the planning tool to think through the story and then never referenced it again, it seems that even that would be a huge win - at least based on Jordan's storytelling workshop experiences.

[ghing]

I'm fully on board with this suggestion from @jwirfs-brock and @bpawlak:

Maybe a first step could be simply offering a planning stage first, then offering the story builder as-is without >> explicitly connecting them.

From a speed-to-market perspective, doesn't this make the most sense? Offer a planning tool that is primarily intended to just get people to think through the storytelling process and structure in the first place. They can reference it while using the builder if they want, but it wouldn't be required/integrated at all (at least initially).

I have a few questions about this:

• How would the user access the story planning tool?
• How would the user reference the story while in the builder?
• Would there be a one-to-one relationship between story plans and stories?
• What do we want this activity to feel like? Should it feel like filling out a survey or something more abstract or lightweight?
• How much time should we make the planning activity take?

I'm also all for rolling this out in an experimental way and seeing if users use it and how they respond to it. That said, I'm worried about the overhead of keeping story plans around forever, especially as we change the format of the activity or data stored and change how/if it's integrated with the builder. Any ideas about how we minimize the overhead of keeping the experimental plans around, or how to set user expectations about the fluidity/volatility of the feature?

[ghing]

In an attempt to make my idea for story planning as a tagging excercise clearer, I've made this paper mock-up.

I like planning as tagging because:

• There's a clear integration with content in the story builder process
• It's abstract enough to work with elements from a variety of narrative structures.
• It encourages users to be brief, and fluid.

Users are given empty tags

They are labeled and color-coded to correspond with different narrative elements. I've chosen the ones from the "Character, Want, Obstacle" structure, but they could be from a different structure.

Users create their tags with words or brief phrases

In the builder, users can apply tags to assets or sections

This helps them track which elements of the story plan they're not using, or what elements they forgot to plan for

Users can view their tag list at any time

The number of times a tag has been used is shown, with extra emphasis on unused items.

[jwirfs-brock]

@ghing Thanks, that clarified the process a lot. I am deconstructing/reconstructing a story from the Denver Foundation for a webinar on Friday. I will try to recreate the story with the tagging process as well.

If you want to try it yourself, here's the original story: https://docs.google.com/a/piton.org/document/d/1oR7pgtJ8yq2oJ9UcR-YgeQtvuT_iq8oAGFkHxu_LU_k/edit

I'll share what I have one I've incorporated the tagging process.

So far, I've tried adapting it with the story circle, which worked pretty well:

Planning process - https://docs.google.com/document/d/1vzrin4OoZPyJFB1k_LDhcUOpjAX3WoQldHAsoZ_-e6Y/edit?usp=sharing Annotated text - https://docs.google.com/document/d/17mnOl2GfwhgdOB14t4T1gNRo3T2ZfwmO6xs5jqKWJso/edit?usp=sharing

[patternleaf]

@ghing LOVE the tagging illustration. thanks for that. :)