Some questions about SPA UX

Ankush Thakur on August 05, 2018

I came across SPAs a few months ago, but have never been able to wrap my head around them. I keep running into fuzzy guidelines and conflicting opi... [Read Full]
markdown guide
 

Hi Ankush, only built one SPA and a half here so I'm definitely not an expert but I like them so I'll try to give you my perspective.

If an SPA sends an Ajax request to a backend and for whatever reasons the whole thing takes five seconds, the experience, I believe, will be worse than a server-rendered page's (where at least the user can see a 'loading' icon).

The user experience doesn't have much to do with SPA/non-SPA in this regard. It's just up to you to show tell the user that tha SPA is loading something. It's quite easy, most CSS frameworks have a loading state for their components or a loading div that covers the container. You can also use progress indicators or placeholders, depends on your UI. There's a lot of content regarding loading states on Google.

Now, if the response is delayed, the user will be left feeling stupid. If you show a loader, on the other hand, you've committed an SPA sin.

I'm not sure why showing any loading state is a SPA sin. I'm sure there are SPAs that are bad out there but I don't think it's an intrinsic defect, it's just that most people are bad at UX :-D

For instance, again, if there's an e-commerce search and the results contain one million products, we can't all pre-load them; and even if we keep caching them as the user navigates forward, there will come a time when the RAM will just explode. And even if there's more than enough RAM, how many products do you cache?

Again, how's this an issue of SPAs instead of bad programming practice? It's going to be the same bad experience if, with a server side rendered page, I send to the user ALL the results :D And why you should you cache everything?

BTW dev.to is a SPA that makes use of service workers (so technically a PWA), outside the response of user interaction, maybe you could take a look when the code is going to open sourced in three days :-)

The Laravel community, especially the LaraCasts author Jeffrey Way, is mostly against SPAs and Flux (Elm) like central stores, at least. In the words of Jeffrey from a podcast interview: "Sure, it's cool, but . . . is it useful?"

Wait, that's weird. Laravel and its community is one of the reasons why Vue.js has so much adoption for example. Granted that different people in a community can have different opinions, bust still... :-)

Some ideas and insight will be greatly appreciated. What do you think of this whole mess? How do you manage your SPAs?

I don't think it's a mess. It's definitely a more complicated approach then "render a table server side, send it to the user and sprinkle the page with jQuery" because JS tooling and frameworks are a lot to take in but I don't think SPAs are a mess. It's just another paradigm of creating a web app, it might be right or wrong depending on the case.

My one and a half SPAs are quite similar, they are both in Vue, with a router, the latter one has a central store (Vuex), the first one is completely driven by the API (I didn't deem the store necessary at the time).

Or maybe you just 'eschew obfuscation' and avoid SPAs?

What does "eschew obfuscation" mean? :-)

 

Hey, thanks for the reply! Here are my thoughts:

The user experience doesn't have much to do with SPA/non-SPA in this regard. It's just up to you to show tell the user that tha SPA is loading something.

Well, if I show a loader on every page, the distinction between an SPA and a server-rendered app vanishes. The 'smooth' transitions are definitely the part of SPA UX (please see the new section I added to my post: 'The Back button').

Wait, that's weird. Laravel and its community is one of the reasons why Vue.js has so much adoption for example.

They love Vue.js because it can included like jQuery and isn't weird like React. It doesn't have any fundamental connection to SPAs.

BTW dev.to is a SPA that makes use of service workers (so technically a PWA), outside the response of user interaction, maybe you could take a look when the code is going to open sourced in three days :-)

I noticed that dev.to progressively loads HTML for articles mentioned on my feed when I scroll down, or even when I do nothing. I guess server workers are neat, but the question of when to update and how to represent it (UX) remains, at least for me (again, could you take a look at 'The Back button' section and tell me what you think of it?).

What does "eschew obfuscation" mean? :-)

Well, it's a sort of joke I came across some time ago. It's a more complicated way of saying 'avoid complexity'. 😄 Maybe I should remove this reference, or maybe not . . .

 

Well, if I show a loader on every page, the distinction between an SPA and a server-rendered app vanishes. The 'smooth' transitions are definitely the part of SPA UX (please see the new section I added to my post: 'The Back button').

I disagree with that. The only real required difference between a SPA and a traditional web app is that the SPA avoids page loads. Ideally, a regular user shouldn't notice nor care whether the app is single page or not.

You talk about the SPA UX, but I don't think there's anything particularly different in UX considerations between SPA and traditional web apps. Smooth transitions enhance any app's UX. SPA can be (but not necessarily are) a way to achieve smooth transitions.

Usually, smooth transitions mean fast transitions. The promise of SPAs is that by only loading data, you avoid the extra time that it would take for the browser to parse the html, css and scripts for the new page and therefore the transition is faster. That is entirely different to no loaders should be shown ever. Ideally you want the transition to be so fast that the loader is never shown, but if the request takes a noticeable time (there could be a hundred reasons, slow connection for instance), you definitely want to show a loading state to the user instead of just leaving the app unresponsive.

Thank you, thank you for your thoughts. This is really reassuring:

The promise of SPAs is that by only loading data, you avoid the extra time that it would take for the browser to parse the html, css and scripts for the new page and therefore the transition is faster.

But then again, could you please address how to handle the Back button. Dev.to doesn't reload the content when I hit back, so what if there's an update on the page?

That's just the way dev.to is built. Nothing would prevent a SPA from requesting the data again when going back to the previous page.

In fact, requesting the data again would be the default behaviour, if you want to cache your pages like dev.to does, you need to specifically build it. Otherwise, the app doesn't care how it got to the current page, whether the user loaded the page there through a bookmark, a link within the app, the back button... It just requests the relevant data and renders the page.

Also, I think that the dev.to behaviour is not specific to the back button, I've noticed that articles and pages I've visited recently aren't updated when I visit them again, so I doubt that the caching is specific to the back button.

In fact, requesting the data again would be the default behaviour, if you want to cache your pages like dev.to does, you need to specifically build it.

Honestly, what a relief. I avoided building SPAs for the last few months because I thought something was wrong with my approach. 😅 Thanks a lot, good (sir? madam?)!

 

I'm not UX expert though, what I was trying to say is that what you attribute to SPAs intrinsically to me seems it's more about UX issues than the technology itself.

Well, if I show a loader on every page, the distinction between an SPA and a server-rendered app vanishes. The 'smooth' transitions are definitely the part of SPA UX (please see the new section I added to my post: 'The Back button').

Well, it can still be faster even with that.

This is something I see on dev.to as well. If you're on an article and navigate to another one, when you hit Back, there's no communication between the client and server. What if someone has commented on the article while you were away? Does that get handled (and updated) via WebSockets, or not at all?

Don't know about the details of dev.to yet, but SPA doesn't mean you never ever hit the refresh the button though.

mobile.twitter.com AFAIK is more or less like that. If you go back and you end you in the homepage, the homepage will pile up the new tweets and push them at the top of the feed.

But keep in mind that not all SPAs are the same.

I'm still convinced what you highlighted in your post is more of a design/UX issue than a technology shortcoming :-)

Thanks for your comments. Yes, looks like I've made it appear like a criticism of SPAs than questions about UX. But I disagree that this is a pure UX question -- avoiding page reloads is impossible in a traditional app but is (almost always?) possible in an SPA so there's definitely UX difference arising out of technological differences.

But keep in mind that not all SPAs are the same.

That's a relief to hear. So, my SPA can have spinners on every page, whether you navigate away from it or to it? 😊

 

If the app needs data it doesn't have, and the network is being slow/unreliable, of course you should indicate that to the user.
This goes for any app, whether browser-based or completely native.
A naively-made app (on any platform) might block the user entirely with some kind of "this app requires Internet connectivity" modal. A better app will allow them to navigate to other pages, view old (only possibly stale) data, and even compose posts/messages to be uploaded once online.
Honestly, it's nontrivial to think of a "website" that wouldn't benefit from offline capabilities at least in some sections thereof.

Then, there's reducing cost of server compute and bandwidth by caching the application shell (not even on cdn, directly on the clients) and only loading compact data from apis, all while benefiting the user as opposed to exploiting them.

 

I wanted to respond in detail but didn't get the time, so here goes. Yours are all valid points, but they also reflect the state of front-end development -- incredibly complex. The bar seems to be raised a few notches every month, and sometimes all I want to do is sit down and cry. 😂

I can't even begin imagining the complexity of a progressive front-end that has service workers and offline capabilities. 😐

 

There's all sorts of open source that will really hide the complexity from you. It's a great choice for any pragmatic business need.
Only in a few rare cases outside of being an obsessive perfectionist do you need to get your hands dirty.
Something like Next.js + apollo-client + workbox and you're off to the races.

 
 

The Laravel community, especially the LaraCasts author Jeffrey Way, is mostly against SPAs and Flux (Elm) like central stores, at least. In the words of Jeffrey from a podcast interview: "Sure, it's cool, but . . . is it useful?"

Yeah, it really is. Speaking for Elm anyway. But you model central stores differently, especially with Elm union types.

I mostly write SPAs nowadays. The client-server separation forces a more-or-less healthy mental model of how the UI should be separated from interaction with back-end resources. I also had particularly bad experiences with server-side components trying to abstract rendering details from me, but then I depend on those rendering details for styling purposes, or the generated scripts interfere with other scripts. So being able to take control over those things if necessary on the client side makes solutions easier to achieve.

jQuery... no I don't do that anymore. Last time I did, I was not pleased how it turned out. MVU (Elm) style is pretty much the only way I would do SPAs anymore until someone comes up with something better. Mainly because most of the code is my own code, not incantations to invoke the framework features "just right".

 

True. I included Elm because that's where the original idea comes from, although Redux/Flux seems to take all the credit. 😏

I think the higher your skill-level as a front-end dev, the more these things make sense. Juniors absolutely love jQuery, because there are so many elegant plugins out there; mid-level developers like me know the pain of jQuery, and also know that frameworks are better, but their front-end skills hold them back from making a complete switch; really experienced ones are either writing in Elm or even vanilla JS.

All this said, though, consulting (freelancing) is a different beast. They (includes me) need to get the job done in the least possible time, which obviates stuff like React, SASS, unit testing, browser testing, and so on.

code of conduct - report abuse