-
Notifications
You must be signed in to change notification settings - Fork 41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Composer redesign: Notifications #277
Comments
Notes from a meeting with the team on 5/30: Validation or required fields for story save and/or publication
|
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.
|
"Are you sure?" confirmation designsThe 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 |
Success saving, loading for saving, and loading for publishing are covered by the disabled button states in #275 (C2). |
Error treatmentThe 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. |
Success treatmentThe 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. |
Loading treatmentThe 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/). |
Redesign notifications. Some scenarios to account for:
The text was updated successfully, but these errors were encountered: