App Store Meta Tags

Screen shot of Dominos home page on Nexus 7.
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 is an adapted and updated version of a blog post on my site from last week. This post includes a real-world example of the feature.

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 experiences 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.

Platforms

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

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 app stores that offer similar features, please let me know so I can update this post.

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.
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:

Site on the iPad3 without the app installed. Site on the iPad3 with the app installed.
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.

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.

Advertisements

Letting Mobile Users See Desktop View of RWD Site

Originally posted on my blog on January 11, 2013.

Bruce Lawson tweeted out a seemingly random musing today that I have pondered myself — what if, while on a mobile device and surfing a RWD web site, I want the desktop version of a site?

There are many reasons as a user that this might be the case, ranging from poor development practices that hide chunks of content you need to see to just wanting to know what it looks like.

Clearly it’s enough of a use case that mobile browsers such as Opera Mobile, Chrome, Firefox, and so on, have a feature to request the “desktop” version of a site from a menu built into the browser.

Except that feature doesn’t work with a RWD-powered site because media queries, typically based on viewport width, are used to deliver styles for traditional desktop window sizes. The browser feature only sends a different user agent string (bypassing terrible user agent sniffing) but doesn’t do much else. Your 320-pixel-wide device is still 320 pixels wide, and the media queries know it.

Until the mobile browser makers report a false viewport (or, rather, assume one when choosing CSS from a set of media queries), we’re kind of stuck. While I have many ideas on how that might work, that won’t address the issue today.

While I had bandied about an idea to address this on the redesign of my site a couple years ago, it took a client request last year to get my team the time to finally code a solution.

There are some core steps the hammer out in the logic of any solution:

  1. Put a link on the page to view the desktop layout. I prefer to have it in the raw HTML over writing it in with script.
  2. In the more mobile-friendly CSS files allow this link to display. In the more desktop-friendly CSS files hide the link.
  3. Either using a round-trip to the server or client-side script, remove the media query logic and serve up the “desktop” CSS.
  4. Warning for Europeans: cookies. Set a cookie with that preference for the user. Whether it is for the current session, forever, or somewhere in between is worth an internal discussion.
  5. Now display a link to view the “mobile” version of the site. Again, this can be done with or without script.
  6. If the user clicks the link to see the mobile version, re-instate all your media queries, clear the cookie and pretend nothing happened.

This process is a bit oversimplified, but it covers the broad strokes.

There are some hurdles, of course. Your users might not understand what you mean by “desktop” or even “mobile.” You could make the link to get out of one of the views too hard to find. You could bump up against expectations set by the mobile browser feature to request the desktop site. If you serve mobile styles to IE6 users, you could confound them if you don’t clear the link from the page for them. And so on.

You can play around with what we implemented for our client at CHSBuffalo.org. View the source to see the styles and script. There is obviously logic on the server side, but you can make up your own for your own server platform.

These screen shots should give you an idea of what to expect when you visit the site:

The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7, all styling determined by media queries.
CHSBuffalo_iPhone_desktop CHSBuffalo_Nexus7_desktop
The CHSBuffalo.org site as seen on an iPhone and on a Nexus 7 after clicking “View desktop layout” (with the zoom as the user would initially see it). The link to return to the mobile layout is at the top, though not as obvious as it could be.
CHSBuffalo_iPhone_desktop_oops
This is what the user on an iPhone sees as soon as the desktop view loads—note the link to return to the mobile view is nowhere to be found. We did a poor job there and will have to fix it. Don’t make the same mistake if you try this.

Related

HTML5 and Enterprise on Mobile

This post originally appeared on my blog on Saturday, March 10, 2012.

An Argument

HTML5, CSS3Early last week .net Magazine posted an article Why HTML5 is not the choice for enterprise mobility by David Akka. The article starts off with the statement HTML5 is being hailed as the programming language… That’s as far as I got before I realized this article had a fundamental misunderstanding of HTML5.

If you’ve read my blog enough, you know that I have been constantly struggling with how developers have shot themselves in the foot by allowing HTML5 to mean far more than just the HTML5 specification. Reading the comments to the article you can see that some people think the author is talking about just the mark-up language, and others seem clueless that there is a markup language.

I soldiered on and read the rest of the article. I realized that the main thrust of the article is less a technical assessment of HTML5, but is instead a discussion of how this collection of specifications is seen by so very many as a panacea for web application development. The author makes some valid points about security (specifically user-based, such as phishing scams thanks to bad browsing habits), lack of robust synchronization, and the ongoing changes to the W3C standards that can wipe away development efforts when the browser makers decide to change direction to match.

The author’s inability to clearly and correctly identify the appropriate specifications and speak to examples left the door wide open for anyone who rails against words such as “enterprise” to attack the article on its lack of technical merits.

A Response

In a response post, Why HTML5 is a choice for enterprise mobility by Kevin Sweeney, the three core arguments from Akka are challenged. The security issue is brushed aside as a function of poor development. The asynchronous nature of the web is addressed out of hand as a function of images and CSS, not so much about client-server communication and how best to lock and release records (for example). The argument about HTML5 as an unfinished specification isn’t addressed any more than to suggest that using it will make it wrap up sooner, but still with a fundamental misunderstanding of just which of the W3C specifications are really the ones in question.

A Response to the Response

Akka responded with another post, Why HTML5 is not the right choice for enterprises right now – or the defence of David Akka, which gets into some more detail on the technical side, but still gets some terminology wrong. As the one comment on the post demonstrates, people will skip the arguments within just to go after the technical detail, making the response effectively moot.

My Thoughts

When I get past all the misunderstandings of the specifications in the posts, including HTML5, I tend to agree with the overall message of the original post that rapid adoption, possibly for the sake of being cutting edge, is a real issue. This also assumes, of course, that the writer of (and responders to) the original article actually understand what “enterprise” means.

Security

So much of modern web security is about defending against user-initiated attacks — phishing scams, malware, adware, viruses-as-email-attachments, and so on — that I think the real issue with security is really a combination of keeping users from doing daft things and protecting your environment when they do.

Add to this developers who haven’t been inculcated in an enterprise environment and maybe don’t think about the sensitivity of data passed over the wire, or enterprise developers re-positioned to use these new web technologies, and you have some further risk.

Factor in web beacons that seem to come with the territory of developing all the “new shiny” and there is also an end-user security factor to consider. While a developer may not embed a Facebook button or an ad banner on an enterprise web app, that doesn’t mean they aren’t in the code borrowed from somewhere else, especially if the developer is new to the game.

Synchronicity

I’d like to think every developer has already built a system to lock records — ideally one that doesn’t halt all other operations on the system. This should always happen at the server level. The challenge here is how to handle dropped connections, users who don’t “log out,” and the other trappings of a stateless protocol propped up by a scripting language that has to manage calls to an API on the server that actually does the real work.

This can be addressed and has been successfully on the desktop. On mobile it’s a bit trickier with more likelihood of flaky connections and long wait times. It doesn’t need to be, but too many scripting solutions that ping the server (maybe for XML, maybe to order a pizza) don’t have clean methods of handling dropped connections and can end up leaving users stranded.

While that’s not the technology’s fault it is something that, lacking a clear standard, requires each company to re-invent for itself.

Unfinished Standards

Many sites are leaning on the W3C Web Storage specification (which is not HTML5, but is lumped in with it). If you’ve been paying attention over the last week you have seen a battle over this specification, with some developers calling for its termination in favor of a solution like Mozilla’s IndexedDB or the now defunct WebSQL W3C specification.

Those developers who might have wanted to use WebSQL only to see it get pulled may now fear the same thing happening to the localStorage API (Web Storage). Web applications they built to support it may need to be revisited. Clients, projects, etc. may need to be updated. Dollars will need to spent. This is enough to make a company hesitate.

If you aren’t in the loop, check out some of the ongoing discussions and remind yourself that anyone in enterprise development through web apps (mobile or otherwise) needs to stay on top of these battles to make ongoing informed decisions.

Conclusion

Look to the business case. Don’t fall for the arguments against enterprise mobile web applications just because someone is afraid of a new paradigm, but instead make sure the resistance is based on sound business and technical considerations. Don’t fall for the arguments in favor just because of a knee-jerk reaction against “stodgy” enterprise models or a gee-whiz fanboy/girl mentality to all things mis-labeled as HTML5.

Comparing Mobile vs. Desktop Data for Improved Experience

Mobile web sites and web pages are all the rage and it’s no wonder, with sales of mobile devices soaring (Gartner). So, maybe you’re considering a mobile version of your own site, but you want to be smart about it, doing what’s best for your site based on what makes good sense for your business. Thankfully, web analytics is here to the save the day! Analytics = super exciting, right? Well, bear with me here.

Start by accessing your Google Analytics account (if you don’t have Google Analytics installed on your web site, check it out to learn more about the insights and information the service can help you gather about your site).

You’ll want to set your date range for the past 12 months and go to the Mobile Overview section* (Click images for larger screen shots):

Mobile Data Overview

This report will show the percentage of visitors came to your site from mobile devices during the past year. If it’s a decent piece of the pie chart, usually 10% or more, the data is telling you it would probably be smart to invest in the development of a mobile site.

Click one level down to Devices and you’ll see which mobile devices are the biggest drivers to your site. It’s important to note if Apple devices are at the top of ­the list as Flash won’t work on these devices (and probably never will). You’ll want to keep this in mind and consider an alternative to Flash when designing your mobile site.

Now, let’s dig a little deeper. What kinds of content are your mobile visitors viewing most often (Content>Site Content>Pages)? Does it differ from desktop users? If so, those answers can point you to better ways to organize your content for a mobile site design.

Here’s how: Hop down to the Content section, click on Pages, and bust out some Advanced Segments. Under the defaults, you’ll automatically have a Mobile Traffic option at your fingertips. This report will give you insight on what the most viewed content from your mobile visitors is. Is this same content at the top of your mobile site design or extremely easy to access on a mobile device? It should be.

You could just compare “Mobile Traffic” to “All Visits” but let’s be more awesome.

Create a quick and simple “Custom Segment” for Desktop Visitors.

Click “+ New Custom Segment” > Name itDesktop Visits” >Select “Include Mobile Exactly Matching No” > Test then Save your segment. You’ll know you did it right if your Mobile Traffic and Desktop Visits add up to All Visits.

Creating Desktop Visits Custom Segment

Now, you can start comparing differences between your mobile and desktop site visitors. Just select the “Mobile Traffic” advanced segment and your new “Desktop Visitors” custom segment, hit apply, and check out the differences. For example, on our own site I found mobile visitors spend way more time on our Web Design and Careers pages than a typical desktop visitor.

Mobile vs Desktop Visitor Data

If you don’t see a lot of differences between the way mobile and desktop user visit and interact with your site, simply creating a more mobile-friendly version of your current site is probably a valid option and should work perfectly for the vast majority of your mobile visitors. On the other hand, if there are big differences between the two kinds of interaction, you may want to consider a new design for your mobile site, pushing the most important content for mobile visitors to the top or highlighting it to make it more easily accessible via mobile devices.

If you’re an analytics user, have you tried any of these reporting options and checked out your metrics? Did you find anything interesting? I’d love to hear about it.

*All data shown is anonymous and is not reflective of our clients’ accounts.

The Mobile Web

Author: Garret Hussak
February 15, 2012

If you’ve been listening to the word on the street, you’ve noticed…everyone’s talking mobile. We now expect that companies will provide us with access to their sites from mobile devices like smartphones and tablets, and developers are being called upon to create mobile sites and applications more and more often.

So, Why The Push For Mobile?

It’s simple – people are using mobile devices and the technology isn’t going away.

  • By one count, there are 5.3 billion mobile device subscribers in the world.
  • In the 4th quarter of 2012, manufacturers shipped more mobile devices (100.9 million) than PCs (92.1 million).
  • According to one source, mobile browsing has jumped almost 200% worldwide in the past year and is closing on 10% of total browsing.
  • It is estimated that by 2014, mobile browsing will surpass desktop browsing.

What To Consider?

While we can probably agree that mobile development is “where it’s at,” we need to remember, of course, that developing for mobile devices is it’s own animal, with both limitations and advantages that need to be taken into account:

  • Smaller screen size
  • Potentially slower connection speeds
  • Higher resolution displays
  • Access to the user’s location with GPS & other technologies
  • Access to the user’s camera
  • Access to the user’s contacts

How Do We Implement Mobile Functionality?

There are a variety of methods to reaching mobile users and catering to the benefits and limitations of mobile devices:

  • Mobile Applications – Apps are a great, often fun and engaging way to present content to people on the go. But it’s important to remember that apps are platform specific and can a long time to develop. You also need to take individual device capabilities into account when creating mobile apps.
  • Mobile Web Sites – Mobile versions of web sites that are either already in place or are being redesigned or developed from scratch are a perfect way to ensure visitors have the best possible experience when they access your site on their mobile devices. Mobile sites come with some great advantages over applications, as well, since they don’t have to be platform specific (though they can be, if necessary) and usually have a faster development time. Device capabilities also aren’t the issue they can be when developing apps.

Finally, Let’s Talk About Some Of The Technological Hurdles Involved In Mobile Development

As I mentioned earlier, mobile development is its own animal and we have to keep a few important practicalities in mind when we think about a mobile project:

  • The “old-school” idea that tables can be used for layout simply won’t fly on mobile devices. In a mobile environment, elements need to be able to stack as opposed to live side-by-side as in a desktop element.
  • Fixed widths won’t work. A 450px element might fit great on a desktop version of a site, but on most mobile devices that will have be switched to a fluid width.
  • Different users will see things (slightly) differently. Each device can have a different display resolution, aspect ratio, and browser.
  • Flash is dead slow and dying. Content previously presented using Flash should now be displayed using one of many mobile friendly technologies.