I’ve posted before about the problem of AJAX tabs and how they leave an odious flavour of frustration in the mouth of your google search engine users (that’ll be pretty much everyone then).
It’s taken me a while to get round to writing a follow up post that solves this (no, not because I couldn’t come up with a solution) but actually because I’ve been too busy on other things, *honest*.
Now the first solution I intimated back when I wrote the post was to solve it all backend, by creating a degrading experience that loaded in content on the fly. Although this is a tangible solution, it does create the problem of having several pages that have a majority of the same content, so it would work but is not optimal and would cause more work on the search engine side.
I also realised a second problem with AJAX tabs, again which hampers their everyday practicality. The use case I was considering was what happens when your user manipulates an AJAX tab to change the content sees something interesting and then tries to send that to a friend?
The resultant behaviour in fact being that he copies, pastes and emails a URL which by default takes that other user to the vanilla page without the information the original user was viewing visible. Definitely not the desired outcome.
In order to solve the original problem of coming in from a search engine and not being able to see the correct content we take advantage of the document.referrer property, this allows us to see the url that the page was linked to from. So a typical google URL might look something like this:
http://www.google.co.uk/search?source=ig&hl=en&rlz=1G1GGLQ_ENUK317&=&q=Test content 3&btnG=Google+Search&meta=lr%3D
if we analyse the querystring we see it splits into the following parts:
source=ig hl=en rlz=1G1GGLQ_ENUK317& q=Test content 3 //! This is the search term btnG=Google+Search meta=lr%3D
now most of that is irrelevant but the q= parameter is the query of the search which is useful.
With this query data we can search the content of our tabs to see if that string exists in th hidden content, then if it does we dynamically switch the default tab to the one with the relevant content. Ta da, no more aggravated user engaging in invidious search activities to locate the content they had been promised by the search engine. To test this out you’ll need a google indexed page, fortunately I’ve hacked one to prove it works, just follow the link on the page.
For the second problem we take advantage of the html anchor hash within which to store data about which tabs are open at that precise moment. We replicate the query string syntax as it’s familiar and people should be able to understand it easily. The result of which means that whenever you click on a tab your query string updates to something like the following:
Dissecting the hash string we see:
the tabSelected tells us that smartTabs is on the page, the mainTab1 – is the ID of the tabs & the Tab 2 is the text inside the tab that was last selected.
Our script then traverses the tabs and selects the one that matches the one in the pseudo query hash string, displaying the content that the user was viewing at the time. An example of which can be seen here.
So although my code is far from perfect, it does provide a possible solution to these conundrums. My main hope is that people start to consider the wider reaching usability problems that they introduce when they creating these flashy widgets and all the different scenarios in which they can fail the user’s expectations.
In general the tab wars are long from over, I’ve yet to see a decent aria implementation for example, but at least smartTabs brings us one step closer.