re: Some questions about SPA UX VIEW POST

TOP OF THREAD FULL DISCUSSION
re: 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 s...
 

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? 😊

code of conduct - report abuse