Feature Request: Ability to customize scroll behaviour in WebChat V4

[CHuijsman]

Is your feature request related to a problem? Please describe.

User experience is one of the most important KPI’s for our entire website and thus for our product. This includes the ease at which users can read the information the chatbot provides them with. To this end, we feed our users small chunks of text. Most responses consist of multiple text bubbles. By default, the WebChat scrolling behavior is in such a way that it automatically scrolls all the way down to the most recent text bubble. Since we compose responses consisting of multiple separate text bubbles, the user interface ‘bounces’ down with every text bubble, ruining our user’s experience. This is a problem, because it is paramount that our users can take their time reading the information, and empower them to scroll down themselves when they’re ready. We require scrolling behaviour that enables this ease of reading while visually making clear that new messages are available. We are quite surprised that WebChat V4 does not yet support a feature to customize the scrolling behavior.

Describe the suggestion or request in detail

A feature or customization option (Hook) that lets us control the client’s scrolling behavior. We require that both the last user input, the first bot response to that user message, and 2,5 lines of text of the 2nd chatbot text bubble are in view of the client. A setting or Hook that would allow us to customise scrolling behavior to our own requirements would be very much appreciated.

Describe alternatives you have considered

• continue using WebChat V3 while it still functions; we have built this feature ourselves for WebChat V3. This is not acceptable because we need to keep up to date with technologies.
• taking our chatbot offline when WebChat V3 stops working as long as WebChat V4 doesn’t support this feature. This is not acceptable because we have a duty to provide services with our product.
• using another chat vendor that does support this customization feature.

Additional context

We are currently using WebChat V3, but would very much like to upgrade to V4 when it includes this customization feature.

To clearify our request we uploaded a video, you can find the video here

[Enhancement]

[compulim]

Your video looks great. Always feel inspired when look at how our customers modify Web Chat.

I am open to having a better scroll behavior.

Today, in Web Chat v4, we implement "sticky bottom" behavior:

• If the scroll view is currently at the bottom, we stick to it
• If the scroll view is not at the bottom
  • If a new message come from the bot, don't scroll
  • If the user send a new message, scroll to bottom
• The stickiness has zero pixel tolerance, which means, the scroll view is considered at the bottom when it is 0 pixels from the bottom. If it's 1 pixel above, it is not at the bottom
• You can also call this hook to scroll the view to the bottom

To try it out:

• Navigate to https://microsoft.github.io/BotFramework-WebChat/01.getting-started/a.full-bundle/
• Say random things to the bot until the scroll bar appears
• Type proactive
• Scroll up
• In about 5 seconds, keep your eyes on the scroll bar, you will see it contracted because new messages come in below, but the scroll position didn't move

With what I read from your description, is "2.5 lines tolerance" the only difference compare to the current behavior in Web Chat v4?

For interoperability, bot written with Bot Builder v3 will continue to function properly in Web Chat v4. Web Chat has no version dependencies on the Bot Builder.

[CHuijsman]

It is great to hear that you are open to improve the scroll behaviour.

We checked your sample with the proactive message, this works when the user scrolls up (which they normally don’t do).
The problem is best illustrated when you send help in the sample, in this case you need to scroll all the way up to start reading the bot reply. This is caused by the behaviour you described:

If the user send a new message, scroll to bottom

Then, when the bot reply follows, the following rule is applied:

If the scroll view is currently at the bottom, we stick to it

This makes that in a normal situation, WebChat will always stick to the bottom after the user sends a message.

With the customizations we did in WebChat V3, the window sticks to “the first reply to last user message”. We performed UX tests and found that users prefer the “start reading at the top and scroll down manually” experience over the “multiple replies flying into view, and then having to scroll up” experience.

We implemented the following behaviour:

• If the user sends a new message, scroll to bottom
• If the bot sends a new message, scroll down according to these rules:
  • If there is only one bot message after the last user message, scroll to bottom
  • If there are multiple bot messages after the last user message, scroll down only as far so that the first bot reply is in view, and a part* of the 2nd reply is in view

* in our case: 2,5 lines of text.
We chose for 2,5 lines because this makes it is visually clear to the user that there are more messages further down. This makes that user naturally wants to scroll down.

The “start reading at the top and scroll down manually” experience is shown in the video after the ‘wat is eigen risico’ messages (00:05). You see the bot responds with multiple text bubbles, however you can also notice the window stopped scrolling down. This allows the user to already start reading, while the bot may be sending more messages.

[compulim]

(Sorry I am tightened up with some work so my reply is slow. You should already see me finishing some pretty big PRs recently.)

This is very interesting.

Need to think a bit more about "if multiple bot messages is received", because Direct Line is pretty asynchronous. My gut feeling is that is should be technically doable in a neat way, but need some thoughts on the architecture.

With your explanation of 2.5 lines, now I fully understand how your video represent the idea.

Let me rephrase the behavior in pseudo code:

• If the last message was from the user, and a bot message is received, scroll to bottom
• If the last message was from bot, and another bot message is received, the view will be scrolled at a maximum of 2.5 lines

For the UX, could you explain a bit more about the following scenarios?

• If the last message was from the user, and a bot message is received and is taller than Web Chat, will Web Chat scroll to the top of this new bot message? Or to the bottom of the new bot message?
  • Furthermore after receiving this very-tall message, if another bot message is received > 2.5 lines, will the view be scrolled down by 2.5 lines?

BTW, a side question, are there any particular reasons why suggested actions are not preferred, and your design team preferred inline buttons? Today, Web Chat v4 support two layouts for suggested actions: carousel and stacked. Both stick to the send box but not the bubble. Looks like inline layout could be a good enhancement for Web Chat, but it looks a bit jumpy UX-wise.

[EdwinOtten]

Hi, I'm replying on behalf of @CHuijsman (we're on the same team).

are there any particular reasons why suggested actions are not preferred, and your design team preferred inline buttons?

We are still using WebChat V3, and we didn't like the carousel behaviour of the suggested actions back then. I didn't know about the 'stacked' orientation, but it looks nice! I would prefer that to the carousel orientation.

If the last message was from the user, and a bot message is received and is taller than Web Chat, will Web Chat scroll to the top of this new bot message? Or to the bottom of the new bot message?

I have discussed this with our designers. We don't expect the WebChat to scroll to the bottom of new message.

Our C# bot is currently at V4 and our WebChat is still on V3. And while we're still unsure about some smaller details*, our stakeholders require us to at least implement the 'improved scroll behaviour' that we currently have, before migrating to WebChat V4.

* smaller details: in the case of a very-tall message we are still not sure whether we would scroll to the top of this new bot message, or to the top of the last user message

---

Proposal:
On one hand we want to improve UX with better scrolling behaviour, on the other hand it is hard to actually define a definitive solution. We think the optimal experience may vary based on target audience/type of content, and is best achieved by iterating, and even doing A/B testing.

Therefore, I would propose building one (or more) Hooks that allow developers to customize the alignment the of the activity in the viewport. A (not so pseudo)-code example of this:

function getAutoscrollPosition(activities: Activity[], nextActivities: Activity[]): ScrollAlignment {
    // Some custom logic here to determine how to align the view
    return { ActivityIndex: 4, ActivityAnchor: Position.Top, WindowAnchor: Position.Top };
}

enum Position { Top, Middle, Bottom }
interface ScrollAlignment {
    ActivityIndex: number;
    ActivityAnchor: Position;
    WindowAnchor: Position;
}

[cwhitten]

Hi @CHuijsman. I like your proposal. I will work with @compulim and team to formalize this API. Realistically we'd be looking at a May '20 or August '20 release that introduces this behavior.

[cwhitten]

This is targeted in to land in an upcoming release.

[provJaredWeiss]

Hi there, I just want to check in and see if this feature is still being worked on? Looks like last activity was a couple months ago. I am currently using the scroll 1px up trick, but it's not ideal obviously. Thanks!

[CHuijsman]

Hi @compulim @cwhitten,

I just noticed our feature request has been reprioritized to R11. Due to this, we also have to postpone our update to Web Chat V4 till this features is released. Can you give us more insight on your planning and can you inform us if we can rely on a release in R11 of our feature request.

[cwhitten]

@CHuijsman -- this is high on our priority list and we hope to address this in our next release.

[cwhitten]

@CHuijsman we're continuing to work on this feature, however it will not make it into our November release. It remains a high priority feature.