If the browsing user selects one of the samples on the site (which is verified easily with a quick hash on the client side), why on earth are you processing it again? Load shouldn't be an issue here.
Honestly, users shouldn't even be able to ruin your sales pipeline by interrupting your pitch. Why let us enter any markdown? It's an example, you have a few representative samples, just take their output and hard code it and move on. As it stands now, I probably won't remember to come back so see what this is all about, and waiting for an email isn't really going to increase the odds that I come back.
Just some honest feedback for you. TL:DR: I was intrigued by the first page, put off by the unnecessary wait when you could've hard coded the response when a user chooses an existing sample.
I might be misunderstanding your feedback, but I think you're asking why we enable the user to edit markdown in our "try it now" demo -- and thus "interrupt the pitch".
Our rationale with our live demo is to show what the content creation process looks like for our prospective customer. The visitors to a completed workflow won't have the ability to edit the markdown.
again -- I'm sorry about the limited number of users we can support at the moment (and thus the redirect to our signup page).
Disallowing editing is only one solution I suggested. The other is: determining that they haven't actually changed the sample text from one of the pre-canned selections, and thus returning the result from a static copy of a previously-performed transformation.
Edit: in other words, if a user changes the text from one of the pre-filled selections (MD5 hash of the text would be sufficient to determine this, or even simpler, note whether a keyup event was raised by the textbox), put them in the queue you're using now. If there was no keyup event, then read which selection was made from the drop down and return the already-transformed-in-advance result.
Making a potential "ready to hear your pitch" customer wait in line is unnecessary. There can be an "express lane" without compromising the "scenic route".
I think what OP was getting at was is if you're processing each example on the fly, why aren't the unedited default examples cached so if a user just hits "Run" they can see it working, regardless of whether it's their own content or not.
I think the explanation that might be missing here is that every user that hits "Run" gets his or her own linux container in which they will be working.
The process of provisioning a new container (especially under high load that we're seeing today) is what takes a few moments. We however do a fair amount of pre-allocation and other tricks to speed this process up.
Since the purpose of our product is to give each user his or her own execution environment to freely explore the software that stacktile is helping to demonstrate, we need to give that user access to his or her own container.
Perhaps the confusion is coming from the fact that a stacktile workflow is more than "pre-known" static content -- it is markdown coupled to a an interactive, running shell process in which code can be executed.
>"Perhaps the confusion is coming from the fact that a stacktile workflow is more than "pre-known" static content"
We know this. People are saying that you need to have some sort of "pitch" that can't be overloaded by too-many users.
So, either you provision a lot more containers to handle spikes like the ones HN gives.
Or, you scale automatically to handle traffic-spikes. Or, you do some sort of caching. Or, you have an explainer video/tutorial, something.
Just because your product is "interactive", does not mean you have to have an interactive sales-pitch. Because right now, you're losing the valuable attention of HN-eyeballs.
The big confusion is that nothing even says what this is truly about before you say "here, try it out". I can understand that having to spin up a linux container per user means there are large resource costs, but I don't understand why you need a linux container to make an interactive tutorial. Further reading on the page clarifies that you are giving terminal access to the linux container and such, but the initial "above the fold" content makes no mention of that, and nor does the "We can't right now, give me your email and I'll tell you when page". Knowing what's involved, I can now understand it, but from a fresh slate, it (to be blunt) looks like you either don't know what caching is, or your system is shit. You might consider an explanation of all that stacktile does on that signup page, so people can see "oh, it's giving me shell on a fresh container, of course that needs lots of resources and such".
I think the main point you're not taking yet Dan is that you SHOULD be able to accommodate every user in your sales pipeline demo.
Even if you fake it with pre-baked results or something in the meantime, Pick a sample->click next->load static html.
If they want to try out their own markdown, then worry about spinning up a container.
I tried it a couple of times. You only get prompted to sign up if the system is overloaded and it dumps you into the waiting queue. Otherwise, it goes right into the demo which creates a clickable preview to auto enter commands or you can type directly into the shell.
This looks promising. Nice work Dan and Stacktile team. Looking forward to seeing what the community does with it.
Maybe I can also share a bit more insight into what's actually going on behind the scenes. When a user on stacktile creates a workflow, we are also executing a linux container environment on their behalf. This container provides the interactive environment to run the code in the workflow, but it's also a resource (and operational cost) which need to limit at the moment.
That and for those of us seeing the notification that their server is backed up, I can't even see it in action right now. Seems like this should have been cached
Hi, Dan here again,
some of our visitors will hit our waiting queue today.
If it's any consolation, I can certainly appreciate the frustration some will experience due to this, but we're just bound by the reality of our wallet at the moment. We also mean no harm by inviting those in the queue to provide an email.
I would at least add a demo video or something to show how the product works. I had the same experience and was confused why the demo would require me to signup. At best, it came off as poor UX, at worst, a bit sleazy.
At any rate, it's an interesting idea. I would like to see a demo without having to signup for something.
My suggestion would be to simply tell people that the internet's hug has overloaded the servers, offer an apology, and let them know that you hope they will come back later.
The problem is that asking for email suggests people should trust the website at a time when there is no basis for trust and many people have substantial experience to suggest not trusting.
> The Data Controller reserves the right to make changes to this privacy policy at any time by giving notice to its Users on this page. It is strongly recommended to check this page often.
By the way, there are already services at least for automatic diffing: https://www.changedetection.com/ etc. (I don't know if this one is better than others, but this one has a memorable name; I have it pointed at one page, and get notifications from time to time, but never actually cared to dive in and check the diffs... :/ )
thank you for pointing this out -- the above user is pointing out a provision in our Privacy Policy. Our privacy policy is very much a work in progress -- we're a small team that put this policy in place as a first attempt, although I know that's not a very good answer. I fully agree with you that that clause in particular is quite draconian.
I have brought this to our team's attention and we will be reviewing it as soon as we can (A.K.A. as soon as we're done dealing with the huge influx of new users from HN)
we're giving people the option to sign up to be notified when we have a free slot, but you're not required to sign up to try us out. It's just that we have many more people coming to try us than we expected.
Just yesterday, I received a straight to voicemail all from a company from whom I once purchased software in 2007. My guess is that I'm in their lead database for upgrades that is given to new hires in phone sales. It got me thinking about email collection -- it's one of my standard feedback items on "Show HN".
Anyway, I thought for a moment about the fact that there is no company that I love so much that I want to receive periodic emails from it. Not even Taco and few companies do engagement emails as beautifully designed as Trello.
There's a scale at which bulk email operations make sense. I don't think the "doing things that don't scale" is the right stage for optimizing. Usually, emails are another TODO item in the receiver's inbox. They're not solutions.
The usual scam, they ask for email and try to gather more leads.
```
Unfortunately, we are out of free slots at the moment. We're Sorry! If you would like to be notified as soon as we have a free slot available, we invite you to sign up.
```
I'm sorry if you hit an error, we're a victim of our own popularity at the moment. We're working to accommodate pretty huge the increase in traffic from HN.
Honestly, users shouldn't even be able to ruin your sales pipeline by interrupting your pitch. Why let us enter any markdown? It's an example, you have a few representative samples, just take their output and hard code it and move on. As it stands now, I probably won't remember to come back so see what this is all about, and waiting for an email isn't really going to increase the odds that I come back.
Just some honest feedback for you. TL:DR: I was intrigued by the first page, put off by the unnecessary wait when you could've hard coded the response when a user chooses an existing sample.