

Why should I have to install an app to figure out subway times? - jheitzeb
http://stefanweitz.wordpress.com/2011/01/16/deep-plane-thoughts-the-appocalypse/

======
roc
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
_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
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.

~~~
roc
Pretty much.

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).

------
RyanMcGreal
> 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
"Hello it looks like you're trying to take the subway, would you like help"

~~~
jamesjyu
That better not be clippy saying that :)

------
jws
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
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
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
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
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>

[2]
[http://www.citygoround.org/apps/nearby/?q=san%20francisco,%2...](http://www.citygoround.org/apps/nearby/?q=san%20francisco,%20ca)

[3] <http://www.gtfs-data-exchange.com/>

~~~
erikpukinskis
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?

~~~
enf
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
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.

------
stevenp
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.

------
cstuder
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.

------
sfphotoarts
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.

------
cletus
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.

~~~
nkurz

      > 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.

[https://www.customerservice.att.com/assistance/faq/qa.jsp?fa...](https://www.customerservice.att.com/assistance/faq/qa.jsp?faqCategoryId=ld_shop_faq)

\---

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.

~~~
cletus
Ok, thanks for that.

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.

------
neworbit
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.)

------
akgerber
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
* 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.

------
eyeareque
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
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.

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

------
TetOn
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.

~~~
there
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.

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

------
phlux
Heh - apropos....

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

