Skip to Content

Yesterday I ran a hands-on session with some of the target users for our first Personas application. This was the first time end users had been given hands-on access to it – previous user feedback had been based just on demos given by me. I explained the ideas behind the design and gave a brief explanation of how it worked, and then let them explore it for themselves. It was gratifying that they did indeed find it easy to do the things they needed to do, but it was also educational to see how they managed to find ways to break it that I hadn’t anticipated! I consider myself to have a reasonably devious mind, and can usually find ways to use systems that the original designer hadn’t anticipated. When you are the designer, though, you are usually too close to the design to be able to fully think as a user.

One thing that simply didn’t occur to me was the use of the browser back button. My Personas application is designed as a launchpad built on the SAP start screen, giving the users access to all the functionality they need right from there. There are buttons to launch relevant transactions and reports. Each such transaction and report has itself been tailored using Personas, and each has a “Home” button on the screen to take the user back to the start screen. However, all of the users involved in the testing yesterday ignored that home button and reached instead for the browser’s back button. This is running in a web browser, so that is bound to work, right? Wrong…

Personas, at least version 1, the Silverlight version, runs in a plug-in. All of the navigation between transactions happens inside the plug-in and doesn’t affect the browser history at all. Pressing the browser’s back button takes you to a “system selection” screen, a screen user’s will not normally see and if there’s only one system a user has access to (the typical Personas installation) this screen is bypassed. As it happens, the users all managed to figure out how to get back without me having to tell them, but I’d really like to avoid this happening in future. Ideally I’d like to disable the browser back button. Yes, yes, yes. I know you shouldn’t do that. Indeed, you can’t do that. A web app should be designed to cope with inappropriate use of the back button. Personas isn’t really a web app, though. It runs in a browser, but it isn’t a web app. I guess when I’m using the HTML version this problem will go away? WebGUI certainly seems to cope well with use of the back button.

Until then, I would still like to find a way to avoid this problem if possible. I have come up with a sort-of solution, involving manipulating the browser history. It works like this. On my launchpad screen I’ve created a script button. That script button contains just one action, a JavaScript action that contains the following:

window.history.pushState({}, "Personas", document.URL);
window.history.pushState({}, "Personas", document.URL);

This just adds the main Personas URL to the browser history so that pressing the back button doesn’t do anything. And it adds it twice just for good measure. If you press the back button enough times, though, you will eventually go back. Now, use this screen’s “OnCreateHandler” property to automatically trigger the button each time the screen is rendered. That will slowly build up enough of a browser history that the user will get bored before the back button does anything! Finally, hide the button as the user doesn’t need to see it. You could, of course, also add this to other screens if you wish.

I wonder if a “standard” way of dealing with this could be provided in a future version of Personas 1? And Personas 2 if it doesn’t already handle this properly. Until then, this does sort of work. If anyone has a better solution to the browser back button problem, do please add a comment!

To report this post you need to login first.

5 Comments

You must be Logged on to comment or reply to a post.

    1. Steve Rumsby Post author

      Thanks. I haven’t tested this on all browsers and all platforms yet. My own machine is a Mac, so testing on IE happens last 🙂

      As it happens, I think my organisation has just rolled out IE10 so I may be safe. In any case, if it doesn’t work I’m no worse off!

      If you happen to know of a better way to deal with this, do please share…

      (0) 
  1. Simon Kemp

    Hi Steve,

    Can you control the browser to open in full screen mode, thereby showing no buttons at all?

    Just a thought, sort of like a kiosk mode.

    Cheers

    Simon

    (0) 
  2. Tom Van Doorslaer

    Hi Steve,

    Persona’s being a silverlight app, shouldn’t be an issue, as it still has to run inside of a web-page. So my guess is that SAP forgot to add some functionality there. If that web-page (landing page) were HTML5, with internal navigation to either the systems page, or the silverlight embedding page, than there would be no history behind the back-button to mess with in the first place.

    Perhaps you can solve this yourself by creating a simple HTML5 webpage that embeds either the systems page, or the silverlight app? (https://persona.internal/#systems and https://persona.internal/#gui )

    Just thinking out loud though… I might be on the wrong track

    (0) 
  3. Hristo Hadjihristev

    Hello Steve,

    thanks for sharing your ideas. We recently had the same issue. One possible solution/walkaround could be also to create a seperate shortcut for the Internet Explorer and add the following text to the shortcut target:

    -k http://<host&gt;:<port>/sap/bc/bsp/persos/mainapp/index.html

    This provides the user a single point of entry for Screen Personas and the look and feel is more like a SAP GUI because all functionalities of the IE are hidden.

    Regards

    Hristo

    (0) 

Leave a Reply