Why should I have to install an app to figure out subway times?
stefanweitz.wordpress.com
stefanweitz.wordpress.com
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.
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).
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.
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.
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
[2] http://www.citygoround.org/apps/nearby/?q=san%20francisco,%2...
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?
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.
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.
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).
---
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.
https://www.customerservice.att.com/assistance/faq/qa.jsp?fa...
---
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.
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.)
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."
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.
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.
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.
I am working on this very thing. But for a specific vertical.