June 2011 Archives

Isn't life like a bank? Don't we get everything at the moment when we prove that we don't need it at all?

Or it's the bank like life?...

Some people see the Mr. Cynical as "spitting on the world's paradigms with pointless negativity", some not. The ones that will laugh, will most likely understand and positively change.

or

or

or

So just laugh and enjoy!

Theory, fail 1, fail 2 => so now the current (good?) solution. To get to it, I didn't had to develop a new idea, but I had to escape the old idea that the best thing to do for a mobile devices is to send the images in the native screen resolution. This is still true for the older handsets, but not any more for the new age of smart-phones.

It's enough to put following tags to the HTML header:

<meta name="viewport" content="width=640, user-scalable=yes"/>
<meta name="HandheldFriendly" content="true"/>
<meta name="MobileOptimized" content="640"/>

and then just optimize the page for 640px width. This works awesome good for recent devices with recent browsers, or in general the browsers that supports the viewport meta tag. Both image and font-size will be adapted to the screen size and the page will look similar on iPhone 3 or 4, iPad, Android 2.x, new MS phones and Opera browser.

So at $work we will still support the old devices that needs image resizing, for the other companies that doesn't have time, budget or an interest, it might be enough to target the recent smart-phones via 640px optimized pages with a proper viewport tag.

After the theory, first wrong solution, here comes the second wrong solution. It's easier one and the JavaScript is used only for iPhone-s where it was also tested. The problem with iPhone 3 and 4 is that both hardware versions are using the same OS and because of that the same user-agent string. So there is no way of knowing which resolution does the device have when the HTTP request comes to the server.

Following two meta viewport tags works fine for all phones besides the iPhone. The first one is when scaling should be disabled, the other when enabled.

<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=1.0, user-scalable=no, target-densitydpi=device-dpi"/>
<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=3.0, user-scalable=yes, target-densitydpi=device-dpi"/>

To get the native resolution for the iPhone 4 I had to create a JavaScript that detects 320px vs 640px resolution, sets the cookie and makes a refresh while setting the url parameter so that it also works when cookies are disabled. Then our server-side code has to resize the images properly and update the "width=640" in the viewport meta tag. Still a little complex, right? But works! :-)

Now what are the problems.The fonts can get pretty small as iPhone 4 applies the 0.5 scale and the Androids with high resolution uses the high-densitydpi. And it doesn't work so well for Opera too.

Here is the JavaScript code (much less lines then the previous one):

The part1 described some troubles with the screen sizes of the mobile devices. Since then I spend some time playing around with the problem and I found 2 wrong solutions until I got the (hopefully) right one. So let's start with the first of the wrong ones.

The solution relies on the fact that we have the device screen width and height in our DMS (Device-Management-System) database and this is compared with the real width of the device using JavaScript, then if there is a difference a cookie is set and via this cookie our Renedering-Engine on the web server is instructed to resize the images using the zoom level. It requires refresh, lot of "junk" in the HTML header and all the "machinery" on the server side. But the images are properly fit even for Opera browser that has the same user-agent string for different devices with different screen sizes.

See the code below, it's a nice example of a working-complex-bad solution :-)

First time that I've tried to use "#" instead of "?" for url parameters was on the CPAN2Deb page. No page reloads needed everything handled by JavaScript. Yesterday I've tried that same, but for search.youonl.com. How does it work? Every time a new search is made the location bar is updated without a need for page reload. This is fast (the browser makes no unnecessary request to the web server) and it allows easy bookmarking or copy&pasting of the current search configuration.

Here are some examples:

• http://search.youonl.com/en/#s=gw;q=axiology (Google+Wikipedia search for Axiology)
• http://search.youonl.com/en/#s=gg;l=ende;q=axiology (Google+Google search for "Axiology" in English and German)
• http://search.youonl.com/de/#s=yo;l=deen;q=wien%20besuchen%20tips (Yahoo+WolframAlpha in German + English for "wien besuchen tips")
• http://search.youonl.com/sk/#s=ww;l=ende;q=Rak%C3%BAsko-Uhorsko (phrase in Slovak language showing English and German Wikipedia article for "Rakúsko-Uhorsko")
• http://search.youonl.com/en/#s=gt;q=learn%20juggle (Google + Helper tags for "learn juggle")

The ";" vs "&" for separating the arguments is good because "&" needs to be escaped in HTML while ";" can be simply copy&pasted directly.

One side effect of switching from "?" to "#" for the url arguments is much more privacy for the clients as the requests with arguments are not passing to the server, so there will be no user queries in the server logs any more. search.youonl.com still uses Google Analytics for statistics, but the search queries are shared exclusively between the client (web browser) and the search engines that he uses.

And last, but note least, is that fewer requests to the web server means less processing and data transfers.