If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.
>> So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
Just implement an additional back button on the SPA. This is actually not confusing and is done in some places. Navigation buttons within an SPA are common enough.
So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
If the navigation simulates what would happen if we follow links to SPA#pos1, SPA#pos2, etc so that if I do two clicks within the SPA, and then hit Back three times I'm back to whatever link I followed to get to the SPA, I guess it's OK and follows user expectations. But if it is used as an excuse to trap the user in the SPA unless they kill the tab, not OK.
From the browsers perspective those are the same thing though. It’s a paradigm boundary.
The real answer is to have desktop applications that work like applications (buttons do what feels right), and websites that work like websites.
SPA, is a page application. Pages aren’t applications, applications aren’t pages. AutoCAD is an app, the Robotech Encyclopedia is content.
1 reply →
Of course, but programmatically, how do you enforce that?
1 reply →
>> So that in single-page applications, it can work intuitively instead of always taking you all the way out of the app.
Just implement an additional back button on the SPA. This is actually not confusing and is done in some places. Navigation buttons within an SPA are common enough.
Because it has a legitimate use. As anything, the tools will be abused by malicious actors