Video first so you get the idea of how interactive controls could support playgrounds. You can watch the full-size version here.
Like all things Swift and Playground, this is more a proof of concept than anything practically deployable. You can download this playground and kick its tires from my github repo. If the running version appears dimmed, kick-start it with Editor > Execute Playground.
Deploying a demo-controlling slider to a separate floating window isn’t ideal. Its goal is to support and demonstrate playground code not pull attention away from it. It would be so much better if interactive GUI elements could be embedded to value history panes, the way that non-interactive views currently can be.
I love this demo because it seems to me that this is exactly the kind of thing a playground should be able to do. Here are a few other thoughts about playgrounds and interactive documents:
- Embedded examples need execution controls, specifically Run/Pause/Reset buttons. End-users should be able to reset your examples to their original states.
- Playgrounds should be paged. Most real world examples aren’t limited to a single filter, a single concept, or a single page. A single “wow” playground should be the starting point not the ending point of this technology. Paged playgrounds with tables of contents, glossaries, and more could provide an expansive interactive system that iBooks Author failed to deliver to an audience of API consumers and computer science students.
- Xcode isn’t Pages. It’s tough to create interactive playground documents using the current toolset. Xcode is not a text editor, let alone a nuanced rich text editor.
I have an entire section of workarounds in the newly updated Playgrounds book if you’re looking for tips. Here’s hoping the updated version will go live soon.