Don’t break the browser
There is usually a lot of state on each page of a Single Page Application. It might be pagination, or the amount of scrolling the user has done when using infinite scroll, or the detail of something that appeared in a lightbox when he clicked on it. Such things usually lead the user to another page when using a regular website, but in a Single Page Application, it usually doesn’t. Even though the user would still expect the state to somehow be perserved.
Test on real mobile devices
The mobile browsers are pretty good at displaying
<a href="..."> links, but
they might not be so perfect at drawing your fancy charts, or at handling that
parallax scrolling you just added using 5 different hacks. In fact, scrolling
is probably the most absused thing I’m running into. It just always feels that
I’m either using a mouse on what was designed for a touch screen, or the other
way around. Just because you’re developing on a MacBook Air with a Trackpad, it
doesn’t mean that everyone in the world uses a Trackpad as well.
An important thing to note here is that testing on a real device is not the same as resizing your desktop browser window to 480x360. There is a completely different feel from using your fingers to move around.
SPA users have higher expectations Once you start with the whole SPA thing, your users’ expectations will grow massively. Take Discourse for example. If you’re replying on a regular forum, you simply hit the reply button and start writing your reply. If something pops up in your mind and you decide to search the forum some more, you simply open a new tab in your browser.
On the other hand, Discourse implemented this neat feature when you can keep navigating the site, while having your reply still open at the bottom of the page (see this topic). This however, while being an awesome feature, brings up a lot of newborn complexity. For example, they’ve also implemented a feature, that if you finish writing your reply while being on a different topic than you were originally, you will be prompted to reply to that topic instead.
You can also collapse (minimize) the reply form, it saves the text as you type to the backend, etc. Just a bunch of very cool things from a UX perspective.
But there’s a downside to this as always. Think about how much work goes into designing the workflow I just described, vs creating a simple and static HTML form. It isn’t even on the same scale. You can deliver a much better experience to the user, but you’re also going to delay the whole project by a significant amount of time. Ever new feature will yield 10 new opportunities for making the UI better (and more complicated), and in the world of client side applications, that also means it will take more time.
Do you really need a Single Page Application?