Botframework-webchat: Need offline UI: Connection is taking longer than usual

[corinagum]

Original issue is #135, which has been split into multiple issues.

We need UI specs and implementation for:

• When the bot is offline, due to
  
  
  
  • Never able to connect successfully (or a definite result for not able to connect)
    
    
    
    
    
    • In the first 5 seconds, don't say it's not able to connect
    
    
    
    • UI for bad configuration (wrong secret or access token)
    
    
    
  
  
  • If it last for > 5 seconds , we should show an error
    
    
    
    
    
    • We need to find a good number, is 5 seconds 'longer than usual'?
    
    
    
    • UI for network error
    
    
    
  
  

(This thread is very long -- please see the summary so you don't have to read every comment. :) )

Summary

• Modify "Send failed, retry" text to "Send failed. Retry"
• Message will show above the sendbox (static location), and disappear when status is fixed. Message will not bump up or scroll when new messages are added
• We will use the warning or error icon for both statuses:
  
  
  
  • ! Web Chat is taking longer than usual to connect. Retrying in 30 (will countdown) seconds. (Retry now)(button) - Warning icon
  
  
  • ! Web Chat is unable to connect. Error icon
  
  
• Warning for taking longer than usual will appear after ~15 seconds, but this number is pending adjustment after design sees the implementation
• Full error "unable to connect" will show up when we receive a failing HTTP header OR after inability to connect after 20 seconds. -- this is also pending adjustment for after design team sees implementation

What we need

• [x] Design specs
• [x] Acceptance criteria
  
  
  
  • [x] Text matches below.
  
  
  • [x] Colors of icons and text meet design specs
  
  
  • [x] Messages show up when connection:
    
    
    
    
    
    • is taking longer than 5 seconds,
    
    
    
    • has failed,
    
    
    
    • credentials are incorrect
    
    
    
  
  
  • [x] Messages should always remain above sendbox (does not flow with transcript, disappears when resolved)
  
  
  • [x] Colors are accessible
  
  
  • [x] Narrator handles warnings gracefully (aria-live = polite)
  
  
• [x] T-shirt sizing
• [x] Localization updates

Text:

Web Chat is taking longer than usual to connect. Retrying in 30 seconds. (Retry now)(button)
Web Chat is unable to connect.
> ‘Web Chat is unable to connect; please check your bot's credentials’

[cwhitten]

@mewa1024 can we sit down and discuss this?

[DesignPolice]

@cwhitten @mewa1024 I'm working today if this needs a visual. I have not experienced this error, so not sure what we are looking for, but happy to create something if we need it.

[cwhitten]

Sure @DesignPolice that would be great! We need primarily three indicators:

1. A warning somewhere that WebChat is taking longer than usual to connect to a bot
2. A error saying that WebChat has failed to connect to a bot
3. A error saying the credentials used to connect to the bot are not working

[corinagum]

Updated top comment with design specs and acceptance criteria. Please let me know your feedback. :)

[DesignPolice]

@corinagum - It depends on how often this happens, seems like it might be nice to see it in line, vs disappearing.

[mewa1024]

@corinagum @DesignPolice Hey all, quick question about the behavior: does Web Chat check for a connection periodically or only when the a message is sent? The reason I'm asking, if it's the latter case, then I think the error message should appear in place of the time stamp below the failed message, similar to the iPhone Message app and slack screens here:

If we do this, then the error message should scroll along with the message bubble. We might also want to allow the user to click on the error message to resend, similar to this feature, but not necessary:

If it's the former case, I think we should disable the text input button until the connection is restored. Examples are Skype for Business and slack.com:

In this case, we wouldn't need to scroll the error message since the conversation would be stopped until the connection is established.

[DesignPolice]

Thanks @mewa1024 well with 700 Million iPhones in service that does seem like a solid solution. @cwhitten can call the ball on his preference, if I need to design a screen like that or if we have a default already and it is just plugging in the text?

[corinagum]

[EDIT]
After speaking with @compulim, it looks like Web Chat checks the DLJS connectionStatus$ on the server every second. I think this may mean that it's better to have it as a status, as opposed to a notification on each message, that disappears once it no longer applies. Thoughts?

[mewa1024]

@corinagum @DesignPolice Then I think we should do this:

• show a message above the sendbox when Emulator is unable to connect (but do not disable the send box). This message will disappear when Emulator is able to connect again. It will not scroll.
• show an error "! Failed to send" in place of the timestamp of a chat bubble if the message was submitted when Web Chat was unable to connect. This error will scroll with the chat bubble.

The message above the sendbox should be one of these:

• ! Web Chat is taking longer than usual to connect.
• ! Web Chat is unable to connect.
• ! Web Chat is unable to connect; please check your bot's credentials.
  (Are the circumstances different for the last 2 messages? If not, can we eliminate the second message?)

Does this cover everything?

Do we support clicking on a message that failed to send and allowing the user to retry?

[corinagum]

@mewa1024 This looks good to me. :)

• I'm inclined to agree with you that we don't need the 'please check your bot's credentials' message, but maybe other people have differing opinions.
• I believe this does cover everything, except what you point out:
• I believe @compulim talked to me about resending a failed message as a 'nice to have', though I'm not sure about the difficulty of implementation. @compulim what are your thoughts? Should we file another issue, or add resending as part of the requirements for this issue? (Tagging @cwhitten for his input as well)

[compulim]

@mewa1024 love your UX study on this topic, especially focused on mobile scenario. 👍

Similar to @corinagum. I think for unusual errors (more like dev errors, e.g. wrong credentials), we could surface the actual error message in the F12 log. We can just say, unable to connect.

Few things:

• We can detect connectivity, there will be 10-15 seconds delay about bad connectivity (in best case, it should be detected under a second)
• If it is not able to connect, should Web Chat automatically retry connect?
  
  
  
  • If yes, how often should we retry?
    
    
    
    
    
    • Some systems retry every 30 seconds
    
    
    
    • On top of 30 seconds, some allow you to retry right now if you click a button
    
    
    
  
  
  • If no, how can the user reconnect?
  
  
  • We will also break the connection if there are JavaScript errors
    
    
    
    
    
    • JS errors usually caused by dev writing bad code, can be classified as "unusual errors", surface in F12
    
    
    
  
  
• We already have "send failed, retry" prompt today, is it sufficient?
• For "longer than usual", what is the good number here? 5 seconds or 15 seconds?
• I am clinging not to "resend automatically", because there are lots of implications there, and the user manual resend is not huge effort given the user didn't type too much stuff

[mewa1024]

@corinagum @compulim How about this?

Web Chat tries to connect and cannot, so it shows the message

• "! Web Chat is unable to connect. __Retry now.__"
  or
• "! Web Chat is unable to connect. Retrying in 30 secs. __Retry now.__" where 30 counts down to 0. That might be unnecessarily complicated.

I think "send failed, retry" is fine. Maybe just change the capitalization and punctuation to "Send failed. __Retry__." And yes, I agree in that I don't think we should resend a failed message automatically when the connection is restored.

Regarding what "longer than usual" means, I'm thinking 15 seconds is too late to get an error message. Is that something we can try out and then adjust?

[DesignPolice]

I think that is a solid solution. @mewa1024 I will make some mockups today.

[corinagum]

after discussing with @DesignPolice, I'll be getting started on the implementation of this feature while he works on redlines. :)

[corinagum]

Hey all, I wanted to summarize the above (super long) thread, just to make sure that we're on the same page. @mewa1024 and @DesignPolice, could you take a look and add final comments? After the confirmation I'll add this summary to the top of the issue for anyone to have access to.

• Modify "Send failed, retry" text to "Send failed. Retry"
• Message will show above the sendbox (static location), and disappear when status is fixed. Message will not bump up or scroll when new messages are added
• We will use the warning or error icon for both statuses:
  
  
  
  • ! Web Chat is taking longer than usual to connect. Retrying in 30 (will countdown) seconds. Retry now - Warning icon
  
  
  • ! Web Chat is unable to connect. Error icon
  
  
• Warning for taking longer than usual will appear after ~15 seconds, but this number is pending adjustment after design sees the implementation
• Full error "unable to connect" will show up when we receive a failing HTTP header OR after inability to connect after 20 seconds. -- this is also pending adjustment for after design team sees implementation

[mewa1024]

@corinagum @DesignPolice
To questions above,

• Yes, "taking longer than usual" should use the warning icon (but "unable to connect" should use error icon)
• 20 secs for the "unable to connect" to start with sound good to me. We can test and see if that feels too long or short.
  Thanks!

[DesignPolice]

yes! @mewa1024 @corinagum thanks