XHR option to trigger busy indicators

[stevesouders]

Browsers have default "busy indicators" that provide feedback to users that the page is loading, eg, the tab icon, status bar, and reload icon. These busy indicators are triggered in some situations (eg, clicking a link), but not others (eg, issuing an XHR). (See http://www.stevesouders.com/blog/2013/06/16/browser-busy-indicators/.)

In the absence of these busy indicators, users are uncertain and thus anxious about the status of pages loading. If the XHR response is slow to arrive and its content is critical to the user experience, the user has no idea that anything is happening. This problem grows as more pages adopt XHRs for core functionality.

A good example is this article from eBay about how their XHR-based single-page-web-app was perceived as slow until they added a progress bar (http://calendar.perfplanet.com/2014/the-power-of-perceived-performance/). That article also mentions Twitter's approach of adding a throbber to the page when XHRs are fetching tweets.

While requiring developers to add custom progress indicators is a workaround to this problem, it's not ideal because 1) it's more work for developers and 2) each progress indicator is a custom implementation and thus there is not a typical experience for the user that they are trained to look for and expect.

Since users are "trained" to look for the typical busy indicators, these indicators should be triggered when an XHR is issued for content the user is waiting on. However, XHRs are also used for background requests where the busy indicators should NOT be triggered. I suggest we add an option to XMLHttpRequest, eg, showBusy. Setting showBusy=true would explicitly tell the browser to trigger the busy indicators. This would allow for the current behavior (no busy indicators) to be preserved, but also allows an easier and more standard way for developers to use XHR while giving progress feedback to users.

[annevk]

Is there implementer interest to the extent they are willing to put UX resources on this? (Opera used to show all XMLHttpRequest activity and it was very bad (due to the background resources you mention).)

[josh]

I would ❤️ this so much and we'd totally use this on @github for pretty much all our page transitions instead of custom spinners.

[jussi-kalliokoski]

👍, but instead I'd suggest programmatic control over the feature, because loading may include JS, fonts, images or processing in a worker (e.g. if a data blob is cached, but requires processing before being fed to a view).

[jussi-kalliokoski]

And also because the actions may be canceled (e.g. a user clicks on a wrong link and then the correct one).

[d2s]

More consistent UI behaviour between websites (and different browsers…) could make things much more clear for the users. Also, less code to implement for front-end developers, reducing need for additional building blocks.

[rauchg]

This should not be tied into XMLHttpRequest, because of possible alternative transports in play (WebSocket). Also because a sequence of requests might be needed to trigger the following page.

Maybe we should consider something on the navigator or window object.

navigator.setBusy(true);

I personally would like to see this happen not just because of the perception of slowness, but because of the duplication of user-agent UI that's happening with the "slim progress bar" trend (as seen on YouTube, Medium, etc)

The performance angle is more nuanced. Many single page applications solve it by making the transition to the new page immediate, and displaying placeholders there (eg: Facebook Newsfeed)

[josh]

It's more than a binary state, you really want something associated with
progress events.

I kinda doubt UAs are going to give complete direct access to something
like navigator.setProgress(0.75) given the ability for abuse, even though
it'd be pretty cool.

Restricting to something request-like would cover most use cases.
On Mon, Jan 19, 2015 at 12:33 AM Guillermo Rauch notifications@github.com
wrote:

This should not be tied into XMLHttpRequest, because of possible
alternative transports in play (WebSocket). Also because a sequence of
requests might be needed to trigger the following page.

Maybe we should consider something on the navigator or window object.

navigator.setBusy(true);

I personally would like to see this happen not just because of the
perception of slowness, but because of the duplication of user-agent UI
that's happening with the "slim progress bar
https://github.com/rstacruz/nprogress" trend (as seen on YouTube,
Medium, etc)

The performance angle is more nuanced. Many single page applications solve
it by making the transition to the new page immediate
http://rauchg.com/2014/7-principles-of-rich-web-applications/#act-immediately-on-user-input,
and displaying placeholders there (eg: Facebook Newsfeed)

—
Reply to this email directly or view it on GitHub
#19 (comment).

[rauchg]

It depends on how it's implemented. The iOS status bar binary loading state works pretty well, for example.

[josh]

Also consider that the "Stop" button is closely linked to "in progress".
It'd be kinda neat if that put the user in control of canceling the request
if they wish. Shout to cancelable fetch promises.
On Mon, Jan 19, 2015 at 1:22 AM Guillermo Rauch notifications@github.com
wrote:

It depends on how it's implemented. The iOS status bar binary loading
state works pretty well, for example.

—
Reply to this email directly or view it on GitHub
#19 (comment).

[gaearon]

navigator.setBusy(true);

Different parts of code may want to push/pop an async operation so this wouldn't work well as the primary user-facing API IMO.

Instead I'd rather prefer something like this:

window.attachToBusyIndicator(promise);

Internally, we'd keep track of promises in progress and only show spinner when there is >= 1 such promise. When promises resolve, we remove them from the queue.

var busyPromises = [];

function refresh() {
  NativeImplementation.showBusyIndicator = busyPromises.length > 0;
}

window.attachToBusyIndicator = function (promise) {
  function detach() {
    busyPromises.splice(busyPromises.indexOf(promise), 1);
    refresh();
  }

  promise.then(detach, detach);
  busyPromises.push(promise);

  refresh();
}

This also works nice with cancellation because, whatever approach you choose for cancelling promises, if cancellation implies rejection (and it should), our counter will decrement on cancellation. Example of a nice cancellation API.

[fabiosantoscode]

I completely agree that the browser's busy indicator should not be tied to XHR or fetch(). What about JSONP, WebSockets, PeerConnections? they are perfectly valid ways of getting data which you have to wait on.

Busy indicators, progress indicators, are visual indicators, and thus in principle should not be triggered by network operations, even as an opt-in.

[rauchg]

@gaearon I actually prefer browser APIs to be minimal. You can add the Promise layer on top of it trivially. Just like not everyone uses XHR exclusively (the very premise of my post), not everyone has to use Promise to trigger the indicator.

[gaearon]

@rauchg

I was thinking about bad libraries messing with a boolean field that you have no control over. Imagine some SDK doing that. Maybe it's a library's problem though.. I'm not sure it's good to encourage bad patterns by exposing API that's too easy to misuse.

And for a good API, I can't think of a better fit than promise. It represents an asynchronous operation in the language. You don't need to use promises in your code to represent async operations if you don't want to, but wrapping any async result (socket, XHR, whatever) in a promise is as straightforward as any other async API could be. If you want to track async operations in the UI, you need a way to represent an async value, and promises are baked into the language precisely to be the way to do that.

If core browser APIs expose promise-based async operations such as fetch, IMO it's weird for async operation tracker to expose lower or higher level API. Otherwise, why make fetch promise-based?

Finally, I can't build promise-based layer on top of isBusy because I have no guarantees somebody (including third-party libraries) doesn't set isBusy directly, thus making my layer completely unreliable.

[rauchg]

@gaearon

Your layer can be implemented by listening to busyChange events and querying an isBusy flag.
That said, I agree that Promise could increase harmony between 3rd party libraries.

[gaearon]

@rauchg

Your layer can be implemented by listening to busyChange events and querying an isBusy flag.

Say I have two pending promises in my layer. Thus I set isBusy = true.

Then nasty module X comes along and does .isBusy = true.
But it's busy already. Would the busychange event fire?

If it's a change event, it wouldn't, but then, when my pending promises have resolved, I'd have no way to know from my layer that somebody else wanted to keep the app busy.

If we're sure we don't want a Promise API for that, I still suggest two methods over isBusy:

window.setBusyIndicator(): operationId
window.clearBusyIndicator(operationId)

These can be called safely from different modules.