A Builder Redesign Sketch 1 #704
Comments
|
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. |
|
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... My next steps to develop this idea are to...
I'd love any feedback as I'm doing this... |
|
@patternleaf, in your proposed meta narrative editor, do the "Who", "What", "Actions" and "Effects" blocks correspond to "Pages", or are they something else? |
|
Ok, here's my very rough, probably incomprehensible, sketch. More detailed picture coming shortly... |
|
@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. |
|
@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"? |
|
@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.
|
|
@patternleaf That paper was pretty much the inspiration for this entire On Wed, Apr 10, 2013 at 12:38 PM, Eric Miller [email protected]:
|
|
Ok, here's roughly what I pictured it might look like with the narrative structure incorporated into the drag-and-drop/open-canvas design. 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. |
@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:
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 ... |
|
@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? |
|
@patternleaf Whoa, that's really cool! |
|
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. |
|
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. |
|
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) |
|
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. |
|
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:
Here's their list of features: http://www.literatureandlatte.com/scrivener.php?show=features#section-corkboard 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. |
|
@bpawlak Your suggestion for,
is really interesting. Going back to the workflow interviews, I observed that...
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:
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. |
|
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? QUESTION 2: Where and how does the process of OUTLINING (creating a narrative structure) fit in to the storytelling process? 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: What do you all think? Are these the right questions/hypotheses to be tackling? Can we set up mini-tests of these? |
|
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. |
|
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. |
|
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: Here's some more detail about them...
Thoughts? |
|
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 And here are some screen shots of how stories are presented: |
|
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... |
|
Yes, that's true. The stories are short and concise (just a paragraph of On Mon, Apr 22, 2013 at 3:40 PM, bpawlak [email protected] wrote:
|
|
Ok, I did some doodling to try to capture a conversation Bill and I had on Tuesday about the story builder redesign. Essentially:
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/ 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:
|
|
A couple of other things we discussed and thoughts I had:
|
|
Thanks for the comments, @bpawlak. I have some thoughts...
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: 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).
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.
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 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.
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. |
|
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:
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.
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. |
|
@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.
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:
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. |
@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:
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. |
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. |
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. |
|
I think regardless of how we map the planning process onto the builder, it starts with the user answering some simple questions:
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? |
|
I don't think I completely understand the tagging concept as it applies to spanning the story planning and building workflow steps, either.
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. |
|
I'm fully on board with this suggestion from @jwirfs-brock and @bpawlak:
I have a few questions about this:
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? |
|
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:
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. |
|
@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 |
|
@ghing LOVE the tagging illustration. thanks for that. :) |
mgrayinnovation
modified the milestones:
Iteration P7: Ideation,
Ideation (discussion of future development ideas)
mgrayinnovation
modified the milestones:
Iteration P7: Ideation,
Iteration P3: Story Builder Ideation
A sketch of possible builder re-implementation to provoke thought/conversation. Main features:
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.
The text was updated successfully, but these errors were encountered: