Twitter App Sets Browsers Back 10 Versions

Screen shot of a web page as seen in the Twitter app, with a menu showing the option to open in the user's default web browser.

The title of this post may be a bit of hyperbole for some, but it is completely true for me.

Sometime over the course of the last week Twitter changed what happens when I tap links in the native Twitter app on Android. Links now open within an embedded browser, not in my default browser.

I have Chrome 40 installed on my Android phone. The built-in web view on my phone is 10 releases back, at Chrome 30. Normally this isn't a concern of mine, but when a good deal of my Twitter timeline consists of bleeding edge web development techniques, I want to view those on a current release of Chrome.

The first image shows that the user agent string within the Twitter app includes Chrome 30. The second image shows my default browser user agent string is Chrome 40.

This change appeared while I was traveling internationally, which means I had a slower connection than usual as well as a data cap. Not only do I have to view content in an old browser, I have to know that the web view is older so that I then know to open it in my default browser.

That's at least two more taps, plus the burden of the download starting in the web view that I don't want. That extra download burden also impacts my data cap, which is an even bigger issue if I have chosen to surf with Opera Mini to make the most of my limited data cap (you know, data budgeting).

Not only did I never enable this feature, I cannot disable it. It appeared three weeks after my last Twitter app update (see the caption below).

The first image shows the settings screen in the Android Twitter app, version 5.48.0. You can see there is no option to disable the in-app browser, though it has been enabled. The second image is the note in the Google Play store that tells me the only change in the new release is updated profiles so it's easier to view bios, Tweets and photos. The final image shows the option to disable the in-app browser, but only because I updated to version 5.51.0 (when I returned from home and shed my data cap).

So What?

A couple months ago Peter-Paul Koch wrote about the massive fragmentation in the world of Chrome (Chrome continues to fall apart at brisk pace), something to which Twitter is now contributing en masse.

In the modern world of rapidly updating browsers, 10 releases may not seem like a big deal. I guess it comes down to what you want to see, or more importantly, what you want your users to see. Can I Use provides a quick way to compare Chrome 30 and Chrome 40 to see which features you may be missing. Here's a short list:

• The ability to discard many -webkit- prefixes,
• Font unicode-range subsetting,
• matches() DOM method,
• CSS touch-action property,
• CSS Font Loading,
• Custom Elements,
• picture element,
• Web Cryptography,
• WOFF 2.0 - Web Open Font Format.

If you rely on any of these (or many other) features of the open web platform, and you receive traffic from Twitter, I suggest you monitor your logs to see if the most common version of Chrome drops.

As for user experience, If you plan to allow users to toggle a new "feature," don't push that feature to them without the toggle. Especially when you exclude it from your update notes within the app store.

Announcing My Ring Warmer App

Animation showing the Ring Warmer in action.

If you have to wear a ring, then perhaps you have experienced the discomfort of putting a cold ring on your finger (maybe in the morning in a cold house). I decided that I could do something about that using the only tool in the modern developer's toolbox — the smartphone app.

I'm kicking off the new year by announcing that my Ring Warmer app is done. Well, it's a web app. Actually, it's just a web page. Living as nothing more than a block of code at CodePen. Regardless, I started this in late 2012 and then mostly forgot about it, so I'm thrilled to call it done.

The opening image is an animated GIF that shows how one might use the Ring Warmer app. I've also embedded the same animation as an Instagram video (or view it directly on Instagram):

My ring warmer app is finally ready for release.

A video posted by Adrian R (@aardrian) on Jan 1, 2015 at 9:23am PST

The idea here is that you can choose a ring size and a warmth level, place your ring in the designated spot, and wait patiently for it to work its magic.

The idea is, of course, absurd.

In the strictest sense, it can work. At the lowest setting (warm), only the red LEDs will light up, carrying one-third of the total heat a pixel can produce. As you move to the highest setting (hottest), all the LEDs are lit to generate white, so each pixel is producing its maximum heat as the red, green, and blue LEDs are all lit.

Of course, the amount of heat this carries is negligible. You will transfer more heat to the ring from the warming battery than from the pixels. The ring itself might not get very warm unless you also fire up the radio antenna (I left that feature out as a courtesy).

Now that I've gotten as much pranking out of this fake app as possible, I figured I'd at least write it up a bit.

Very simply, I use a border radius with some box shadows to make the glowing ring. Then I drop the white glowing dot (using box shadows and border radius) onto one edge and rotate the entire thing in perpetuity. It's a mess of mixed sizing units, questionable animation syntax, and useless elements.

Then I made a form so you can change the ring size and the temperature. The ring size isn't matched to any real measurements, except in Chrome on my Samsung Galaxy S4 the default size matches my ring. All sizing after that is based on ems, so it doesn't scale like a real ring. The temperature change is nothing more than colors with CSS transitions and some JavaScript that sets explicit styles instead of classes. In other words, it's a terrible idea to copy this code.

Regardless, here's the pen in action:

See the Pen Ring effects by Adrian Roselli (@aardrian) on CodePen.

This will not be available in any app store. You can load the pen in full screen view to trick your friends if you are that bored.

Google Needs to Provide Android App Interstitial Alternative

Yesterday Matt Cutts from Google tweeted that Google search results for users on smartphones may be adjusted based on the kinds of errors a web site produces (of course I was excited):

Important: if your website has smartphone errors, we may change rankings for smartphone users: goo.gl/x8R4A #smx

— Matt Cutts (@mattcutts) June 11, 2013

Matt links to a page that outlines two examples of errors that might trigger this downgrade of a site's position in the Google search results and, right in the first paragraph, links to Google's own common mistakes page:

As part of our efforts to improve the mobile web, we published our recommendations and the most common configuration mistakes.

I think it's fair to assume that anything listed on the "Common mistakes in smartphone sites" page can negatively impact your site ranking. In particular this section on app download interstitials caught my eye:

Many webmasters promote their site's apps to their web visitors. There are many implementations to do this, some of which may cause indexing issues of smartphone-optimized content and others that may be too disruptive to the visitor's usage of the site.

Based on these various considerations, we recommend using a simple banner to promote your app inline with the page's content. This banner can be implemented using:

• The native browser and operating system support such as Smart App Banners for Safari on iOS6.
• An HTML image, similar to a typical small advert, that links to the correct app store for download.

I think it's good that Google links to the Apple article. I think it's unfortunate that Google does not link to Microsoft's own solution. If you read my blog regularly, or just follow me on Twitter, you may know that I covered both Apple's and Microsoft's app banner solution in January in the post "App Store Meta Tags."

You might also note that I stated that Google Play offers no such feature. Google, the force behind Android and the one now (or soon) penalizing sites in its search engine for app interstitials, provides no corresponding alternate solution of its own.

A great thing that Google could do for its Android users, for its search engine results, and for app developers, is to support a custom meta tag that allows web sites to promote their own Android apps in the Play store. Developers can start to replace awful Android app interstitials on web sites, users can get a cleaner experience, and site owners who can't conceive of other ways to promote their apps on their home pages can move toward something that is easier to maintain and doesn't penalize them.

I think it's nice that Google is paying attention to web devs by adjusting search results, but my ranty tweets are probably falling on deaf ears. The web would be indebted to someone who can get Google's and Android's ear on this.

App Store Meta Tags

Why yes, Dominos, I'd love to tap again to get your real home page to order a pizza when I could have done it right here, below your over-sized app pitch that could be done in a tiny ribbon.

This may be old news to some of you, but I haven't found a place that collects this in one spot.

One of the most offensive experience I have when surfing a site on my mobile devices is being forced to click through an advertisement for the site's app in the iTunes store (even moreso when I am surfing on a non-iOS device). There is a fair number of sites I have tapped away from because of this (I also don't expect to be served the page I came to see, but instead shunted to the mobile home page).

If yours is one of those sites, whether promoting your entire user experience or just a product, there is a less offensive way to present your pitch to users on iOS and Windows Phone.

iOS 6

Safari on iOS 6 and later devices can promote your app with a standardized banner. Essentially you stuff a custom meta tag into your page that references your App Store ID. If the user already has the app installed, then the ad becomes a launcher instead.

The code is pretty simple:

<meta name="apple-itunes-app" content="app-id=myAppStoreID, affiliate-data=myAffiliateData, app-argument=myURL">

• app-id is required and references your app's identifier.
• affiliate-data is optional and uses your iTunes affiliate string.
• app-argument is also optional and can allow users who have your app installed to jump to a specific place in your app.

More details at Apple's developer site: Promoting Apps with Smart App Banners

Windows 8

Microsoft offers a similar feature for users of Windows 8 in non-desktop mode who are also using Internet Explorer. I have not tried it, so I cannot explain how this works as the user changes modes nor how it works with the "charms" feature of Windows 8.

This code is relatively simple as well, though it requires two meta tags and supports up to five:

<meta name="msApplication-ID"content="microsoft.build.App"/>
<meta name="msApplication-PackageFamilyName"content="microsoft.build_8wekyb3d8bbwe"/>

• msApplication-ID is required and references your app's identifier.
• msApplication-PackageFamilyName is required and contains the package family name created by Visual Studio.
• msApplication-Arguments is optional and lets you pass arguments to your app.
• msApplication-MinVersion is optional and can direct users with an old version to the Windows Store.
• msApplication-OptOut< is optional and allows pages to opt out of installing the app, switching to the app, or both./li>

More details at Microsoft Developer Network: Connect your website to your Windows Store app (Windows)

Google Play, BlackBerry App World, Etc.

In addition to Google Play, BlackBerry App World, I looked for similar features for the Firefox OS and Ubuntu Mobile stores. I know there are other mobile platforms out there for which I did not look.

If you know of other apps tores that offer similar features, please let me know so I can update this post.

Related

There are other places where custom meta tags are used to display targeted content. One example is used for Twitter Cards and another example is used with Google News. While you can build support for them, neither Twitter nor Google is going to use them unless you have been vetted in advance.

Updated: January 29, 2013

I wrote a version of this post with an example at the Algonquin Studios blog. I'm pasting the example in here...

Real-World Example

One of our spin-off companies, SWRemote, has an app available for iPads. There is value in promoting the app to visitors of the site but not in blocking their access to the site content with a splash page or an extra click, especially if they are not on iPads. The SWRemote web site is powered by QuantumCMS (yes, I am promoting our web content management system), which makes it about 30 seconds of effort to add the necessary meta tag to the site.

Screen shot of the QuantumCMS custom meta tag screen.

If you are already a client of ours on QuantumCMS, all you have to do is choose Site Configuration from the Settings menu and pop into the Marketing tab. This is the screen that allows you to add custom meta tags. Press the Advanced button and you are off to the races. In the Name field, for this example, I just entered “apple-itunes-app” and in the Content field I provided the custom ID for the app appended to “app-id=.” As soon as I hit Save the web site was showing the app bar to visitors:

Screen shots of the SWRemote site on an iPad3 both with the app installed and without it installed, showing how the bar changes its message.

Oddly, even though the app runs on the iPad Mini, which is running iOS6, the app bar never appeared on the site when viewed on the iPad Mini. On an iPhone 5, the app bar started to appear and then disappeared — probably as the device recognized that there is no iPhone version of the app.

If/when there is an app available for Windows Phone, the process to add this feature will be the same, allowing the site to promote both apps dependent on the audience. QuantumCMS helps make the process easier, with no need to code any changes to your site templates.

Update, March 8, 2013

What he said:

I think "Download our app!" is the new "Skip intro…"

— Jeffrey Veen (@veen) March 8, 2013

Update, April 24, 2013

There is a recap of recent rants over at .net Magazine in the article "Devs rally against mobile web doorslams."

Update: June 12, 2013

Google has just announced that it may penalize sites that promote apps with those awful interstitials. Yet Google offers no solution (as you see above) for Android apps through the Google Play store. You can get more detail in my post "Google Needs to Provide Android App Interstitial Alternative."

Update: March 11, 2014

I told you above that you needed to get the app identifier and package family name to make the Windows app banner, but I neglected to tell you where to get that information. Some kind soul over at Adobe's forums provided instructions.

Update: August 31, 2014

I keep forgetting to link this: jQuery Smart Banner, which uses jQuery to stuff a Smart-Banner-like feature into your site for old iOS versions, Android and Windows. I have not tried, so I can offer no feedback on whether it works well (or at all).

iPad Retina Display Concerns and Tips

TL;DR

The iPad 3 retina display means a lot of apps and web sites are going to feel pressure for sharper (bigger) images. Knowing if you need to scale your images, the impact on end users and some ways to mitigate that impact is the right way to approach this.

What's All the Fuss?

With the announcement of the new iPad's "retina display," there has been quite a lot of buzz among web developers about what that means for graphics. Some are welcoming the change by diving right into their projects and kicking up the size of their images, and some are lamenting the ongoing unabated bloat of web pages and apps since images can quadruple in size.

If you don't believe Apple sees the potential for apps to grow in size, earlier this month it raised the cellular network download limit in the App Store from 20MB to 50MB. While there are many arguments on why Apple might have done this, knowing that the image assets for any app may bloat in size by four times when targeting the new display provides a rather compelling reason on its own.

David Sleight points this out in his post A Retina Display Reckoning for Magazine Publishers, using magazine page sizes as an example of the problem scaled-up images could produce:

The screen volume may have quadrupled, but the new iPad still ships with the same three memory options: 16, 32, and 64GB. As I noted on Twitter, the growth rate of the potential payload size just outgrew the growth rate of device storage exponentially.

Apple also understands that images on the web will grow in size to target the iPad 3. The method Apple employs to deliver these images is not only inefficient, if web developers user Apple's code as a baseline then all the sites they build will affect their users. From a post last week, How Apple.com will serve retina images to new iPads, Jason Grigsby outlines just what happens to the end user:

As far as I can tell, there is no attempt to prevent duplicate downloads of images. New iPad users are going to download both a full desktop size image and a retina version as well. […] The total size of the page goes from 502.90K to 2.13MB when the retina versions of images are downloaded.

This doesn't even account for the HTTP requests for the original images, the HTTP requests for the high resolution images, and the HTTP request to test if there is even a high resolution image to retrieve. All of this is wrapped in a browser detection script, something at which a seasoned coder may wince.

Josh Clark points out in his post 3.1 Million Pixels Are Heavy that responsive design is still a method-in-progress and that using techniques like Apple does to serve high resolution images can push down far more than a user needs:

Sending a full-screen iPad image (1536x2048) to an iPod Touch browser (320x480) is overkill to the tune of 25 times the file size. Over a wireless connection, that's gonna smart.

Peter-Paul Koch takes this a step further in his article The iPad 3 and Moore’s Law, where he talks about the impact that larger images will have on network speeds and ultimately user experience. Citing an example of an app that will bloat from 18.3MB to ~35MB, he brings the file size discussion to its logical conclusion:

Thus the Retina display puts incredible extra strain on the already-strained mobile web. Retina may be great for the end user, but the data networks simply cannot handle it (yet).

A common response to the scaling of images involves reliance on SVG images. Because SVG images are vector files, meaning the elements of the image are defined as scalable shapes instead of columns and rows of pixels, they can be sized up or down and still maintain the same file size and not lose any information. For images that are not photographic this sounds like a good workaround when targeting iPads only, regardless of SVG support in other browsers.

As anyone who has worked with vector imagery may know, however, vector images typically don't scale in ways that maintain the goal of the image. If you look at the icons on your computer and explore all the sizes, you may notice some elements change shape, relative size, or are even discarded altogether. The article About those vector icons by Kirill Grouchnikov demonstrates this in detail with some great examples. He also has a well-supported conclusion:

So no, SVG is definitely not the answer. At least not today.

The SVG solution is the common comment response to Brad Frosts' post iPad3′s Retina Display Will Wreak Havoc on the Web. As you read through the comments it's easy to see why I stress about the return of the browser monoculture, this time iPhone and iPad rather than IE6, as I wrote about a couple weeks ago (The Return of “Best Viewed in…”). Sadly, from that entire assault of comments pushing SVG or suggesting users just accept the bloat, only three comments even thought to mention responsive images, something the W3C is working to address now in a dedicated responsive images community group.

How to Adapt

I haven't reviewed all this to disparage the new retina display on the iPad 3. Instead an informed developer takes into account the pros and cons of every scenario and makes informed decisions that balance the needs of the user with the practicality of development efforts.

If you build stand-alone apps for the iPad, then you'll need to make many decisions about the images you use and whether or not they all need to be updated. You may find that getting the right icon size can be a bit tricky though, and Louie Mantia was kind enough to put together this iOS app icon template.

As for web development, a few posts have started to pop up that echo the same ideas good developers have used for years — evaluate the need, weigh the solutions, don't get too caught up in the bleeding edge. Here is a distilled list from the post iPad 3 and Retina Screen: What it means for your mobile commerce site:

1. Prioritize important images;
2. Make text into text;
3. Boost button sizes;
4. Make the logo bigger.

Brad Frost offers some tips in his post Optimizing Web Experiences for High Resolution Screens:

1. Media queries (that sadly still lean on vendor prefixes);
2. SVG, with a link to browser compatibility tables;
3. @font-face to put icon typefaces to use;
4. Detect network speed (its own special kind of train wreck);
5. Get involved with the W3C Responsive Image Community Group;
6. Don't forget some basic best practices:
   • Start with low resolution images first;
   • Make sure you optimize your images;
   • Use CSS3 for corners, gradients, etc.;
   • Use resolution-independent options;
   • Detect the network (when you can);
   • Know your browser compatibility.

My simplest tip on all this is to look at the logs for the web site in question and see if enough users come in on iPads to warrant the stress at this point.

Related

• Case study: Tweetbot for iPad from ImageOptim showing some impressive manual optimization tricks.
• Is the New iPad Screen Too Good for the Web? from The New York Times, because your clients may be reading it.

Color Has a Gray Pallor

Color is the newest social media application on the block, launched just after SxSW and relying on proximity-based media sharing instead of a friend model. Founded by names from other successful ventures along with $41 million in funding, Color seemed poised to storm the social media market.

One day after its launch, Color Labs, Inc. released an update to the Color app. Originally launched to support a 100 foot radius to find people for sharing, its new update was released to adjust that radius on the fly based on nearby activity. Considering the app is essentially useless without others who participate, this update is necessary to gain users (and necessary given it missed a great geek-dense SxSW event). When you read the opening statement in the product description in the Apple App Store and Android Marketplace, you can see that this need for others using the app nearby isn't exactly a surprise for Color:

WARNING: DON'T USE COLOR ALONE.

With so little activity visible to a user, users might look to the interface to provide some clues to using the app. After all, knowing if you are even using it correctly can manage your expectations one way or the other. Once installed, the app immediately asks for your first name, then prompts you for a photo of yourself, and then drops you right into its interface with some inexplicable icons (notwithstanding the tiny "Next" text-link-like buttons that move you along in the process). With no activity, it's hard to know what those icons do. This company-provided screen shot shows the app with its confounding icons in an ideally-active stream of content:

You might be motivated to look for a help screen in the application, but you'll have no luck. You might even be motivated to go to the Color web site to look for a tutorial or some form of documentation, but no luck. It turns out that there is a demo video available on Vimeo, but Color doesn't even link it from the site — you have to find it somewhere in the copious industry press coverage, which is something the typical user won't be doing.

When the Color Labs CEO says that the company is much more of a research company and a data mining company than a photo sharing site, it seems fair to question if the technology led the product rather than a tangible business model taking the lead. Given Color's reception so far, that seems like it may very well be the case.

In the Apple App Store product page for Color, the highest rated review of the product is really a parody, comparing it to a puzzle game (images of the full description):

You conquered Myst. You understood the end of Lost. You can do this! You're not going to let this new adventure game genre get the best of you! You will master this if it takes all weekend. You discover a button to create a group! You wonder what a group is. Progress, of sorts.

Given how easy it is to spoof GPS locations on a phone, even though the Color Labs CEO says that Color doesn't rely on GPS, it's a matter of time before a method to spoof locations is widespread. Let's not forget that Color is essentially anonymous, too, requiring no validation beyond location. It won't be long before you can expect to see Color turn into nothing more than a spam outlet or Chatroulette variant. I can assure you, I would not be letting my children (non-existent though they may be) install this app on their phones.

Related

• Color's Ambitious Photo App Seeks to Reinvent Mobile Social Networking
• Color CEO: The Tech Justifies the $41 Million
• Color to Get Major Update, Fix 'Loneliness' Problem
• PR Case Study: Where Color Went Wrong
• Color: Is it just the latest useless social media app?
• GPS check-ins taking off

Don't Choose Between Mobile Web and Mobile Apps

When Adobe released InDesign it included a novel feature that was otherwise unheard of to the average agency — the ability to import content into its page templates from XML data. Having developed a web content management system (QuantumCMS for those of you interested in hiring us), we had selected XML as an output option for content, allowing us to deliver that content into any medium that could support XML (such as web pages via XSLT). The idea we proposed to our agency clients was simple: author your content in one place, one data store, and push it out to the web, print, and other media.

None of them got it. Fear of the technology and comfort with an existing platform made it impossible for them to step back and evaluate whether there was a good business case in play. This approach (or lack thereof) is not limited to agencies. Unskilled web developers spent years building text-only versions of sites, feeling terribly proud of themselves when they realized they could wrap different templates around the same content instead of maintaining duplicate sites. Even now in 2011 I still see web developers take advantage of clients by selling the text-only site as an add-on service.

We're in the same place in the world of mobile. Organizations and developers (clients and vendors) are struggling with the right way to deploy their products to the masses (customers, end users). For reasons perhaps grounded in technology assumptions (preferences, fears, lack of understanding) they tend to look at two options for mobile — apps and web. Assuming that there are only two options is the first mistake they make.

With the recent marketing push over HTML5, CSS3, new APIs (such as geolocation) coupled with the most compliant browsers we've seen in years appearing on mobile in far greater percentages than desktop, we have a viable platform on which to develop web-based experiences that are functional and effective. The idea that a developer can develop one web-based application and deploy to the web, to iPhone, Android, Palm, Blackberry and Windows Mobile devices should be a compelling reason to consider that a starting point.

There are many things, however, that we cannot yet do via the web, such as access your mobile phone's camera, or take advantage of more robust touch-based interfaces. These are features best utilized directly through the mobile device, ideally via its API.

It is possible to develop an app for a mobile phone that is nothing more than an embedded web browser (by instantiating the default browser) along with elements that access the phone's hardware features. You risk the loss of a more robust user interface for your web-based content, but you gain the benefit of developing simpler apps for each platform while retaining control over your core service and content in your own hosted environment.

With the new payment models that are shaking out in the mobile apps market, the web-first approach might be a more appropriate way to build your business model. Given the uproar over Apple's recent requirement that subscription-based app developers offer subscription options through the Apple app store (and at no cheaper on their own sites), in exchange for a hefty 30% cut, relying on the mobile device itself to deliver your content becomes a suddenly more costly solution. Instead, just having a mobile-friendly site can be sufficient to handle sign-ins and subscriptions, which also carries over to other devices (iPad, Android) and platforms (desktop, tablets).

Certainly not everything can be deployed via the web. A music service, for example, is tough to do even with excellent support for the unfinished HTML5 audio element. But looking at a web-first or hybrid approach allows you to reduce your development and deployment costs as you support fewer platforms, and share your content with nearly any web-enabled device.

Related

• The False Dichotomy of Native vs. Web Apps
• How HTML5 Is Aiding in Cross-Platform Development
• Is Developing a Mobile App Worth the Cost?

Posts on this blog that help lay some of the groundwork of these thoughts.

• W3C Starts Mobile Web App Standards Roadmap
• Apps Are Not Killing the Web
• W3C Releases Mobile Web App Best Practices
• Targeting the Mobile Web
• Current(ish) Smartphone Use
• More on Hover vs. Touch
• UX Challenges in Touch Interfaces (at evolt.org)
• Luke Wroblewski on Mobile First

There is so much content out there about the Apple app store rules that, while I had planned to write post about it on my own, I felt that adding to the noise wouldn't help. Instead here are some of the links I cultivated for the post I never wrote.

• Apple’s Big Subscription Bet: Brilliant, Brazen, Or Batsh*t Crazy?
• Apple new subscription rules now upsetting developers, too
• Readability’s App Store Rejection Portends a Cloudy Future For Developer
• An Open Letter to Apple
• Opinion: Apple's subscription policy is a poisoned Apple
• Why you should fight Apple’s Subscription Extortion

Update: March 11, 2011

If you read An Open Letter to Apple from Readability, then you know that it submitted an app to the Apple App Store that was in limbo. The issue came down to the Readability business model (70% of subscriptions to writers) bumping up with Apple's new store rules (30% to Apple). Even though Readability already had a mobile version of the site, on Wednesday Readability released updated apps for multiple devices that are really just wrappers for web content. In the end, this can bypass the Apple App Store if Readability can deploy it all via the web, removing the need to use an in-app purchase that pushes 30% directly to Apple. Yesterday ZDNet covered this in the article Readability goes HTML 5 on iOS, expect others to follow, where I think you can see others are starting to see the viability of the business and technology model, partly spurred by Apple's new pricing model.

W3C Starts Mobile Web App Standards Roadmap

The W3C has taken a step toward gathering all the information relevant to the mobile web, as authored by its disparate working groups, under one umbrella as a singular (recurring) reference source: Standards for Web Applications on Mobile: February 2011 current state and roadmap (read the accompanying W3C blog post).

You may recall when the W3C released its Mobile Web Application Best Practices "cards" with tips and techniques for web developers diving into mobile. You may also recall that it was very focused on mobile and didn't address how those best practices are handled via the standard desktop browser (such as the tel: URI scheme).

This, however, promises to be a bit different. Instead of being pushed out by the W3C monolithic entity, one person has made the effort to take on this responsibility and clearly state that he can't possibly get it all right all the time:

...[T]he data in this report have not received wide-review and should be used with caution. Feedback on every aspect of this document should be sent to the author (dom@w3.org) and will serve as input for the next iteration of the document.

The document outlines a series of categories of technologies that apply to the web, including the relevant technology for each. These categories are:

• Graphics, which includes SVG, CSS, WOFF and other acronymns.
• Multimedia, such as audio and video.
• Forms, including the new input types and attributes like pattern and placeholder.
• User interactions such as touch and speech events and even a vibration API (no specs, just working groups).
• Data storage such as the different file APIs and local vs. web storage.
• Sensors and hardware integration which will lean on the geolocation API and eventually APIs for using your phone's camera and microphone.
• Network, which covers XMLHTTPRequest (level 1 and 2) and the WebSocket API.
• Communication using the messaging API to allow SMS and emails from web apps.
• Packaging, consisting of HTML5's ApplicationCache and W3C Widgets.
• Performance & Optimization such as the Mobile Web Application Best Practices along with support timing and threading.

Each of these items includes a table that outlines the appropriate specification, working group, maturity, stability, draft status, current implementations and test suites — if any — for each feature.

When it's all gathered in one place for us to review, it's a pretty compelling list of features in the pipe, even if we all know it will be quite some time before most of them shake out. I look at this roadmap as more than just a reference source, but as a path to shedding the costs and limitations imposed by building custom apps for each device (iOS, Android, desktop, television, etc).

Related

• Apps Are Not Killing the Web

Apps Are Not Killing the Web

Forrester Research is an oft-cited source by businesses when making decisions or declarations about trends and technologies. In many circles Forrester is something of a de facto standard for analysis. As such I fully expect to start dealing with a recent statement from its CEO claiming that the web is dead when I sit down to talk with clients.

On Thursday morning at the DeSilva + Phillips Media Dealmakers Summit, George F. Colony, CEO of Forrester Research was on a panel discussing the future of media in light of tablets and e-readers. Expanding on an answer to a question he fielded, Colony said, We think the Web is dead.

When he says we, he means the folks at Forrester. Back in October another Forrester staffer was quoted as writing that the golden age of the Web is coming to an end. This was in an article by The New York Times covering the hub-bub about Wired Magazine's over-hyped death of the web article. Wired's article relied heavily, but not totally, on a graph showing the decline of the web as we know it, but Boing Boing quickly refactored that graph with a more accurate visualization using the same numbers. You might recall that I wrote up my own response to Wired's argument in my post Enough about the Death of the Web

In May of 2009 Forrester also claimed that the smartphone was dead. To be fair, the full title of the study was The Smartphone Is Dead: Long Live Smart Phones and Smart Gadgets, showing that Forrester didn't really think the concept of the smart phone was dead, but that it was no longer worth breaking into its own category given the ubiquity of capable phones and devices. That may very well be the logic the Forrester CEO was using in his comments, although I don't think so.

The web is not dying (again). If anything, the advent of tablet and tablet-like devices coupled with support for HTML5 and CSS3 (really just CSS3) in the browsers that are coming on those devices (Webkit-powered Safari and Chrome on iPads, iPhones, and Android devices) is going to ensure that the web will be around for quite a while longer. The Webkit engine (along with the mobile version of Opera that many are grabbing) does a good job of supporting the newest still-in-development standards, creating opportunities for far more interactivity and style than could be achieved in browsers targeting just CSS2.

Angry Birds is a great example of an app that you cannot replicate as easily in HTML/CSS, if at all. But so many other apps are geared toward media, such as eReaders and photo sharing utilities, that delivering much of that content through a browser is a more cost-effective approach. For example, an app like Picplz has to be built separately for both iPhone and Android devices in order to use the cameras built into each. The method you use to browse your photo, profile, and the photos of others, however, is delivered through an embedded browser. This allows the app developers to focus on the features unique to each device while the universal elements are maintained back on their web server, removing the need to push an updated app to users for each minor tweak.

Soon we can expect that an app delivering content of any sort will really be a wrapper for a web browser, handling just the interaction with the hardware and operating system that is necessary for things like user validation, preferences, and so on. This will reduce the cost of app development as the heavy lifting is done via the web server and CSS3 (HTML5 if you've bought into the hype). You can expect to see RIM and Microsoft move to catch up by deploying more capable browsers to lower the bar for app developers to deploy to Blackberry and Windows Mobile devices. This closes the gap in available apps for each device, making them more appealing to more users.

This approach also supports users who don't have these new devices, allowing your typical desktop user with a capable browser to access the same content, even if he/she uses a mouse instead of a finger. A good example of this is the Marvel Comics comic book reader for Chrome. Originally built for the iPad, and supporting a swipe interface, viewing it in Chrome gives you a similar experience but with clicks instead of a more tactile experience.

The new model is build it once, deploy it across the web and your apps. Except it's not a new model. It just makes sense.

As I was wrapping up this post I stumbled across this article from The Nieman Journalism Lab, The Newsonomics of apps and HTML5. I think that, even though it takes a different path, it comes to similar conclusions as I do.

Update: February 10, 2011

Go read Robert Scoble's take on the new HP TouchPad. If he's right and it takes off, building web-based apps seems that much more like a good idea now, doesn't it? Supporting compiled apps for each of iOS, Android, WinMo, RIM and WebOS seems far less compelling to me.

Update: February 11, 2011

John Dowdell explains the concepts a bit more succinctly over at his Adobe blog: Blends of native and global. It's pretty much the same argument I make — some bits will have to be developed to run on the device, some bits can be best delivered via the web. Automatically excluding either of those options isn't a sound business or technical decision.

Ning Apps Launch

Ning has announced today on their blog that Ning Apps have launched.

We use the Ning platform to run the Ride for Roswell community site (RideConnect) and for the QuantumCMS forum (QuantumCMS is Algonquin Studios' web content management system, for which I am responsible, so go sign up with us). Having access to 90+ applications should prove useful to these sites. Sadly, I can't offer much commentary on them since they just launched today. The complete list of Ning Apps is available at the Ning Apps Directory.

Ning has set up a sample site for the apps at ningapps.ning.com so users can try them out.