Introduction

nimble |nimbəl| (adjective):

• quick and light in movement or action; agile.
• (of the mind) quick to comprehend

Webmaker is trying to provide the necessary building blocks for people to teach and learn web literacy. To that end we have built Popcorn Maker for creating web media, Thimble for interactive HTML, CSS, and JavaScript code editing, and X-Ray Goggles for live exploration and modification of existing web pages. All of this is tied together with a unified publishing, indexing, and discovery service we call the Make API.

In what follows I propose a new tool called Nimble. The name makes obvious reference to Thimble, which is intentional: Nimble is (eventually) a drop-in replacement for Thimble, but also something much more powerful. Nimble is a progressive HTML, CSS, and JavaScript learning and coding environment that grows in power and complexity along with its user. Fundamental to Nimble is the idea of configurable feature addition/removal based on a) the needs of the user (i.e., their skill level and understanding); and b) the requirements of a particular learning module, tutorial, or make.

From Thimble to Nimble

To understand the promise of Nimble, it's important to first look at Thimble, it's strengths and weaknesses.

What is Thimble?

Thimble is live-edit coding environment made up of a few parts:

1. a code editor, based on Code Mirror
2. some intentionally minimal editor "chrome" (e.g., Undo, Font Size, Show Hints)
3. an HTML parser that provides extra help for beginners learning to code called Slowparse
4. a preview iframe, which provides secure (i.e., different origin) live preview of the code being edited in the editor.

Thimble is a stripped down editor aimed directly at the first-time user of such a tool, and those who would teach with such a tool. In its present form, it has been very popular and useful. Thimble does an excellent job of putting the code being worked on front and centre: nothing needs to be installed, there's no complex setup for seeing the rendered result of the code in the browser, there aren't complex menus or hidden options. Thimble is simple, to the point, and effective.

Thimble also has some shortcomings. First, its greatest strength also turns out to be a weakness over time, since Thimble can't grow to meet the evolving needs of a user as they learn more about the web; it's stuck in first gear. Second, Thimble isn't easily extended, and overlaying new types of pedagogic or development information is tricky. For example, early versions of Thimble included instructions to users via inline HTML comments. Today Thimble uses a separate Tutorial view, but adding it wasn't easy.

How to Improve Thimble

Making Thimble more capable without undermining its main strength, namely, its simplicity, needs to be done carefully. To help understand the problem, and explore a solution with Nimble, consider this curriculum flow for learning web development:

• Lesson 1: Create your first HTML web page
• ...
• Lesson 5: Introducing the <img> element, and adding images to your text
• ...
• Lesson 8: CSS and inline styles
• ...
• Lesson 10: Loading external style sheets with <link>
• ...
• Lesson 18: CSS prefixes and cross-browser styling
• ...
• Lesson 22: JavsScript
• ...
• Lesson 34: JSHint and finding errors
• ...

In this imagined curriculum, Thimble is an excellent choice for lessons 1 through 9 and early work with JavaScript. With all the style and script resources being included inline, Thimble's single-page model helps make clear to new users where everything is happening. However, at a certain point a single document approach becomes unmanageable, hard to read, and inefficient.

Another issue is that as the code complexity grows, part of learning to code for the web is learning how to use tools. For example, validators for HTML, CSS, and JavaScript are important so one doesn't waste hours on silly mistakes like overwriting a global variable because the var keyword wasn't used, or forgetting to include prefixed styles for other browsers. As one progresses in their learning and mastery of web development, such warnings are imperative. However, encountering them too early in the learning process will be overwhelming and add complexity that may confuse or discourage the learner.

Nimble seeks to aid the user by providing a coding environment that responds to the requirements of the learning taking place. When a particular feature (e.g., multi-file support, JSHint validation, etc.) is needed, it becomes available; until then it doesn't exist as far as the user is concerned.

Mentors and teachers using Nimble for their work can configure these features along with their Makes, examples, and curriculum. The coding environment is responsive and extensible, and dynamically loads whatever UI and internal services are needed. Exactly how this might be done is unclear, whether through <meta> directives in the learning HTML, or with some other metadata. The best implementation is unclear, but the concept is obvious: being able to not only author the content of what the learner will see, but also to selectively configure the environment in which they will encounter it, is very powerful and acknowledges that one size doesn't fit all, and no single use tool is appropriate to every learning situation.

Nimble's Foundation

Building the technical underpinnings of Nimble requires a number of problems to be solved. First, extensibility is critical: how are features, tools, and UI packaged and loaded? Second, how to build and add the large number of features that are required for more advanced features, for example integrated validators, navigation within larger projects, multi-file environments, etc. Webmaker's goal isn't to lead the web in creating cutting edge development tools, and getting sidetracked on building out a wealth of new features would become a distraction. What's needed is an existing solution that can be adapted to fit into Webmaker. One possible solution is Brackets.

Brackets

Brackets is an open source web coding editor built using open web technologies. It's the editor that powers Adobe Edge, among other things. In building their next generation web editing tools, Adobe chose to dog-food HTML5. Further, instead of building things in-house, they decided to work in the open and created an open source project to help give the web a more powerful platform for building open development tools.

Brackets isn't at 1.0 yet, but it's already highly usable, and very interesting. The architecture is modern and modular, with an early emphasis on extensibility and loadable extensions. Like Thimble's current code editor, Brackets is built on Code Mirror. However, it extends the idea of a single editor to include an environment with multiple files, and understands the connections between these files (e.g., where CSS or JS is declared).

Progressive Enhancement with Brackets Extensions

Because Brackets is built around a modular extension system, turning on new features is as easy as including new extensions. Extensions are themselves made of JavaScript, and can be dynamically added to the editor at run-time without requiring a restart. The value of extensions to Brackets as a code editor project is obvious: users can customize and extend their tool to meet their own individual needs. The value of extensions to Nimble is that teaching and learning exercises can now include a tailor-made environment in which to explore and understand the concepts. Each lesson, Starter Make, or other unit of learning can have its own approach to how and what it presents to the learner.

Consider some of the earlier issues with trying to teach a deeper understanding of web development in Thimble. Here's a current starter Make in Thimble with FriendlyCode replaced with Brackets:

NOTE: this screenshot in no way represents an optimal or appropriate UI for using Brackets in Webmaker; it merely serves as a starting point for our discussion.

Consider one of the current Starter Makes: https://thimble.webmaker.org/project/20795/remix. This project mixes HTML and CSS in a single page. If we redo it in Brackets, we get the following:

Now we can let's split it into multiple files and use Bracket's in-line context editing to explore the relationship between the CSS and HTML, without having to include all the CSS inline:

Next we can add a CSS Linting extension and again examine our styles, this time noticing errors we've made.

Brackets + Badges

One of the long standing discussions within the Webmaker project is how best to integrate Open Badges. With badges it is possible to give users recognition for the completion of various learning activities. As they progress through a curriculum or learning path, various badges can be made available, and get collected. For example, learning how to use a particular aspect of CSS correctly.

With a progressively enhanced learning environment like Nimble, where certain features and functions can be enabled or disabled depending on the ideas being taught, badges become another way to help tailor the environment to an individual's abilities and interest. Imagine being able to use Nimble at your own level for an arbitrary Make, where the features of the tool are determined by previous achievement as measured by associated badges. For example: if you've been successful in learning about JavaScript debugging, the debugger might be automatically enabled for you in other learning modules. By relying on the users badges, whether earned via Webmaker or other similar learning systems, it becomes possible to create a tool that fits the experience and expectations of the learner.

Issues

Brackets isn't fully supported yet in browsers. The project's primary target seems to be a desktop web app running on top of WebKit. At the time of writing there is an experimental in-browser branch that uses a node.js-websocket based backend to simulate the file system and other services. The resulting editor can be hosted in a web page, but is far from universally usable across various HTML5 browsers. Here is a screenshot of it running in WebKit (top) and Gecko (botom):

Making Brackets work cross-browser would be necessary, which would mean writing/adding shims for various WebKit-only dependent APIs (e.g., File System API), and dealing with -webkit prefixed CSS. The backend node server would also likely need work, and getting all this landed in master vs. as an experimental branch would be ideal.

Conclusion

In providing a platform for learning open web technology and development, Webmaker has to balance the need for simplicity at the beginning stage, and a gradual expansion of capability as learning progresses. The web is easy to start learning, but becomes more complex quickly. Expert developers know that one only manages such complexity with tools and augmented environments that make navigation, discovery, and validation possible. A successful learning strategy will not only include an ever increasing difficulty in lessons and examples, but also more powerful and advanced features in the learning environment. Providing these too early will mean learners are overwhelmed and distracted. Not providing them will mean that learning beyond the basics becomes more difficult. The progression from Thimble to Nimble could help ease the transition for learners and teachers without requiring a false dichotomy between simple vs. powerful.