One of the more notable critiques of WPtouch (well not just WPtouch, but any website formatted for the iPhone/iPod touch) is that mobileSafari does a great job of showing websites the way they are regularly, so why bother tailoring sites for the devices?

There were a number of considerations we grappled with when creating WPtouch, and this was of course one of them. The whole impetus for WPtouch was based upon our usage of iPhones and iPod touches, and the sense that in some cases, something like what we’ve created would be more appealing/desireable for visitors than visiting some websites as they are now. It was not just a concept which we thought cool- it was an approach to WordPress on the iPhone and iPod touch which we thought would not just help with viewing on the devices but actually enhance it.

So let me rifle off a few things we thought about while developing WPtouch. In short, there were three considerations we looked at which gave rise to the need for something like WPtouch: speed/size of webpages & load times, accessibly on a touch-based interface, and providing the visitor with the option to choose how they’d like to view the site.

JS Molasses

Firstly, if a website regularly employs oodles of javascript then it will likely load slow on the iPhone. The meager processor on the iPhone/iPod touch can’t get through the JS as fast as if the site was aware of the device’s limitations and served up a more digestible version. This is especially noticable over EDGE connections.

Zoom And Gloom

Secondly, all the zooming in/out isn’t for everyone, and getting to the content you want isn’t as friendly as it is wowing.

All The Same Features, Half The Fat!

Thirdly, you can format a blog (like we have with WPtouch) in a unique way that tailors the site for this specific device (touch interface) without being tacky and without taking away any of a blog’s features (pages, comments, search, categories, tags etc). The iPhone/touch is plenty capable of handling some javascript, but using it smartly, tastefully, and appropriately will yield a much better browsing experience.

One of the drawbacks of using a plugin like ContentRobot’s iWphone, is that you can’t switch between the custom mobile view and the site’s regular view. We’ve developed WPtouch such that visitors can choose between the WPtouch view and a site’s regular view, providing the end user with a choice.

As website designers/developers, we often run into situations where the capabilities of one browser differ from another’s, as each major browser freely available today (Internet Explorer, Firefox, Opera, Safari) offers both support for commonly accepted web standards (for the most part) and also has proprietary features which enable advanced functions. For some web projects, the employment of different CSS declarations is necessary to bring about the most similar user experience across browsers and platforms. In other cases enhancements upon proprietary features are available to users of a particular browser and not others (as is the case with matthewgood.org).

In the case of WPtouch, we wanted it to perform like an enhancement on a WordPress-based website which visitors had the option to use or not, and was specifically designed for mobile Safari. This way it’s not a forced decision on the part of the website host to re-format content in the WPtouch way, but rather offer it as an option to the end-user visiting on one of Apple’s popular devices.

For some websites, using WPtouch makes no sense or is not necessary- for others, it’s the perfect compliment and actually adds something to the website/blog. As with any WordPress plugin, it all depends on the needs of the owner whether or not a particular plugins’ functionality is needed.

WPtouch is no slight on mobileSafari, either… in fact it’s quite the contrary: without mobileSafari’s rich features, WPtouch wouldn’t be possible. Ironically it is mobileSafari’s capabilities that provide for WPtouch, not the opposite.