TWDB Mobile 0.2 is GO!

I figure about half my readers are of the age group that will immediately recognize the obscure 60’s TV show reference I just made in the title of the post. I can be fairly sure of that because Google Analytics tells me that’s the percentage of my readers who are roughly within my generation, age-wise. Google tells me all sorts of vaguely interesting things and sometimes some very specifically interesting things such as the fact that towards the end of April, they’ll be modifying their search algorithms to quite heavily reward those websites that are specifically designed for mobile browsers with greater rankings in searches conducted on smartphones and tablets.

Admittedly, I tend to resist sweeping change in technology, (which is what the switch in main consumption of the web from Desktop browsers to Mobile browsers really is), but the straw has been placed and the writing is on the wall: little-bitty screens of indeterminate resolution that require navigation be in the form of big-fat, thumb-pressable buttons is the FUTURE and the NOW. This cat better hop on the train ‘afore it clears the platform, baby, and this cat ain’t anything if he ain’t agile – despite his love of obsolete tech.

Thus TWDB Mobile 0.1 got pooped out in a day, but it had problems stemming from certain “feature” of the jQuery Mobile framework. Namely, jQM intercepts HREFs in your markup and ajaxifies them *and* for some reason url_decodes the URI before sending it to the webserver. This “feature” renders url_encoded search terms in your URI *useless* because the whole point of url_encoding the URI is to keep the webserver from choking on special characters like “#”, “/” and “?” that are programmatically meaningful to the webserver’s URI parser. Gah, this meant that every model that had any of those characters in the “model name” field were just broken. There doesn’t seem to be any way around it except to do something ugly like base64_encode the search term so at least I’m sure there can’t be any URI-illegal characters in it and it can still be parsed back to the original term with base64_decode on the server side, but dayum – that results in URIs that aren’t even remotely human-readable or meaningful for SEO. ):

But I did it (and for anyone desperately searching for the cause and solution for this particular issue with jQuery Mobile, see above), so the 0.2 edition of TWDB Mobile is now relatively bug-free. I also added some color to the layout. And then I implemented some server-side browser sniffing to automagically re-route mobile browsers to the mobile site.

TWDB, now Googlebot-approved for mobile-friendliness!

I realize that this means users on mobile browsers can’t log in anymore to use the “Typewriter Hunter” features, but those are coming soon to the Mobile site, so have patience and use a desktop browser to do Hunter stuff for the time being. (: