What is Fiori’s (or your) take on self-implemented back buttons inside a non-split stand-alone UI5 app? We all know that being able to navigate back is fundamentally important in UX design and I understand that an app might need its own back buttons if it has multiple pages displayed concurrently on which the user can drill down for each page (e.g. Master-Detail). But if the app is not split, it seems confusing if it has its own back button in the header toolbar close to the browser’s native one because they are doing pretty much the same thing: Telling the browser to navigate back.
So I’m not sure if webapps, in such cases, should have their own back buttons at all if the browser already offers one – Assuming the app has implemented proper route handling for each screen already.
Would you still recommend to add a back button for stand-alone UI5 apps? On FLP, there is already one in the shell bar.
Edit: One benefit I see for having my own back button is when the user performs a deep link navigation where he/she opens up the app via the link to the already navigated page initially. In this case, pressing on the native back button would terminate the app whereas the my own back button would lead to a previous hierarchy of the app; Similar to Android’s back– vs up-button.
Fiori 2.0 standalone apps should offer a Back button in the merged 2.0 shell bar. Back navigates to the previously visited screens. Only if a deep link to an application is called and there are no SAP Fiori entries in the browser history, no Back button should be displayed.
Please check the Shell Bar chapter in the SAP Fiori Design Guidelines for reference.
You must be logged in to reply to this topic.