Classic SPA routing problems
Hi, there. You're not logged in. So, you must be a visitor. Welcome!
What is this? You are viewing one of our supplemental "Stories." In addition to our core design curriculum, we are constantly building out additional resources. Stories are a collection of real work tasks, design history, UX explorations, and work-throughs. Stories are often off-the-cuff and less concerned with production value.
Introduction
Building an application inside an HTML page sounds like a great idea. It is! But there are some classic bumps in the road.
We’re going to keep some examples of common situations that arose in the past, and what we still run into today. There are some technical things to consider, but many of these problems can be solved with design decisions.
Routing that isn't tied to the URL or state
Browsers browse web documents. Each web document has it’s own address. Those places you visit will form a history and allow you to go backward and then forward again. When you use buttons instead of links to swap out the elements on the page, it will feel like it’s going to a new page. But it’s not! And it’s not tied to the history. There are ways to create your own sub history within your app’s state. And there are ways to save the content you entered in case you need to refresh. But even in 2024, it’s common to run into situations where this hasn’t been considered. There’s no official right way – but tying state to the URL and adding to the native browser history can solve a lot of these problems.
Imagine working as a online help desk person. The user can’t find the FAQ about how to restart their product. So, you might have to say “Go to the home page. Then look down on the left. Wait, what type of computer are you using? No. Then look down on the right. It’s maybe the 3rd one down. Then click that. Then look at the nav bar on the left. Click the 2nd or third one down. I can’t remember… ” etc etc.. because there’s no direct route. But if you could go directly to /site/faqs/categories/product/question-02 then everyone would know where it was and you could link directly to it.
This can also apply to sub routes. events/create/poll/step-3. It’s not always the right choice, but it’s a good standard to consider. A quiz app might need to change the history to disable going back to the previous question. A user signup might have no reason to start at the third step. But in any case, the user shouldn’t accidentally hit the back button and lose all their hard work. And having a native back button and also an internal app back button (when AngularJS came out) was a big problem with Single Page web Applications (SPAS).
Have you found any interesting situations like this out there?
If so, send us the URL or take a video of it so we can include it in this little history area. Then we can use these as examples in various parts of the course to remind people about the “why” if it.