Daily Archives: December 10, 2010

How the iPad Is Influencing Web Apps?

Source: http://yhoo.it/gkvsaC

Google officially unveiled its Chrome Web Store yesterday, and with it, a veritable treasure trove of highly optimized web apps that use technologies like JavaScript and HTML5 to create optimized experiences that blur the lines between web and desktop apps.

We’ve already profiled some of those apps, most of which work on any modern browser, not just Google Chrome.

A few months ago, we talked about how the iPad is transforming web design. We dubbed this phenomenon the "iPadification of the web." As much as the iPad has had an influence on web design, its influence over this next wave of web applications is even more apparent.

Looking through the Google Web Store, we couldn’t help but notice the similarities — in some cases perfect facsimiles — that some of these apps share with their iPad counterparts or with the general trend of iPad apps and iPad websites. Let’s look at some examples.

1. USA Today
The USA Today app [iTunes link] for the iPad is extremely well done. It offers a reading experience that is really optimized for the size of the iPad’s screen, is touch friendly and has built-in social sharing features.

The new optimus.usatoday.com) is a near carbon copy of the iPad app. In fact, we feel confident in saying that save for a few iPad-specific optimizations (mostly dealing with navigation), this is the iPad app.

That’s not a bad thing by any stretch; we think this offers a superior reading and browsing experience over the standard USA Today website.

2. NPR
Another news app that has significantly borrowed from its iPad counterpart is NPR for Chrome.

We’re big fans of the NPR apps for iPhone and iPad, and we’re adding its Chrome app, which is also accessible in other browsers at npr.org/webapp, to our list.

The HTML5 framework SproutCore was used to create an earlier demo of the NPR app, and we feel certain elements of that exercise have been used in the new web version.

Not only is the interface extremely usable and attractive, it creates a consistent experience between platforms.

3. Flixster
The flixster.rottentomatoes.com) very much mirrors the layout of its iPad app.

Consider the lack of scrollbar on the left column — this scrolls independently of the main column, just as it does on the iPad app.

The buttons and navigation points on the two implementations do have some differences. The iPad app uses the bottom of the screen (which is common parlance in iPad UI design); the web app uses the top.

The web app also has a fixed width of just under 1,000 pixels. In landscape mode, the iPad is 1024×768. To be fair, the resolution on many netbooks is 1024×600, but we still find it interesting that the elements were designed for such a fixed size.

4. Amazon Windowshop
The windowshop.com, but that doesn’t mean that as a web app, it isn’t impressive.

The app matches the layout of its iPad counterpart perfectly.

The only difference — and this is significant — is that a scroll control has been added to the lower right of the web app, enabling users to scroll up, down, left and right within the app or the various sections.

To us, this makes it clear that the app was designed first and foremost for touch, and then adapted for the mouse and keyboard.

5. Weather Underground
The chrome.wunderground.com) is not the same as the Weather Underground app for the iPad.

However, the Chrome app, which offers a very attractive way to view and search for weather conditions, does share some striking similarities with some other iPad weather apps.

For example, Weather HD [iTunes link] takes a very similar approach to showcasing weather conditions. Weather HD uses animated images (something Weather Underground might want to consider aping) and can also show hourly conditions, but the overall layout of the two apps is similar.

6.Blurring the Lines Between HTML5 and Native Apps
Google’s official line might be that Android is for tablets and Chrome OS is for netbooks, but in practice, it looks like more and more web developers are designing their web apps with the tablet form factor and features, like multi-touch, in mind.
And why not? As we can see from the above examples, many iPad apps are in large part, just HTML5 apps, inside a wrapper. Sure, there are some benefits to creating a native app for platforms like iOS or Android — even if that app is largely just built using HTML5 — but the fact that HTML5 and JavaScript are becoming the building blocks for these kinds of applications means that porting them to other platforms or devices is significantly less challenging.

Last week, the Netflix engineers blogged about the company’s decision to use HTML5 in many of its new apps.

Clearly, many other companies are also seeing these benefits. We think that design cues from the iPad and future Android tablets will continue to influence web design and development in the traditional web browser.

The true convergence of these types of devices — the desktop and the tablet — might still be a few years off, but users will start to see similar user interfaces, application experiences and features across their various computing platforms.

Chrome Web Store: a solution in search of a problem?

Source: http://bit.ly/feHDhO

Google launched its Chrome Web Store yesterday alongside its announcement of the Chrome OS pilot program. Google seems to think that the modern Web, which is increasingly capable of delivering desktop-like application experiences, needs an application delivery channel, even though there is nothing to actually deliver—except URLs.

The way that users consume applications in the desktop and mobile world is fundamentally different than they way that they do it on the Web—where paywalls are often reviled and there is little distinction between content and software. In such an environment, does the application store model make any sense? We are not convinced.

A lot of commercial websites use ad-based business models or take a freemium approach, offering a baseline set of functionality for free and allowing users to get more by paying recurring annual fees. Google wants to open the door for more conventional single-payment purchases, allowing Web developers and content producers to sell their material on the Web the same way that they do it on cell phones.

When you want to deliver a native mobile application to a smartphone user, there are a lot of advantages to using an application store. You have a seamless vehicle for deploying your software and subsequent updates, obviating the need for your user to download and install a package. It gives you basic analytics tools for measuring the number of users. It also makes billing painless by avoiding the need for individual users to thumb-type in their credit card number.

It’s not clear, however, if having a standardized retail channel is as unambiguously advantageous in the context of a desktop browser. There is no actual software to deliver and no updates to manage and roll out. You don’t need a store for analytics because you are tracking the traffic to your actual website. All the store does is handle billing and add a glorified bookmark to the user’s browser. The billing problem has already been solved on the Web a hundred times over. You can use PayPal or any other similar mechanism (unless you are Wikileaks) and it won’t be a significant deterrent to sales.

As the company behind the Android Market, Google has a first-hand view of the mobile application gold rush. It’s not surprising that the search giant wants to try to adapt that model to work in the browser, but we’re not convinced that the Chrome Web Store’s support for conventional billing will somehow encourage native application developers to start porting their software to the Web. The ability to erect a simple pay wall in front of your Web application so that you can charge a few dollars for access just isn’t all that novel or compelling.

If a Web app is easily accessible and offers some functionality for free, it can more easily build an audience. The way people consume software on the Web is by clicking through a link and deciding if the destination has value. There is no overhead in doing that. A user can put a query into a search engine to find Web destinations meet a certain need and then open half a dozen in browser tabs and pick the one that looks the best. It’s not like a mobile environment where the overhead of having to download and install an application gives users a reason to read customer reviews and refer to top app lists.

Google’s approach to enabling commercial Chrome apps might be a bit more interesting if Google were to offer really robust micro-transaction services that application developers could integrate into their actual software (Google’s recent acquisition of Jambool is an interesting development in this space), but even that could be offered as part of Google Checkout and doesn’t really rationalize building a whole marketplace.

The only really compelling use case of the Chrome Web Store as a commercial distribution channel is to snag some impulse purchases of Web-based games. EA appears to be enthusiastic about that opportunity and has partnered with Google to get its free "Poppit" balloon game included as part of Chrome 9 (we would make a joke about Chrome OS getting its very own crapware, but it’s probably just a link like every other "installed" application).

Aside from gaming, the idea of an application store in a Web browser—where installation is little more than bookmarking—seems counterintuitive and leaves us with the impression that the entire exercise is a solution in search of a problem. The Web itself is already a great way to deliver content and services–arguably one of its greatest strengths. We see no reason to drag the conventional app store paradigm into a medium where it just doesn’t fit.