My latest Flickr photograph

Portfolio in curriculum vitae

Sunday 9th of June 2013, 09:27:01 am

Diving deeper into custom elements in mozilla

Sunday 24th of March 2013, 04:38:34 pm

Let's talk about web components some more, shall we?

In the last post I talked about decorators. Those things are great, but also fictional. The CSS toggling turns out to be such a headache to do right, safely, that you need more than one head to suffer it. However, custom elements are exactly as functional, so let's look at those. Turns out they do exactly the same thing, just differently. First off, the spec, which can be found uponyonderhyperlink:

https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html

It lets us define our own elements, with all the associated browser behaviour. If we didn't have <audio> or <video>, this would let us add it ourselves without having to worry about browser support. So let's have a look at an example:

  <element name="my-element">
    <template></template>
  </element>

This is the minimal custom element: an element needs a name -containing a hyphen-, and a template child. It may also have any number of script elements, which is where the true magic will happen. In fact, the above example is a bit silly, let's just jump straight to a real custom element:

  <element name="webmaker-media" attributes="start end">
    <script>
      // This script runs once, when we load/import the component
      if(!window.Popcorn) {
        var script = document.createElement("script");
        script.src = "https://popcorn.webmaker.org/src/butter.js";
        document.head.appendChild(script); }
    </script>
    <template>
      <style scoped>
        webmaker-media {
          /* desired styling goes here */
        }
      </style>
      <content></content>
    </template>
    <script>
      // this also runs only once
      var template = this.querySelector("template");
      var templateContent = template.innerHTML;
      this.register({
        prototype: {
          // But this one is crucial: it gets called every
          // time we create this element, either through JS
          // or as a normal HTML element in the DOM.
          readyCallback: function() {
            var e = this;
            var h = this.innerHTML;
            var c = templateContent.replace("<content></content>", h);
            this.innerHTML = c;
            var start = this.getNamedItem("start");
            var end = this.getNamedItem("end");
            var div = this.querySelector("div");
            div.setAttribute("start",start);
            div.setAttribute("end",end);
          }
        }
      });
    </script>
  </element>

Okay, slight wall of HTML, but let's analyse that thing, because it's going to turn the HTML world upside down. Or rather, it'll complement it.

  <element name="webmaker-media" attributes="start end">
    [...]
  </element>

This defines a new element with tag name "webmaker-media", and it says it can take two attributes, "start" and "end". No "data-start", just "start". Super convenient.

  <element name="webmaker-media" attributes="start end">
    <script>
      [...]
    </script>
    [...]
  </element>

Any script tied to a custom element executes when the element definition is read in. This means that if we need special functionality for a custom element, we're free to import and load anything and everything that is necessary for this element to do its job on a page. We're allowed zero or more script elements, so we can nicely separate by function and namespace.

  <element name="webmaker-media" attributes="start end">
    [...]
    <template>
      <style scoped>
        webmaker-media {
          /* desired styling goes here */
        }
      </style>
      <p><content></content></p>
    </template>
    [...]
  </element>

The template is a special element that can contain HTML code relevant to your new element. At the least, this usually involves a style element with the incredibly important keyword "scoped". This keyword ensures that the styling will only apply to "this element or its descendants", so you can't pollute the global styling. Then there is the "content" element, which serves as a convenient element that can be replaced with the content found when the custom element is actually used. For instance, if in our normal HTML document we use this:

  <webmaker-media start="0" end="24">Monkeys monkey monkey.</webmaker-media>

then the template replacement would look and act like:

  <webmaker-media start="0" end="24">
    <style scoped>
      webmaker-media { /* ... */ }
    </style>
    <p>Monkeys monkey monkey.</p>
  </webmaker-media>

At this point we have all the "HTML" bits sorted, but a custom element that doesn't do anything special isn't very useful. Let's give our custom element some superpowers:

  <element name="webmaker-media" attributes="start end">
    [...]
    <script>
      var template = this.querySelector("template");
      var templateContent = template.innerHTML;
      this.register({
        prototype: {
          readyCallback: function() {
            // ...
          }
        }
      });
    </script>
  </element>

Inside any <element> script block, "this" refers to the <element> DOM object. That means it can querySelect subfragments, check parentNode, access the .children NodeList, and other such useful things. However, it also has one very special function: .register()

The register function lets us tack things onto the element's prototype, most important of which is the readyCallback function, which is triggered everytime a custom element of our new type is created. This function is the place where, for instance, we tack "default" event handling onto our element, so that if we're -for instance- creating a new kind of super-movable-button element, we can assign it a default click event, because it's a button, and a default click-drag event, because we claimed it was movable, and be sure that every instance of our draggable button responds to clicks and click-drags. (note: the current spec puts this functionality under a lifecycle interface, calling it the ".created()" function, so what it ends up actually being called is still up for grabs; the important part is what it does when it is called, rather than what it is called, of course).

In our own example element, above, we had this readyCallback function:

  readyCallback: function() {
    var e = this;
    var h = this.innerHTML;
    var c = templateContent.replace("<content></content>", h);
    this.innerHTML = c;
    var start = this.getNamedItem("start");
    var end = this.getNamedItem("end") || 0;
    console.log("start is " start " and end is " end);
  }

This first creates a local reference to "this" (in case we're going to set up anonymous functions; any properly complex custom element will have a fair number of anonymous functions, so: good practice). It then performs templating; while the spec is still being worked on, we have to do this ourselves, but the idea is that this ends up being a "comes supplied right out of the box" part of custom elements. Still, no biggy, it's easy enough to do because we have access to our template element.

After that, we grab our attribute values; we declared our element as having valid attributes "start" and "end", so we can grab those using the standard DOM ".getNamedItem(...)" function. We don't have to do any silly "data-..." attribute accessing, it's just a normal attribute. We then log the values to the console, because we can, but in a real element we'd use these values to set up something functionally sensible.

So what's the take-home message? "If browsers didn't have anything except a base HTML element, a JS engine, a CSS processor, and knowledge of how to create Custom Elements, we could implement all of HTML5 in it. Including ALL the events handling, default behaviour, src fetching, media playing, and so on and so forth". This thing allows you to make EVERYTHING you need to do what you want, encapsulated in neat, tidy, <element> packages that wrap all the HTML, CSS and JS required to make things work.

Did I mention you can put this in its own file? I may not have. You can put this in its own file, and then link to that file using a normal <link> element; Effectively, if I were to put all the "webmaker" elements in its own file and hosted it on "http://components.webmaker.org/all-elements.html", you could use them, and all you had to do would be to include this one line in your own source:

  <link rel="component" href="http://components.webmaker.org/all-elements.html">

Done. Without having to do anything else, you can now use a <webmaker-media> element anywhere on your page, and it'll do for you exactly the same thing that it does for me. It is, effectively, a new common HTML element that we, or more specifically: EVERYONE can use.

This changes everything.

0 comments - view/add comments

A few words about Web Components, and why I'm totally in love. in mozilla

Monday 18th of March 2013, 09:10:42 am

For the past week I've been looking at a new, additional take on HTML that is being thought up by a large group of people who think that the web can be further improved. People from Apple, Mozilla, Google, but also general public voices are pitching in to come up with a standard for what they call "web components". Let me come right out and say I think that what they're doing is going to change how we think about web pages, in a good way. I love what they're working on, and with this post (and it's probably the first in a series) I will try to explain what it is they're doing, and why I love the idea so much.

Right now, if you ask someone "in the know" what a web page is, they'll say that it's a combination of HTML, which is used to mark up content on a page, CSS, which is used to define what that marked up content looks like when a browser shows it to you, and JavaScript, which is used to define all the dynamic behaviour a page has (basically "what happens on the page once that page has loaded"), as well as acting as a general programming language to turn web pages more into web "applications". More and more CSS is also getting the ability to define dynamic behaviour, but the kind of behaviour that CSS can do is still about styling the page, whereas JavaScript can also manipulate content (adding, removing, or changing the content, HTML code, and even CSS).

That's an interesting description, because it shows how people who work with the web think about web pages. If you ask the same question to a regular user, someone who has never made a single page, let alone an entire site, and just uses things like Facebook and Youtube and the New York Times, the answer is radically different: a webpage is this "thing", on the web, which let you do things. Watch videos, post messages to your friends, read news articles, that kind of stuff. To a normal user, web pages consist of functional components. The fact that those components are made using HTML, CSS and JavaScript is essentially irrelevant.

So what if you could describe your functional page components as such? What if you wanted to say: "I am the New York Times, and my page layout consists of these blocks. There are a number of article summaries, so 'article summary' is one thing, and there's a number of ad blocks, so 'ad' is another thing, ..." and so on. Right now, whether you're the New York Times or anyone else, you can do that kind of thing using templates. Templates let you say "this is the generic HTML code for something like [an article, an ad block, etc]" and then use that template to build content on your page by taking the generic template, filling in the blanks, and putting that on the page. The problem with this is that there are a million templating engines, and if the New York Times has a good template for articles, there is no way I can just do "view: source" on their webpage and see what their template looks like so I can use it on my site, too.

Another way to think about templates is as "widgets", or "plugins", such as offered by Content Management Systems (CMS) like WordPress, Drupal, Django, Magento, etc. If I have a wordpress site, and my friend has a Django website, and he uses a cool plugin, I can't use that. It's tied into his CMS, and usually has deep server-tie-ins to get its job done. Effectively, these templates, or widgets, or plugins, create lock-in. You can argue "so what", and fair enough, so what, but what if you approached plugins, or widgets, or templates, differently? What if you approached them as *page* components, rather than server functionality? What if these things just lived on the web, like everything else, and you could use them regardless of which CMS or back-end or even front-end technology you used, because they were just standard HTML and CSS and JavaScript?

And to make that "what if" real, Web Components is getting developed. I can rant about this for a few thousand words (and in fact have, my scratchpad for writing this post is very, very long!) but actually showing you what you can do with Web Components is probably going to be much more to your liking, so here we go:

Say I run a project like Mozilla's Popcorn Maker, a website that lets you do video remixing using almost any video on the web. You can mix clips to create your own mashup, or overlay a video of current events over a video of yourself reading the news, with a ticker tape scrolling in the bottom, generally cool stuff. In the current world, I would have a javascript library called Popcorn.js that can take media streams and a collection of plugins, and trigger those plugins based on where in the media stream we are when we play it. 10 seconds in, a text box pops up, 15 seconds in it disappears again. 30 seconds in a google map is shown based on what the people in the video are talking about, at 1 minute 17 it disappears again as the video changes topic.

I can write those plugins as Web Components, and by doing so, make them a resource that others can use on their own page, rather than just on Popcorn Maker. And, conversely, enable others to make similar plugins that they can host on their site, but I would be able to use in Popcorn Maker very simply. I'd do this by defining each of my Popcorn plugins as a normal HTML element that encodes my plugin properties (its start time, its end time, position on the page when it's shown, etc) using normal HTML markup, for instance:

  <div class="my-popcorn-plugin">
    <time class="start">0:10</time>
    <time class="end">0:15</time>
    <p>This box pops up at 10s and disappears at 15s!</p>
  </div>

and I'd make a components.css file that has this CSS rule:

  .my-popcorn-plugin {
    decorate: url(#my-popcorn-plugin-component);
  }

That's a new CSS property that is used in combination with Web Components. It says "take this element, and decorate it based on the an HTML element that's also on this page with id 'my-popcorn-plugin-component'", where that HTML element is a special element of type <decorator>. If you're not familiar with decorators from a programming context, decorators are things that "wrap themselves around" something, preserving the information in that something, but making it bigger, better, more functional and perhaps even more beautiful. In the case of Web Components, we're aiming for all four. To stick with the example, I will show you the decorate I'd use for my popcorn plugin:

  <decorator id="my-popcorn-plugin-component">
    <script>
      if(!Popcorn) {
        syncFetchAndInject(popcorn.js);
      }
      Popcorn.registerAsNewPlugin(this);
    </script>
    <template>
      <div class="popcorn-plugin popcorn-web-component">
        <content></content>
      </div>
    </template>
  </decorator>

What does this do? first off when the CSS rule styles my <div cass="my-popcorn-plugin">, the browser does some DOM manipulations: first, it takes the content from my div, and puts it inside the <content> element in the template, then replaces my div with this filled-in template:

  <div class="my-popcorn-plugin">
    <time class="start">0:10</time>
    <time class="end">0:15</time>
    <p>This box pops up at 10s and disappears at 15s!</p>
  </div>
  <div class="popcorn-plugin popcorn-web-component">
    <time class="start">0:10</time>
    <time class="end">0:15</time>
    <p>This box pops up at 10s and disappears at 15s!</p>
  </div>

If that's all it did, this would be fairly silly, it looks just like an outerHTML replacement, but it does more than just this template replacement. When it does the replacement it will also execute the script block that it finds for this decorator. I told it that it should check for popcorn.js, and if that hasn't been loaded, fetch and load it (turned into a single function call for legibility, here), and then register this element as being a plugin definition with popcorn. The best part is that I can put these things in their own file, let's called it popcornComponents.html:

  <style>
    .popcorn-plugin { ... }
    .popcorn-web-component { ... }
    .decorated-for-popcorn {
      decorate: url(attr('data-plugin-type'));
    }
  <style>
    ↓
  <div class="decorators">
    <decorator id="popcorn-video-block">
      <script>...</script>
      <template>
        <div class="popcorn-plugin popcorn-video">
          ...
        </div>
      </template>
    </decorator>
    <decorator id="popcorn-text-plugin"> ... </decorator>
    <decorator id="popcorn-wikipedia-plugin"> ... </decorator>
    <decorator id="popcorn-google-maps-plugin"> ... </decorator>
    ...
  </div>

And I put this file up on http://components.webmaker.org/popcornComponents.html - now anyone can use my components without even copy-pasting them: they just add a link in their page header just like for CSS, except with the "component" relation, and they're good to go:
<link rel="components" href="http://components.webmaker.org/popcornComponents.html">

They now have everything they need to build their own "Popcorn remix". A modicum of HTML knowledge is still required, but the work involved becomes infinitely less. I could now put a remix on my own website without ever having to touch Popcorn Maker, or JavaScript:

  <html>
    <head>
      <title>lol, awesome mashup</title>
      <link rel="components" href="https://components.webmaker.org/popcornComponents.html">
      <link rel="components" href="https://components.google.com/fancyHeader.html">
      <link rel="components" href="https://api.fb.com/components/like.html">
      <link rel="components" href="https://api.fb.com/components/comments.html">
    </head>
    <body>
      <div class="google-fancy-header">
        <p>This is my bestest mashup!</p>
      </div>
      <div class="decorated-for-popcorn" data-plugin-type="popcorn-text-plugin">
        <time class="start">0:10</time>
        <time class="end">0:15</time>
        <p>This box pops up at 10s and disappears at 15s!</p>
      </div>
      <div class="decorated-for-popcorn" data-plugin-type="popcorn-text-plugin">
        <time class="start">0:15</time>
        <time class="end">0:30</time>
        <p>And then this box pops up after that, for another 15 seconds!</p>
      </div>
      <div class="decorated-for-popcorn" data-plugin-type="popcorn-wikipedia-plugin">
        <time class="start">0:15</time>
        <time class="end">0:30</time>
        <data class="pageUrl">en.wikipedia.org/wiki/I18N</data>
      </div>
      <div class="decorated-for-popcorn" data-plugin-type="popcorn-credit-roll-plugin">
        <p>Video: the National Zoo</p>
        <p>Music: Skrillex</p>
        <p>Mashup: ME!</p>
        <p>catering: Tim Hortons</p>
      </div>
      <div class="fb-likes"></div>
      <div class="fb-comments"></div>
    </body>
  </html>

My friend sees my mashup page, and loves it. They want to do something similar. They hit view:source, copy and paste the components <link>, and to get them start, copy-paste my popcorn elements, and they're off, they immediately have a working page that they can play around with themselves. No going to a special website, no loading specialised tools, copy paste and off you go!

But it doesn't end there. As Popcorn Maker, the actual editor components can also be Web Components. For instance, every plugin has a start and end time, what if the timeline component was simply a decorator that, when actually applied on a page, gives you a timeline bar at the bottom of your page (anchored to the browser window), and searches for everything with the class "popcorn-plugin", adding those things as timeline events so you can see what's going on? Easy-peasy, and if someone wanted to play with their page like that, they'd just have to add the component:

  ...
  <div id="timeline" class="decorated-for-popcorn" data-plugin-type="popcorn-maker-timeline-ui"></div>
  ...

Done? Delete that single div and it's gone. Need it back? Put it back in and magically the timeline view is back. This is webmaking at its finest. "How do I add a facebook comment section to my page?" - "oh just use the facebook components and add an 'fb-comments' div wherever you want the comments to sit". "How do I put a code editor on my page?" - "link to the codemirror components and then just add a class='codemirror' div".

"How do I add X?" - "by adding X".

This is a future I want to live in!

4 comments - view/add comments

A simple thimble button in odds and ends

Friday 8th of February 2013, 07:10:27 am

I've been working on Mozilla's webmaker program for a while now, and one of the things we run into is that we all want a million features, but only have so many people working on it. I'd love a nice UI-integrated way to slide between "code view" and "preview view", and a number of people have been brainstorming about this and coming up with amazing things, but they're going to take considerable work to put in, and as is the way with dev work, it won't be in until it's in.

So for my own Thimble work, I figured I'd write a bookmarklet that lets me slide between 'preview' and 'sourced'. It's only a few lines of JS, it's completely untested, it's not integrated into the code base, but it certainly works a treat!

If all went well, just drag the following link into your bookmark bar, and the next time you thimble it up, hit that button!

A Thimble preview sliding bookmarklet

0 comments - view/add comments

Hackable games at the Mozilla Festival in Mozilla

Monday 19th of November 2012, 02:34:23 pm

I've been working at the Mozilla Foundation for a few months, initially rolling into what became the webmaker.org Thimble tool. The project was an attempt to make it super easy to learn HTML and CSS by showing people both the code and the page it built, side by side. The idea was that this would allow people to "remix" the web, using the internet as a source for creativity, rather than as a passively consumed medium. We had a lot of positive feedback on it, and several partners helped create some really fun and great projects that people could do using the Thimble tool, easing people into the idea of changing a webpage to be what they want it to be, before giving them an empty Thimble page where they can make whatever they want, not bound by any predfined template other than the minimal HTML code required to define "a page".

The idea of Thimble fits nicely into the "What if we had a giant 'remix' button for everything on the web?" question that underpins the webmaker philosophy. What if, while watching a youtube video, you could right click and select "view source", to see all the timing events, overlays, captions, what-have-you's? What if, while playing a web-based game, you could do the same, and see all the object definitions, and the game logic, and level design? What would something like that even look like? What would you expect to be able to do? What would you WANT to do?

For video, there is the amazing "Popcorn Maker", which has just reached its 1.0 release, and lets you remix videos on the web in a way that used to be reserved only for people willing to learn how to use very specific video editing tools. It's the "remix button" for youtube, vimeo, etc., letting you create your own videos by pulling in data and information from as many sources as you want, while keeping everything understandable. And preserving the remixable nature of your mix when you decide to unleash your creative awesomebomb onto the web by publishing it through webmaker -- incidentally, if you haven't had a look at it yet, I strongly recommend that you do =)

For games, things are less clear. There are as many ways to program "a game" as there are actual games, and even on the web there are myriad technologies that are currently used to deploy games. From HTML and JavaScript to Flash/Silverlight to Java Applets and WebStart applications to even things like thin clients that basically turn the browser into just a monitor with an input device for sending control signals to a remote server that's actually running the game. When there's a million-and-one approaches to making games, how do you even begin to come up with a way to remix all these things?

Rather than trying to figure out a universal answer, we decided to focus on what makes a game "remixable" or "hackable". What would you need to do, in order to write games that are inherently "hackable"? Think of the concept of modding, where game publishers deliver not just "the game", but also an extensive system for changing the look and feel, or even the mechanics, of the game that you bought. Blizzard has an excellent track record for this with titles like "World of Warcraft" and "StarCraft", and many RTS games, such as the "Command and Conquer" series, offer similar functionality - but what would you need to do to make this something that simply comes naturally as part of open, "webby" games?

Ideally, hackable games are games that are made just like any other, but with a tool chain that simply bakes in the hackability. In an ideal world, the game developers don't notice a difference, but the game that comes rolling out is simply hackable because "that's what games are". It's a bit like how we think about web pages these days - If I browse a website and it's white text on a black background, I can just change the colors so that it's dark text on a light background instead. I don't need access to the webserver and the original files, I can just make a change in my browser when I need, or want to. What if, in a hypothetical futures where "hackable games" is an established concept, playing a game like "Modern Warfare" or "Paper Mario" with your friends and going "hey, let's change the gameplay" is as obvious and trivial an idea as saying "hey, let's play a different game"?

In the mean time we're still in a place where the answer "what makes a hackable game" remains largely unanswered. So to get the ball rolling, we looked at the tools we already had: HTML, CSS, JavaScript, Thimble, and free assets from places like opengameart.org and freesound.org. With the Mozilla Festival fast approaching, we wanted to come up with something that would demonstrate the ideas of a hackable game, without making things completely inaccessible for people who "just want to change something". We're not all game developers, but we all have our own ideas of what would make a game better, or more fun, or different and interesting. Not all remixes are code hacks, some are as simple as asset changes, or a small change to a game mechanic by changing a few game parameters, so we wanted something that wasn't necessarily done, but was good enough to let people play with it and get an idea of what hackable games might be.

So, for the Mozilla Festival, we settled on making a "pure" HTML game: we created an HTML version of the immortal "Pong" game, using box2dweb.js for the physics, and HTML elements as our world objects, so that the entire thing is a webpage; walls, paddles, balls, everything is divs with classes that our physics code can simply look at and go "I see this div is of class 'ball', I'll just tie 'ball physics' to this element". If you have no programming experience, or a desire to learn to program, you can still play with the HTML and CSS and tweak your game to suit your taste.

Because it's a webpage, all the styling is achieved through CSS. The Pong game is extremely easy to "skin"; you can change the colors or use image art; We have several data-[...] attributes for tweaking things like gravity, object density and bounciness, friction, key based interaction, etc. Things you might normally tweak through code, we added as live parameters. Change the HTML source code, and the changes take effect in the webpage preview. It's a bit like a live coding environment, with a focus on experimenting more than just "learning how to do X". It has to be fun first, and educational second. Done right, the second is simply a happy side-effect of the first.

For people who want to do more elaborate tweaks, we have "onbounce", "onmousedown", and "onmouseup" event handlers for introducing and manipulated (limited) game mechanics, such as removing things from the game world (based on CSS selectors), keeping score, playing audio files using HTML5

To test how robust our idea was, we remixed our own Pong game so that it became an "Arkanoid" game instead, with the right paddle changed into some thirty-odd small "wall" divs that disappeared on an onbounce event.

If you're a game developer, this might all sound trivial, but if you've only ever enjoyed games solely as a player, the idea that you can simply go in and change the game to do what *you* want, rather than what the game developer thought you should want, can actually be very empowering. It's the difference between being a consumer and a creator. We don't magically stop being consumers, but gaining the ability to create and manipulate is an incredibly enriching experience. Even if you rarely ever exercise it, knowing that you could change something if you wanted to is already empowering.

Running our session

We had the good fortune of quasi-co-hosting our session (which spanned both days) with a session run by the people from Babycastles, who were doing a "build a one-button arcade cabinet", which gave us the opportunity to give people more than just games to hack on: if they felt up to the task, they could also design a game that had a single button for user input (in our case, onmousedown and onmouseup) which could then be used in the arcade cases that were building built at the same time.

Thanks to MozFest's incredible number of attendants this year (1000 people!) we had a good mix of skills and ages, ranging from people without any programming or HTML/CSS knowledge whatsoever to developers, with age ranges between 12 and 50 (rough estimate =), and it was really interesting to see the different approaches that people took to "hacking up" the games.

We had a class of secondary school children, who had zero HTML and CSS experience, started playing with the games, focussing on making "Pong" their own game, learning how to work with CSS styling as something that allowed them to customize their games. They minimally changed the game mechanics, working in two groups, with one group producing a space-themed pong, where the ball slowly speeds up as it bounces around, and the second group producing a very hard game with paddles closer to the center, and two balls that speed up a lot as they bounce around. It took them maybe 15 to 30 minutes to understand that there was a difference between HTML and CSS, and that you changed the look and feel mostly through CSS rather than the HTML, but after that they were off doing their own thing, developing as a group with one person behind the keyboard and several others looking on, saying what to try next.

It was great to see a bunch of kids come in, listen to the pitch, skeptically poke and prod the thing a little, and then just run away with it. I think this is a clear sign that we're tapping into something good here.

We also had a group of adults interested in hackable games, who ended up working in groups as well, working together to create one button games, with different people working on different aspects - people with no or little HTML experience worked on the look and feel, playing with CSS and doing paper design, while people with programming experience started to modify the game logic to enable more elaborate games, injecting JavaScript code and radically altering the game behaviour because even though our physics engine had some built-in functionality, it couldn't do something, but they had the skills to change it, and the hackable games version of Thimble let them. A particularly nice result was a "build a hamburger" game where a hamburger, consisting of a bun with three ingredients, had the bottom part of a bun as "paddle", and the player had to collect the ingredients and top bun in the correct order as they fell down. As a one-button game, you couldn't directly move the "paddle" left or right, but rather it went back and forth between the side walls on its own, and a mouse click would reverse its direction.

If watching kids run away with the hackable games concept was great, seeing adults make their own thing with a minimal setup was equally inspiring, and I think it shows (once again) that creativity just needs a way to be expressed. Even if the tools are far from perfect, being able to tinker and fiddle and create something fun is infinitely preferable to not having that option.

The thing I really liked about this was that people with zero experience in web making were able to, with minimal help, go from "user" to "maker" in under an hour. The fact that they were hacking games made the exercise fun, but the tools they used also taught them a little bit about webmaking in general. I love this concept of "people learning something because it allows them to do some other thing". Learning HTML and CSS can be useful, but if you learn it because it is a means to an end, rather than an end in and of itself, the learning is that much more powerful.

Where do we go from here?

It's been interesting to see people playing with the notion of hackable games, and making something that enables people to express themselves creatively through a hackable game has been insightful, but there's a lot of exploration left: "real" webby games, as made by game developers who are serious about releasing a game, won't be made using Thimble. As a first, small attempt, these hackable games were great, but we've only dipped our proverbial toes in the ocean of hackable games, and there's a long walk left. It's getting exciting.

There are two things that I took home from our hackable games experiment:

1) "If you need it to do something fun, you'll learn how to do it". This is kind of an obvious thing, but seeing it in action again is a great reminder that we're not "teaching people HTLM and CSS", we're turning them into webmakers, and HTML and CSS, as well as JavaScript, are means to that end. Having tweakable/hackable/remixable HTML-based games available for people to have fun with gives us another way to engage and motivate future webmakers.

2) "We need more implementations of tools that enable hackable games". Thimble projects are a great way to engage the newcomers, but you don't win over the tech crowd with tools they will never use. If we want to entertain the idea of hackable games as a given in a future webmaking world, then we should engage amateur and professional developers using their own tools, either extended or hooked into in such a way that creating an inherently hackable game is no more work than creating the games they do today. How can we do that? No idea, so let's find out!

I had a lot of fun during MozFest, and I think the most important thing to do, now that we have some time for evaluation, is to sit down and figure out where to take the notion of hackable games in the immediate future, as well as what kind of goals (and I want to stress the plural form there) we want to achieve long term. It seems to me that hackable games in Thimble is a major winner for the overall webmaker idea, but our hackable games session at MozFest is the intersection of a two circle Venn diagram, with the "webmaker" and "hackable games" circles meeting at Thimble... in the same way that there's more to webmaker than just Thimble, there's definitely more to hackable games, too. It's time to find out how much more complex that diagram is!

0 comments - view/add comments

Load text with custom fonts when the font is ready. in programming

Saturday 21st of January 2012, 06:40:06 pm

Over the past year and a bit I've run into many occasions where it is ridiculously tricky to load a bit of text, styled with a custom font, because browsers don't know when a custom font is ready. They can tell that they finished downloading it, but then can't tell when it is also ready for typesetting (A large font can easily have 200ms between 'download complete' and 'fully parsed and ready for use').

The solution: through my own work on font parsing, work I did for Processing.js, and a P.O.C. for PDF.js I have now come up with (almost) the perfect solution: Font.js, a library that adds a sorely missing object to the JavaScript toolbox, namely a "new Font()" object.

Check out the Font.js demonstrator page, or have at it by forking it on github!

2 comments - view/add comments

Trap keys for HTML elements - show the browser who's boss in odds and ends

Sunday 20th of November 2011, 02:38:26 pm

Say you're writing a browser game. Everything's going great until your user hits "backspace" and BAM! The browser goes to the previous page. How annoying is that? Forget about annoying, it means your game is unplayable because it doesn't trap important keys.

With this simple self-contained script, it can. And it comes with a handy jQuery .trap() function, too, so that you can just chain it in wherever you like.

Now THAT's handy.

Also: github link here.

0 comments - view/add comments

Adding macros to your CSS without breaking things in odds and ends

Sunday 20th of November 2011, 02:36:26 pm

For the redesign of Nihongoresources.com I needed CSS macros at the client. I like SASS, but it doesn't let you keep shared design elements actually shared once the CSS it generate is loaded in a browser, so I needed something that kept those links in. LESS has a horrendous syntax, and is not CSS compatible, so I rolled my own macro package that sticks with the syntax that is used in proper CSS so that things work even if people block scripts.

Get your CSS macros here.

It also comes with a jQuery .macro() function, so you can change macro values even after the page has been loaded by the client's browser and be assured that everything that uses that macro is updated accordingly.

Also: github link here.

0 comments - view/add comments

Get your simple page comments here. in odds and ends

Monday 31st of October 2011, 04:08:42 pm

So I needed something to add instant commenting to random pages I write (because I don't keep all my stuff on one website, and sometimes I'll make pages that have a limited lifetime but I'd still like comments for). So I dug into my Primer on Bezier curves, and ripped out the commenting functionality as it was the most modular starter I had lying around.

I cleaned that up, made it truly modular, and the result is a really quick and simple way to add a comment section to a page. It only requires three lines of PHP to add comment functionality to any page, and is highly customisable thanks to nearly everything being CSS classed.

It's also on github

2 comments - view/add comments

Let's do JS templating! in odds and ends

Friday 21st of October 2011, 01:17:39 pm

For no good reason, let's get some templating going on for HTML pages, without needing server-side variable substitution. I have no idea when you'd actually use this, but then again maybe it's exactly the kind of thing you were looking for. Have some.

0 comments - view/add comments

previous 10 posts