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.
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.
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.
The author's identified 'problem' is: I can't find a subway map when I need it because it's too difficult to find and install 'an app for that'.
My reply was working from the assumption that the author was proposing a solution that was designed to address that.
If the context-sensitive search site is merely identifying that I'm looking for a subway map, and then forwarding me on to one of 10,000 disparate subway map web services as erikpukinskis seems to be suggesting, users will inevitably bookmark the web service interface they like best and query it directly in the future. Leading to the same use scenario as with apps. The only differences being trivial technical ones (from the standpoint of the user).
> 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.
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...
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.
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.
Neat. I saw the list you have on the front page of 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?
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.
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.
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'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.
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.
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.
> 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).
It's somewhat off-topic to your main point, but I'm from the US, and I don't think this is true. While there are flat-rate calling plans, these are new and more commonly associated with VOIP lines. I think that most people in the US still have plans with very complex rates based on destination and time-of-day. For example:
---
What are AT&T basic rates? What is the AT&T basic rate plan?
They are the standard long distance rates charged to customers who are not enrolled in an AT&T Long Distance calling plan. There is a $4.95 monthly recurring charge associated with the state to state direct dialed basic rate plan (sometimes referred to as the basic rate plan), which applies each month whether or not a customer makes a call. The current per minute state-to-state basic rates are as follows: 42¢ Peak (7 AM - 6:59 PM, M - F), 36.5¢ Off Peak (12 AM - 6:59 AM and 7 PM - 11:59 PM, M - F) and 15¢ on Weekends. In-state basic rates vary by state.
Incredibly, due to federal telecommunications regulations, the in-state rates have historically been higher than the state-to-state rates. What you say is true about local calls though, where "local" is a complex term of the art rather than something simple. And times are changing --- for all I know, no one buy my family members are still on the traditional plans.
With regard to apps, I think I see it opposite to the way you do. Previously, most small apps would be directly accessed as free websites with no metering. Now, more of these micro-services are moving to becoming paid apps, free-loading on top of the public web sites. Would you be comfortable with the NYC metro deciding not to put up a public information site at all, and offering only a paid app? I worry this the direction things are headed.
Perhaps my perception is clouded in this regard. I've only lived in the US for a few months (in NYC). I'm from Australia. Whenever I've seen phone plans they're part of cable plans (eg Time Warner) and the package options are either without phone or with ($30/month, unlimited nationwide).
I was also in the US in the 90s and saw the same thing then.
In Australia the move has been to cap plans, particularly for mobile. So you'll pay, say, $49/month for your phone and can use $400/month of credit on voice, SMS and data (actually a lot don't include data). Voice might be $0.50/minute, SMS 10c, data $100/GB, which may sound a lot but remember you're paying $49 for that notional $400.
Why do they do this? Because customers like knowing that most of the time they pay $49/month and because if you go over your bill can quickly go up. So it's really a tax on the stupid. My nephew for example has had bills of hundreds in a month when in fact a $150 cap would be more than anyone could ever really use.
> People generally prefer flat cost models for simplicity, even when it means they pay more than they would had they paid for each call.
Not just in the tech realm. From the Wikipedia page on the Carte Orange,[0] an institution of the Paris metro for decades that let you ride as much as you wanted for a flat fee:
While transit authorities had estimated that 650,000 Cartes oranges would be sold, within 6 months of its introduction 900,000 were in use.... they assumed that only those public transit users who would save money with the Carte orange would buy one, but this was not to be the case. Many people were attracted to the idea of using Parisian public transports without worrying about tickets or fares, even if it proved to be more expensive.
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.)
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."
* 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.
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.
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.
Also worth noting that non-app solutions do exist. [NextBus](http://www.nextbus.com/), for instance, includes both a web interface and an SMS-based query centered around texting it your stop number.
i wrote 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.
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.