Chapter 12. Design Ideas

This is a compilation of ideas for different approaches we might take in making a live code sandbox. The code could be executed by a couple of backend options, such as:

At some point in the future I’ll write up the pros and cons of each of these approaches.

Surfacing the Sandbox

Probably the first step is to figure out how to surface it from within Atlas. There are a variety of possibilities:

  • Every listing is in the sandbox. This is what we’re doing with JSBin’s now: each one is a live box that is inline with the reading experience. This would probably cause performance issues.
  • The listings would be plain text, but you’d click an icon to pop open the sandbox. This is how JQuery Fundamentals works, and it’s really effective.

Of the two, I’d tend to lean towards the "click an icon on the listing to pop open the example in a live editor." Here’s an example:

Code Sandbox

Probably the most basic way to start is an unstructured sandbox that allows you to type some code into a box, press the "run" button, and view the output on a console. (Basically, this is a repl.it clone.) Here’s a sample design:

Some key features include:

  • We’d use the Ace editor to let people create the lisings
  • You’d enter your entire file so that you could execute it
  • There would be a way to pre-populate a file
  • The output is directed to a collapsible output window in the sidebar.
  • If you click run and the output window is collapsed, it should pop open
  • For fun, it has a "gist" button that would allow you to save this to a gist in your own github account.

Live Terminal

We could also do a basic REPL terminal using JQuery Console to capture user input in the browser and then send it to an interpreter so it can be evaluated whenever someone hit enter. Here’s an example of how this might look:

It’s unclear how much value this has versus the code sandbox, but I guess it would be nice to have a simple way to let people type arbitrary commands.

Heroku Sandbox (super theoretical!)

This is a coding in an environment similar to runnable.com. You’d be able to buy a product in Atlas, fork it to your account, and then work with it as you read through a book.

The main parts are:

Login to GitHub
This signs you into github and connects you to the correct repo.
Push to Heroku
I’m not sure if this is even possible, but the idea is that the user provides some heroku credentials that would allow a worker-like process to push the repo up to their account on Heroku. We would capture STDOUT from the worked and send it into the console window so that you could see what was going on. The Heroku API makes it seem like it would be possible to do this. We’d pass the user’s API key to the worker, who would then be able to push the repo up to heroku. Note that the worker would have to be added as a collaborator to the app, but this can also be done through the API. So, there would be a "atlas" account on heroku that you could push stuff too.
File Selector
This is like what’s in Atlas now — you’d be able to select files and navigate around.
Editor
Basically, this is the Ace editor as we have it now. There would be a simple set of menus / buttons to allow you to save, create new files, search and replace, or view the file at different points in its commit history.
Console
This window displays the output from the "Push to Heroku" process. Again, it’s basically STDOUT on a worker wired up via the Pusher API.