Comment by thangalin | Hacker News Reader

Comment by thangalin | Hacker News Reader

Parent Full thread

"Reasoning from first principles: What’s the least information I need to collect from the user to make the app functional?"

Functional web apps do not need any user information.

People should be able to use the app without having to submit any contact details. An account is created for them automatically, and, presuming they like the app, they can provide contact details later.

Similarly, most apps do not require passwords at all. E-mail authentication provides a better security layer than forcing users to pick yet another (insecure) password.

The algorithm for using the site becomes:

1. System creates an account with a unique account ID if the user has no site cookie.

2. User, upon being impressed, provides e-mail and name.

3. User can sign in later using their e-mail address.

4. User receives an e-mail with a login link to click.

Most users these days will already have their e-mail application open (be it Outlook, GMail, etc.), so leveraging all the work that has gone into making e-mail secure is a win.

This works if the ultimate goal is to sign them up for a free account. But what if the goal is to convert them to a paid account after a certain trial period? A user can just clear their cache or cookies and use it free indefinitely.

In freemium models, some features are free. People should be able to use the app without submitting contact details. I did not state that all features had to be free. Enough features should be available that users can quickly understand premium account benefits. Deciding what features to make free vs. premium can be a difficult business decision.

Then, unlock premium features for registered (paying) accounts. (Trial periods require superfluous tracking code that offers little business value, if any.)

See: http://www.forbes.com/sites/brettnelson/2013/07/23/the-freem...

For the life of me I can't find the link right now, but it was from Pat and Bingo Card Creator. He requires an account for troubleshooting and support purposes. The vast majority of support is from first time/free users and when they did not create an account, support was a headache at best and impossible at worst. Perhaps there were other solutions for him, but if you can get people to create an account and it makes your life easier, why not?

A/B testing could determine whether my hypothesis is correct, which is: more people will use and share a site if an account is not required to use its minimal functionality (think pastebin, jsfiddle, and Wikipedia) because account creation is a barrier to usage.

Thought-experiment. Imagine two nearly identical websites: one requires registration and the other does not. What site will people be more likely to use?

There were other solutions to the troubleshooting problem. For example, only registered accounts can contact for support. Note that there are three types of accounts: an unregistered account (free), a registered account (also free), and a premium account (paid).

Sure, but one really has to ask themselves whether it's worth that trouble.

I'm certainly not saying you are wrong, but looking at a product like Bingo Card Creator -- something that's really only worth keeping up if the work is minimal and the profit's fairly steady -- I doubt I'd go to the trouble.

And as someone who works for a public service institution, the "only registered accounts can contact support" is a nice sentiment, but rarely works in practice. What ends up happening is that people didn't read that particular piece of fine print and now their pissed that you won't help them and you'll never make that conversion to a paid account. Obviously Pat tried it your way and made the determination that it would be better for his product’s future to limit engagement.

You're working on the assumption that engagement and conversion of the maximum number of people is the sole goal. Perhaps there are other considerations that creator has.

It's nice to work from first principles, but once the product is on the ground, you really have to revisit your own goals for the product to make a determination what will work best.

So really, the answer is to use payment details as user information.

That seems like a great idea. /s

Where did I say to use payment details as user information?

Persistent state (e.g. documents, settings) only available to signed-in users?

> so leveraging all the work that has gone into making e-mail secure is a win.

What? Email isn't close to secure.

The point is that e-mail vendors (e.g., Google, Microsoft) have dedicated far more resources and effort to securing their e-mail software (e.g., GMail, Hotmail) than start-ups will, or can, dedicate for their own authentication component. (For example, how often are all GMail passwords been stolen?)

I am suggesting that the authentication process for e-mail is far more secure than what a start-up could produce to authenticate for their own site. I am not suggesting that e-mail is NSA-proof.

One can hardly count on users always having one of the big provider mail accounts and beyond the big providers, most email is still sent across the wire unencrypted. Email isn't generally script kiddy proof, let alone NSA proof.

While I like the idea of login via email link, it's only good if the login link expires very quickly.

Email is not an auth mechanism, if you want to rely on the big providers to do auth, they have systems specifically for that already.

Most websites use email as the password recovery mechanism. "Authenticate by email" is strictly better than "authenticate by password or email".

Reply on news.ycombinator.com