Your Browser Broke My Webapp

Readying to embark on my first highly JavaScript driven official project, I have been looking for answers to problems I have always had. I want to make this app user proof. One of the problems of single page JS driven “Chubby/Husky/Thick”(take your pick) apps is that most of them are developed without taking the rest of the browser into consideration. I have see many postings about the ‘browser causing problems with their web apps’. Huh? The forward and backward buttons are said to break ‘Ajax’ applications. Isn’t it called a ‘browser’? It is ment to allow you to navigate documents. I read suggestions to ‘build your own back and forward buttons to keep the user from using the ones in the browser’… again, what? I plead with all developers, do the research. Although there is that ‘error’ part in ‘trial-and-error’ programming. Usability studies as well as real world examples prove that duplicating controls for similar but not the same functionality cause user confusion. This post and many others. suggested giving web pages the ability to disable back and forward. I shudder to think of the irritating things that would lead to. Being truly trapped on some advertisement that makes you blush. It is clear that at over 20,000,000 hits on Google there are alot of people thinking about it. I read about an interesting hack today that raises a good question, which I will rephrase.

Why fight the browser?

Do you really want to work against the environment your application was designed to run? There are better ways. Like programmatically placing entries in the history of the browser. A good library for incorperating in your tool box is Really Simple History (Tutorial here). There is also proper use of cookies. Also ASP.NET has an interesting way of handleing it in the form of the state string. When not abused, this is an interesting way of handling things. The sad fact of the matter is that more often than not, it is abused. It though, does not directly handle the problem of bookmarks, which may be another subject. Also, there is discussion of a out there on W3C for discussion. There is an eventual need for the browser to be fully aware of what JavaScript is doing. Maybe it should even save some sort of dom history. IMHO unlimited DOM undo would be my eventual choice, but we will see.

So lets step back for a minute. As programmers we know what is easy. We know what is logical from an operation standpoint. But, what we need to ask ourselves is ‘What is logical to the user?’ I came across this post. This is the best question you can ask yourself. What has twenty-two years of programming taught me? It doesn’t matter what I think about how it should be done. The end product needs to have an interface that users will use. If users knew what programmers new and thought like them, they would just have a bunch of databases out there and a black shell window for a desktop, forever typing in INSERT and UPDATE commands and telnetting from BBS to BBS. Sound like 1989?

So, I am sure someone will have something to say about this, but people see back and forward as undo and redo. Also when you close an application that has unsaved data, it should ask you if you want to save. Granted, not every click or keystroke needs an undo history, but there should be certain actions that a user should be able to undo. But, now, if we are using the back and forward buttons alone for this function, the user may not always logically seek them out for that function.

For those users who have been conditioned to the ways of the JS application, we can offer them what they perceive as additional functionality. That is undo and redo buttons. Hold your email, I do understand this is like what I said to begin with, two sets of buttons that do the same thing. The difference here is that the buttons do not look the same. This way we are seemingly adding a hook to the back and forward events and piping them to undo and redo. The user will think themselves clever if they figure this out. Yet another bonus.

So lets put this into perspective. How would this play out in the real world. Say a user is in your shopping cart. They click on an item thumbnail to see the details on that item. Then they decide to place that item in their shopping basket, and they click ‘add to cart’ or drag the thumbnail to their cart. Then they decide they don’t want it in the cart. What do they do but hit the back button. Your application recognizes this and asks ‘Are you sure you want to remove xxx from your shopping basket?’ They say yes, and then the user wants to see the list like it was before they clicked on the thumbnail, and they click back again, and the details are closed. All without reloading the whole page.

Does this not seem natural? Actually, it may not to a conditioned web user. But that brings us back to what would happen if an unknowing user did hit back? Until the browsers give us some native way of dealing with this, we have to choose.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s