Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 472

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 487

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 494

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-settings.php on line 530

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-includes/cache.php on line 103

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-includes/query.php on line 21

Deprecated: Assigning the return value of new by reference is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-includes/theme.php on line 623
blog.gkaindl.com » Reinventing the Web for the iPhone

blog.gkaindl.com

nerd nouveau

Reinventing the Web for the iPhone

Since the much-anticipated iPhone launch last month we’ve seen a lot of websites crop up that are specifically designed for Apple’s shiny new gadget. High-profile sites such as Digg.com or 37signals’ free Ta-Da List have gotten the iPhone treatment. Even Google (or one of their iPhone-wielding employees on their 20%-rule day) has been working on an iPhone-specific search interface. On the developer front, there are already some tips on how to create iPhone-optimized versions of WordPress themes, and the first CSS/Javascript frameworks to easily provide the iPhone experience have been released.

As many people have noted, this is quite interesting, since with the advent of web standards, designing specifically for certain browsers or serving different stylesheets to different browsers has been rather seen as something to avoid. Now suddenly, everybody is pumping out iPhone-specific sites.

To be honest, most of these efforts are very much in line with what Apple suggests in their “Web Development for iPhone” guide: Paying attention to web standards to ensure that the content is available to desktop browsers as well, but serving a specialized stylesheet for the iPhone.

Then again, David Storey has been critiquing the iPhone for not supporting media queries in which it would identify itself as “handheld”, causing other handheld internet devices not to profit from the streamlined design for the iPhone. Conversely, Opera has specifically introduced the “TV” media type when creating the Wii Browser, so that other browsers using a TV as their means of display could benefit from Wii-specific website designs as well.

Upon first noticing the trend for designing specifically for the iPhone (often basically reinventing the site, for example in the case of Digg, where the iPhone-version is a whole lot different from the desktop one), I tended to agree with the folks disliking the idea of creating a specific version just for the iPhone. I like standards, too, and generally dislike the idea of designing for a specific browser version, let alone for a specific browser version on a specific device. But the more I think about it, the more I understand the reasoning behind these efforts.

First, I understand why Apple refuses to let the iPhone support the “handheld” media query: After all, “handheld” internet has (unfortunately) often been associated with a watered-down, crappy version of the internet. The iPhone, on the other hand, wants to provide the “real” internet. I can see that Apple doesn’t want its iPhone to load a badly designed mobile version of a random website that has not been designed specifically for the iPhone’s advanced browser and high resolution screen. In that case, just displaying a scaled-down variant of the desktop version is preferable. Of course it would be nice if other handheld devices could benefit from websites that get a mobile version now because of the iPhone release, but the inverse case is more likely: That the iPhone would have suffered from badly designed, stripped-down mobile versions that are already out in the wild. Badly designed because almost nobody has used them until now.

Second, the iPhone is not a desktop. A website (and its user experience) can greatly benefit from a specific design when viewed on the iPhone. After all, there are many constraints such as screen-size and slow EDGE data rates that do not apply to desktop versions, but become relevant for the iPhone. Just swapping the stylesheet for an iPhone version is a convenient, simple and, most importantly, non-hacky way of providing for a better user experience on the device, without having to explicitly ask for a generic “handheld” variant. It may not seem to be elegant at the first glance because we quickly associate the serving of browser-specific stylesheets with Internet Explorer incompatibilities and the such, but in this case, it’s something else. It’s not just about different browsers, it’s not even only about different devices, it’s about different paradigms. The browsing experience on the iPhone differs so vastly from other devices in the context of its overall user experience that I think it’s perfectly warranted to provide a special website version for it.

Of course, we’ll have to wait a bit to see if this is just an short-lived fad fueled by Apple’s ingenious pre-launch hype (since the adoption rate isn’t as high yet as some analysts have predicted). The iPhone isn’t even available outside of the USA yet.

However, what remains true is that a unified, “standardized” version of a website, a piece of software or a generic interface is not always preferable over specialization. Browsing on a desktop with mouse and keyboard is different than browsing on a handheld device with a stylus. Browsing on the iPhone’s scalable, multi-touch controlled Safari version is different than browsing on an ordinary handheld that mostly mimics the desktop. So is browsing on the TV set with a Wii. The more ubiquitous web browsing will become, the more we have to distance ourselves from the “one site for all” idea that we’ve excitedly embraced with the advent of web standards. It’s not about being non-compliant with the standards, it’s about creating different experiences while adhering to the standards. And if we don’t want to resort to ugly hacks, there’s no better way than creating different stylesheets (or even whole front-ends) for different devices. After all, we want our users to access the same content on any device they wish, but we should not force them to adhere to the one usage paradigm that we prefer. Even if there’s already a “handheld” media type available, there are so many different ways a “handheld” device’s UI can be designed that this becomes an inappropriate generalization. There’s no way you can compare the low resolution, clunky Opera experience on a GPRS-enabled Razr with the iPhone, for example.

No matter how the iPhone will establish itself on the market in the long run, I think it has already started to give the mobile web a well-needed awareness boost. If more developers continue to create high-quality mobile versions of their sites for the iPhone, other mobile browsers will benefit in the long run, too. And who knows, if the most often crappy, generic mobile websites get replaced by well-crafted iPhone-specific versions, then Apple may very well decide to let the iPhone support the “handheld” media query in the future, or, even better, create a new one that other manufacturers could use, too, one that takes the iPhone’s multi-touch capabilities and high-resolution, scalable screen into account. Other manufacturers are going to copy that soon, so its own media type wouldn’t be useless. Otherwise, we can at least be assured that developers are concentrating more on the mobile experience from now on, and even if that means a specific iPhone version and another one for the rest of mobile internet devices, we can still hope that the latter will benefit from the quality boost as well. Maybe all it needs is a bit more awareness that some people actually use the mobile internet?

4 Comments

Comments are closed | Comments RSS

  1. Deprecated: Function ereg() is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-content/plugins/google-analyticator/google-analyticator.php on line 445
    Barry Welford
    wrote on Jul 25, 2007 at 23:27

    I really enjoyed this post, Georg. I guess that’s becaues I’ve been spouting the same view for some time. Instead of the One Web Principle, I’m pushing for the Multi-Web Practice. That was written when the iPhone was very much in the development stage, but I think it’s the only way to go if you follow your different paradigms notion.


  2. Deprecated: Function ereg() is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-content/plugins/google-analyticator/google-analyticator.php on line 445
    georg
    wrote on Jul 26, 2007 at 1:19

    Thanks, Barry. Yes, it’s interesting to see how much our views align with each other.

    I really like your description of different device classes, but I think it’s important to not only classify them by screen space and connection speed and bandwidth costs/constraints, but also by the applied usage paradigm. For example, on a PDA, we generally don’t have a mouse. Thusly, there is no constantly moving cursor on the screen. Instead, we only have discrete “click” events. But this, in turn, renders “rollover” events non-functioning on such devices because there is no such thing as a “rollover” when we only have discrete clicks. However, it’s easy to dig up some websites that make extensive use of “rollover” events, such as when expanding menus when the mouse rolls over a headline etc… All this does not work (or would feel awkward, since we don’t want to drag our finger or stylus over the screen like a mouse) on a handheld.

    Instead, the more diverse web-browsing devices become, the more we have to employ what you refer to as ‘Multi-Web Practice’, in order to create website front-ends that blend in well with the usage paradigm of each device, as well as its physical (and possibly economic) properties.


  3. Deprecated: Function ereg() is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-content/plugins/google-analyticator/google-analyticator.php on line 445
    Barry Welford
    wrote on Jul 26, 2007 at 4:14

    Indeed, Georg, we certainly are thinking along the same lines. Since I wrote some of that early ’stuff’, I’m including now the possibility that input might come either from voice commands or from barcodes via the camera. I’m sure the list will get even longer as time goes on.


  4. Deprecated: Function ereg() is deprecated in /nfs/c03/h01/mnt/52932/domains/retiredblog.gkaindl.com/html/wordpress/wp-content/plugins/google-analyticator/google-analyticator.php on line 445
    Fred
    wrote on Jul 26, 2007 at 15:57

    It looks alot like the Vista hype: too soon released and very unstable. I think I’ll wait for a year or so…

About

Hi, how are you? My name is Georg Kaindl, and I'm a twenty-something from Vienna, Austria. During the day, I'm a CS student at the Vienna University of Technology, but at night, I turn into an independent software developer for the Macintosh platform, social nerd, lazy entrepreneur and intuitive researcher.

I like to write about everything that matters to considerate technology enthusiasts, but humbly retain the right to go off-topic from time to time.

My posts are licensed under a Creative Commons Attribution 3.0 License.

Contact

You can reach me by email if you have something to say that's not related to a blog post or that you don't want to have publicly available as a comment to a post.

However, you'll have to prove that you are human! Even though I personally like robots very much, I'm less of fan of SPAM. It's just a simple riddle to solve, but a SPAM bot won't cut it!

To get my email address, take the word before the .com in my domain name first (Hint: The word you are looking for starts with a "g" and ends with an "l"). Next, simply attach @mac.com to this word.

Boom, there's my email address. Simple, isn't it?

Powered by WordPress

Comments RSS

Entries RSS