Hi, Dan from stacktile here,

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.

I figure that's what you're doing, but man, why do you want to re-run a container when the result is already known?

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.

I hope that helps clarify

>"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.

This is absolutely correct. OP unfortunately missed this opportunity. Let's hope other readers don't make this mistake in the future.

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".

Hi, point taken: we can explain on the signup page in more detail why we can't accommodate every user.

Thanks for the feedback.

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.

From what I've seen, part of the "result" is a connection to a linux terminal. Not exactly easy to pre-bake that.

Yeah, you should not process your four examples over and over with that cost

Exactly what I thought. Crazy to be prompted to register an account when I'm just trying to run the demo

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.

thanks for the kind words

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