Comment by PinkPigeon | Hacker News Reader

Comment by PinkPigeon | Hacker News Reader

Parent Full thread

So I think this is an excellent point. I'd love to do something like that for my product as well.

However, there are a few considerations, some of bigger consequence than others:

- How do you keep users from losing their data when they leave and come back? Cookies with an ID are a brittle solution. You could have a unique link, where the user's work is saved right up until they want to register

- How do you deal with the inevitable onslaught of people using an open system? If you're bootstrapping like me, I don't think I could possibly handle the influx of an HN frontpage's worth of people simultaneously hammering the system

- When do you clean house? You won't necessarily know whether someone wants to build a site, disappear for a month and then come back to it. Feels unlikely, but it's still possible.

All of this would be solved by having (at the very least) a quick email-only signup, which auto-generates a password and a welcome email, but also takes you straight into the system. It's a small barrier to entry, but perhaps one that's worth putting in place to avoid hammering the server(s) too much?

What do you think of video content showing off the system, could that help as a sort of interim solution?

You could require a login after someone has added at least 5 objects and/or spent at least 5 minutes making edits. This makes sure that if data is lost, it's nothing that can't be easily recreated.

After at least 30 seconds of activity, you can display a prominent banner at the top of the page that says "make a free account to ensure your work is saved". Then it's clear that your ability to retrieve their data upon their next visit is a favor and not something they're obligated to. It's not exactly the same, but you can look at CoderPad's sandbox notice as inspiration for how to word this: https://app.coderpad.io/launch-sandbox (Note: you'll only be able to make one sandbox per cookie, so visit this in incognito mode)

To address scaling, you can probably limit the total number of "logged-out users" who are currently editing. If more users visit the site during the same time period, require them to make an account, just like you are now. If you're worried about users expecting a playground and getting confused, you can look at Google Docs's "This is getting a lot of traffic, you're in read only mode" notice that appears when more than 50 people are visiting a doc as an example of how explain the situation in an easily understandable way.

Now that you've properly set user expectations, you can clean house whenever and it should be okay.

btw, I just tried out this tool and I think it's awesome for a lot of the reasons mentioned in the top replies. Hope some of this is helpful + wishing you best of luck!

These are all really good, creative ideas!

Fantastic tips. I think some of that will end up in my own work.

I never watch videos personally, but that's more because most of them are terrible and don't help than anything (they either just talk about it and never show the actual product, or take 5 minutes introducing themselves before the 1 minute demo, etc.). I'm sure it could be done right though, but I'd bet other people have also been trained not to click videos.

The email gate sounds good (except don't generate a password that will then be visible in plain text, generate a one-time login that can't be reused after a certain amount of time and give the user the option to set a password later if they want one); sites could expire after a bit and a real account (where the site doesn't expire) could only be created if/when the user chooses to create a password and you can't save or use features that could trigger emails until you've verified your email or something.

Yeah, I can't stand those videos. With anything I do, it's straight to the content and as short as possible always. Though I agree with you about videos in general. I always prefer text-based tutorials. But many friends of mine are video fiends, so I always make both :)

Serializing the user's session state to LocalStorage comes to mind as a reasonable solution. Comes with it's own caveats, of course (you now have a state versioning problem), but addresses all the points you bring up pretty adequately:

1. As long as their on the same device/browser, they lose zero data. This is a pretty reliable happy-path use case.

2. The only onslaught you'll deal with is simple pageviews since everything in the trial is stored client side, which also makes #3 no problem.

Very good point about LocalStorage, I haven't explored that avenue yet.

Re your second point, unfortunately with my product this works a bit differently. I'm generating static websites in the background, as part of a realtime-preview functionality. That, unfortunately leads to reasonably high server load.

I'll have to have a think about how to approach that in the future :)

Reply on news.ycombinator.com