1568305 - Client-side navigation suffer because of lack of visual feedback

Status: RESOLVED WONTFIX

(developer.mozilla.org Graveyard :: Design, enhancement, P1)

Description

[Peter Bengtsson [:peterbe]]

One thing I've noticed, when clicking around on the read-only site, is that sometimes it feels like my clicks aren't picked up. "Did I not click the link?! Crap! I better click again"

Usually, my local instance is a bit unresponsive because of docker-compose being under load and being a bit sporadically sluggish. A more realistic thing is that the Internet connection is slow. There's an easy way to simulate that fairly without using complicated wifi or browser throttling. Inside the kuma.api.v1.views.document_api_data view function I put in a import time;time.sleep(3). That means that every XHR (e.g. GET /api/v1/doc/en-US/Web/HTML/Element/canvas) is slowed down by 3 seconds. And if you don't use XHR and instead fall back on SSR it equally gets a 3 second delay every single time.

If we didn't do client-side navigation the browser chrome, which I'm very "muscle-memoried" to notice animates the tab.

Ultimately, I think our attempt of a thin faint blue top bar isn't visually "helping" enough.

Comment 1

[Peter Bengtsson [:peterbe]]

(not sure where to upload the screenshares so I used my personal site)

Intercepting clicks. I.e. client-side navigation
https://www.peterbe.com/bug1568305/client-side-navigation.mov

NOT intercepting clicks. I.e. traditional mode.
https://www.peterbe.com/bug1568305/not-intercepting-clicks.mov

Comment 2

[Peter Bengtsson [:peterbe]]

I really think, we can do better if we just do something immediately in that click interception. Something that immeditately tells the user that the click was at least received and that we're working on it.

Comment 3

[Peter Bengtsson [:peterbe]]

We did kick the tires on this here.
There is no slam dunk solution that isn't without its own flaws.

My original point is that visually not conveying that I clicked. Not only is a spinning browser chrome (the animated browser tab) something we're all so familiar with, the really neat thing about it is that it starts to animate the instant you clicked.

A lot for form submissions that are intercepted by JavaScript and dealt with with XHR solves this by doing something like this:

<form onSubmit="return handleFormSubmission()">
  <input name="name">
 <button type="submit" onClick="this.classList.add('loading');this.textContent='Please wait...'">Save Changes</button>
</form>

That's not too different from what we're currently doing on our implementation but unlike a progress bar, the <button class="loading">Please wait...</button> is right where you clicked which is closer to focus.

Comment 4

[Schalk Neethling [:espressive]]

One of the things we should do is look at what the browser affords a user when navigating between pages the old school way. From there we can determine what we are losing by taking over ourselves, and also have a more defined idea of what user expectations are when it comes to navigation.

One point I do agree with, with Nick is that our current "progress" bar is not really a progress bar. When I think of a progress bar, I think of the one, one finds on Github for example. Here we also have a native HTML progress element we should use as it affords us some native accessibility as well.

I will add more thoughts as they occur to me.

Comment 5

[Kadir Topal [:atopal]]

(In reply to Schalk Neethling [:espressive] from comment #4)

One of the things we should do is look at what the browser affords a user when navigating between pages the old school way. From there we can determine what we are losing by taking over ourselves, and also have a more defined idea of what user expectations are when it comes to navigation.

What the browser does is to animate the browser chrome (greyed out reload button, animation in tab bar, status message in footer, etc). We don't have access to that as far as I know.

Comment 6

[Dan Callahan [:callahad]]

Seems like we don't have a visually distinct :active style for links, either. Which would at least help me know "yes, I did click."

Comment 7

[Schalk Neethling [:espressive]]

(In reply to Dan Callahan [:callahad] from comment #6)

Seems like we don't have a visually distinct :active style for links, either. Which would at least help me know "yes, I did click."

Good point, could not agree more.

Comment 8

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub pull-request: https://github.com/mozilla/kuma/pull/5599

Comment 9

[GitHub Bugzilla PR Linker]

Attachment: Link to GitHub master push: https://github.com/mozilla/kuma/commit/e18c4f4c801a4891da4eb5f110d81e45d9cf2afd

Commit merged into master by GitHub
Authored by Schalk Neethling (schalkneethling)

Comment 10

[BMO Automation]

MDN Web Docs' bug reporting has now moved to GitHub. From now on, please file content bugs at https://github.com/mdn/sprints/issues/ and platform bugs at https://github.com/mdn/kuma/issues/.