Rather than spending the placement working on a single large body of work I took on a number of smaller projects. Some disposable builds such as a visualisation tool for showing connections between user created projects on webmaker.org. Some more permanent like KitBuilder (which I’ll detail a little more later).
The above chart (GitHub 2014) clearly indicates that the last few months of my time with Mozilla have been the most build heavy. Although not 100% representative of my technical work, it gives a clear visual indication of how the types of project I worked on have changed over the course of my placement. Towards the beginning I focused much more on expanding my skills in non-technical areas, and learning how to utilise proper build environments and tools.
Once I became more comfortable with working in a way that fitted well with my technical colleagues I started taking on more code centric projects.
In the interest of being thorough, but not boring, here’s a quick list of key projects I worked on over the year, and a brief about them. I’ll then go into some depth on one that I feel provided me with the most valuable learning experience.
This project never saw the light of day, however it was a research project exploring the possibilities for running the Mozilla Webmaker tools on a USB flash drive (or “stick”). This was to address the growing need for offline resources that our community in rural parts of the world. Unfortunately the resulting outcomes indicated that it was not viable to pursue the course of action due to the large number of technical dependencies the Webmaker toolset had.
The project did however provide me with a great crash course in how Webmaker tools are made, as well as a better understanding of NodeJS (the JavaScript platform the tools are written in).
An event schedule Web app driven by a Google Spreadsheet. It was originally created by a small team at the Mozilla Corporation for the Mozilla Summit. However as there was a need for this technology at the Mozilla Festival (MozFest). I was tasked with giving the Web app a new theme to match the MozFest branding, but also to make improvements and changes given feedback from over 1,500 Mozillians that had used it during the Summit.
This meant repurposing the venue selection into a track selection, adding offline support, and pulling updates to the FAQ page of the app from a dynamic source. Given the preexisting use of Google Spreadsheets this prompted the use of Google Docs for the FAQ.
This is a more recent creation that acts as a companion for Firehug, that follows similar principles but instead of showing a schedule for an event (e.g. the Mozilla Festival) it shows proposed sessions, after a review, and provides just an API for filtering proposals by track. In addition to flittering the dataset it also strips sensitive information such as email addresses, twitter handles, and organisational affiliation, based on the preferences of the user who submitted the proposal.
This is a key replacement for previously tied systems which lacked the flexibility needed for the Mozilla Festival while still providing simplicity of use for the event organisers.
Within Webmaker there are a large number of starter project for remixing that help promote making as learning, which teaching basic coding and scripting skills such as HTML, CSS, and JavaScript.
During my time at Mozilla I’ve been tasked with creating a number of projects including simple games, testimonial templates, and single-page website designs.
A community quilt is a method of gathering small snippets of feedback, via free form text, from a community. Each contribution is added to the larger whole forming the story. The SupportOpen Quilt is an implementation of this built on Webmaker infrastructure that gathers these testimonials using the MakeAPI1
An example of the SupportOpen Quilt can be found at http://mzl.la/webwewantremix.
http://mozilla.github.io/webmaker-whitepaper
Since I started at Mozilla one of the ongoing strands of work as been around detailing why Web Literacy matters, and why Mozilla cares about it. I was lucky enough to be working on the same team as Dr. Doug Belshaw, one of the people leading this effort at Mozilla, who along with the expert educators, and the wider Mozilla Community created the Web Literacy Map, and the Webmaker White Paper.
I worked with Doug and the Webmaker User Experience team to create the website that the whitepaper is published on.
The Web Literacy Map is at the core of the Webmaker initiative. Its used to drive strategy, resource creation, and product development. Over the summer of 2013 Doug lead the push to bring this to version 1.0, along with a collection of community member, developers (myself included), educators, and other experts in the field.
The Web Literacy Map is at the core of the Webmaker initiative. Its used to drive strategy, resource creation, and product development. Over the summer of 2013 Doug lead the push to bring this to version 1.0, along with a collection of community member, developers (myself included), educators, and other experts in the field.
I’ve had the chance to work a wide range of technical projects over the year. For me one of the most notable was the yet to be released “KitBuilder” as it ties together a large amount of my learning from this placement – both technical and pedagogical – into a single tool for educators.
This tool aids the creation of Teaching Kits (an open educational resource) using the provided template from Mozilla.
It combines the idea of creating modular resources and remix-able content.
This is the first project I worked on in which I made full use of a modern Web development environment. Making use of automated testing and syntax checking, as well as a proper code review process/workflow.
The project started as a simple prototype to help save time for the existing community of mentors and educators who were contributing resources to the Webmaker ecosystem. Prior to the existence of this tool Teaching Kit creation had to be done within Mozilla Thimble – an online code editor built for education. This was a less than optimal use of their time, as it required editing the HTML/CSS source for the kits directly.
KitBuilder allows the mentor to input content into compartmentalised sections using Markdown and/or HTML. This is then compiled into the Teaching Kit template. Where possible it automates the creation of content for the user, by extracting the meta-data of resources linked to within the kit.
A search of existing Teaching Activities is also possible so that the user can include them within their Kit.
1. The MakeAPI is a simple service that sits at the core of the webmaker.org toolset. It stores metadata about user created content “Makes” and provides and API to create, update, and search for information about these without exposing sensitive user data. ↩