There are many don'ts in web business. One of them is 'do not ignore the browser'. Browsers are getting better and people are becoming more selective. The statistics below show that people are not happy with the default browser of their operating systems. Otherwise browsers like Chrome and Firefox wouldn't have such market shares although they are not default browsers of most used operating systems.
Source: StatCounter Global Stats – Operating System Market Share
There are some basic functions that are supported by most of the widespread browsers:
Web apps working like state machines have the problem that one user session matches to one state. Think of a travel planning site with following steps:
- choose the departure and destination cities, the number of adults and children, the dates and search for available flights and hotels
- choose the flight
- choose the hotel
- provide passenger details
- provide payment details
The browser application retrieves (or fetches) code, usually written in HTML (HyperText Markup Language) and other computer languages, from a web server. Then, it interprets this code and displays it as a web page for you to view. In most cases, user interaction is needed to tell the browser what website or specific web page you want to see. The good news is that troubleshooting browser problems isn't too difficult—the process is similar for a lot of the issues you're going to come across.
Each step may be implemented as a web page. It is not possible to use tabs, if one session has exactly one state. For example you cannot choose different flights in different tabs and compare the details.
The site may offer a comparison function. However this would only be a replacement for a browser functionality. People want to use the tools they know. The more invisible the tool is, the better experience the user has. A new tool as a replacement for a known one will be eye-catching in a negative sense.
The problem is, each tab holds a URL. If you work in the first tab, you advance to the next state. That makes the state in the second tab invalid, since the server thinks, you are seeing the next state of the application.
The same problem holds true for navigation buttons and bookmarks as well. You cannot bookmark the second state of the page if states are not persisted. The solution to the problem is to persist the states.
Safari browser online, free. Cookies can be used to persist the state, however the bookmarks are then not shareable, since they will only work in the one browser holding the cookie. Persisting the state on the server-side introduces complexity. If navigation buttons are to be supported, every single state of the application has to be stored on the server. This means storage and an intelligent mechanism that will clear the unused states.
The most elegant solution is to persist the state in the URL. Let's look at the URLs generated by the use-case above:
It is not a good idea to store payment details anywhere.
No storage in the browser, no storage on the server. The whole state information is kept in the URL. User can work with several tabs, bookmark each step, can use navigation buttons, can even share each step of the application with her friends.
Back and forward buttons are supported by this technique, because the browser keeps a list of URLs and each URL tells the server, which state is to be shown to the user.
There is one extra benefit that this strategy delivers. Since the server does not need to store anything about the user session, the requests can be handled by any server. No need for sticky sessions. The application can scale very easily by just adding new server instances.
In the usecase above, the site may also offer one ajax-heavy page, where the next step will be loaded as a block via ajax, when the current step is done. Since all previous states are on the same page, the user may do corrections without leaving the page.
There is no tab problem in this case, since there is only one page. But what if the user wants to compare different flight&hotel options? What if the user right-clicks the select flight button to open the next state in a new tab?
Bookmarking and sharing are also hindered, since the only URL to the page points to the very first state of the application, to the initial state.
HTLM5 has an answer to this problem: pushState. You can change the URL displayed in the browser through JavaScript without reloading the page:
The page below shows which browsers support that feature:
For older browsers you can use location.hash. Since the manipulations are made after # sign of the URL, the page will not reload.
Imagine reading an article on your smartphone when travelling from work to home. When you arrive home, you want to continue reading that article on your desktop. Some modern browsers do this automatically for you. You have a URL open in your mobile browser, you will see the same URL on your desktop if you are signed into the browser. Also this feature is based on the fact that each resource can be located by a URL. Unfortunately that feature doesn't work with many modern web sites today. It does not even work with youtube.
Visit the following link with your mobile browser:
Don T Be A Browser Meme
If you visit that link with Chrome on your MAC, you will still see the mobile version of the page and will not hear anything (may be a bug?).
Users want to see the same content, but in a suitable way for the devices they are using. If someone sends me a mobile version of an article and I try to open the link on my desktop computer, I want to see the desktop version of the article.
One common mistake done by many web developers are to forward the user to a landing page suitable for the device they are using. The article is lost. You have to search for it in the version of the site that is suitable for the device you are using.
The reason is, there are two different versions of the site that has nothing to do with each other except sharing the same datasource. That's the simplest solution, however it ignores almost every feature of modern web browsers. Links are only partially bookmark-able, since they can only be opened on the device, where they were bookmarked. That's also true for sharing and synchronization of browsers where the same user is logged in.
One solution is to maintain one site supporting many devices. That site will have only one version of a page that layouts itself according to the user's devices. That's where responsive design play a big role.
Another solution would be to provide two different sites with intelligent routing algorithms. Each URL points to a resource (text, image etc.). Each resource will have n URLs (n = # of devices supported). Each of these URLs will lead to the same resource, however in a different form that is suitable for one device. For example an article about 'modern Browsers' may have following URLs:
You need some kind of filter that analyzes each incoming requests (e.g. a ServletFilter). The filter is responsible for translating URL of one resource to another URL of the same resource. The filter should follow the steps below to decide, how to route the request:
Don T Be A Browser Song
- urlDevice = for which device is the URL meant for (e.g. for mobile if it starts with http://mobile.*)
- userDevice = extract device from http request headers
- if urlDevice userDevice => do nothing
- forward the user to another URL of the same resource that supports the user's device
