Clean up steps in Story Builder (was: Publish is too far along in the story building process/story builder has too many steps)

[jwirfs-brock]

We discussed skipping some of the intermediate steps (add data, tag), and simplifying the story building process so that it looks something like:

1. Build --> 2. Publish --> 3. Enhance/Amplify/Add Metadata (we didn't settle on a name for this, but this is where you add tags, add data, etc.)

[jwirfs-brock]

We also discussed a workflow that looks like:

1. Build ---> 2. Story Information (package/wrap w/ title, byline, featured image) ---> 3. Publish

This also addresses issue #578.

[jwirfs-brock]

We should probably rename this issue to something like "Clean up steps in Story Builder."

[jwirfs-brock]

Agree that we should revisit this discussion. We covered most of our bases when we talked about it before. Essentially, we had decided to move the tagging step AFTER publish, and instead have BUILD --> PUBLISH --> ENHANCE (formerly tagging), right? The "ADD DATA" step is gone now. We still need to discuss whether we want to keep "REVIEW" or remove it. I recommend removing it, since we have a preview button (and right now it doesn't really have any additional features -- just some reminder questions that would be more helpful if we were to integrate them into the builder in a more obvious way).

[jwirfs-brock]

A summary of the various workflow update options are here: https://docs.google.com/spreadsheet/ccc?key=0As2exFJJWyJqdG42OVM3aUhFTTJ5RzFRbDV5NDUwbVE&usp=sharing

[jwirfs-brock]

The preferred workflow is number 6 from the document above.

But both @ghing and I agree that we need to present the title earlier, but don't like having the title in its own view.

The preferred way to do this would be to have a ubiquitous title (as we do in the story viewer), but there isn't room in the story builder UI to do that.

We still need to figure out where/how users will edit the title.

[jwirfs-brock]

One potential solution to the title would be to put it where "Floodlight Story Builder" is in the current builder.

[jwirfs-brock]

The preferred solution is to have the title and byline in the same spot (at the top of the Story Builder). But the height of the bar may not be large enough.

[jwirfs-brock]

We will remove the "Review" step from the workflow, and document the items that we might potentially want to include in an auto-check as a future feature.

[ghing]

so, to summarize what we'll do:

• we'll go with workflow 6 (as it is in the google doc)
• which means removing the "Review" step
• We'll put the title and byline (if it fits) at the top bar
• We'll move the Tag step to the end (after Publish/Share)

BUILD	STORY INFO	PUBLISH/SHARE	TAG
Story content	Summary	CC license	Topics/Keywords
Title *	Featured Image	Publish/unpublish	Projects/Organizations
Call to Action	Byline *		Locations

[jwirfs-brock]

@ghing Should we change the text for editing the title and byline from “This is my title” and “By Jordan Wirfs-Brock” to “Click to edit title” and “Click to edit byline”?

[ghing]

@jwirfs-brock Where are you seeing "This is my title"? I'm seeing it default to "Untitled Story" and "Unknown Author" when the user hasn't entered anything. I'd say this is something we should test on friends and family.

[jwirfs-brock]

D'oh. I edited them and forgot that I did that...

[jwirfs-brock]

Well, I still suggest, "Click to edit title" and "Click to edit byline" -- something that tells the user they need to click there.

Looking at the title again, it seems less obvious than it did before that you can just click to change the title and byline.

[jwirfs-brock]

@ghing Another solution to make it more apparent that the title and byline are editable would be to have the text change in some way on a hover. For example, in Google Drive, the title of a document has a subtle grey highlight when you mouse over it.

[ghing]

Let's test whether users can figure out how to edit the title and byline of the story. Can you take a stab at writing a usability testing task for editing the title and byline? Then we can ask friends/family and adapt the interactions accordingly. I think we can take a similar approach with making sure people fill out the featured image and summary as well, and deciding what, if any microcopy is needed.

[jwirfs-brock]

@ghing That makes sense. I'm really eager to get some user feedback.

Do these usability tasks make sense?

Usability tasks

1. Show readers a sample story and ask them to recreate it.
2. Ask readers to create a new story with very little guidance (i.e., with only a photo as a starting point).

They seem similar, but there's an important distinction between these two tasks.

The goal of task (1) is to find out if users have any trouble editing/reproducing the elements we think a story should have (title, byline, summary, featured image, simple body) when they have been prompted to include them.

With task (2), users won't be explicitly prompted to include a title, byline, summary and featured image in their story. The goal is to see if the story builder UI encourages users to include those elements without additional prompting.

[ghing]

I think these tasks actually have too much going on to get feedback for the questions that we have. I think the task is something more like just setting a title and byline for the story.

However, I think you're on to something with the goal of your second task, "see if the story builder UI encourages users to include those elements without additional prompting". I wonder, however, if there are actually two questions we're trying to figure out:

1. What are the important parts of a story?
2. How do you edit those parts?

Perhaps we could just have a task where we instruct the user to click on the "Sandbox" template with minimal instruction ("This is an app for creating stories ...") and browse around the builder for 5 minutes. Then we could just ask them to list the "important parts of a story". I'm not sure if this will actually be a better way to do it, but my intuition is that we want to get separate feedback on the user understanding what to edit vs. the user understanding how to edit.

[ghing]

@jwirfs-brock, should the user be able to jump ahead to the "Story Info" section when they first select a template, or should they have to at least make some kind of edit that saves the story?

[jwirfs-brock]

@ghing I think they should be able to jump to the "Story Info" section at any time, without first editing the story body.

On Tue, Nov 19, 2013 at 5:17 PM, Geoffrey Hing notifications@github.comwrote:

@jwirfs-brock https://github.com/jwirfs-brock, should the user be able to jump ahead to the "Story Info" section when they first select a template, or should they have to at least make some kind of edit that saves the story?

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

[jwirfs-brock]

The goal of these tasks is to understand the user’s ability to edit the important non-body elements of a story. They do not test whether the user can identify what those elements are in the first place.

Story elements we are testing:

1. Title
2. Byline
3. Summary
4. Featured image

These tasks should be done while sitting with the user or while having a screen-sharing session with the user so you can observe his or her actions.

Task A: Ask user to create key elements in a new story. Setup:

• Ask the user to login to his/her Floodlight account (or use yours).
• Ask the user to launch the Story Builder and create a new Sandbox story.
• For editing the featured image, you should have a file on your computer or a URL at the ready.

For each subtask, observe whether the user can find the element, whether the user can modify the element, and whether the user can save changes.

1. Create a new title for your story
2. Add a byline to your story
3. Add a summary to your story
4. Add a featured image to your story

Task B: Ask the user to edit key elements of an existing story. Setup:

• I created a test story for this task: http://dev.floodlightproject.org/en/build/f573d4a8ead44101a3ae7e6ee5f4ed20/
• You can either let the user access the story via your admin account, or assign the story to the user’s account
• Ask the user to launch the story in the builder (you can walk them through this part, because this isn’t what we are explicitly testing today)
• For editing the featured image, you should have a file on your computer or a URL at the ready.

For each sub-task, observe whether the user can find the element, whether the user can modify the element, and whether the user can save changes. You could also do this by asking the user to (a) locate/identify each element, then (b) edit that element.

1. Change the story’s title
2. Change the story’s byline
3. Change the story’s summary
4. Change the story’s featured image

Sample post-task questions: How easy was it for you to find the title? How easy was it for you to change the title? Do you have any suggestions for how you would like to edit the title? Do you have any other thoughts on the title?

How easy was it for you to find the byline? How easy was it for you to change the byline? Do you have any suggestions for how you would like to edit the byline? Do you have any other thoughts on the byline?

How easy was it for you to find the summary? How easy was it for you to change the summary? Do you have any suggestions for how you would like to edit the summary? Do you have any other thoughts on the summary?

How easy was it for you to find the featured image? How easy was it for you to change the featured image? Do you have any suggestions for how you would like to edit the featured image? Do you have any other thoughts on the featured image?

@ghing What do think about the structure of these user tasks? I'm open to suggestions for how we might modify them.

[ghing]

@jwirfs-brock, these look pretty good. I'm up in the air about whether the sub-tasks should be first-level tasks themselves, just to make it easier for the tests to be more atomic/faster for testing with people with limited time. Maybe we should go with what you have and see how it goes and adapt as needed. We're trying to get insight, not scientific data, so I think its ok to change things up mid-process.

A lot of articles I've read on usability testing suggest using synonyms for UI elements. I think this pretty difficult to do with "Title" but we might want to try it for things like "featured image".

We should take a first pass at microcopy for the "Story Info" section. I'll make an issue for this and assign it to you.

Can you write a short intro script explaining the context for the task. Rough idea: "You are testing a web-based storytelling tool. Stories can be simple or complex, but all stories should have an attention grabbing title, a summary of the story, an image used when listing stories and authorship information". That language is terrible, but hopefully it conveys what I'm getting at.

Also, re:

They do not test whether the user can identify what those elements are in the first place.

I wonder if we should have a task to test this as well.

[jwirfs-brock]

@ghing I think splitting up the sub-tasks into individual tasks should be fine.

As for synonyms, is the intention here that they are simply non-jargony, or that they are markedly different from the terminology that we use on the site in microcopy (to test whether users are identifying with the underlying concept behind the term)?

Here's a brief intro script:

You are going to be doing some exercises using a digital storytelling tool.

Stories can be short and simple or long and complex, and can include a variety of multimedia elements such as text, pictures, audio, video and data visualization.

All stories should have some basic elements: a compelling title, a short summary that pulls readers in, an image that accompanies the story wherever it appears on the site and elsewhere, and author information.

I will ask you some tasks that have to do with identifying and editing these basic story elements.

[jwirfs-brock]

@ghing Oh, and I think it makes sense to test whether users can identify key storytelling elements in a separate test. It's still really important, but for the sake of simplifying these tests so we can finalize the fixes to the workflow, I think we should keep them distinct.

[ghing]

@jwirfs-brock, re: avoiding synonyms in text:

As for synonyms, is the intention here that they are simply non-jargony, or that they are markedly different from the terminology that we use on the site in microcopy (to test whether users are identifying with the underlying concept behind the term)?

The language should definitely be non-jargony, but the intention of avoiding synonyms is the second factor that you described, making sure users are understanding the app and finding the UI elements that let them achieve the tasks in an intuitive way rather than just searching for a particular string.

[ghing]

@jwirfs-brock, taking another look at the test tasks and the builder UI, the only thing that feels like we should use different language is "Featured image", since that text appears in the UI and it seems easy enough to describe that in different language. We shouldn't worry about phrases like Title or Summary, because I can't think of alternate language for those things that isn't artificially obscure.

[jwirfs-brock]

@ghing Here are the notes from my first user test: https://docs.google.com/document/d/1SBOml6LgbEF96FdQq1q0XvL2Gb1bI-KKh-1-f2vu1Gc/edit?usp=sharing

[ghing]

@jwirfs-brock, those test results are really informative. I've opened another issue, #900 to capture some of the info about confusion around autosave. Please update the issue if you have anything to add.

It seems like there was some confusion around the term "byline". Am I interpretting that right? Perhaps this is too jargony and we should change it to something like "fill in your name as the author of the story".

[jwirfs-brock]

It seems like there was some confusion around the term "byline". Am I interpretting that right? Perhaps this is too jargony and we should change it to something like "fill in your name as the author of the story".

Yeah, "byline" was definitely too jargony. In the test, I said "change the author information" which was an easy enough to follow direction. My mom said she never would have thought of that as a "byline."

[jwirfs-brock]

@ghing And here's another user test, this time with my dad. I asked him to create and edit a story from scratch. Again, lots of valuable insight!

https://docs.google.com/document/d/19ZwGt5MEmnFTbQwT9ZX3G5R_YFWDtaNyWya1luHMVn0/edit?usp=sharing

[jwirfs-brock]

@ghing While going through the test script, I noticed that in Firefox, the "Publish" button was not working initially (nothing happened when I clicked it). After a refresh, the button worked properly.

Up until I tried to publish, I had been following the test script pretty much line for line.

[ghing]

@jwirfs-brock I consolidated your usability test notes into a single doc (https://docs.google.com/document/d/1urNXtsbEw49yLFmWdlwHifvRWCuwmbJYGhuYhJ0opFA/edit#) as I'm going to be doing a couple of tests today and I think it will get unwieldy to have a doc for each tester.

[ghing]

@jwirfs-brock I did 3 usability tests today and recorded the observations in the consolidated google doc at https://docs.google.com/document/d/1urNXtsbEw49yLFmWdlwHifvRWCuwmbJYGhuYhJ0opFA/edit

All the testers mistook the section title for the story title and didn't immediately grasp that the story was comprised of sections. I want to tweak the title editing widget before we do any more tests as I think its safe to say that this is a part of the interaction that is problematic. None of my testers had any problem interacting with the title/byline widgets, but did have trouble finding the story title initially.

[jwirfs-brock]

@ghing Yup, that's five out of five testers who mistook the section title for the story title. Do you think adjusting the styling will fix it, or are you thinking we'll need to change placement?

One thought that came up in my tests was moving the title next to the content, instead of having the workflow menu squished in between. On Nov 27, 2013 3:17 PM, "Geoffrey Hing" notifications@github.com wrote:

@jwirfs-brock https://github.com/jwirfs-brock I did 3 usability tests today and recorded the observations in the consolidated google doc at https://docs.google.com/document/d/1urNXtsbEw49yLFmWdlwHifvRWCuwmbJYGhuYhJ0opFA/edit

All the testers mistook the section title for the story title and didn't immediately grasp that the story was comprised of sections. I want to tweak the title editing widget before we do any more tests as I think its safe to say that this is a part of the interaction that is problematic. None of my testers had any problem interacting with the title/byline widgets, but did have trouble finding the story title initially.

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

[ghing]

@jwirfs-brock I want to try starting out with the title field being an input and popping a little tooltip. My test subjects said the title made sense there, but it was just hard to find initially and confusing because they didn't come into using the app understanding that a story was divided into sections (the tour would help with this somewhat). I feel like having a "Section title" label or adding the "Section Title:" to the placeholder of the section title input might also be helpful. If doing that doesn't test better, then we can talk about moving the element.

While other users mentioned having the title be with the rest of the content, I don't think this is a good solution because the content editing already gets pushed down so much.

[jwirfs-brock]

@ghing During testing, I noticed some strange behavior in Chrome while reordering sections. When I clicked on a section and dragged it to a new position, the section I was dragging disappeared. It reappeared (in the correct, new spot) once I let go of the section.

Here's a screen shot:

[jwirfs-brock]

@ghing In response to the title behavior, I have a few suggestions:

1. We should definitely add the title to the tour. (But I doubt that will solve the entire problem).
2. We should also doing something to highlight the story title...a big "start here by editing your title!" flag or something. I'm not sure how to make it helpful yet not annoying.
3. Another thought I had was to toggle off the section title, or make the section title optional.

What if the basic story builder screen looked something like this?

• The text, "Click to add section title," could appear all the time, or only when a user mouses over the "+"
• If the user never clicks on the "+" then the section has no title
• If the user does click on the "+" then he/she can edit the section title the same way he/she can edit the story title or the byline

Here's what it might look like in a template that has a predefined section title:

• The user can still click on the section title to change it (we can use a tool tip the way we do with the title to show this, or we can instead display something like: "Personal Success (click to edit)"

Thoughts?

[jwirfs-brock]

@ghing When I tested the entire workflow in Chrome, almost everything worked smoothly. However, I did notice some strangeness with the asset drawer when I went back to edit the story after publishing.

After I deleted a section, then added a new section, I observed that the asset drawer appeared at the bottom of the window: It stayed there after I dragged the assets into the story: Also, I was able to scroll way up above the story, revealing a lot of white space (that has no reason for being there):

None of this prevented anything from working properly.

[ghing]

@jwirfs-brock, re: ]your ideas for disambiguating the story title and section title](https://github.com/PitonFoundation/atlas/issues/579#issuecomment-29630424). I made the following changes at the end of last week to address these issues:

• For new stories, show the story title input (rather than the default title, "Untitled Story") to make it more apparent that text can be input there
• Highlight the open text input with a fancy tooltip

I'd like to usability test the builder with these changes using the same tasks as last week (but with different subjects) and see if they run into the same problem.

If it's still confusing, I want to add a "Section Title" label to the title input.

If that doesn't work, we can try to address the presentation of the section title. I recall that the section title used to have a "click to edit" behavior similar to what you described but we changed it for some reason. I'm open to trying something like this, but let's see if the more subtle change addresses the issue first.

[jwirfs-brock]

@ghing Here's the new usability test for observing the entire story building process and testing the validation: https://docs.google.com/document/d/11URv4KeWoev0L5nUJQ4HrLonfo3G8UkROQidqjUBz14/edit

Feel free to edit it. This was just a first stab at it. If you have suggestions for how we might structure the test differently, I am open to those, too.

My idea was to ask users to create a PhotoVoice story and provide some sample images they could use to do so. I haven't yet gathered the sample images, but I was planning on putting them in a Google doc along with the URLs so users could just copy/paste those into the Story Builder.

Thoughts?

[jwirfs-brock]

@ghing I just had another idea for how to do this. We could seed the same images as removed assets, so they would be in the asset drawer. That would mean the user would have to open an existing story instead of creating on from scratch, but since we are not trying to test that part of the process, I think it would be ok. They would be harder to preview (smaller, because just the thumbnails would be visible), but it would avoid the problem of having to flip back and forth between two tabs. Thoughts?

[jwirfs-brock]

And here are the test images: https://docs.google.com/document/d/1MQwpBLTVMxYZi585IYMJoZi7a_33R8WJG4gwrCk2wO0/edit

[ghing]

@jwirfs-brock, I'll take a look at these and comment this afternoon.

I also had a thought when doing one of my usability tests yesterday, which was to see how viewing a story on Floodlight before going through the building process would affect the way the users interacted with the builder. I don't know how to turn that into anything actionable, but it strikes me that some of the things that are confusing about the builder might become less so when you have a sense of the structure of a story. I'm just putting this here to capture the idea for later.

[jwirfs-brock]

@ghing I was actually thinking the same thing about starting by showing users a Floodlight story before they build. I almost wrote that into the test, but figured we should start by keeping it simple. I'd be open to trying that here, although we could hold off on it and then do some A/B testing with that being the key variable later.

[ghing]

@jwirfs-brock The tasks and documentation of the test seem right on. I made some comments. Feel free to resolve them or reply in the document. Regarding setting the story up with pre-seeding assets in the story, I think this is fine to try, but might be a moot point depending on what you think of my idea of users creating a simple photovoice story from one of their own photos.

[jwirfs-brock]

Based on a comment in one of the usability tests that the grey text on the workflow steps in the builder made them seem unclickable, I suggest that we make the following change:

• all workflow steps are white text on a black background
• active workflow text is either orange text on a black background (matches the rest of the site navigation), or white text on an orange background

[ghing]

I did a quick and dirty pass at:

• Removing the logo bar
• Moving the story title below the workflow step bar
• Moving the "tools" menu into a collapsible menu

It looks like this:

Template selection:

Build step:

Story info step:

I just want to get a sanity check that this is the right direction before I go any further.

[jwirfs-brock]

@ghing These screen shots look good. I like the direction this is going.

[ghing]

@jwirfs-brock, I updated the workflow step link colors as you requested at https://github.com/pitonfoundation/atlas/issues/579#issuecomment-30435243 with the additional semantics of making disabled steps dark gray. (For instance, you can't access the "Publish" step if you haven't first saved your story).

Note that I couldn't make the icons orange when they're selected because they're part of a sprite image and I don't have the original design file. If you know where this might be, I can update the sprite so it has icons in an orange state as well.

[ghing]

@jwirfs-brock, I updated the dev server with the builder with the moved title element. You'll likely have to do a hard refresh to see the changes.

[jwirfs-brock]

@ghing I like it a lot. It feels a lot cleaner and more intuitive.

Should we do some user tests with this new layout? Let me know when you think it's ready.