3 ms·
On the other hand: why? Browsers already have a back button that works that way. Users are used to back buttons on the page moving up some in-app hierarchy, whi
by robinson7d 3y ago
On the other hand: why? Browsers already have a back button that works that way. Users are used to back buttons on the page moving up some in-app hierarchy, which, admittedly maybe they oughtn’t be used to because maybe it’s not a good pattern in the first place.
But instead of reimplementing the browser’s one and potentially confusing the users, why not remove the button entirely and have people use their browser’s more consistent UI? If the extra space is awkward surely there’s something else that can go there.
There are useful cases for history.back, but I’m not sure a back button is it.
- fwlr 3y agoThere are good uses for app-specific back buttons, for sure! Two cases I’ve seen - one is a site with “single page app”ish flow for reading sequential posts, where rather than reloading the entire site it fetches just the JSON data for next and previous posts and updates the HTML; the back button here uses the already-fetched data rather than getting the whole site again. The other case used custom back logic on their site’s back button on form pages to avoid “re-sending form” pop-ups and to avoid losing entered form data. When I said “mildly detrimental” I was thinking of a specific example (go back to the previous page that is on the same domain, implemented solely to improve metrics), so perhaps I shouldn’t have said “usually”.