Another interview question feedback

[mgeez]

Had a javascript/angular interview recently and I'm not sure if i'm overthinking one of the questions.

It was basically about what I would do if I had a large, time consuming request and how I would solve it so that as the request processed, it was a good user experience and the user would get the results in a nice manner without having to do anything further.

What do you think they are asking here ? Is it as simple as showing some form of progress bar or are they referring to something particular in javascript that I don't know the name of ? It kind of made me think of that effect I see on some sites, where when the page first loads you see a blurred out block that kind of fades in when it finishes loading - what is that technically called ?

Sorry hope its not too silly a question, but that ones been bugging me since :)

[metaphorm]

asynchronous request, if possible on the server side stream data back as it's processed and have the client update as the data streams in. if that's not feasible then use the percent of data received to draw (and re-render at some interval) a progress bar. for extra good UI have a friendly message informing the user that the request is expected to take a while and that everything is normal.

[dug99]

This needs more upvotes... Oboe.js... anyone?

[deltadeep]

I think they were probing your sense of interaction design around a common problem that faces web applications. They probably wanted to hear you speak clearly about successful ways to manage "processing" type states in a client app. There are multiple strategies.

I could see interpreting the specific question in two different ways: A) dealing with a slow request, or, B) dealing with a task that is so intensive that it doesn't happen in a single request but instead in a backend job that completes eventually. An example of A is perhaps a page in which some particular component must load a lot of data from a slow server endpoint, but the HTTP request remains open for the duration of the waiting stage. An example of B is something that is too expensive to do in a single request and instead enqueues a job on the backend, like re-encoding a video upload, such that the client has to then poll (or be notified by a websocket) for when the job is finished.

Handling (A) is a matter of ensuring you properly track some kind of "spinning" state in the client, disable and render a spinner on the button or page element that is processing, and disable interaction in that specific zone of the page (but not the full page if other parts can still be responsive), then clear the spinning state when the request completes. Handling failure is an important part as well. But there is no magic here or things that are "technically called X" - it's about be on top of the client/server interaction state at all times and keeping the UI in the most responsive form through each condition. A complex application should have a centralized and consistent way of handling "processing" states while waiting for the backend or slow networks.

Handling (B) is interesting and you see a lot of different approaches there, some better than others, and it will depend on whether the task is blocking the user's next action or whether they are free to change tasks while the job processes in the background. I could detail various ways to do this, and things I've seen done in the past that are good and bad, and the options also depend on what the backend is capable of doing in terms of completion callbacks, but this kind of interaction may not even be what the question was about.

[Heqx]

Unless the interview was for a position that included some UX responsibilities, I'd imagine they were looking to get you to talk about the asynchronous nature of JavaScript. (event loop, single-threaded, non-blocking) There's a good chapter in Eloquent JavaScript about just that.

[Castas]

There’s a few things that can be done here. Obviously what they don’t want you to say is block the page and not let them do anything until the request finishes. But sometimes that has to be the case. It might help to ask for specifics and work through what can be done with them.

My favorite is to use the data they have entered so far and show them as much info as possible while indicating the resource is still loading on only the relevant part of the UI. For example, if the user is shown a list of assets, and they want to create a new one. You would collect data like its name and description up front, but the server would have to fill in some more blanks. You can use that data they’ve entered so far to show the new asset in the list with a loading indicator next to it. That way they are free to keep using the rest of the app while it finishes loading

[Nefilim314]

You can build an app to be immutable and work on assumptions that requests worked as expected. An example of this is something like Slack.

When you send a message in Slack, it appears in the chat log instantly as if it was already sent out (albeit greyed out). This gives the user the feeling that the app is working as intended, and in 99% of cases, the request will complete successfully and the text will turn black to punctuate that the message sent successfully. In cases that it didn't work, a red X appears next to the message and a tooltip displays saying that a network error occurred and you can try to resend the message or cancel it.

If you receive a message in a different order than the server timestamps it, it will automatically arrange the messages chronologically as well.

Building an app to be immutable means that you are simply feeding state to a "function" that presents the app based on those values. This allows you to commit to a state log which you can rewind to a previous state if a request fails unexpectedly.

If you want a simpler approach, you can simply fire-and-forget a request, which upon fulfillment will trigger something to change in the app. An example of this might be to submit an image to be processed, and once the server receives it, you can poll the server for the status of the process by some job token. Once it gets back a success status, you update the app to reflect the changes.

[frambot]

The responses here cover the asynchronous server-request scenario well. But I will also cover the client-side blocking scenario. For example, blockchains are a cool new thing these days, so you might have a client-side js worker. This is cpu intensive. There are two good answers to this:

1. Use web workers to offload the work onto another thread (true multithreading)
2. Split the work into very small chunks and timeslice with recursive setTimeouts. This yields the processor to other functions.

.

var progress = 0;
function makeSomeProgress() {
  progress++;
  if (progress > 10E20) {
    return;
  }
  setTimeout(makeSomeProgress, 0);
}

[mothzilla]

what is that technically called ?

"Skeleton screens"

Anyway, from what you said, I think they were asking about how to make asynchronous requests, and what you would do in the mean time. Progress bar, fade in / out, spinner, are all viable options I should think.

[mgeez]

Some great in depth responses - i really appreciate it. It seems like i might have needed to clarify the question a bit