Packaged HTML5 Apps: Are we emulating failure?

tl;dr - URLs delivered a better experience than native desktop apps; they can do the same for mobile apps.

update: see my follow-up post - HTML5 App Stores don't go too far enough.

HTML5 in a box

When we discussed Sencha's Fastbook app on the mozilla.engagement.developers list Robert pointed out that Sencha compared their HTML5 app running in mobile web browser to Facebook's HTML5 app running in an iOS WebView - the way Sencha & PhoneGap packaged HTML5 apps actually run. It's widely discussed, as we did with Fastbook, that HTML5 apps perform worse in iOS UIWebView than iOS Safari. There are similar stories about Android WebView performance, and Tulsa Web Dev and HTML5 PhoneGap developer Rod just posted a similar performance-related anecdote about BlackBerry WebWorks.

That made me think, "PhoneGap is just that - a stop-gap." ... "we should drop this whole PhoneGap App nonsense and go (back) to mobile web at simple URL's" since:

  1. App discover-ability & installation sucks
  2. App content discover-ability sucks

App discover-ability & installation sucks

A couple months ago, my wife and I took our daughters to Incredible Pizza. When we sat down, I saw this table-tent:

Incredible Pizza Table-Tent

I spent a couple minutes trying to make this "check-in" UX work on my wife's phone. The table-tent literally reads: "TIP: A QR-Reader App is necessary to scan QR codes. There are several free ones available. Check your app store." So, here's what I did to find an app:

  1. Connect to Incredible Pizza wifi
  2. Tap "All apps"
  3. Swipe down to "Play Store"
  4. Tap "Play Store"
  5. Tap "Search"
  6. Type "qr reader"
  7. Swipe thru a huge list of apps
  8. Pick one at random (*)
  9. Tap "Install"
  10. Tap "Accept & Download"
  11. Wait for download & install

Android prompts me with a wall of permissions that I have to accept in order to install the app. And because app updates with new permissions can't be automatically downloaded & installed, many app developers just make their app request all permissions.

* Especially interesting to developers - I picked a free qr reader app at random, verifying that App Stores are more like casinos than gold-mines.

Content discover-ability sucks

Once I had the QR reader app, I started to use it to check-in to Incredible Pizza on Facebook:

  1. Hold the phone in front of the card
  2. Tap "Visit Link"
  3. Tap "Browser"
  4. Go thru 5 redirects to a prompt to open native Facebook app
  5. Facebook opens
  6. Wonder: "Why am I trying to do this in the first place?"

There was no human-readable URL on the card. I had to choose between "Browser" and "VZ Navigator" that came with the phone from Verizon. The redirects took about 20 seconds. Finally, since they don't deep link into the native app, I ultimately end up just staring at the Facebook app as if I'd opened it myself - nothing there at all about Incredible Pizza.

This totally obscures the app's content, and value, from the user. If I package my HTML5 app with PhoneGap I have to also register a custom URL scheme to link to a specific part of it - something PhoneGap doesn't help you to do(?). And even when you do it, you will need to make and deploy an update to the app anytime you want to add new URL-driven logic to it, invoking another round of app review.

The Plain Old URL approach

Contrast the above experience with a more traditional web approach:

  1. Connect to Incredible Pizza wifi
  2. Tap Browser
  3. (Maybe) Type "incrediblepizza.com"
  4. (Maybe) Tap "Yes" at a geolocation prompt

Incredible Pizza could immediately give me the store-specific web page via captive wifi portal with big buttons for location-and-date-specific coupons, facebook check-in, etc. Or, if I'm not on their wifi, I type "incrediblepizza.com" to get the same thing via geolocation. In addition to a simpler experience, deploying new or updated content is as simple as updating the website.

So why package HTML5 apps?

Considering all the above, I usually ask web devs using PhoneGap: "Why are you using PhoneGap instead of just putting an HTML5 app at a URL?" and they often reply "everyone wants an app." This "everyone wants an app" situation is a problem we developers and designers should address - but not just technically. We should work with our clients and customers to consider the full user experience of native vs. web - especially app installation & content discover-ability.

... although many brands and creative agencies believe that they need to develop iPhone apps, what they need in reality is a good mobile site. It costs less to develop, manage and work across all handsets.

- HTML5 - The End of Apps | Mobile Europe

If you're making an HTML5 app, consider - do you want to make a native desktop application? Why or why not? Then consider if the same reasoning is true for the native mobile application. Consider the URL experience for your customers. Walk your clients thru both native app and URL experiences on mobile devices. We used web URLs to deliver a better experience than native desktop apps - we should do the same with mobile apps.

Good HTML5 Packaging - URL Bookmarks

Vendors like Mozilla (disclaimer: my employer) and Google are also working on manifests to install HTML5 apps on Firefox (OS) and Chrome (OS). Opera and previously(?) Microsoft (via Silverlight) use the W3C Packaged Web Apps (Widgets) standard. I like these efforts if they contribute towards a consistent "installation" experience that works more like an enhanced bookmark. I.e., turn this:

  1. Visit URL
  2. Tap "Add to ..."
  3. Tap "Add to Home Screen"
  4. Tap "Add"

into this:

  1. Visit URL
  2. Tap "Add to Home Screen."

But next time you make an app, consider the tried-and-true web experience:

  1. Tap Browser
  2. Type URL
Packaged HTML5 Apps: Are we emulating failure? / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA
Leave a comment ?

66 Comments.

  1. I had a conversation that was very similar to this with my wife last week. Despite my conviction that typing a few letters in the urlbar is as easy, if not easier than navigating an app store (and I’ll only install an app if its something I’m really passionate about having handy all the time), she feels the exact opposite. Its one of the major things that makes me really hopeful for open web marketplaces. i.e. Anything that isn’t a highly graphical set of search results with big plush install buttons seems doomed to be declared “too hard” by a large subset of users.

    But I firmly believe that in 5 years we’ll all be looking back and saying “I can’t believe people had to install an app just to check their email”.

  2. I think you touch on the benefits of an app with your last point: you get a free advert in the platform’s app store and, after installation, in the list of apps on the phone. With a mobile website you need to type the URL in each time. If the mobile vendors could let you do that with an enhanced bookmark thing then we might be able to forget about native apps (or at least PhoneGap).

    • IMO, that free advert in the app store is worse than nothing, because

      1. “The closest thing I’ve seen to a ‘business model’ for marketing iPhone apps is to advertise like crazy until you get into the top 50,” says David Barnard of AppCubby. “Once you’re there, the top 50 list will start generating its own buzz…But that’s not a business model, that’s like rolling the dice at a casino.” (http://www.fastcompany.com/1792313/striking-it-rich-app-store-developers-its-more-casino-gold-mine)

      2. Your users will suffer from the WebView experience. I’d love to see numbers of return users between WebView apps and their equivalent mobile web versions.

  3. There is a third reason why people prefer apps/packaged webapps … some fundamental permissions missing. The fact that I cannot create a HTML5-offline-capable podcatcher as a webapp (because of single-origin XMLHttpRequest limitation; and no, I don’t want to proxy downloads of zillion multimegabyte media files over my server) seems to suggest to me that there is something wrong somewhere. I know making cross-origin XMLHttpRequest safe enough would be very difficult, but unless we are unable to resolve hard issues we are making webapps less functional alternative to native apps (http://www.youtube.com/watch?v=32wer_j5soQ).

  4. (BTW, you Persona login is broken … at least doesn’t work for me with FF/Nightly).

  5. This also makes me wonder: Why don’t mobile browsers have built-in QR code readers? (and maybe RFID integration?)

    As it’s one of the great problems in computer science, naming things is hard. Having worked at several ad agencies, I’ll tell you that human-friendly URLs get complicated, especially on large global sites. That “incrediblepizza.com” URL becomes something like “incredible-pizza.pizzapalace.info/2013/campaigns/43/?fooid=8675309″ because:

    * We couldn’t afford incredible pizza.com
    * Our content is grouped by year, by site policy
    * We’re running a few dozen campaigns, tailored by market
    * Metrics told us to put that ?fooid thing on there

    Of course, URL shorteners can help here. But, that wasn’t even a thing when I was last doing a lot of work at agencies. And sometimes, clients demand URLs look a certain way, for reasons unexplainable or unquestionable.

    This is also a spot where Facebook and geolocation will trump URLs. If Facebook knows you’re at Pizza Palace, and Pizza Palace is a client, they can take care of the rest.

    • I cringe at the thought of Facebook “taking care” of more than they already do.

      More interesting to me would be a geolocation/geofencing extension to the sitemaps protocol. i.e., Incredible Pizza can tag their Tulsa pages with geofencing metadata to tell search engines which of their pages are most relevant to geolocations.

  6. But all that said about funky marketing URLs and geolocation – I think where app stores win over plain old URLs is discoverability.

    URLs are precise, but they’re sharp and poky for most people to handle.

    An app store lets you be fuzzy: Just get to this one place, and fat-finger in something like an app name (you can even misspell it), and you’ll probably find what we were trying to get you to find.

    Of course, we already have something like this for URLs: it’s called a search engine. For HTML5 apps, this just becomes a special case search engine where the results are constrained.

    It’s also handy to have an app store as a special case, because people understand the UI better: I’m not just searching for random info on the web, I’m searching for a thing that does stuff and lives semi-permanently on my phone. In implementation, that might just also just be a special case of bookmark, but the mental model is different enough to be important.

    • Again, an App extension to the sitemap protocol could help with app discoverability.

    • The UI of the app store “apps” sucks. Well google play’s app currently sucks and my memory of the app store on first generation iphones is just as bad.

      However, the google play website is much, much better. Best of all, when a friend wants to tell me about cool app, they have a url to take me right to it. Even better than that, the google play website works perfectly with the browser’s back button. Going back in the play store app after scrolling past 400 entries is very inaccurate.

      • All of that web naming crap is fine. I’m just glad that the market has moved away from all of that protocol nastiness :)

        archie:
        gopher:
        http:
        telnet:
        ftp:
        file:

        For me the importance around a web app that is wrapped with something like phone gap is that when it’s running in a browser I don’t have access to certain functionality that I have when it’s running in it’s wrapper. For US that’s bluetooth, reminders, a more secure version of SQLite etc…

  7. I think the right solution is to make it possible to install HTML5 apps from app stores. Just like visiting incrediblepizza.com, except it’s in the store. It’s just a bookmark though, so it’s very lightweight to download and keep updated. Perhaps also make expanded permissions available.

    Clients I work with either want an enterprise deployed app or an app in the app store. And if you can’t deliver because you’re trying to talk them out of it, they go somewhere else. But, on the other hand, if you were able to say “yeah, we can get you in the app store and get you a website for people who don’t want to install the app and it’ll be the same cost”, people will go for it. But first, the app stores would have to allow that. (And unfortunately, just wrapping the site with PhoneGap doesn’t work on iOS because that’s against the rules.)

  8. Unfortunately, with Firefox OS, we end up having a large number of apps in yet another packaged format, and without that, they don’t get permissions to more delicate Web APIs. I hope you find that as unfortunate as me and I hope somehow a way can be found to make things more “webby” in the future.

    • Do you know why we couldn’t (re-)use the W3C Packaged Web Apps standard?

      • Well, I’m just another person watching things while having an opinion, but not someone to make decisions (I’d probably never have decided to let in a packaged format into FxOS). Still, for one thing, I didn’t know there was such a thing as a standard for packaged apps (and that smells funny as web and packaging don’t go well together IMHO), but I guess m1879 already laid out the reasons why packaging was done for FxOS.
        That said, I wrestle to understand appCache, but distributing your own packaged app seems to be even harder from what I see now with trying it. :(

  9. The link in this quote is broken: “… although many brands and creative agencies believe that they need to develop iPhone apps, what they need in reality is a good mobile site. It costs less to develop, manage and work across all handsets. – HTML5 – The End of Apps | Mobile Europe”

    :)

  10. I think you’re entering the dark magic realm of marketing.

    Having “www.incrediblepizza.com” somewhere in your browser history isn’t as sexy as an Incredible Pizza app shining in your face.

  11. google goggles can deal with qr codes btw

  12. I agree that many of the HTML5 ‘Apps’ in appstores (android or otherwise) really don’t serve much of a purpose: e.g. “Domino’s”, “Papa John’s”, “Incredible Pizza”, “NPR News” and are better served with fast mobile websites, there are some exceptions.

    Notifications.

    Any app that currently needs to be able to notify the user can’t use native notifications without doing an App. Facebook, IM and other messaging apps are good examples. Sure, we can all use email notifications instead of native notifications, but many of us do not want to clutter our email, and would like real time updates and not have to go through our mail to see a facebook update.

    What might be a good idea though for future HTML5(6 maybe?) mobile web apps would be to allow web apps to do notifications like native apps do.

  13. You may have seen them, but there have been long discussions on why this was done on the dev-webapps email list (and others I think) starting early in 2012. Much of it was summarized here:

    https://wiki.mozilla.org/Apps/Security

    Just curious: with a website how would you handle giving access to some of the upcoming Web APIs like contacts, camera, phone, etc. etc?

    By the way I could not sign in with Persona until I wrote a comment. Intentional?

    • I love the way Geolocation and local storage ask for permission as-needed. So something like, “This website wants to access your contacts/camera/phone. [Allow] [Deny] [] Always”

      ?

      • Asking user to make security-related decisions is a bad idea in general because the user only wants things to work and does not understand the implications in general.

        Geolocation and local storage are relatively easy to understand, but some other permissions much less. Take a look at https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/PermissionsTable.jsm to see how diverse and too technical this can be.

        • I’m not a UX pro, but I don’t necessarily agree. When it was first introduced – in 2008 – geolocation wasn’t easy for the average user to understand. But it seems we could group permissions for things like ‘settings’, ‘audio’, ‘storage’ and provide an anitial checkbox like []Always allow for this site or []Always allow for all sites. Some UX Mozillian wrote a blog post specifically about permissions but I can’t remember who or where it was. :(

  14. I “live” on the web less than a lot my fellow Mozillians, not for any philosophical reasons but for a few practical ones:

    1. The browser is a worse application switcher and window manager than my desktop OS. (Butler, distinctive window shapes, spatial positioning, etc.)
    2. Web app UIs are inconsistent. Standard widgets, nav schemes, and text sizes save my brain for more important things.
    3. Desktop apps usually have more (and more consistent) keyboard shortcuts, letting me work faster.

    So my use of the web is limited to tasks where my primary goal is collaboration or fetching data (Github, Bugzilla, Wikipedia). The transparent upgrades are great, and it’s handy to be able to pass URLs around.

    Interestingly, mobile makes #1 and #3 go poof, so if we can provide the consistency bit on Firefox OS (through our examples, guidelines, and dev tools), we might win over even curmudgeons like me. :-)

    • I’m right with you on #1 and #3! I love it when webapps provide keyboard shortcuts – gmail, github, etc. – but not enough of them do.

      However, the web gave us the most consistent and universal UI ever conceived – the humble hyperlink. Train yourself to use the “Quick find within link-text only” firefox key (‘) and you’ll get #2 and #3 on the web.

      • Oh, I use Quick Find all the time to navigate, but it doesn’t make the UI any more consistent, any more than “using the keyboard” equals “consistent”. What I mean is: how about a common, short keystroke for “go ‘up’ in the document structure” (as when reading documentation). I used to have that rigged with iCab when people used link rels properly. Remember how the Mac standardized command-Q, command-W, command-Z -X -C -V? That sort of thing.

        By #2, I mean I’d literally like every web site to look exactly the same (if I want), apart from its content. When I load a new site, my workflow goes like this: hit command-plus or -minus several times to get it a reasonable size, then maybe resize the window as well. I’ve tried a slew of auto-resize addons, but none work very well.

        • RSS Reader. But not all sites offer a feeed :(

          All the sites I visit regularly do. That might be why they’re the only ones I visit regularly.

  15. Grrrr. Damn you, Luke Crouch.

    Yes, HTML5 apps are awesome. Yes, HTML5 apps could and SHOULD be used more often then they currently are.

    But NO, your Incredible Pizza example is not a good example of why. Why not? Because the Incredible Pizza example is a example of why most marketing people suck…not why apps suck.

    First off, QR codes are so 2010. In the US they were a largely failed marketing experiment, partially because of poor usage by marketers as exhibited in your example. Markets gets all giddy and self-affirming when they feel like they are using technology by putting a QR code on something they it never occurs to them what happens when a customer actually tries to use the code. I’ve seen dozens and dozens of examples of QR codes that were in places where they are not practical to use (tiny ones on billboards, QR codes on the moving objects like buses). It’s way to common that QR codes are not accompanied by a human readable URL . In most cases a shorted or creative URL is more effective than the QR code. But the biggest offense with QR is not designing the experience of where the QR code leads. The most common mistake is to take someone to a non-mobile friendly web page. Complete. Utter. Failure.

    In the Incredible Pizza case, if you can’t engineer a URL to take the user to the actual check-in page, or better yet to actually check them in then the QR code should have never been used to begin with. Furthermore, most people that know what “Check-In on Facebook” means have a Facebook app on their phone (Yes. That’s right, I said it. AN APP. RIGHT THERE ON THEIR PHONE.) and are only distracted, as you were, by the QR code.

    As for discover-ability… in this case, I would argue that it’s still a marketing mistake, not a technology one. Why on earth would Incredible Pizza direct the user to not one, but TWO apps or websites that aren’t Incredible Pizza? A huge part of the (general) failing of QR was a lack of understanding by the general public. If you have to educate people about QR you’ve already lost.

    Smart marketers would have a QR code go to a web page that detected the mobile OS and then redirected to their own app in either the App Store or Google Play as appropriate. (And of course provide an easy, short human readable URL to the same). This solves the discoverability problem (and yes, it also works for HTML5 apps).

    As far as installation. I agree, installation on Android sucks. It doesn’t on iOS. Meh.

    Generalized discover on iOS is better than Android (and HTML5 apps) because there’s only one place to look: the App Store. The key is naming your app correctly and out-of-store marketing.

    …bottom line is that the moral here is one of poor use of QR, not one of native app vs. HTML5.

    • We’ve talked a bunch about native vs. web, so you know I like sensible native apps.

      I’m puzzled here by we web dev’s who shoe-horn our HTML5 apps into an “almost-native” experience. What value are we trying to capture?

      We don’t get offline capability, since users have to be online to install new apps anyway.

      We don’t get a native in-app experience, since HTML5 apps don’t match the device UX (and WebViews hurt performance).

      We don’t get discover-ability, since we still have to do the out-of-store marketing.

      It seems we’re just trying to re-use the “Go to app store, search, install” experience. But I argue that “Go to incrediblepizza.com” is every bit as widely understood and accessible.

  16. Great discussion, and I largely agree with everything you say. Good timing for me as I just built my Sencha app in a native wrapper for the first time yesterday and actually noticed that it is a bit more sluggish than the straight mobile web version.

    I do think the “add to homescreen” is essentially the equivalent of a bookmark in the mobile app (native or not) world and is important. Going to the browser and typing in the URL or using a browser-based bookmark just won’t cut it IMO.

    Obviously, most games and anything that provides access to the camera and hardware needs to be in a native app. In my app, the only thing I really wasn’t able to do in the straight Sencha web app was provide a good OAuth2 login experience for Facebook (can’t redirect to the open instance of my web app after completion.) Was trying to find a solution within the native wrapper.

    Thanks.

    • “Going to the browser and typing in the URL or using a browser-based bookmark just won’t cut it IMO.”

      Why not? What is it about “Tap Browser; type url” that is so scary on a mobile device?

      • I find it pretty tedious to use my phone’s keyboard to type a picky thing like a URL. And I have a large screen (Samsung Galaxy s3).

      • The first time, maybe. After that, if it is an app I’m using with any kind of regularity I want an icon on my home screen. It isn’t about being scary – just about being easy and convenient.

        One of the nice things about the app store is that I know exactly what I’m searching through (iOS native apps) and what to expect. With URL’s, I could end up anywhere being served all kinds of things and I’m searching the entire web.

        I’ve often wondered why there isn’t an HTML5 web app equivalent of the Apple App Store. There probably are some, but nothing I’m aware of as reaching a critical mass.

        • Although it can be improved further, “Add to home screen” isn’t much more than “Install” IMO.

          I agree there should be an HTML5 app store. But it seems like it would just be an app-aware search engine.

          • I agree on “Add to home screen”. Hopefully people get get familiar with using that. If there was a “killer app” that was accessed that way, it would help.

      • The same thing that’s scary about it on desktop. I know older people who can type in facebook.com into the search field and nothing else. Other who type facebook.com into the address bar, thinking it’s the search field, and are pleasantly surprised *every* time that it “found” exactly what they wanted. “Why can’t it find exactly what I want when I type in Cheapest Hotel in Miami.com?”

        They get all their news from msn.com because it is the default. They only check their email when I come over to their house and type in gmail.com and their username and password (that they refuse to remember for themselves).

        There needs to be a 1-touch method for adding a website to a device’s main list of app icons.

        I’m on a nexus 7 using a stylus and I still have a hard time entering URLs. Thankfully I do all my browsing/reading via Google Reader so I usually never need to type any urls when on my tablet.

        • My main point is:

          I can get my uncle to type in a url for a site or app correctly ONE TIME. He’ll never use/visit it again unless I bother to nag him and walk him through it again.

          There needs to be a 1 touch method of adding a site to the list of app icons.

          It needs to be something the user touches within the site itself.

          My uncle refuses to touch browser chrome. He fears it for some reason.

          • If you look at the instructions on apps.ft.com/ftwebapp/
            that 1 too many steps for some people.

            The device, browser, and website should be able to communicate:

            – Site asks the browser to ask the OS: Is there already a home screen icon for this site?
            – OS says no -> Browser says no -> Site shows a big green button “Add us to your home screen!”
            -

          • I totally agree. But if we package HTML5 apps to fit into the current app stores, there’s less pressure on the mobile platform vendors to support a 1-touch site-to-home-screen feature, isn’t there?

            We should push the “Add to home screen” method instead of shoehorning HTML5 into the app store distribution method.

  17. Nice article. Just as an FYI, Sencha Fastbook runs equally fast in a WebView as it does in Mobile Safari. The performance comes from optimized DOM, not from JavaScript JIT.

  18. @groovecoder: yes, yes a thousand times yes! Great article. About a year ago I decided to ditch this app store nonsense, and I strive to build mobile web apps wherever possible.

  19. One position you’re not considering–or if you did, I somehow missed it–is the value of an app store for acquiring an audience.

    Your pizza parlor example is good in that anyone in the restaurant who might be inclined to use its app (or app-like) experience from is a captive audience. So posting a QR code or url is an easy task.

    If you’re concerned about your city’s tourism, or if you run a tourist attraction, then prefering a web app over a native one is fine since, again, people using it would be captive. Simply print the link in a conveniently seen place, and there you go.

    But if you’re developing a non-location specific app, one where a potential user isn’t within convenient “eye-shot” of a url or code to scan, then packaging your web app makes sense.

    I can create my html5-based game, say, and rather than have to rely solely on the usual search engine–or whatever other methods you use to drive traffic to your website–game, I can upload my packaged app in an app store and therefore have a smaller hill to climb.

    Also, the advantage of Sencha, phone gap, et. al. is that I can take what would normally require internet access, and develop it to work offline. In this case, HTML5, CSS3, and javascript simply comprise another framework for developing a native app. Just because I create a html5 game doesn’t mean I must be tethered to the internet.

  20. FT has done a great job in packaging their HTML5 app without phonegap or any other converters: http://apps.ft.com/ftwebapp/

  21. The market approach it’s essential for the purpose of selling something. Probably this can be an idea that someone could develop, and build a market for html5 apps based in a simple URL. The browsers and the OS should have the possibility to encapsulate such type of apps, so they can look like a native app. In windows 8, the IE app experience it’s quite diferent from the traditional browser look and feel.

  22. I use phonegap and the likes as a last resort if one feature carefully picked to enhance the user experience has to be done natively, like taking a picture and having access to it right away. If there was an easy way to have access to the device file system and such, believe me that would be the end of packaged apps.
    I haven’t had the chance to keep up with the new trends (so many to track) to see if such things are in the works, in the meantime that is going to be the unfortunate tradeoff that we as WEB developers (emphasis on web) will have to make.

  23. Groovecoder – this is a REALLY great article. Nice work. My company, Azurati, has been promoting (sometimes it feels like trying to row upstream) HTML5 apps for enterprise mobile use. What we have found is that:

    1. there is a general expectation that an app should be launched by selecting an App badge/icon
    2. typing a URL or even accessing mobile bookmarks are not culturally acceptable anymore.

    To counter this, and to provide a solution that enables BYOD at a much lower cost than traditional native apps and MDM solutions, we have come up with the concept of the Azurati Mobile Portal – a mobile app container for HTML5 web apps.

    Developers can publish web apps to the Mobile Portal, allowing users to access web apps securely without having to enter URLs or ID credentials.

    Further information on this can be found at: http://www.azurati.com/products/azurati-mobile-portal/

  24. Hi All–
    Great discussion. One other reason why people prefer apps to URLs is related to gestures– apps can define a set of unique gestures and interactions that are specific to the way the app should work and make it easier for people to interact with the app. Browser-based apps have keystrokes, gestures, and buttons that HAVE TO apply to any app you might like to call up in your browser.

    For example, a two finger pinch on your email app might close a message, but in a browser it would close the whole app tab. A swipe to the left might go to the next message, but in the browser it opens my browser settings menu. In short, your gestures can be optimized for the activities you do in the app.

    I’ve long though that for a browser-based future to work, it would be necessary to have site-specific gesture settings that could take over from the browser’s settings somehow. I imagine this as a browser-plugin where each site could submit a set of interactions that override the browser’s gestures. This way, you could approach native-app-like interactions in a browser.

    I don’t have the coding chops to create such a thing, but hopefully one of you do?

    Ted

  25. who the hell wants to check-in anyways, whats it good for

  26. Disclaimer – I work for Adobe and am a PhoneGap lover. :)

    I’m curious why your two introductory arguments (app discoverabilty and content discoverability) are used as a means to argue against PhoneGap? Those arguments apply to native apps in general. Is there a reason why you have them here in an argument against packaged HTML5 apps when they apply to native apps as well?

    As to PhoneGap, one of their philosophies is to actually *not* exist in the future. The team would love to see mobile web get to a point where things like camera access and other hardware APIs are opened up to the web. I think that would be great too, but I can never see it happening completely.

  27. Very nice discussion. IMO the factor which governs the success/failure of html5 apps is not the technology itself but it is going to be evolution of the financial model behind these apps that would ensure a proper RoI. Until unless we have a sustainable Appstore like the once with native applications this is not going to last long.

    We being a mobile company (http://www.techendeavour.com/mobile-application-development) have done all. Native, hybrid as well as Web (HTML5 based) but still the trend does not seem to shift towards html5.

  28. I would just like to tell that I really liked your blog post. In fact I am going to

    bookmark your blog and will regularly visit the site. You come up with such an amazing

    articles thank you for sharing this your site.

  29. I would just like to tell that I really liked your blog post. In fact I am going to bookmark your blog and will regularly visit the site.

Leave a Comment

NOTE - You can use these HTML tags and attributes:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Post comment

What is Persona?

Packaged HTML5 Apps: Are we emulating failure? / groovecoder by groovecoder is licensed under a Creative Commons Attribution-ShareAlike CC BY-SA