How about automatically created anonymous user accounts and ability to later merge into a regular user account with username and password.

An anonymous account would essentially identify a single browser and enable server side storage required for full application functionality.

Should the user later feel like the registration is worth the trouble after all, he could merge one or multiple anonymous accounts into a single regular account.

One thing to think about in advance could be to prepare for merging data from multiple accounts.

I think Amazon shopping cart did something along these lines?

We are using this method on our site. Create temporary user on the fly and let the user overwrite it if they select to save their state and it works great for us. I think just by renaming the registration page to save work page gives you an advantage since the users are sick and tired of having to register in order to get any value.

I think this is the way to go. I am taking this approach for a multi-player game I'm developing - you can play without registering, but you can register afterwards to save your score.

My primary project, mystorespace.com, takes a similar approach. We have a fully functional demo accessible without an account (you will be automatically logged in as testuser@mystorespace.com). I really don't like having to register in order to try something, so I assume most users feel the same way.

You can only offer a limited feature set if you lack true user accounts. Photoflock.com for example relies purely on client persistence to manage the user's upload history. It's a simpler solution than requiring accounts -- there's less friction for a user to begin interacting with your site (ie no registration process) -- but doing things like tracking accounts and providing reliable usage stats is pretty difficult.

Additionally, your users will never be able to (easily) sych between computers and to be honest you'll eventually add user accounts anyway. That's not to say that you'll implement a full username/password scheme, but you will need some sort of server-side persistence.

That's where I'm at in my development right now, and I'm looking at a happy middle ground where the user CAN have an account (optionally) to do things like sync between computers but will vary rarely be asked for account information. My advice would be to sketch out a road map and assume that you will eventually add some sort of user account -- and then architect your site so that when you make that transition your users won't lose all of their data (as will be the case for photoflock's history data).

If I understand, you're saying people use your site to do a bit of video editing. In this case, I guess the purpose of registration is to save user state, beyond sessions/cookies. Therefore, you could simply have a 'save' button, only asking for name/pw once it has been clicked. This way its up to the user to decide when/if to register.

I was actually pondering about this one time. Do we really need user registrations and accounts? The answer I can give you it depends on what app you're building.

I would say yes if you require your user to save some sort of content online. Giving them incentive to come back to your site.

I always thought that user registration adds friction to any app. I guess it all comes down to how it's implemented and how easy it is to get user from point A to B on your app.(e.g. reddit's way of user registration comes mind) Although the implementation of OpenID should ease that restriction a bit.

In short I personally like the idea of not having to register on your app. Why don't you try it? see if users like the system. Besides it's their opinion that matters anyways. Is seems like a novel way of approaching web apps these days. Hope this helps....

Thanks to everyone for all the great feedback. You all present really good arguments on the topic... I think the "best" solution for my app would be to create the temporary account converted to a registered user upon save. Like some of you mention, I will probably end up registering users at some point but I don't think what I'm offering now justifies a sign up...

I was thinking about making it very basic, no registration, user can create and save but they have to take care of tracking their own edits... bookmarks or taking the embed for a one time use. I realize it would not be all that feature rich but does it need to be?

Light, nothing to commit, like tinyurl with video edits...

Here are a few valid reasons, from a user's point of view for registration:

1. I want to use your site on different machines.

2. I have no idea when where my cookies go or do, but I know it's good to delete them from time to time.

3. I have information on your site that I consider semi-private.

4. I really like you app, and I like being a part of your community (assuming you have one).

5. I really like the people who use your app. (You've already said this isn't valid in your case)

I wouldn't discount the first three points though.Instead of requiring it, just make it optional and ask why people are signing up during the process. They'll let you know.

Good luck!

Many blogs require an email address if you want to comment. I've never understood why. I just enter a bogus address

If they require you to activate your email address, it's probably to reduce spam. That, I think, is a very good reason to require registration.

Why do we require user registration? Because the value of an application is usually tied to the community it serves. The larger the community, the more value. Without a login, it's more difficult to gauge the community.

Also, personalization of site. You could do that solely with a cookie, but then when I'm on another computer ...