I completely disagree. Most app/website referrals aren't verbal. Verbally communicated referrals are easily forgotten (e.g. "what was that photo sharing site Mike was telling me about at the party last night?") Most referrals are via an email that includes a URL, a blog post or tweet from someone you follow, or an email generated via the "Share" feature within the app itself. All of these eliminate the "search" problem, and reduce the time to launch significantly.

In 2012 I consider twitter, email, facebook and so on practically verbal communication. If I found out about something through a friend's tweet, I would tell you that I got it verbally, by word-of-mouth, when you asked me.

Can you point to data showing that most app referrals aren't verbal?

No, it's anecdotal evidence.

it is reality for my business, on both fronts.

While amusing :) it's not really accurate. The Web part is missing "finding the correct link on search results (damn Google keeps changing, also everybody is running out of unique names it seems)", "finding the signup button or free plan on plans&pricing (sometimes you need to find the p&p first!)", "oauthing via twitter/fb or registering (if registering, then creating another pass, verify email, log in)". Unless the Web example is a simple, non-interactive content site. But where's fun in that?

You also have to look through the app store's search results. And sign up in the app if it requires it.

Actually, if the app requires sign up then I close and delete it (unless it's a mobile interface like Skype).

But after the user downloads the app, it's a fixture on their home screen. They can use it now, use it later, use it repeatedly.

The web side needs a 0th step: "What was that URL you sent me last week again? I forgot..."

It's getting better with omniboxes. At worst you need to do a history search. Really, the web is too vast to be browseable through icons.

Ah, but sudo apt-get cal<tab><tab> brings up virtually all the apps I need.

He forgot a few steps for web apps revolving around registering -> checking email -> validating -> load first run page

That only applies to sites which require user accounts for being usable. Also using existing logins simplifies this step quite a bit.

That's why we have things like browserid and oauth

The only advantage of native app stores is in gaining initial visibility/traction. Things like the google chrome store are not good enough for that. We should have something effective for web apps instead of infesting HN, reddit and various blogs. Are there any startups working on making the process of bootstrapping a new web app easy?

I launched Threddie.com two years ago by submitting to web app directories like appstorm.net . It was a manual and repetitive process which bored me half to death, but it still yielded better long term results than posting on HN & reddit or cold mailing big tech blogs.

From that experience I did notice that getting listed on a relatively big one like KillerStartups.com always resulted in an avalanche of automatic listings on smaller directories and blogs - as well as a lot of twitter activity.

From poring over google analytics, and talking to users, I concluded that while a lot of that chatter is automated garbage, it does often end up being read by real people who follow the links and sign up for the app.

All of this is to say that potential web users are scattered across too many discovery vectors to solve the problem by simply building The One True Directory.

What could be done, maybe, is build a sort of central repository to which developers could post their apps in a standardized fashion and then have those listings freely available. That repository could work a bit like Crunchbase, except with less focus on money & people and more on categorization & features. Ideally, app directories would then consume and relay that information to their audiences - editorialized or not.

Such an initiative would require massive participation by app developers, which, of course, is the real crux of the matter. In practical terms, there would be little difference between building a solution now or simply flocking massively to one of the already available directories. Which begs the question: why don't we?

There have been many central directories in the past. What is needed is people to actually give a go at the apps and spread them virally if they like them. One would need to organize a large pool of mechanical turks around a pay-to-submit-your-app model.

I agree with you, and I'm working on a solution as we speak. I'm looking to feature web app submissions real soon. If you would like more information or just want to chat, please email me at contact(at)webmenu.org. :)

I think you can download Android apps directly from the web to whatever device you select. Yet, I use an iPhone.

You can, and any URLs to the play store will offer an option to be opened in the market. Which also won't ask for your password.

Instant open apps would be nice, that's something that should be aimed for I think.

But...the chart stops at "Open App", at which point the comparison is "Rrrruuuunnnn" vs "RunRunRunRun".

It really depends. I know web sites that are super snappy and apps that are dog slow.

And I would wager the minimum possible startup time is actually smaller for a web page than an app. Apps usually take at least a second or two to open for me, and Google has their page load time down below a second, right?

Either way, your choice of platform is not going to be the thing that prevents you from building a fast app. It's going to be your failure to use the architecture well.

  > I know web sites that are super snappy and apps that
  > are dog slow.

Yes, but would dog slow app implemented as web app be any faster? Or even more slow?

iOS 6 now lets you update your apps without a password, but you still need to enter your password to download a free app.

I don't understand why you need to enter your password to download a free app. At the very least, you should be given an option to turn off the password protection.

The reason that a user has to enter his password for a free app is to train him to enter his password for a paid app.

If Apple didn't do this, their users would forget their passwords and stop buying apps.

A lot of free apps are basically 900 numbers. Free to get, but then they want you to pay $4.99/minute to play/work/have information.

I think a long time ago (a year?) the in app purchase options didn't require passwords, so password-to-install was the only line of defense. It may be a holdover from that.

What used to happen was that you had to enter the password to download the app, then for 15 (?) minutes the device remembered your password and would not ask you for it.

This blew up IIRC with the Smurfs kids game, one of the first really popular freemium games. A parent would download the game, hand the device to the kid, and the kid would be free to make as many in-app purchases (or other games?) as he/she wanted. Someone got a bill in the thousands and complained.

Apple changed it so password entry for paid content must be re-entered for each purchase. Free apps and updates still required password to download, but honored the 15 minute window. With iOS 6, updates do not require the password at all. Combined with the strict limitations for auto-renewal payments (subscriptions only allowed for music, magazines and video content), it's pretty hard now to spend money by mistake.

the app store does make up for this deficiency in other ways though.

- app reviews (incl. facebook integration now) that make it a lot easier to know whether the app is working/useful/great.

- highlights in the app store app itself. sure this is limited to what Apple chooses to show but there's no perfect equivalent on the web (maybe HN or TC?).

"But once a user has signed up, make sure you take them by the hand along the funnel." A few weeks ago, Danielle Morrill of Refer.ly, blogged about a her company's new user onboarding process (http://bit.ly/QZ9cxt). She was apprehensive at first to "hand-old" first time users, but ultimately the strategy worked for getting people to share their first piece of content.

My question follows: What's the rate of returning users that create more than one piece of content when using a hand-holding on-boarding strategy compared to using a very minimal on-boarding strategy? That might be the next step in Gabor's chart.

I think the point is right, but comparing is to web was a poor choice. They both have their own challenges that are unique to the platform.

I've never had to enter a password to install an app.