8 ms·

Why should I have to install an app to figure out subway times?

71 points by jheitzeb 16y ago

jws 16y ago
The obvious reason in because you have no internet connectivity in the subway stations. But that doesn't affect the arguments, just that one example. On a recent visit to New York, Google guided me all around Manhattan with great efficiency, but I had to keep an app for when I was underground.
- rexf 16y ago
  Google Maps works great as a default without having to install a new application. Further, the free NYC Mate official app is great for offline (underground) access. Both include time schedules.
swombat 16y ago
Well, UDDI was an architecture astronaut's fantasy back then... and it still is today. This might be a theoretically better way to deliver the service, but it needs too many bits and pieces to fall into place (particularly bits that require the concurrent agreement of thousands of businesses and governmental organisations with conflicting aims) in order to become a reality...
joelhaasnoot 16y ago
Get your transport company to submit their dataset to Google Transit. Not all transport companies want to do that, they believe it's proprietary data.
- davepeck 16y ago
  I did a lot of transit-related software development [1] in 2010, so I've experienced this first-hand. For those who don't know, Google maintains a specification called GTFS that captures transit agency timetable and route information. Unfortunately, as parent mentioned, a lot of transit agencies illogically believe that they need to protect their data. Most agencies are at least partially publicly funded, so there is no reason keep data behind closed doors. Of the 800 or so transit agencies in the US, only about 150 provide their data publicly today. (Many more provide their data to Google, but not to the general public -- a strange state of affairs.) The community has organically developed a three-pronged assault: 1. Use carrots to encourage agencies to provide their data. Google Maps is a good carrot, as it gets agencies to use the common GTFS format. Unfortunately, Google is willing to take data from agencies that won't make their data otherwise publicly available, so it doesn't fix the entire problem. Walk Score's Transit API [1] is another carrot. If agencies make their data public, it will immediately be available through this API. The Transit API makes it very easy for third-party developers to do great things with transit data, and it takes care of all the difficult issues: finding the data, keeping it current, and dealing with real-world bugs in the data. (Transit data headaches were my life for many months last year!) 2. Use sticks to encourage agencies to provide their data. I helped build City Go Round [2] to shed light on the innovation that happens when agencies open their data. You can also see quite clearly what agencies in a given locale haven't yet ponied up their data. (Search in San Francisco, for example.) 3. Create a public clearinghouse so there is high visibility. The GTFS Data Exchange, or GTFSDE [3], is where public GTFS data goes to live. It's a great resource for transit developers and, along with the GTFSDE mailing list, is the focal point for the community at the moment. -Dave [1] http://www.walkscore.com/services/public-transit-api.php http://www.walkscore.com/services/public-transit-api.php [2] http://www.citygoround.org/apps/nearby/?q=san%20francisco,%20ca http://www.citygoround.org/apps/nearby/?q=san%20francisco,%2... [3] http://www.gtfs-data-exchange.com/ http://www.gtfs-data-exchange.com/
  - erikpukinskis 16y ago
    Neat. I saw the list you have on the front page of http://www.citygoround.org http://www.citygoround.org and immediately thought "Cool, a list of cities I never want to live in!" But then I saw Phoenix on the list, which is where I am currently living, and I'm confused. Google Transit works great in Phoenix, but you've got Valley Metro listed as not providing their data. What's going on there?
    - enf 16y ago
      They can submit their schedule data to Google but not let anyone else see it. AC Transit is another agency that is in Google Transit but does not give the general public access to their GTFS schedule data.
      - davepeck 16y ago
        Yes, that's it exactly. It's a frustrating middle ground where data available to Google is not available to the general public, even though many of these are public agencies to begin with.
- detst 16y ago
  This reminds me of a story about public parking spaces in Ann Arbor. They had a live data feed of parking spaces available a few years ago. Someone used it to create a phone service that would tell you the available spaces and text when a space opened in a garage. I can't remember what her position was, but some women decided that was a service the city should be responsible for. Instead of building the service, she decided that they should shut down the data feed. It amazes me that someone could come to that conclusion, even after realizing the usefulness of the service. How could she not see that someone created something of use to the residents of the city that the city probably would have never provided or even thought of providing? I would expect that after seeing what people can do with open data, she would look for other things to open up. I don't know what happened after that.
TetOn 16y ago
Also worth noting that non-app solutions do exist. [NextBus](http://www.nextbus.com/ http://www.nextbus.com/), for instance, includes both a web interface and an SMS-based query centered around texting it your stop number.
- there 16y ago
  i wrote http://metra.jcs.org/ http://metra.jcs.org/ to provide train schedules for the metra rail lines in the chicago area after metra spent $3.9M on a new website that wasn't even usable on an iphone. they finally have a mobile version now but i find the interface difficult to use compared to mine. aside from word of mouth, or searching google for "metra iphone", i have no way of directing traffic to it like i would if it were a dedicated app in the app store/android market. i've often thought about just taping up flyers at each metra stop to advertise for the site.
akgerber 16y ago
This sounds like a combination of Wolfram Alpha-esque search experience with APIs. But I think this fellow is discounting how much value a good UI/UX is a part of what makes an application valuable. Every transit system out there had some crappy trip planner for a long time before Google Transit came along & replaced them. Star charts get a lot more useful with window-to-the-sky UI in new apps. Does the NYC subway even have a fixed schedule during most times of the day? It's usually just "go in the station and a train will show up in a couple of minutes."
- Anechoic 16y ago
  * Does the NYC subway even have a fixed schedule during most times of the day? * They do, headways (intervals between trains) vary at specific times of the days (large headways late at night/early morning, small headways during peak transit hours, mid-size headways during the day) and you can use those to compute the schedule. In NYCT's case, they run enough trains that in Manhattan a train comes pretty much every few minutes but in the other boroughs they may run infrequently enough that you'll want to plan ahead.
cstuder 16y ago
The nice side effect of those apps: Every developer is actually building webservices to drive them. So the big UDDI vision might yet come to pass.
scottporad 16y ago
This sort of reminds me of Dave Winer's RSS Cloud stuff, but maybe exactly the opposite.
cletus 16y ago
Apps vs the Web isn't a new debate. Some thing apps are merely a stepping stone and the Web will be everything in the future. A bit like how 5-10 years ago, Flash was the only way to do "rich" Web apps whereas now most things Flash can do, HTML/JS can now do. The problem with apps isn't really about payment though. I have a paid NYC subway app and quite happily paid for it. I'd prefer to do that than have some micropayments system where really I had no idea how much it was going to cost. It's a bit like how phone calls from land lines, unless they're international, aren't charged on a per-call or per-minute basis (in the US, YMMV elsewhere). The situation is analagous to micropayments IMHO. People generally prefer flat cost models for simplicity, even when it means they pay more than they would had they paid for each call. But that's a function of risk. You pay insurance on your house even though the expected value of all your insurance payments is you're worse off than had you self-insured: you're transferring that risk to a third party. Also, micro-payments (and this includes charging per phone call) has another cost: the cost of billing actually becomes significant. So the phone provider prefer a flat rate rather than keeping track of and billing you for all those calls. Anyway, back to apps. Some people don't like apps because they're balkanized. If you write an app you need to write an iOS version, a version for Android, a version for Blackberry and so on. It's a valid point but one I think will sort itself out in time as such platforms inevitably become commoditized. What you have to remember is that most people aren't tech-savvy. So give a person and tell them you click on this icon and it gives you a subway map and the times and they understand that. Tell them to go to a Web page and it's a whole lot harder. Yes you can bookmark a page on the home screen but that experience isn't yet as good. Web apps generally don't work offline (which is a bit of a problem in our subway example). Web pages vary greatly in their mobile user experience, both in terms of display/layout and in terms of remembering what the user was doing as you switch apps (which is an issue on mobile but not on a laptop/desktop). Lastly, games I see as being apps for a very long time to come. Sure computing power is increasing but power on mobile is an issue so the pressure will simply be to reduce power consumption rather than increasing CPU power, making the viability of HTML/JS for something like Angry Birds just that much further in the future. The fact is though you don't need to buy apps for pretty much anything. There are lots of free apps and free Web pages. I can navigate around NYC using Google Maps if I want to but I like my paid NYC subway map.
- 16y ago
roc 16y ago
Because search still sucks. No-one does context very well or very consistently. Even with hints. Google can't do it. Wolfram can't do it. UDDI sure doesn't/can't/won't do it. Further, a huge part of the drive to apps is because people prefer more-responsive and dependable apps that are geared for the mobile use-case of the query they need at that instant. e.g. an interface that's not only finger-friendly, but one-thumb friendly and/or low contrast-friendly. Even in a magical UDDI future, no generic interface group is going to churn out something that displays subway maps as well as a dedicated UX group that's only worried about subway maps. Lastly, you only search for an app once. And most people never search randomly at all: their friend recommends an app and they search for that specific app by name. You may recognize this behavior as: the way most people use the internet. The worst the 'appocalypse' could ever get, is as horribly unusable as the current internet. And we certainly have enough history on that to see whether people will ignore it because it can be difficult to find things [1]. That the author totally skips the UX concerns and shamefully overhypes the search process strikes me as somewhere between 'just not getting it' and 'intentionally disingenuous'. [1] So we're clear: It really is still too difficult to search for most things online. My point is that state of affairs just doesn't matter. Maybe you could get more use from more people with better search. It remains to be seen whether people would rather search for themselves or whether they truly prefer to get their information through third party curators and aggregators. But clearly apps won't run into a roadblock because of search any time soon.
- erikpukinskis 16y ago
  the author totally skips the UX concerns I don't get your point. People do UX design on the web. Instead of opening your NYCSubway app, you just type "NYCSubway" into Google, touch the first link, and now you're on nycsubway.com, whose UX has been meticulously crafted just like the NYCSubway app. The point is that downloading apps is an unnecessary step.
  - mrbogle 16y ago
    It seems the article is talking about having some search interface call some data providers, then display the data returned by the providers. I imagine what your parent was trying to say was that the search interface cannot generify the display and interaction with the data provider's data.
RyanMcGreal 16y ago
> When I query for Rockefeller Plaza and I’m sitting at the Thompson LES, a logical intent is travel to/from Rockefeller. For you, this may be a logical intent; but it would be a bad idea to try and generalize to a whole population of users from your own anecdotal experience.
- rmc 16y ago
  "Hello it looks like you're trying to take the subway, would you like help"
  - jamesjyu 16y ago
    That better not be clippy saying that :)
- erikpukinskis 16y ago
  That's why Google gives you a whole page of results/widgets, not just one.
phlux 16y ago
Heh - apropos.... I am working on this very thing. But for a specific vertical.
sfphotoarts 16y ago
Apps provide a thick-client experience (richer UI, off-line storage etc) and people when they want to do a specific task know what to use. It seems obvious why until the web can be all things to all people we will always have apps. 10B to be precise! Clearly a lot of people like them. Until native UI features are available using a web based driver there will likely always be some advantage to a slightly thick-client. Exposing UI features is a battle, look at the past for details of hard this is, ActiveX for example. In theory this would have made all Windows UI components available to the web browser, until someone figured out that a security model would be necessary that handicapped things so much it led to Flash. Now we are a decade and a half further on and technologies like jquerymobile will likely see many web solutions be more app like. Once Apple figure out a better way to save a web 'page' to the home-screen that's intuitive and provides for local storage we will see apps.
eyeareque 16y ago
Remember the first iPhone? You weren't supposed to need to install any apps because you could just make a web page to do the same thing. Apple has served up 10B apps to date.. so developers will be making money from selling "useless apps" through app stores for at least the next few years. I can see this changing if wireless phone data networks can speed up network latency. The web is too laggy on phone data networks at this point IMO.
- uxp 16y ago
  This was my frustration with Google Voice and Google Wave homescreen bookmark "apps". Both of them were extremely laggy and took minutes to fully load. Definitely not the experience I desired.
deleted 16y ago
[deleted]
guynamedloren 16y ago
This entire article is based on an extremely flawed assumption. Introduced in the second paragraph, the assumption is that people are confused by this foreign and complicated idea of "apps". Never in my life have I met a person, young or old, who does not understand what an app does (since they have acheived mainstream popularity within the past few years, largely thanks to Apple). Sure, they may not realize that an app is just a few lines of code that pushes queries and pulls data from the cloud, but honestly - does it matter?
deleted 16y ago
[deleted]
contextfree 16y ago
Nota bene, the author is a PM at Microsoft on Bing. (Not meant as a 'gotcha', just a bit of possibly interesting context.)
stevenp 16y ago
I'm the developer of Routesy (routesy.com), a public transit app for SF Muni/BART/Caltrain/AC Transit. My app has been around since the first day of the app store, and I get asked this question all the time. The short answer is that Apple gives me two important things: 1. A decent development platform with UI controls that provide a good, familiar user experience 2. A marketplace that lets my app make money so I can afford to continue developing it I've done some offline app development using HTML5 as well, and these apps just don't "feel" the same. Had I taken the HTML5 route, it would have been far easier for me to port my app to Android (which I haven't done yet), but my experience has been (at least for productivity and utility apps) that the more native an application feels, the better it sells.
neworbit 16y ago
There are two good rebuttals to this article: 1. Apps are useful in an offline market, like when you are in the subway with no data service. 2. People don't like micropayments. They are willing to put up with ads instead. Why do people keep flogging micropayments and ignoring actual customer behavior? On-search-result ads will get you some slight income without the hassle of trying to get your customer base to adopt some wacky and ill-supported payments mechanism. I feel that the dismissal of apps in favor of a major shift in customer behavior is at best a sign of detachment from what the end user wants. (And I would tend to go further into "boil the ocean" and "architecture astronaut" thinking but that is not likely to be productive here, so let's leave well enough alone.)

71 points by jheitzeb 16y ago

jws 16y ago

The obvious reason in because you have no internet connectivity in the subway stations. But that doesn't affect the arguments, just that one example. On a recent visit to New York, Google guided me all around Manhattan with great efficiency, but I had to keep an app for when I was underground.

rexf 16y ago
Google Maps works great as a default without having to install a new application. Further, the free NYC Mate official app is great for offline (underground) access. Both include time schedules.

swombat 16y ago

Well, UDDI was an architecture astronaut's fantasy back then... and it still is today. This might be a theoretically better way to deliver the service, but it needs too many bits and pieces to fall into place (particularly bits that require the concurrent agreement of thousands of businesses and governmental organisations with conflicting aims) in order to become a reality...

joelhaasnoot 16y ago

Get your transport company to submit their dataset to Google Transit. Not all transport companies want to do that, they believe it's proprietary data.

davepeck 16y ago
I did a lot of transit-related software development [1] in 2010, so I've experienced this first-hand. For those who don't know, Google maintains a specification called GTFS that captures transit agency timetable and route information. Unfortunately, as parent mentioned, a lot of transit agencies illogically believe that they need to protect their data. Most agencies are at least partially publicly funded, so there is no reason keep data behind closed doors. Of the 800 or so transit agencies in the US, only about 150 provide their data publicly today. (Many more provide their data to Google, but not to the general public -- a strange state of affairs.) The community has organically developed a three-pronged assault: 1. Use carrots to encourage agencies to provide their data. Google Maps is a good carrot, as it gets agencies to use the common GTFS format. Unfortunately, Google is willing to take data from agencies that won't make their data otherwise publicly available, so it doesn't fix the entire problem. Walk Score's Transit API [1] is another carrot. If agencies make their data public, it will immediately be available through this API. The Transit API makes it very easy for third-party developers to do great things with transit data, and it takes care of all the difficult issues: finding the data, keeping it current, and dealing with real-world bugs in the data. (Transit data headaches were my life for many months last year!) 2. Use sticks to encourage agencies to provide their data. I helped build City Go Round [2] to shed light on the innovation that happens when agencies open their data. You can also see quite clearly what agencies in a given locale haven't yet ponied up their data. (Search in San Francisco, for example.) 3. Create a public clearinghouse so there is high visibility. The GTFS Data Exchange, or GTFSDE [3], is where public GTFS data goes to live. It's a great resource for transit developers and, along with the GTFSDE mailing list, is the focal point for the community at the moment. -Dave [1] http://www.walkscore.com/services/public-transit-api.php http://www.walkscore.com/services/public-transit-api.php [2] http://www.citygoround.org/apps/nearby/?q=san%20francisco,%20ca http://www.citygoround.org/apps/nearby/?q=san%20francisco,%2... [3] http://www.gtfs-data-exchange.com/ http://www.gtfs-data-exchange.com/
- erikpukinskis 16y ago
  Neat. I saw the list you have on the front page of http://www.citygoround.org http://www.citygoround.org and immediately thought "Cool, a list of cities I never want to live in!" But then I saw Phoenix on the list, which is where I am currently living, and I'm confused. Google Transit works great in Phoenix, but you've got Valley Metro listed as not providing their data. What's going on there?
  - enf 16y ago
    They can submit their schedule data to Google but not let anyone else see it. AC Transit is another agency that is in Google Transit but does not give the general public access to their GTFS schedule data.
    - davepeck 16y ago
      Yes, that's it exactly. It's a frustrating middle ground where data available to Google is not available to the general public, even though many of these are public agencies to begin with.
detst 16y ago
This reminds me of a story about public parking spaces in Ann Arbor. They had a live data feed of parking spaces available a few years ago. Someone used it to create a phone service that would tell you the available spaces and text when a space opened in a garage. I can't remember what her position was, but some women decided that was a service the city should be responsible for. Instead of building the service, she decided that they should shut down the data feed. It amazes me that someone could come to that conclusion, even after realizing the usefulness of the service. How could she not see that someone created something of use to the residents of the city that the city probably would have never provided or even thought of providing? I would expect that after seeing what people can do with open data, she would look for other things to open up. I don't know what happened after that.

TetOn 16y ago

Also worth noting that non-app solutions do exist. [NextBus](http://www.nextbus.com/ http://www.nextbus.com/), for instance, includes both a web interface and an SMS-based query centered around texting it your stop number.

there 16y ago
i wrote http://metra.jcs.org/ http://metra.jcs.org/ to provide train schedules for the metra rail lines in the chicago area after metra spent $3.9M on a new website that wasn't even usable on an iphone. they finally have a mobile version now but i find the interface difficult to use compared to mine. aside from word of mouth, or searching google for "metra iphone", i have no way of directing traffic to it like i would if it were a dedicated app in the app store/android market. i've often thought about just taping up flyers at each metra stop to advertise for the site.

akgerber 16y ago

This sounds like a combination of Wolfram Alpha-esque search experience with APIs. But I think this fellow is discounting how much value a good UI/UX is a part of what makes an application valuable. Every transit system out there had some crappy trip planner for a long time before Google Transit came along & replaced them. Star charts get a lot more useful with window-to-the-sky UI in new apps. Does the NYC subway even have a fixed schedule during most times of the day? It's usually just "go in the station and a train will show up in a couple of minutes."

Anechoic 16y ago
* Does the NYC subway even have a fixed schedule during most times of the day? * They do, headways (intervals between trains) vary at specific times of the days (large headways late at night/early morning, small headways during peak transit hours, mid-size headways during the day) and you can use those to compute the schedule. In NYCT's case, they run enough trains that in Manhattan a train comes pretty much every few minutes but in the other boroughs they may run infrequently enough that you'll want to plan ahead.

cstuder 16y ago

The nice side effect of those apps: Every developer is actually building webservices to drive them. So the big UDDI vision might yet come to pass.

scottporad 16y ago

This sort of reminds me of Dave Winer's RSS Cloud stuff, but maybe exactly the opposite.

cletus 16y ago

Apps vs the Web isn't a new debate. Some thing apps are merely a stepping stone and the Web will be everything in the future. A bit like how 5-10 years ago, Flash was the only way to do "rich" Web apps whereas now most things Flash can do, HTML/JS can now do. The problem with apps isn't really about payment though. I have a paid NYC subway app and quite happily paid for it. I'd prefer to do that than have some micropayments system where really I had no idea how much it was going to cost. It's a bit like how phone calls from land lines, unless they're international, aren't charged on a per-call or per-minute basis (in the US, YMMV elsewhere). The situation is analagous to micropayments IMHO. People generally prefer flat cost models for simplicity, even when it means they pay more than they would had they paid for each call. But that's a function of risk. You pay insurance on your house even though the expected value of all your insurance payments is you're worse off than had you self-insured: you're transferring that risk to a third party. Also, micro-payments (and this includes charging per phone call) has another cost: the cost of billing actually becomes significant. So the phone provider prefer a flat rate rather than keeping track of and billing you for all those calls. Anyway, back to apps. Some people don't like apps because they're balkanized. If you write an app you need to write an iOS version, a version for Android, a version for Blackberry and so on. It's a valid point but one I think will sort itself out in time as such platforms inevitably become commoditized. What you have to remember is that most people aren't tech-savvy. So give a person and tell them you click on this icon and it gives you a subway map and the times and they understand that. Tell them to go to a Web page and it's a whole lot harder. Yes you can bookmark a page on the home screen but that experience isn't yet as good. Web apps generally don't work offline (which is a bit of a problem in our subway example). Web pages vary greatly in their mobile user experience, both in terms of display/layout and in terms of remembering what the user was doing as you switch apps (which is an issue on mobile but not on a laptop/desktop). Lastly, games I see as being apps for a very long time to come. Sure computing power is increasing but power on mobile is an issue so the pressure will simply be to reduce power consumption rather than increasing CPU power, making the viability of HTML/JS for something like Angry Birds just that much further in the future. The fact is though you don't need to buy apps for pretty much anything. There are lots of free apps and free Web pages. I can navigate around NYC using Google Maps if I want to but I like my paid NYC subway map.

16y ago

roc 16y ago

Because search still sucks. No-one does context very well or very consistently. Even with hints. Google can't do it. Wolfram can't do it. UDDI sure doesn't/can't/won't do it. Further, a huge part of the drive to apps is because people prefer more-responsive and dependable apps that are geared for the mobile use-case of the query they need at that instant. e.g. an interface that's not only finger-friendly, but one-thumb friendly and/or low contrast-friendly. Even in a magical UDDI future, no generic interface group is going to churn out something that displays subway maps as well as a dedicated UX group that's only worried about subway maps. Lastly, you only search for an app once. And most people never search randomly at all: their friend recommends an app and they search for that specific app by name. You may recognize this behavior as: the way most people use the internet. The worst the 'appocalypse' could ever get, is as horribly unusable as the current internet. And we certainly have enough history on that to see whether people will ignore it because it can be difficult to find things [1]. That the author totally skips the UX concerns and shamefully overhypes the search process strikes me as somewhere between 'just not getting it' and 'intentionally disingenuous'. [1] So we're clear: It really is still too difficult to search for most things online. My point is that state of affairs just doesn't matter. Maybe you could get more use from more people with better search. It remains to be seen whether people would rather search for themselves or whether they truly prefer to get their information through third party curators and aggregators. But clearly apps won't run into a roadblock because of search any time soon.

erikpukinskis 16y ago
the author totally skips the UX concerns I don't get your point. People do UX design on the web. Instead of opening your NYCSubway app, you just type "NYCSubway" into Google, touch the first link, and now you're on nycsubway.com, whose UX has been meticulously crafted just like the NYCSubway app. The point is that downloading apps is an unnecessary step.
- mrbogle 16y ago
  It seems the article is talking about having some search interface call some data providers, then display the data returned by the providers. I imagine what your parent was trying to say was that the search interface cannot generify the display and interaction with the data provider's data.

RyanMcGreal 16y ago

> When I query for Rockefeller Plaza and I’m sitting at the Thompson LES, a logical intent is travel to/from Rockefeller. For you, this may be a logical intent; but it would be a bad idea to try and generalize to a whole population of users from your own anecdotal experience.

rmc 16y ago
"Hello it looks like you're trying to take the subway, would you like help"
- jamesjyu 16y ago
  That better not be clippy saying that :)
erikpukinskis 16y ago
That's why Google gives you a whole page of results/widgets, not just one.

phlux 16y ago

Heh - apropos.... I am working on this very thing. But for a specific vertical.

sfphotoarts 16y ago

Apps provide a thick-client experience (richer UI, off-line storage etc) and people when they want to do a specific task know what to use. It seems obvious why until the web can be all things to all people we will always have apps. 10B to be precise! Clearly a lot of people like them. Until native UI features are available using a web based driver there will likely always be some advantage to a slightly thick-client. Exposing UI features is a battle, look at the past for details of hard this is, ActiveX for example. In theory this would have made all Windows UI components available to the web browser, until someone figured out that a security model would be necessary that handicapped things so much it led to Flash. Now we are a decade and a half further on and technologies like jquerymobile will likely see many web solutions be more app like. Once Apple figure out a better way to save a web 'page' to the home-screen that's intuitive and provides for local storage we will see apps.

eyeareque 16y ago

Remember the first iPhone? You weren't supposed to need to install any apps because you could just make a web page to do the same thing. Apple has served up 10B apps to date.. so developers will be making money from selling "useless apps" through app stores for at least the next few years. I can see this changing if wireless phone data networks can speed up network latency. The web is too laggy on phone data networks at this point IMO.

uxp 16y ago
This was my frustration with Google Voice and Google Wave homescreen bookmark "apps". Both of them were extremely laggy and took minutes to fully load. Definitely not the experience I desired.

deleted 16y ago

[deleted]

guynamedloren 16y ago

This entire article is based on an extremely flawed assumption. Introduced in the second paragraph, the assumption is that people are confused by this foreign and complicated idea of "apps". Never in my life have I met a person, young or old, who does not understand what an app does (since they have acheived mainstream popularity within the past few years, largely thanks to Apple). Sure, they may not realize that an app is just a few lines of code that pushes queries and pulls data from the cloud, but honestly - does it matter?

deleted 16y ago

[deleted]

contextfree 16y ago

Nota bene, the author is a PM at Microsoft on Bing. (Not meant as a 'gotcha', just a bit of possibly interesting context.)

stevenp 16y ago

I'm the developer of Routesy (routesy.com), a public transit app for SF Muni/BART/Caltrain/AC Transit. My app has been around since the first day of the app store, and I get asked this question all the time. The short answer is that Apple gives me two important things: 1. A decent development platform with UI controls that provide a good, familiar user experience 2. A marketplace that lets my app make money so I can afford to continue developing it I've done some offline app development using HTML5 as well, and these apps just don't "feel" the same. Had I taken the HTML5 route, it would have been far easier for me to port my app to Android (which I haven't done yet), but my experience has been (at least for productivity and utility apps) that the more native an application feels, the better it sells.

neworbit 16y ago

There are two good rebuttals to this article: 1. Apps are useful in an offline market, like when you are in the subway with no data service. 2. People don't like micropayments. They are willing to put up with ads instead. Why do people keep flogging micropayments and ignoring actual customer behavior? On-search-result ads will get you some slight income without the hassle of trying to get your customer base to adopt some wacky and ill-supported payments mechanism. I feel that the dismissal of apps in favor of a major shift in customer behavior is at best a sign of detachment from what the end user wants. (And I would tend to go further into "boil the ocean" and "architecture astronaut" thinking but that is not likely to be productive here, so let's leave well enough alone.)