Friday, April 9, 2010

iPad Apps and Adding Value

My alma mater (which is also the university where I work) just released an iPad application for its student newspaper, the Optimist.

Of course, the folks at my university (myself included) are excited about this product, and about the chance to explore what publications can do on a tablet device like the iPad. But a few voices (including those of my friend and critic @chrylis, and MediaPost writer Steve Smith), pulled me from my personal revelry long enough to ask an important question: Why choose to make a native iPad app when one could make a mobile-optimized website instead?

In his critique of the iPad and its apps, Steve notes several apps (particularly, apps of publications) that provide more limited content compared to their online counterparts and fail to make up for that limitation through seamless navigation or personalization. @chrylis questions the utility of an app that runs only on one device, as opposed to a mobile website that would run on many.

They're right.

No new product (including mobile applications) is worth buying (or selling) if it doesn't add some value above the products that are already available.

If a new product does the same thing as something else on the market without doing it better, or more easily, or more conveniently, or less expensively, or with greater access, or with more satisfaction, then it has missed its mark as a new product that meets consumers' needs.

If an iPad app looks like its online counterpart, but with less content, more restricted navigation, less ubiquity, and no additional not-available-via-web features, then the web version will prove more useful to both iPad-users and non-iPad-users.

Steve Smith recommends two ways of differentiating iPad apps from their web versions: personalization and navigation. I would add a third: communication.

Personalization would enable an iPad user to configure an app based on their personal preferences. Maybe this means pulling in information specifically relevant to the user's interests. Maybe it means adjusting viewer settings to fit the user's lifestyle. Maybe it means reconfiguring navigation so that the viewer's favorite features are the easiest ones to access.

Navigation on the iPad should work intuitively, should flow gracefully, and should access data simply. Maybe this means simplifying the menu to just a few categories. Maybe it means reducing visual clutter. Maybe it means letting users customize the menu to their own preferences. Maybe it means expanding or hiding extra content with just a touch. Maybe it means taking advantage of two axes for scrolling "deep" into a topic versus "wide" across topics. Maybe it means a visually-logical arrangement of information, instead of only lists.

Communication should enable iPad users to easily share comments, connect apps with social media, and integrate information from various sources. Maybe this means allowing activity on an app to update a user's status on their social networks (as desired). Maybe it means that comments made in an iPad app would show up on web versions as well. Maybe it means that users can collect articles from various apps into a centralized database, so that users can bookmark pieces of information, cross-link them, and add their own notes.

As Steve Smith pointed out with current examples of successful iPad apps, the personalization and navigation pieces are already being achieved by several app makers. I suspect that the communication piece will require additional development and exploration, perhaps even in the capabilities of the iPad SDK. Regardless, these value-adds must be part of an iPad app if the app is to be more useful than a mobile-optimized website.

With your own products, whether mobile or not, are you adding value for your customers? Or can their needs be met just as well (or better) with another item on the market?

1 comment:

  1. In addition to the issues Steve presents, it's worth noting that all of the features I've seen advertised for these site-specific apps could be just as well implemented using RSS. Gizmodo, for instance, has long published tagged feeds where readers could subscribe to such complex feeds as "all mobile gadget news except Apple products".

    What most of these apps boil down to is a massive duplication of effort. There's no reason, for example, to maintain two separate comment mechanisms; the mobile-friendly version of many sites is simply a lighter skin on the regular comment feed. Additionally, issues like preferred navigation techniques are what software developers call "cross-cutting concerns": They come into play on every site, not just a specific one, and are thus more efficiently and more usefully solved in a generic reader that can apply the user's preferences to every news source.

    There's a reason that the AOL model, while never dying out completely, has been far surpassed by the Web. Walled-garden content both wastes developer effort reinventing the wheel and forces users to wait on the publisher's pleasure to add or fix features.

    ReplyDelete