Page MenuHomePhabricator

As a user I expect to be alerted to relevant information in an obvious and non-UI blocking way
Closed, ResolvedPublic5 Story Points

Description

Spec

Global Error Banner View

Given I just did something that triggered a global error banner
When it is displayed
Then it should slide down from the top of the screen
And it should contain localized text describing details of the error (e.g. Internet connection appears to be offline).
And it should be presented on top of everything in the app
And it should have styling appropriate for its severity

Language Picker View

Given an article has languages

When I go to view the languages for that article
Then I should see a "loading" banner

And I see a loading banner
When the languages are downloaded successfully
Then I should see them in the picker

And I see a loading banner
When the languages fail to download
Then I should see an error banner

Editing View

TODO: spec out banner behaviors on editing view. e.g. preview fetching "progress", etc.

Account Creation View

All account creation states are communicated using banners for the time being.

Scenario: Account Creation Data Entry

Background: Given I am on the account creation view

When I attempt to create an account
Then I should see a notification that tells me the account is being created
And I should not be able to dismiss the banner manually
And the "create account" button should be disabled

Scenario: Account Creation Response Handling
Background:

Given I am on the account creation view
And I am currently waiting for an account creation response

When account creation fails
Then I should see an error banner
And the "create account" button should be enabled

When the server sends a "captcha required" response
Then I should see a notification describing that I need to fill out the captcha
And I should see the captcha form view
And I should not be able to interact with the account creation text fields or buttons

When account creation succeeds
Then I should see a notification that tells me I am logging in
And I should not be able to dismiss the banner manually

Scenario: Post-Account-Creation Login Response Handling
Background:

Given I am on the account creation view
And I am currently waiting to login

When I login successfully
Then I should see a notification that says I have logged in
And the account creation view should be dismissed

When I fail to login
Then I should see an error banner
And the "create account" button should be enabled

Scenario: Account Creation Captcha
Background:

Given I am on the account creation view
And I see the captcha view

When I tap the "refresh captcha" button
Then I should see a notification telling me the captcha is being refreshed

And I am waiting for a new captcha
When it arrives successfully
Then I should see the new captcha
And the captcha text field should be reset

And I am waiting for a new captcha
When it fails to be refreshed
Then I should see an error banner


Currently we use top and bottom gray bars for notifications. Lets design something better and make it consistent throughout the app.

Make UI for alerting users modern and consistent across the app.

  • Do not block the UI
  • Use legible type
  • Use colors to denote purpose/importance (red bad / yellow meh / green good)

Suggested Pods:
https://github.com/Loadex/MessageBanner
https://github.com/KrauseFx/TSMessages
https://github.com/atljeremy/JFMinimalNotifications

What we have now -

Event Timeline

Fjalapeno created this task.May 1 2015, 3:52 PM
Fjalapeno raised the priority of this task from to Needs Triage.
Fjalapeno updated the task description. (Show Details)
Fjalapeno added a subscriber: Fjalapeno.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 1 2015, 3:52 PM
Fjalapeno renamed this task from Make UI for alerting users modern and consistent to As a user I expect to be alerted to relevant information in an obvious and non-UI blocking way.Jul 5 2015, 9:43 PM
Fjalapeno updated the task description. (Show Details)
Fjalapeno set Security to None.
Fjalapeno updated the task description. (Show Details)Jul 16 2015, 5:00 PM
Nirzar updated the task description. (Show Details)Oct 13 2015, 9:03 PM
Nirzar added a subscriber: Nirzar.Oct 13 2015, 9:06 PM
JMinor triaged this task as Low priority.Oct 13 2015, 9:06 PM
JMinor removed a subscriber: Nirzar.
JMinor raised the priority of this task from Low to Normal.Nov 19 2015, 7:56 PM
JMinor edited projects, added iOS-app-v5-beta; removed iOS-app-v5-production.
Nirzar claimed this task.Nov 21 2015, 12:39 AM
Nirzar added a subscriber: JMinor.Nov 25 2015, 1:15 AM

Here's a spec for the feature after the multiple discussions

  • No actions necessary
  • short and to-the-point messages
  • close button to close the message
  • auto dismiss after certain interval
  • 1 default and 3 flavors.
  • same height as status bar and title bar combined

Values
Flavor: default
auto dismiss interval: 5 secs
slide down animation duration: 0.3s

Create params for

  • flavor [string]
  • duration [float]
  • enable auto dismiss [boolean]

Copy guideline

  • use short sentences.
  • not more than 2 sentences
  • do not use this if you want user acknowledgment on the notification
  • not more than 3 lines of text

Assets + colors
Coming soon............ real soon.

@Fjalapeno @JMinor

  • @Mhurd @Fjalapeno @JMinor @Nirzar to reiterate what we discussed in planning today:

    Offline Alert UX

    We will optimize for the main use case (online, success) by optimistically peeking/pushing the view. In the event of a failure, we need to show the alert banner w/ the error message for offline (taken from Apple's NSError failure reason).

    This means the banner must be shown within the peek. This could be problematic if the banner is a global UI element.

    This really doesn't mean the banner needs to be in the peek.

    Making the banner non-global just to support this edge case makes it much more problematic to implement. For instance, overlapping the top nav bars in other views may not even be possible if we try to embed it within the peek.

    Remember this is a peek into the content being pressed - not a miniaturized version of the full UI - there is no nav bar, there are not navigation buttons, no tab bar.

    My recommendation is just let the empty state of the article view signify to the user that it is not loading (this is exactly the same behavior as Safari.).

    As far as seeing the banner - Remember the peek isn't a static screen, it will only be present for a moment, as soon as the user sees the page isn't loading and lifts their finger, then they will see the normal UI and the banner.

    cc @Mhurd @JMinor @Nirzar BGerstle-WMF

    As far as seeing the banner - Remember the peek isn't a static screen, it will only be present for a moment, as soon as the user sees the page isn't loading and lifts their finger, then they will see the normal UI and the banner.

    The problem w/ a global banner arises if we fail to load the content the user is trying to peek, and the feedback is obscured by the blur effect of the peek itself. I agree that showing the banner inside the view (as we do currently) has a few other trade-offs, and that having a "global" banner mitigates some, but it's unclear what "global" even means:

    • "Take over" the navigation controller's navigation bar?
    • "Take over" the status bar?
    • "Take over" everything (i.e. the app window)?

    The last two options are the only ones I can see getting around the peek issue.

    Except that blocking the window could potentially conflict w/ not blocking the UI (since we have no idea what we'd be occluding).

    but it's unclear what "global" even means:

    Just like the mocks show - and just how most banner libraries work. They show over the top of the UI - they auto dismiss and then if you want to dismiss sooner you can tap them. This is all super standard and very established patterns and I think maybe we are overthinking it here.

    The problem w/ a global banner arises if we fail to load the content the user is trying to peek, and the feedback is obscured by the blur effect of the peek itself.

    Thats why we have the empty content screen. There is no confusion - the user sees the content didn't load and releases to reveal the main UI (which includes the banner).

    I agree with @Fjalapeno on this one.

    The banner should appear on the destination UI, not within the peek. Ideally the peek would be smart about catching failures and show the "empty screen" fallback image, but I don't think thats needed for a first implementation. If the peek is abandoned, then they get no feedback, which isn't great, but is good enough for a first pass. If we feel we must somehow alert a user on a failed peek, then we could potentially show the banner on the source screen after the peek is over.

    ^ ps. this is a global issue with feedback from peeks right? If we really want to address this, we should look into any HIG guidance on communitcating to the user during/after a peek, or look at a few more apps that have implemented peek and see how they handle this.

    Conceptually, I think of the peek state as a mid-navigation state (its just a user cancellable one), and not a place where we should push info to the user. Its like adding a UIAlert in the middle of a slide navigation animation. Its better to disable the navigation option (ie. make peeks not work and notify its because they are offline via the banner mechanism) or let the navigation complete and notify the user why their destination looks different than expected (ie. the empty state screens), rather than try to insert information mid navigation.

    Nirzar added a comment.Dec 3 2015, 4:22 AM

    @JMinor @Fjalapeno @BGerstle-WMF
    No, this banner should not show up inside the peek view of anything. as far as i am concerned about the experience. peek should not work if there is no internet but we blocked that option. so we need to show the blank states for peek view.

    I have posted the blank states for articles, search and feed over at T117925: As a user without internet connection I want a smooth user experience

    we can move this discussion there too.

    Fjalapeno added a subscriber: Nirzar.

    @Nirzar Need assets for this (check marks and other icons)

    @Fjalapeno here's a temporary "icon" for all banners:

    JMinor added a comment.Dec 9 2015, 6:19 PM

    For copy, please use the existing messages from the existing alerts (ie. the scope of this is to change the flow and visual design of the alert system, we will do a separate pass for copy changes if needed).

    Testing Global Error Banner View

    Then it should slide down from the top of the screen

    Passed

    And it should contain localized text describing details of the error (e.g. Internet connection appears to be offline).

    Passed


    Note: a separate bug is filed about kCLErrorDomain error 0 - T121282: [5.0.0.563] When offline, the error message displayed - kCLErrorDomain error 0

    And it should be presented on top of everything in the app

    Passed. See the above screenshot.

    And it should have styling appropriate for its severity

    Needs Design Review
    More screenshots:

    Etonkovidova added a comment.EditedDec 13 2015, 12:16 AM

    Testing Language Picker View

    When the languages fail to download
    Then I should see an error banner

    I was not able to trigger specific error message. When in offline mode, the lang icon in articles is active. Clicking on it displays the banner "The Internet connection appears to be offline".

    Testing Account Creation View - checked with 5.0.0.549 on iPad mini iOS 8.2
    All specs are in place - including auto dismissal intervals.

    Notes:

    And the "create account" button should be disabled

    There is only Next and Done button in the account creation process.

    When in offline - the message about the Internet connection to be offline comes after a user submits the form. Maybe it's better to display it earlier?

    The screenshots:




    @Fjalapeno
    Can you check colors of "Good" notification? Not sure if icon and text match. I made the icon #00C89C.

    The good notification remains on screen for a very short period of time, too fast to read. Is there a spec for that timing?

    @KHammerstein I just updated the colors to that hex (I previously used a color picker to get the value)

    Looks great all, glad we made this happen for beta. I'm sure will need some refinements and edge casing, but really liking the new visuals and interactions!

    JMinor closed this task as Resolved.Dec 18 2015, 6:35 PM