Since the end of October, Mozilla has had an open Directorship position for something called the ‘Webmaking Science Lab’. Other than this posted opening, I can’t seem to find anything written on this project. My assumption is that this is an idea that hasn’t been developed much beyond the recognition that ‘open science’ is an important area lacking critical open web infrastructure.
I’ve been eyeing this open position since the holidays, and I’ve decided to throw my hat into the ring the only way I know how: by starting to hack at it! And if someone else gets the position, hopefully I’ll have helped get them started with their awesome new job!
Apologies to peeps at the Mozilla Foundation if this turns into a case of awkward overstepping.. but it’s all about the love! <3
Where does Knowledge come from?
Mozilla’s Webmaker program is concerned with setting a high standard for web literacy and connected learning. I think Webmaker is an integral program for figuring out solutions to the problems identified in the recent Connected Learning Report because the way in which knowledge is modeled in the human brain mirrors how the web works: like a directed graph. Moving toward an educational paradigm that ‘works like the web’ also has the benefit of ‘working like the brain’. This is both personally humanizing and validating of the global brain theory.
But if open web conventions become the default means by which we encode our civilization’s understandings of how the universe works, how do we integrate the beginnings of understanding into the (social and technical) architecture of the web? How does the scientific process fit into the picture?
This is the question that underscores the idea of a ‘Webmaking Science Lab’ and I’m glad Mozilla’s asking! This is a really important question!
Oh, and it’s made of pure awesome!
Webmaking Science Lab
And so it makes sense for the Mozilla Foundation to create a new ‘Open Lab’ in the tradition of HiveNYC, OpenNews, and OpenArt to investigate this question. And it makes sense to associate this Lab with Webmaker because at its core, science is about the creation of interconnected bodies of literature that encode knowledge and lead to learning. Scientific papers have been linking to each other before the web even existed.
But as our education system is breaking down, so are the research institutions associated with it. And it’s not just the economic models supporting scientific research that are in need innovation, but the way in which science is conducted itself. In fact, I just spent half an hour looking for some links to support these two assertions, and decided doing so would completely derail where I want to go with this blog post! Holy crap, there’s so much! I may come back to break these down further in a future. For now, let’s just say the opportunity space is VAST!
Finding starting points
I have a hypothesis: Figuring out the models that will make open science thrive is a prerequisite for solving the challenges that currently face journalism.
Given that science journalism generally sucks, I think the work OpenNews has done in their Source project would be a great way to build connectivity between the budding world of Open Science and innovative storytellers with global distribution.
Peter Aldhous of New Scientist has a profile in Source and an article published there, ‘How We Made “Your Warming World”,’ which explains the creation of an awesome interactive work of science data journalism!
Great start! Peter: I’m not even sure if I have any authority to make a statement like this, or if it even exists as a real thing yet.. but welcome to the Webmaking Science Lab!
Another hypothesis: Scientific fields studying the web will be amongst the best collaborators in figuring out how to make open science webby.
The historical trend in science toward specialization is rapidly breaking down as cutting edge science is increasingly happening through interdisciplinary collaboration. At the very center of the cutting edge of interdisciplinary collaborations lies Network Science. From Wikipedia:
“Network science is an interdisciplinary academic field which studies complex networks such as telecommunication networks, computer networks, biological networks, cognitive and semantic networks, and social networks. The field draws on theories and methods including graph theory from mathematics, statistical mechanics from physics, data mining and information visualization from computer science, inferential modeling from statistics, and social structure from sociology. The National Research Council defines network science as “the study of network representations of physical, biological, and social phenomena leading to predictive models of these phenomena.”"
There is soooooooooo much I could say about how awesome network science is.. but instead, I’ll post two videos featuring field luminary Albert-László Barabási.
Here is a mindblowing TED Medical video where he talks about the applications of network science for medicine. (This is the sexy video!)
And here’s an hour long lecture entitled “Web Science Meets Network Science.” (I found this one sexy too, but your mileage may vary..)
If my hypothesis is right, this leads dangerously to the meta-ist of meta-projects ever undertaken in the history of humankind. Webmaking science tools built in collaboration with scientists weaving in and out of the growing body of network science could become some of the most powerful tools Mozilla will ever have to, for starters, create analytics for informing future radical developments in the core architecture of the open web. This is an incredibly amazing side benefit that would make the cost of entry completely worth it. But I digress..
When it comes to engaging the scientific community for the Webmaking Science Lab, the two clusters of people I would initially focus on would be those involved in Open Science activism and Network Science.
Third hypothesis: Webby tools for scientific modeling will be just as helpful for conducting original science (plus replication of results) as it will be for making new knowledge accessible to the masses.
This is what makes the connection to Webmaker so amazingly prescient, and relates to why I started out with my hypothesis regarding journalism: interactive simulations of systems are the future of storytelling and the propagation of knowledge. Right now, the application of simulations within science are primarily for the creation of knowledge.. but not so much the transmission of it. Instead, we get pdf documents, textbooks, and poorly written fourth-hand news stories. What if the tools for conducting science were also the same tools for publishing, sharing, and remixing the science?
My third hypothesis will be difficult to find supporting material for because this is the major technical work that has to be done: researching what’s out there and coming up with product ideas for prototyping. But here are a few projects I’ve run across that get my tickle my imagination.
Here’s a demo of this technology rendering 3d molecules within a very old version of Firefox for Android:
This is very cool, and I could definitely see how this could be the starting point for creating webby chemistry content. An academic chemistry paper could be fully interactive using this technology, and these same simulations could be made to be embeddable for journalists who want to strip away all the academic jargon in order to tell a a more compelling story. Then some kid in Webmaker elementary school could remix this same simulation for a class project in such a way that leads the original chemist to find a cure to cancer!
Hey, stranger things have happened on the web! Let’s see.. what else is out there?
There’s an open source toolkit for applied Graph Theory called TinkerPop produced by a company called Aurelius. Graph Theory is one of the major tools used in Network Science, and this group of products includes a tool for interacting with graph data via RESTful web services.
Oh! And I can’t forget the Hypothes.is project which seeks to create a distributed platform for web annotation! This project is directly relevant to making the culture around science (via Peer Review) operate more like the web. This is an ambitious project seeking to create a system that could eventually become a core technology built into the browser. Based on what I’ve read, I’m imagining something like Google Docs commenting feature tied to Mozilla Persona. Frankly, this almost feels like a Mozilla project already!
One of my major motivations for writing this was to get people talking! So far, the only indication that the ‘Webmaking Science Lab’ is a real thing is the description accompanying the Directorship position. Call me overeager.. but I’ve been wanting to know more and how I can contribute! I bet there are others as well.
Seeing as the position hasn’t been filled yet, I figured I’d start working on a framework for identifying key problems and opportunities this Lab might seek to explore. I really REALLY like where this is headed.. so I’ll be polishing my resume this week. ;)
On a side note, I’ve chatted a bit with a few people from the Open Science Federation over the past month, and they also seem really excited about the prospect of Mozilla becoming a voice in the Open Science movement. (They also really helped me out when I was looking for subject matter experts for CrisisCamp! They’re awesome!)
Partnership and community building opportunities abound, and I think there’s a large community ready to jump into whatever Mozilla ends up doing within this space.
Last weekend we had a successful CrisisCamp Boston event at the MIT Media Lab. Here’s a short summary of how it came together and some of the outcomes.
I got together with Rodrigo Davis and Pablo Ray Mazon of the MIT Media Lab’s Center for Civic Media to discuss logistics for this CrisisCamp less than 24 hours after Mayor Menino declared the flu epidemic a Public Health Emergency. In retrospect, this was a great choice to make because of the issues it both revealed and created.
At first, it seemed as though the flu crisis itself wasn’t very accessibly hackable. More on this in the ‘lessons learned’ section toward the end.
After introductions and some basic discussion of the problem space, we broke off into groups to brainstorm ideas for problems we could work on solving.
Sean P Fay and Aaron Kite-Powell presenting on ‘Principles of Planning’ where they outlined facts and assumptions about flu and how what kinds of Apps might have impact. Changing behavior is key, and the biggest opportunities lies in changing social norms, expectations, and response. Framing the value of apps in terms of money saved is also important for showing their value to response organizations. Notes here.
Rodrigo Davies presented on the opportunity space for building solutions. His group explored which communities tend to be hit hardest by the flu and the difficulties involved in reaching them. Solution ideas converged upon a single area of focus: Apps developed around public education and outreach campaign. Notes here.
Jon Lin’s group presented an app idea. As part of the effort to combat the flu, Boston’s Mayor’s Office of New Urban Mechanics released a widely publicized web app to help people find clinics where they could get flu shots. Again, the challenge of accessibility to web based information came up. John Lin’s group decided that the best way to reach communities without access to technology is through the network of responders. They wanted to create an app for responders that facilitates resource matching, reporting, and general information dissemination. The biggest challenge identified in building this, the holy grail of response apps, is the inaccessibility of data. Just figuring out how to find, aggregate, and represent data locked in the diaspora of response organization silos (or not even collected in the first place) in a useful way to developers would be a significant win. Notes here.
At the end of the day we ended up with seven possible projects to work on:
- Flu game – More of a brainstorming exercise than a hackable project.
- ‘Toolkit for street teams’
- CrisisPro – A mobile app to help responders disseminate information to under-served communities.
- InnCrisis – a social fundraising system continuing development from the previous CrisisCamp even in November
- FluShot – hacking new features for the app deployed by Boston’s New Urban Mechanics office
- A Trend tracking & early warning system
Ultimately, the two projects we ended up working on during Sunday’s session were FluReporter and InnCrisis.
InnCrisis is a continuing project from the Hurricane Sandy CrisisCamp. As I’ve spent a bit of time contributing to this project since then, I was pleased to see it maintain momentum and gather more contributors. I’ll be posting an update on this project in a few weeks.
FluReporter, a project with potentially huge scope, was narrowed to a pilot project for gathering sources of mandated health reporting data and creating a standard means for representing data and engaging parties involved in both gathering and using this data. Mockups were created as was preliminary work on defining the data models. A number of contributors have expressed interest in continuing to work on this project beyond the weekend, so it’s entirely possible an initial prototype may be ready for presentation by the next CrisisCamp Boston event.
Some lessons learned:
- Organizing a hackathon is a lot more work than the types of events I’ve organized in the past. Hopefully this will get easier as I and my collaborators gain more experience in this arena.
- Running a CrisisCamp is very different from running a regular ol’ hackathon in the sense that there are problem spaces to be identified and documented. Whereas hackathons tend to be mostly developmental in nature, CrisisCamp requires a continuous feedback loop of R&D. I’d like to connect with other CrisisCamp organizers to see what their experience has been in facilitating this event dynamic.
- Organizing the social media component should include specifying where to dump/share photo and video content after the event. Here are the pics that I took.
- Our focus on the Flu exposed the challenges of working in areas where long-standing institutions have established processes that are ‘good enough’ and resistant to open innovation. This may be why the big success stories of previous CrisisCamps have involved natural disasters and innovation in mapping applications. Long/slow crises in areas such as healthcare, while leading to more suffering and loss, are not low hanging fruit for citizens participation in problem solving.
- Sean P Fay gave a presentation on the Incident Command System (ICS) which is a standard organizing principle used by crisis responders. Awareness of this system may provide a means for CrisisCamp to better integrate with local crisis response organization. FEMA offers training in the ICS, and I’m going to follow Sean’s advice and see if I can get myself and a few other CrisisCampers certified.
- Having emergency response professionals and subject matter experts available to share their knowledge and collaborate really made the event!
My todo list moving forward:
- Keep connecting with emergency response professionals and subject matter experts.
- Update the main hackathon organizer support materials I’ve been working from with lessons learned: Organizing CrisisCamp, Hack Weekends Guide
- Start organizing the next CrisisCamp Boston. I’m thinking the sweet spot between events will be somewhere between 6 to 10 weeks. This will take a bit of experimentation. (If you’d like to help out, let me know!)
- Research ICS trainings and broadcast the opportunity out to other CrisisCampers
If you were in attendance, let me know if there’s anything I missed that you’d like me to add or link to!
This post is going to be the first in a series I’ll revisit from time to time answering the question: “Why Mozilla?”
A little known fact: Mozilla is an organization with a Manifesto.
It’s an inspiring document that outlines the principles upon which Mozilla operates toward fulfilling its mission of preserving a free and open web.
There is an ongoing dialogue at the Mozilla Foundation about whether the Manifesto needs revisiting. When I read the Manifesto today, I feel like it is just as relevant now as when it was first published.. but perhaps some of the language could be touched up to add emphasis on how the principles manifest in Mozilla’s efforts to tackle contemporary challenges that didn’t exist just a few short years ago.
I have no specific suggestions along these lines right now, but what I would like to do is discuss the expression of these principles in terms of major historical milestones and begin to explain why, frankly, I’ve become so obsessed with this organization.
Right now, Mozilla has three significant tent-pole projects: Firefox, FirefoxOS, and Webmaker. Each project delivers a milestone that builds upon and supports each other toward accomplishing Mozilla’s mission.
Firefox: The First Avenger Milestone
The initial release of Firefox set the web aflame. It ended the days of vendor lock-in to a stagnant web under Microsoft’s tutelage. In very measurable ways, it was Firefox’s impact on the market that led to the rebirth of the web in the form of ‘Web 2.0′ and social media. As a highly visible project, Firefox was a major source of mass contributing to the momentum of the Open Source movement. It proved that a purpose driven organization like Mozilla could have impact, and its creation made Mozilla a pioneer in the forms of open collaboration that 21st century organizations must adopt in order to achieve excellence.
I’d argue that only one other product has done as much as Firefox to advance the state of the web in recent years: Apple’s iPhone. It was Apple’s work on Webkit for the iPhone that launched the mobile web and mobile web apps before the iPhone even had an App store. Webkit also became the foundation of Google Chrome: an excellent browser worthy of Mozilla’s vision for a platform-agnostic Open Web.
Despite the original positive and high impact the iPhone had on the web, it quickly became a threat. Native Apps backed by cloud-based data silos circumvent and break the web. Google’s Android, despite being a more open platform, is not an Open Web platform and exacerbates this very problem. Although there has been talk of Android and ChromeOS eventually merging, Google’s ultimate incentive is not to preserve the Open Web but to organize the world’s information in the most direct way possible: by swallowing all the data.
Just as in the days before Firefox, vendor lock-in is the name of the game.
FirefoxOS: Scaling Kilimanjaro
Few in the technology industry truly understand what FirefoxOS represents. It is not just another competitor entering the already crowded mobile OS market.. it is the beginning of a new era in computing. The success of FirefoxOS isn’t dependent upon adoption of devices, but development toward a future in which Web Browsers and Operating Systems begin to blur.
There was a thread early last year on the Mozilla Dev Planning mailing list by Damon Sicore titled “The Web as the Platform and The Kilimanjaro Event” which proposed a major milestone for Mozilla to work toward:
“The Kilimanjaro Event is the point in time (not a release) when we realize a tightly integrated set of products that enables users to use the ID of their choice to find and install Web apps from HTML5 App marketplaces–including one created by Mozilla–and have those apps and appropriate data synchronized amongst devices. It is important to point out that the Kilimanjaro Event is not a single release. It is an incremental effort where we deliver a series of releases and features to each of our products that result in and enable an end-to-end user experience across these efforts.”
While this may sound like Mozilla playing the vendor lock-in game, the difference is that everything is being built upon open technologies. If other vendors don’t eventually adopt and/or adapt these technologies toward a seamless end-to-end user experience that crosses browsers and operating systems, then Mozilla will have failed to replicate the original success of Firefox in preserving the openness of the web.
The key to scaling this monumental goal is an unprecedented alignment in Mozilla’s organizational capacities.. and Mozilla is well up to the task. The work that we see being done now toward launching FirefoxOS can be viewed as establishing Basecamp at the summit of Mount Kilimanjaro. This is only the beginning, and there is so much more to come.
However, FirefoxOS does not solve the ultimate problem of apps being a threat to the web. Apps still, more often than not, lead to silo-ed data.
Webmaker: Shooting for the Moon
If FirefoxOS represents the movement toward a high summit, Webmaker is the launch pad for Mozilla’s Moon Shot.
Through Webmaker, Mozilla is tackling the problems of online learning and web literacy. Webmaker is part software, part movement.. just like Firefox.
This may sound like it’s a new area of focus for Mozilla, but it’s actually a natural extension of the work Mozilla has been doing all along. Webmaker is about making the full creative read/write promise of the web accessible to the masses. This is about far more than just ‘teaching people computers’: this is about things like personal security, socioeconomic opportunity, civic engagement, access to food and healthcare, and global security. Web literacy is that important.
As the Web Platform continues to advance, it’s important that we don’t get swept up into the world of apps thereby losing what makes the web so powerful. It may sound like I’m demonizing apps, but they have a saving technological grace: RESTful APIs! Combined with new technologies coming to HTML5 (Web Components, Web Intents/Activities, Web Sockets, etc), I’m convinced that Webmaker will become the platform that closes the loop between Apps, APIs, and the Open Web. I’ve written about this previously here and here, as has Atul Varma here, by Kin Lane here, and this thinking is already impacting Webmaker prototyping and roadmapping efforts.
In the same way Mozilla has been a leading voice in Open Source during the last decade, it will be a leading voice in Open Data during the next one. This will become apparent as many of the tools developed and delivered into the Webmaker product eventually find their way into the core of Firefox.
Where the success of FirefoxOS is predicated upon unprecedented collaborative alignment within Mozilla, the success of Webmaker will be based upon unprecedented collaborative alignment between Mozilla and the world at large.
It begins with personal data remixed to create personal stories, but it will soon expand to the organizational stories told in aggregate via the Apps that help us weave our webs of social (and cultural, political, medical, etc) interaction.
And that’s just the launch pad! At this point, there’s no telling what Mozilla’s actual Moon shot will be.
The end of the Web Browser
In some sense, this post is almost an uncanny mirror image of that one. In fact, he begins his post with the same conclusion I want to end on: we’re about to witness the end of the Web Browser.
The work being done around FirefoxOS and Webmaker together form something of a knockout one-two punch to followup Mozilla’s first act with Firefox.
Mozilla Persona brings identity into the browser and blurs the lines between user agent and user. The FirefoxOS ecosystem, in blurring the lines between OS and browser, will bring identity into the device.. mobile, and otherwise.
And so, the Web Browser as a technology gives way to the Web Browser as a person: a consumer of information via the first global unifying computing paradigm. This is a pretty bleak future.
And this is why the term ‘Web Browser’ must eventually be deprecated: it is an absolutely unacceptable state for humanity to be stuck in. We must aspire to be a world of Webmakers.
Why Mozilla? Because the mountain will be scaled, but preparations are already underway for us (all of us, globally) to reach for the Moon! Who’d want to miss that?
In my previous post on how Web Components should inform the Mozilla Webmaker roadmap I make mention of ‘widgets, buttons, and badges.’ The context behind this grouping of things is Kin Lane‘s exploration of ‘Embeddable API Strategy‘ contributing to his work on defining API Building Blocks.
When Twitter first came out with their suite of embeddable widgets, it occurred to me that this was a way in which web services could be democratized for hacking by the masses. I haven’t seen very many web startups build comprehensive widget offerings on top of their APIs, but the ones I have seen often tweak my personal vision for what the web can be.
I also haven’t seen very much written on the best practices of building an embeddable API strategy, and I think this is because we’re still in the early days of the practice. I also think Web Components finally landing could be the catalyst that changes this. Every consumer facing company with an API will want to make their users data available for mixing into the web. And if they don’t, their users may very well do it for them. Either way, Apps with APIs will be growing veins into the rest of the web more and more.
Last week Mozilla’s Atul Varma wrote up some thoughts in a post titled ‘Building Bridges Between GUIs and Code With Markup APIs‘ which not only upgrades our use of ‘widgets, buttons, and badges’ with the fantastic term ‘Markup API,’ but adds some serious clarity to how Markup APIs can preserve the accessibility of a read/write web as the web continues to Appify. This is some seriously important stuff!
A few weeks ago, I sent an email to Kin Lane and some people at Singly to talk about some of these ideas and how Webmaker could be an opportunity to define an embeddable API strategy for the entire web. I targeted Singly specifically because of how their dedication to personal data ownership is leading the development of their ‘API Fabric’ platform which generalizes an increasing number of APIs into a single sane API for developers to work with. A Singly Markup API would lower the learning threshold for anyone interested in remixing all of their personal information together in new ways.
Check out all the web services accessible via Singly’s API explorer: https://singly.com/explore
Now imagine if personal data from all of these services were available within Webmaker via Markup APIs.
I think Singly would make an excellent partner on Webmaker for this and many other reasons. Kin Lane and I are going to keep developing these ideas to see if this is a real opportunity.
In my previous post on this topic, I suggested that the x-tags registry could be thought of as a prototype for a Thimble Widget Directory. I stand by this idea.. but seeing as things keep evolving, I’m now going to call it a Webmaker Markup API Gallery prototype. We’ll see how long this moniker sticks around.
Speaking of ideas continuing to evolve, the Webmaker team got together this past week for some intensive hacking and yielded some exciting new prototypes which you can check out on Brett Gaylor’s blog! They are all extremely exciting, but the thing that stuck in my head was the ‘Save for Later’ experiment which provides a potential vector for integrating Webmaker with Firefox through the collection of web content intended for remix. Markup APIs should definitely be a collectible content type!
Furthermore, it would be super cool if there was a way for a Markup API to declare an interface for being hacked on within Webmaker. Imagine for instance if the Popcorn Maker timeline UI element was a hidden part of every Popcorn video or webpage with Popcorn content. Webmaker wouldn’t necessarily need to have Popcorn Maker code within the core application because the UI module for editing temporal based web content would come with content.
In this way, the content itself, once collected, extends the UI of Webmaker within the editing interface for ease of editing. Webmaker’s UX could be infinitely extensible this way, and it defines an avenue for getting everyone with an API in on the Webmaker vision for an accessible read/write web!
Aside from integration with ‘Save for Later’ prototypes, there’s another area where Markup APIs can help integrate Webmaker with Firefox: through Apps.
If a user installs an App with an API into their web browser, that user should have automatic access to their personal data through that API. And if an installed App has a Markup API, those widgets should automatically be a part of that users Webmaker experience.
The implication is that with every single App you install in your browser/OS, your ability to learn and make the web should grow.
I’m working on reinvigorating CrisisCamp Boston by organizing a series of 2013 hackathons! The first will be next weekend at the MIT Media Lab. Click here for more info and registration.
If you know anyone in Boston with experience in web development, crisis response, or who are just rockstars in general, pass this information along and let them know we could use their help!
A few days ago, Brett Gaylor posted a Popcorn presentation with some proposed use cases to inform the technical roadmap for Mozilla Webmaker. I’m actually jumping up and down right now because I’ve literally had this blog post (the one you’re reading at this very moment) ready to go for two weeks and the timing couldn’t possibly be better!
The Web is advancing rapidly, and Mozilla is one of the major organizations driving it. In many ways, the web has been moving haphazardly from being document based toward being app based. For this and many other reasons, Mozilla is pushing hard in making sure the Web Platform is mature enough to support a web of apps. So much is happening at once it’s hard to keep track of it all! Nevertheless, I try and do just that. Once a futurist, the trendspotting never ceases!
There are some potential technical converges coming down Mozilla’s pipeline that I think need to happen much much sooner than later. These convergent opportunities lie between Mozilla Webmaker and the forthcoming Web Components model.
The Web Components model is one of the more exciting advancements coming to HTML5. Using this model, web developers will be able to create their own HTML tags thus making the web more extensible. Among its many benefits, Web Components will make it easier to develop Apps because Widgets will be more modular and have greater reusability. This essentially gives everyone the means to prototype extensions to HTML5.
My intent here is not to explain Web Components, but to explore the potential implications for Mozilla Webmaker applications. If you’d like some additional background, are some good resources I’ve found.
The best video I could find!
The shortest video I could find!
Time for Popcorn!
The way Popcorn Maker (a Mozilla product that lets you remix video with web content) currently works is by giving you a library of web content widgets called Events. The app lets you attach Popcorn Events directly to specific points of time in a video file. This is great for when you are doing post-process work on a video, but what if you want to start working on your web content before video editing has been finished? What if you wanted to start working on your web content before you’ve even begun shooting video?
Web Components would give us the ability to define more descriptive anchor points for Popcorn Events than is provided by the single static timeline of a video file. HTML gives us all sorts of <h> tags, <p> tags, <divs>, etc etc that describe spatially rendered relationships within a document. Perhaps it’s time we prototyped some markup for temporal layout.
I don’t know what kind of vocabulary would be best for describing temporal markup, but it strikes me that video production and stage play conventions provide some great inspiration. Imagine tags for segmenting time into sections such as <act></act>, <chapter></chapter>, <scene></scene>, and <commercial>. We could also have tags to describe the <transitions> between <scenes>.
Note that our markup vocabulary might go in a completely different direction if we used musical notation as our inspiration. These are artistic and technical questions for a future date.
If we were to create this kind of markup, how might we utilize it? Temporal markup would open up new avenues for development of Popcorn Maker toward professional application across the life-cycle of a production. It would allow us to segment media into discrete temporal segments so that we could manipulate groupings of events relative to one <scene> or another rather than relative to the beginning of a video. I think this could be a powerful way to develop the ideas Brett Gaylor proposes such as creating indexes (dvd style or otherwise), sequencing, and keyframing.
Furthermore, Web Components could help us create tools to for the flexible organization of Popcorn Events before even entering the Popcorn Maker editing interface.
Use case: Air Mozilla
Here’s a use case I really really really want to see happen: Popcorn for live video!
Mozilla has a weekly all-hands meeting that is streamed and archived by the Air Mozilla team. Each meeting has an agenda accessible via the Mozilla Wiki. Imagine if each meeting’s agenda was compiled with temporal markup. Let’s call this hypothetical app ‘Popcorn Agenda’.
Every item added to the Popcorn Agenda would be transformed into a Popcorn Event. People who are scheduled to speak could have a Popcorn Event linking to their appropriate online profile, while projects they are discussing could have relevant links prepped to pop up throughout the live video stream. If a speaker has a slide deck, these slides could also be added as Popcorn Events. When a meeting is set to begin, the live video feed would start streaming through an app we’ll call ‘Popcorn Streamer’.
Popcorn Streamer takes the content from Popcorn Agenda and layers it on top of the live video stream. Because meetings never run according to schedule, the Air Mozilla team could use Popcorn Streamer to manually step through Popcorn Events to make sure they align with what’s actually happening during the meeting. Once the meeting has ended, the video can be archived online with all the Popcorn annotation work having been done up front.
One of the questions in my mind regarding Mozilla Webmaker is how to bridge the gap between learning the web, and advancing the web. We don’t want to just make learning the web stack more accessible, we also want to make the deliberative processes by which the web evolves more accessible. When combined with Mozilla Thimble and MIT Media Lab’s Scratch, I believe Web Components could play an important role in making this happen.
Right now, Thimble is a simple tool for creating and hacking away at simple Web pages. What if we were to throw Scratch into the mix? Looks like we’re already exploring this direction! Awesome! Now, what if Thimble were to take a page from Popcorn Maker and generate embeddable content? What if this embeddable content was structured through Web Components?
Use Case: a Thimble Widget Directory
Imagine a directory of the best reusable web elements created by and for Webmakers everywhere. Actually, there’s no need for imagination here because just a few hours ago Mozilla’s X-tags team launched a new version of their project site which includes an X-tags Web Components Registry. You might consider this a prototype for a Thimble Widget Directory. I propose the scope of the X-tags project should be expanded beyond the scope of infrastructure for FirefoxOS development to really turbocharge Webmaker programming.
For the bonus round, here’s an idea for X-Ray Goggles: A tool for content collection. Beyond mere poking and prodding web pages to see what makes them tick, X-Ray Goggles could become a mechanism for collecting Web Component powered widgets for reuse in Mozilla Thimble and Popcorn. This could turn learning web development into, well.. a collecting game experience not unlike Pokemon or LittleBigPlanet! There are some potential content ownership issues here, but perhaps this would be an opportunity to start discussing how infrastructure for attribution might fit into the Webmaker mix.
If I had to offer some advice to the lizard, it would be to throw more resources at the X-tag project team so that they can collaborate closely with the various Webmaker software development teams. Web Components may not yet have landed on the web proper, but I think it’s imminent enough that Webmaker roadmapping efforts will be made much stronger by starting to take them into account now.
As an aside, I think exploring the synergies between Webmaker and Web Components at this early point could help create some strategic clarity in the longterm (2014+) relationship between Mozilla Webmaker and the Mozilla Developer Network. Webmaker should evolve into a platform that gives learners pathways toward many forms of creativity on the Web. One of these pathways clearly leads deep into app-land.