3 ms·
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 upl
by ed 19y ago
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).