Composer redesign: Notifications about mapstory

[glynnis]

Notes from a meeting with the team on 5/30:

Validation or required fields for story save and/or publication

• Should a user be able to publish a story that has no chapters?
  • At least one chapter must be present
• Are required fields or validation for saving a story different than required fields/validation for publishing?
  • title, summary, category, etc. would be good to have before publishing. We want to make sure the user has an opportunity to promote the discoverability of their story. i.e. may not be required, but we want to prompt them.
  • required: don't let them publish if there's still "Untitled MapStory"
• Can a user publish a story that has no layers?
  • a story must have a layer of StoryPins or a StoryLayer in order for the timeline to initialize. There must be at least two pins or two features on a layer in order for timeline initialize. (current state)
  • desired state for new composer: layer of StoryPins or at least one StoryLayer must be present in order to publish, even if there's no timeline
  • datasets with no time should be accommodated
• Should we allow a user to hit ‘publish’ while a save is occurring?
  • No
• Should a user be able to click ‘save’ while publication is happening?
  • No
• Notification design: needs to include prompting the user
  • Example: "hey you might want to add these" for suggested fields (like tags, category etc.), even if they're not required

[glynnis]

The following situations happen outside of Composer, so I'm not including them in this story. I believe most are already addressed by current UX/UI, or are addressed in my work on #726.

• loading for deleting a story
• loading for discarding staged changes
• loading for unpublishing
• error deleting a story/draft
• success deleting a story/draft
• error discarding staged changes
• success discarding staged changes
• error unpublishing something
• success unpublishing something

[glynnis]

"Are you sure?" confirmation designs

The following pattern can be used for any time confirmation is needed from a user before continuing. For example, if a user might be unaware of a consequence of their action, or we want to be sure they intend to do something that cannot be undone, this pattern should be used.

Deleting a chapter (changes cannot be undone)

Trying to exit Composer before save is complete

[glynnis]

Success saving, loading for saving, and loading for publishing are covered by the disabled button states in #275 (C2).

[glynnis]

Error treatment

The following shows how errors should be displayed to a user. In all cases, errors should be human readable and understandable, and if at all possible, advise the user on the next actions they can take to remedy the situation.

Error banners, unlike the "active item" banner (in green below) should be dismissable with an X. When they appear, they should appear at the top of the stack of banners, and the "active item" banner should always be on bottom. All banners should push down the legend, rather than covering it up.

If the error has to do with saving or autosave, note that the autosave text next to buttons should also say something about the error state. The banner will draw the user's attention to the error, but the autosave text should never contradict the error state (i.e. "All changes saved." displaying when there is an error banner about saving also visible should never happen). For more on writing good error messages, see https://medium.com/@thomasfuchs/how-to-write-an-error-message-883718173322 and https://uxplanet.org/design-principle-error-forgiveness-1495f7471113.

[glynnis]

Success treatment

The following mock-up shows how success messages should be displayed to a user. In all cases, success should be human readable and use clear and specific language. For example, "Your MapStory was successfully saved," is much more effective and clear than a message like, "Success saving."

Success banners, unlike the "active item" banner should be dismissable with an X. When they appear, they should appear at the top of the stack of banners, and the "active item" banner should always be on bottom. All banners should push down the legend, rather than covering it up.

Unlike error banners, success banners should appear,and can show a fade animation after 20 seconds or so. Though they are still manually dismissable with the X, fading and removing them after there has been sufficient time for a user to see and read the message keeps the UI clean. For example if a user presses the manual "Save" button repeatedly during an hour-long session, they don't see duplicates of the same success message simply because they didn't manually dismiss them. Error messages, however, should require manual dismissal since there may be some action the user needs to take as a result.

The success banner for saving (as shown in the mockup) should only appear if the user manually clicks the save button. Otherwise, autosave happens quietly in the background.

[glynnis]

Loading treatment

The following mock-up shows how loading messages should be displayed to a user. When possible, the loading message should update or change to reflect what is happening. For example, when a user opens Composer they may see "Loading basemap tiles...", which changes to "Loading StoryLayers...", etc. If such distinction is not possible to display accurately to the user, a simple "Loading..." message will suffice.

Ideally, as the loading of map features or tiles is taking place, the user can still access and manipulate data in the sidebar. The overlay over the map area is black with 20% opacity, and the spinner above the loading message can be animated using Font Awesome's spinner options (see "Animated Icons" here: http://fontawesome.io/examples/).