groovecoder

HTML Text
<span xmlns:dct="http://purl.org/dc/terms/" property="dct:title">Packaged HTML5 Apps: Are we emulating failure? / <a href="/">groovecoder</a></span> by <a xmlns:cc="http://creativecommons.org/ns#" href="" property="cc:attributionName" rel="cc:attributionURL" >groovecoder</a> is licensed under a <a rel="license" href="https://creativecommons.org/licenses/by-sa/3.0">Creative Commons Attribution-ShareAlike CC BY-SA</a>

Plain text
Packaged HTML5 Apps: Are we emulating failure? by is licensed under a <a rel="license" href="https://creativecommons.org/licenses/by-sa/3.0">Creative Commons Attribution-ShareAlike CC BY-SA</a>

Close

1. Wes Johnston 2013-01-08 03:22:22 -0600

   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. Ian Thomas (@ianmthomasuk) 2013-01-08 05:33:20 -0600

   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).
3. Matěj Cepl 2013-01-08 07:15:47 -0600

   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. Matěj Cepl 2013-01-08 07:17:23 -0600

   (BTW, you Persona login is broken ... at least doesn't work for me with FF/Nightly).
5. Les Orchard 2013-01-08 07:48:41 -0600

   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.
6. Les Orchard 2013-01-08 07:55:46 -0600

   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.
7. groovecoder 2013-01-08 08:56:24 -0600

   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.
8. groovecoder 2013-01-08 08:57:22 -0600

   I really hope you're right. The way we look back at AOL, CompuServe, and Prodigy now. ;)
9. groovecoder 2013-01-08 08:58:14 -0600

   I don't think it's difficult to make cross-origin XMLHttpRequest safe? https://developer.mozilla.org/docs/HTTP/Access_control_CORS
10. groovecoder 2013-01-08 09:00:21 -0600

    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.
11. groovecoder 2013-01-08 09:01:53 -0600

    Again, an App extension to the sitemap protocol could help with app discoverability.
12. Keith Gable 2013-01-08 09:03:00 -0600

    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.)
13. groovecoder 2013-01-08 09:16:24 -0600

    I'd be interested to hear a client's reaction to a purely URL-driven experience.
14. Robert Kaiser 2013-01-08 09:37:30 -0600

    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.
15. groovecoder 2013-01-08 09:42:10 -0600

    Do you know why we couldn't (re-)use the W3C Packaged Web Apps standard?
16. Scott Lowe 2013-01-08 09:56:47 -0600

    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" :)
17. groovecoder 2013-01-08 09:59:39 -0600

    Fixed. Thanks!
18. Peter Bengtsson 2013-01-08 13:02:30 -0600

    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.
19. groovecoder 2013-01-08 13:11:23 -0600

    Maybe. But how many people have a Facebook app shining in their face on their desktop?
20. rakkarage 2013-01-08 13:32:55 -0600

    google goggles can deal with qr codes btw
21. Darren Gibson 2013-01-08 14:39:25 -0600

    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.
22. groovecoder 2013-01-08 14:51:15 -0600

    https://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html is supported by desktop Chrome and Safari, and Mobile Firefox, Amazon, and BlackBerry browsers. ;) What do you think about using SMS for mobile notifications?
23. m1879 2013-01-08 18:04:07 -0600

    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?
24. erose 2013-01-08 18:39:08 -0600

    I'm a bit unusual here, but each SMS costs me 20¢.
25. Erik Rose 2013-01-08 18:57:58 -0600

    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. :-)
26. groovecoder 2013-01-08 21:57:24 -0600

    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" ?
27. fabrice 2013-01-09 01:03:06 -0600

    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.
28. Matěj Cepl 2013-01-09 03:27:51 -0600

    Not unless the server-side cooperates. Which is not the case with 99% podcast-serving sites.
29. groovecoder 2013-01-09 07:05:21 -0600

    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. :(
30. groovecoder 2013-01-09 07:11:22 -0600

    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.
31. Matt Galloway 2013-01-09 11:06:06 -0600

    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.
32. Mark in A2 2013-01-09 12:38:51 -0600

    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.
33. groovecoder 2013-01-09 13:37:24 -0600

    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.
34. groovecoder 2013-01-09 13:38:52 -0600

    "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?
35. m1879 2013-01-09 14:04:20 -0600

    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).
36. groovecoder 2013-01-09 14:05:32 -0600

    And yet search for apps in the app store requires the same amount of typing.
37. Mark in A2 2013-01-09 15:01:17 -0600

    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.
38. groovecoder 2013-01-09 15:25:47 -0600

    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.
39. Mark in A2 2013-01-09 15:35:55 -0600

    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.
40. Jarred 2013-01-14 18:44:03 -0600

    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.
41. Robert Kaiser 2013-01-14 21:43:46 -0600

    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. :(
42. groovecoder 2013-01-15 09:16:32 -0600

    Thanks for the clarification. I couldn't find anything in the sencha docs - does Sencha help register custom URL-handling?
43. Mike 2013-01-16 12:18:51 -0600

    @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.
44. J.L. 2013-01-16 18:53:27 -0600

    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.
45. groovecoder 2013-01-16 19:06:24 -0600

    Sure, "acquiring an audience" is a commercial app developer concern. But I'm approaching the "discover-ability" issue from the perspective of a business & their customer. But I would be interested to see numbers re: the smaller hill to climb. I.e., compare app download & install metrics with and without out-of-store marketing. A Sencha-packaged HTML5 still requires internet access to install. And any HTML5 app at a URL can function completely offline using appCache (https://developer.mozilla.org/en-US/docs/HTML/Using_the_application_cache) and local storage (https://developer.mozilla.org/en-US/docs/DOM/Storage), which Sencha actually uses for Ext.data.proxy.LocalStorage.
46. Taras 2013-01-20 03:50:18 -0600

    FT has done a great job in packaging their HTML5 app without phonegap or any other converters: http://apps.ft.com/ftwebapp/
47. Miguel 2013-01-22 06:31:31 -0600

    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.
48. Erik Rose 2013-01-22 14:03:02 -0600

    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.
49. thinsoldier 2013-02-05 15:27:03 -0600

    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.
50. thinsoldier 2013-02-05 15:44:18 -0600

    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.
51. thinsoldier 2013-02-06 08:56:04 -0600

    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.
52. thinsoldier 2013-02-06 09:04:24 -0600

    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.
53. thinsoldier 2013-02-06 09:13:05 -0600

    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!" -
54. groovecoder 2013-02-06 09:59:07 -0600

    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.
55. Ady 2013-02-07 15:58:15 -0600

    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.
56. groovecoder 2013-02-07 21:04:52 -0600

    Check out http://mobilehtml5.org/ - iOS, Android, BB10, and Firefox Mobile all support HTML media capture (http://www.w3.org/TR/html-media-capture/).
57. Ronan Lavelle 2013-03-01 05:40:35 -0600

    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/
58. Ted 2013-03-21 09:48:20 -0500

    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
59. mws 2013-04-04 08:46:33 -0500

    who the hell wants to check-in anyways, whats it good for
60. Raymond Camden 2013-05-11 09:47:56 -0500

    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.
61. groovecoder 2013-05-12 09:25:31 -0500

    You're right, of course. My discover-ability arguments are against native apps. I extend them to packaged HTML5 apps because I don't understand why web developers spend time to support these failures of the native mobile platforms - because "everyone wants an app"? Is that a good reason? I don't think so, and some web app developers are showing that even consumers are poised to repatriate the web on their mobile devices. It makes sense to use PhoneGap to use device/hardware features that the mobile browser doesn't support, but a mobile web app at an easy URL kills native app stores for discover-ability.
62. Rahul 2013-05-21 06:55:47 -0500

    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.
63. groovecoder 2013-05-21 09:35:29 -0500

    I'm interested - what's your company's financial model for native, hybrid, and web-based apps? Last I heard, even the "pure" native app stores don't offer a sustainable financial model for most developers. (http://arstechnica.com/apple/2012/05/ios-app-success-is-a-lottery-and-60-of-developers-dont-break-even/)
64. Wacky 2013-08-12 14:38:41 -0500

    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...
65. Easy Home Noida 2014-12-18 04:41:40 -0600

    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.
66. Virtual Call Tracking 2014-12-18 04:42:33 -0600

    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.

2015 groovecoder | Powered by zBench