Forward Thinking: Scriptable Webmaker Tools
Recently, Brett Gaylor wrote about the prospective future of Webmaker in 2013, discussing the topic of “Content Types”. Using a promotional video from the days of black-and-white GUIs, he drew an analogy between HyperCard and Webmaker ideology. The idea isn’t new — in fact, Ben Moskowitz had written previously about his own inspiration stemming from software like HyperCard and ResEdit. But Brett’s video really drove home the point for me.
While developing all-encompassing UI’s for tools is ideal, it’s also very hard. However, giving users the ability to script in the context of a tool alleviates much of the pain in designing the ultimate extensive UI. Moreover, it incrementally teaches the user the memes which stir around the tool and how to use them expressively to become super-users.
Naturally, I started hacking away at a prototype of this type of functionality in Popcorn Maker.
Originally, one of the goals of Popcorn Maker was to show the user the Popcorn code being built for them with the tool. At every turn, the user should be able to open the hood and look at how their project’s code changed to deliver what they see. Over the course of last year though, as Popcorn Maker really grew legs, that idea was supplanted by other inexorable demands more central to the comprehensive functionality of a web app — all the things usually neglected at the beginning of a fast-paced project born from a prototype, like dependency loaders, layout systems, build environments, sane architecture, bugs, bugs, and bugs.
Instead, Popcorn Maker boasts with a pretty versatile UI system. It’s not too hard on the eyes either. But, after a bit of regular usage, it’s easy to see where digging your hands into a script is sometimes preferable — especially for an experienced programmer.
For example, using the plugins that ship with Popcorn Maker, the timeline has exactly one control flow. In other words, there’s no way for decisions expressed by the user to affect the content of the presentation itself.
They can use the play/pause button, click on images and links, skip around the video, but the video still lacks the elegance of interactivity that can be attained with a bit of customization.
If I want to prepare a Popcorn Maker project that will show content contingent upon the number of prior visits by the user the project’s content needs to be somewhat intelligent. That sort of functionality could be built directly into the plugins, but it’s hard for plugin designers to define everything that should or should not be possible, and present some configuration options to help.
Still, using an expressive UI is favourable over writing everything out by hand, so meeting somewhere in the middle is best. And, of course, this idea has pervaded software even earlier than Hypercard. From Adobe’s creative product suite to modern game engines, there is a distinct and purposeful line between the parts of software architecture that are meant to be malleable, and the relatively steadfast parts that support them. Nobody wants to write NPC scripts in C++, nor is anybody looking to write pixel shaders with Haskell. Large projects provide several important vectors for contribution at different levels, and depending on the piece of the project or the type of work, a user or contributor must choose which is most appropriate (or is forced to through architectural decisions).
To test all of this thinking in a prototype, I created a branch of Popcorn Maker with a rudimentary scripting environment for the Text and Image plugins.
The Text and Image editors have a “Scripts” tab which exposes some opportunities for the user to add some extra customization or flexibility. For now, scripts are chained to specific events, like “onStart” and “onEnd” which are executed during the respective “start” function and the “end” functions of the plugins.
Scripting of this sort doesn’t only benefit Popcorn Maker’s users. Developers at all tiers often enjoy the opportunity to talk to the app at a higher level when implementing features. In the same branch, I made some potential improvements to the layout system by applying the idea of a mixin. In Popcorn Maker’s layout system mixins can be used to describe a piece of UI that the developer doesn’t need or want to know everything about. As an example, here’s the text editor rewritten with “buttermixin”s.
<buttermixin type=”editor” editor-classes=”default-editor”>
<buttermixin type=”editor-tab-item” tab-classes=”basic-tab butter-active”>Basic</buttermixin>
<buttermixin type=”editor-tab-item” tab-classes=”advanced-tab”>Advanced</buttermixin>
<buttermixin type=”editor-tab-item” tab-classes=”scripts-tab”>Scripts</buttermixin>
<buttermixin type=”editor-body” body-classes=”butter-tabs-spacing”>
<buttermixin type=”editor-body-content-container” classes=”advanced-options display-off”></buttermixin>
<buttermixin type=”editor-body-content-container” classes=”scripts display-off”></buttermixin>
When Popcorn Maker starts, this code is exploded into another piece of HTML incorporating predefined UI widgets. Instead of needing to know how to structure the DOM for an entire editor, one <buttermixin type=”editor”></buttermixin> will create most of the important parts that Popcorn Maker expects in order to display an editor correctly within the app. With features like this one, prototyping is far simpler because the time to look up specific CSS properties and DOM structure is reduced, and mistakes are mitigated since forgetful boilerplate syntax is inserted automatically.
I love being able to exploit flexible systems like the ones available through browser technology to implement architectural features. The benefits are often felt throughout the code base and its developers. I’ve only begun to carve away at the landscape of high-level scripting techniques available to web apps like Popcorn Maker. When I’ve got a more punchy example (perhaps a screencast) of these features, I’ll certainly put it up.
- secretrobotron posted this