Mobile Web Junkie

Scrollbars are a pain on web and they are even more of a pain on mobile.

If you’ve ever had to develop a website that does anything imaginative with it’s width then you will have encountered the inclusive / exclusive discrepancy amongst browsers. For example, should your page length exceed the vertical size of a browser window, a vertical scrollbar appears – trouble is some browsers feel the need to subtract the width of the scrollbar from the width of the page – causing horizontal scroll on the page.Of course, on a mobile phone you can’t change the size of your viewport but because every phone can be different problems arise when trying to create a mobile website that works across all devices. Because mobile devices tend to lack the JavaScript support that we all enjoy in big web browsers and therefore it is not simply a case of denying the bars so that everything works.

Wapple Canvas allows you to build mobile websites in a ‘build-once / publish-many’ manner. The Exhibit engine takes care of making the site work across all devices.

Until Wapple solved the problem scrollbars had been a problem – in fact they remain a problem for those not using Wapple. In the past, to get a consistent look across all devices (as in no horizontal scroll), we suggested to customers that they never size graphics to 100% width. We advised that they change the graphic width to 97% (a feature within Canvas that allows complete control of all graphic sizes on a site) so that devices never experience horizontal scroll. The trouble was that on the ‘better devices’ sites ended up with some blank space on the right.

We decided that this was simply not good enough. So we put a stack of effort into sorting this out once and for all.

Over the course of a week we implemented a new Browser singleton. Previously we had been using our Device object to perform a lot of screen related functionality. Separating it into a Browser class means that we can separate the logic for browser screen decisions from the values that need to be based on the actual device sizes.

Upon instantiation, the Browser class deconstructs the screen into viewport and scrollbar values. These are stored in both pixels and percentages. Everything stems from here.

From then on, all screen calculations are handled by this class. Older phones usually have quite large scrollbar widths. Newer devices often overlay the scrollbar onto the screen when necessary. These phone have a determined scrollbar size of zero, creating 100% viewport, 0% scrollbars in the process.

From then on it’s the same calculations working on every device to handle the screen every time it is required.

We have also put on a few min-height things. This keeps things tidy on certain devices.

Obviously, this new system is optional to our users. A site built with 97% width graphics should not have it turned on until sizes have been adjusted accordingly. Otherwise, graphics will be 97% of a viewport width, which might be 95% of the screen. Easily adjusted, though so no worries.

I think that this week we’ll probably roll this out as an option to Architect users.

Of course in order to do any of the clever stuff above you’d need a dyanamic and intelligent mobile browser and device handling system like Exhibit there in the first place. The conversations we had on this topic have lead us to discuss some very interesting community-based tools. More of that to come in the future…

Related posts:

1. IE6 Must Die, Mobile Browsers Must Live
2. Designing and Developing for Mobile Web
3. Importance of Single Domains for Web and Mobile
4. ready.mobi – You Can’t Handle The Truth!
5. Coding for Mobile Web – Automatically Adapting to Every Device and Browser