We now take advantage of mobile handsets browser capabilities – if they support transparent PNGs, and you’ve uploaded one, we deliver it. And we’ve increased the quality of images that are delivered too, so if you have a good quality PNG at around 1000px wide, you’ll get some stunning results on your mobile site.

Of course, our powerful device profiler Wapple Exhibit makes sure that your huge 1000px image is displayed perfectly to scale on any handset and if a particular phone doesn’t support transparencies or PNGs in general, you’ll get the fallback of a JPG (if the phone supports it!) with your choice of background colour. It also ensures that these higher quality images are still minimal in size and load quickly over mobile phone networks.

Get started by logging into Wapple Canvas and upload some new graphics. Overlay some transparent images on top of another background image if you want, the choice is yours!

If you’re using Architect, integrate your better quality Canvas images by using a <graphicChunk> element and reference your new image. More information on how to do this can be found on our documentation site at http://wapl.info/coding-for-the-mobile-web-with-WAPL/chapter/Graphic-Chunk/.

Let us know what you think of this new feature and whether if you’d like to see any other improvements with graphics.

Some are updates to existing functionality, some are completely new. All of them are exciting and greatly improve your mobile browsing experience!

So without further ado, here’s the list.

Radios

We now support radio form items, so when building a form, head over to the Edit Form page and try adding a form item with a radio type.

Google Analytics

We’ve made some updates to our Google Analytics mobile integration. Previously we only supported the JavaScript version (and therefore not all phones), but as Google have updated their code, we have too so we can now deliver to all phones!

Google Verification

If you’re using Google webmaster tools, you have the option of placing a file in your web root to show you own the site. It’s usually named something like “google123456789.html”, and if you head over to the Analytics section of Canvas, you’ll see an option to enter your verification code and prove it’s your mobile site.

Bango Auto Country Identify

If you have Bango Auto Identify enabled, we can now use the country code they pass back to influence the country activation/suppression rules on your mobile site. Check out our Identification section inside of Canvas for Bango options or take a look at Bango for more details.

Try all of these new features out by logging in to Wapple Canvas. And if you haven’t got an account yet, sign up and create one!

There are plenty of other minor bug fixes, browser issues and other small feature requests we’ve added/fixed – if you want more details (or you’d like something added/changed), get in touch and we’ll be happy to talk you!

You can listen to the whole thing on Brian’s website at http://mobilebeyond.net/mobilizing-and-making-money-with-a-wordpress-blog-or-mobile-website/ or have a search on iTunes for MobileBeyond.

Lastly, I must say a big thank you to Brian for first of all giving me the opportunity to do the podcast, and secondly for doing such an awesome job of editing it together!

Let us know what you thought of the podcast – and if you’d like to hear more, tell us what subjects you’d like us to cover!

HTC Magic

Stop Press: The Google Android phone doesn’t support CSS.

Or so the UAProf supplied by HTC for the G1 would have you believe. We’ve got one in the office and have recently updated its browser software. Only the new user agent profile (an XML file detailing the phone capabilities) now says that it doesn’t support CSS.

The good news for users of Wapple is that the device profiling system at its heart knows that vendors sometimes make mistakes and takes that into account. Oh, and when HTC update their Uaprof so that it says it supports CSS, it’ll know and update as appropriate!

Obviously the Android supports CSS and everyone knows that (apart from HTC by the looks of it). This is a great example of how hard it is to do device profiling yourself and why it’s so awesome that you’ve got tools like Architect available to do it for you!

Without these systems in place you’d be looking at stripped down versions of sites with no style, but instead, you still get great looking Wapple powered mobile sites.

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…