Backing out of a page with multiple entry points
-
On the site I'm working on, there's a page that has multiple entry points. You can click a link from the homepage, or arrive at it in the middle of another process, etc, etc.
Like most every page that gets designed around here, there needs to be a "Back/Cancel" button that takes the user back to where ever they came from. But the question is, what's the best non-WTF way of keeping track of where the user came from?
- history.go(-1) isn't much of an option, because the page can postback to itself several times before the user decides to hit "Back". (Though I haven't experimented with wrapping the page in an Update Panel)
- I am trying to get the developers here away from using the Querystring, otherwise every hyperlink in the system would be appended with &fromPage=Me, and there'd be copypasta condition all over the place with "If Querystring(fromPage) = "Me" then...", for every page in the system.
And confounding things, of course, is the fact that the users of the system most likely will bookmark the "landing" page. Where do you send them back to if there is no back? (Default.aspx sounds like a nice place)
Surely there must be some schools of thoughts or design patterns or something for what must be a solved problem? (As an aside, I catered my mother-in-law's wedding yesterday, so my google skills are currently offline. If this is a stupid question, a lmgtfy is an entirely appropriate response)
-
What back-end are you using? Edit: oh it looks like asp.net, from the URL you provided.
I think the standard method would be to keep their page history in their server-side session.
-
Yup, .Net, so I have all the nice Session.Transfer and Page.PreviousPage things to play around with.
-
I've run into this a lot over the years, and the best solution I've found is the "returnUrl" querystring parameter. If it's there, redirect to it -- otherwise, redirect to some default. You can make this a static helper method, too: void ReturnRedirect(string defaultUrl) { string url = HttpContext.Request.QueryString["returnUrl"]; if (string.IsNullOrEmpty(url) url = defaultUrl; HttpContext.Response.Redirect(url);}
There's nothing wrong with the querystring if you use it in a consistent manner.
-
You could you keep the URLs in a Stack object in the session. If the stack is empty, grey out the back button or change the text to "Home" or something and have it navigate to default.
-
frits' idea of the stack could be helpful if you clear it out after doing one of your redirects with it and you can use the multiple copies you will end up with in it to quickly get around having things show up more than once. The thing is it's kinda a hackish solution so it depends on if this is a internal setup so the business deciders don't have to think about something other than the businessy stuff they are doing or if it's a fancy customer facing solution. For the internal the hackish way is probably an OK balance of hackish to quick if you are set against query strings, but it's not something I'd want to support facing out to the wild.
-
@locallunatic said:
For the internal the hackish way is probably an OK balance of hackish to quick if you are set against query strings, but it's not something I'd want to support facing out to the wild.
Keep in mind that links are shared. I've seen more than a few web apps barf when someone copies a URL with a query string to their buddy in another country. If you're going to use query strings, make sure they work if the link gets shared, is what I'm saying. And make sure the sharee gets the correct experience. Personally, I'd try to avoid them if possible.
-
I would recommend using AJAX and letting the browser handle history. Using the query string is ugly and can get baked into bookmarks and using Session variables gets all weird when people do "Open in new tab/window". Supplementing this with a breadcrumb trail isn't a horrible idea. When a custom back button behaves strangely, it confuses people. Broken bread crumbs may look confusing, but they never behave badly.
Besides, web applications work best when you make them cooperate with the web browser rather than trying to fight the browser. It's sad how many web application break horribly when you hit the back button. For example, if you do all navigation with POSTs, the back button will always give the "report form data" message; saying no leaves a blank screen and yes re-navigates you to the current page.
-
@Jaime said:
Using the query string is ugly and can get baked into bookmarks and using Session variables gets all weird when people do "Open in new tab/window".
Also, saved tabs can cause big problems. I used a web contact form to contact a foreign graphics design company, after I was done with sending the message I left the page (showing a 'thanks for contacting us' message) on a tab in case I got no email response and needed to do it again.
Every day after that I got an email from a different rep at the company thanking me for my enquiry, I thought this was very weird after a couple of days especially as they had already started my work...but just assumed their whole sales department was drunk or something.
Eventually after a week I got a 'PLEASE TO BE NOT SENDING US ANY MORE QUOTATION REQUESTS!!!!' message from them.
After a bit of investigation, and vigorously denying abusing their contact form, I found it was being caused that little lonely tab I had forgotten about. Every morning when I started up Firefox it submitted the same damn message. Nice design there...
-
@Cursorkeys said:
After a bit of investigation, and vigorously denying abusing their contact form, I found it was being caused that little lonely tab I had forgotten about. Every morning when I started up Firefox it submitted the same damn message. Nice design there...
I had a woman on a dating site tell me to stop being a creeper and keep looking at her profile constantly. Turns out I'd left her profile open in a tab. For months on end.And yeah, pages that do data submission should NEVER render anything. Form.aspx=>Submit.aspx=>Thankyou.aspx where submit doesn't do anything except toss data across and redirect.
