The shifting definition of the Web browser | PandoDaily

By Nathaniel Mott
On December 31, 2012

The Web comes in all shapes and sizes. Designers and developers are tasked with building sites capable of shifting from 3-inch smartphone displays to 92-inch (yes, really) ?smart? television sets and everywhere in between. Yet supporting an ever-expanding array of screen sizes is only half the battle. Developers also have to account for all kinds of Web browsers ? and there are more of them than you might think.

Most people probably think of Safari, Google Chrome, or Internet Explorer when they think ?Web browser.? (Assuming they know what a browser is in the first place, that is.) But a quick look at the home screen of any device can show that there are browsers hidden everywhere. Your Twitter client probably has a built-in browser. So does your read-later app, the Facebook app, your RSS reader, your social reading app, and so on. Browsers are everywhere, and they don?t always work as we might think.

First, why all of these apps have embedded browsers in the first place: They want users to stay within that app. This means that users are sticking with an app instead of bouncing around to a dedicated browser every time they want to view something that doesn?t reside in that particular app?s data silo, keeping the developer happy ? who doesn?t want their app to be used? ? and saving the user from having to constantly ?shift gears.?

Twitterrific, a Windows Phone -styled Twitter client for the iPhone and iPad, offers a prime example. One might expect that the iPad app?s embedded browser would use the entire screen, but it doesn?t. Users are instead treated to a cut-off view that uses maybe half of the iPad?s screen when held like a magazine. Suddenly the tablet-specific view doesn?t seem so appealing, as the aspect ratio and size are much different than designers probably anticipated.

This sizing problem is common across other embedded browsers, though not to the same extent. Tumblr?s iPhone app shows just a few more pixels on each Web page than Safari for iPhone, for example, while Google Chrome for iOS shows more than either. These differences are slight but noticeable, and go a long way towards making a Web page feel ?cramped? or just-right.

Then there are browsers that just don?t want to cooperate with websites. Prismatic, a social reading app, doesn?t play well with Quartz, the Atlantic?s global business website, for example. Quartz displays a ?this site uses technologies which aren?t supported by your browser? error every time I try to read an article in Prismatic, severely cramping the app?s ?read whatever interests you? style.

But, then, battling with technological differences between browsers isn?t anything new. It isn?t enough to build a site that displays properly in Google Chrome or Safari, which both use WebKit as a base ? the site needs to work in Internet Explorer, Firefox, and, to a lesser degree, Opera. Sites need to work for anyone who visits ? falling short of that, they need to work for as many people who visit as possible, and that means supporting the little niggles inherent with every major platform.

So, what?s the solution? Well, in all honesty, there probably isn?t one ? developers and designers have had to work with the limitations imposed by browser makers? whims for years now, and that doesn?t show any sign of changing. Some form of improved multi-tasking in iOS, which treats every app as a separate entity from the Web and other installed applications, might help a bit, but it?s far from a silver bullet.

Mobile didn?t just lead to the proliferation of different screen sizes. It also started to blur the line between what an ?app? and a ?browser? is, allowing developers to create their own little looking glasses, their own windows into the Web. While this is appealing to both users and developers for the reasons outlined above, it?s also a pain in the ass for developers. Which raises the question of whether or not we?ll ever truly have a uniform, completely optimized view of the Web.

Probably not.

[Image via getonfast.com]

Nathaniel Mott

Nathaniel Mott is a staff writer for PandoDaily, covering startups and technology from New York.

Source: http://pandodaily.com/2012/12/31/the-shifting-definition-of-the-web-browser/

george huguely whitney houston casket photo match play championship the national enquirer marie colvin cm punk cm punk