Markup APIs and the Read/Write Web

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.

Web Components and Mozilla Webmaker

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!

(I’d like to thank Jonathan Wilde and Daniel Buchner for looking this post over! I may be technical, but I’m not a developer by any stretch..)

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.

By enabling the kinds of encapsulation of code currently managed by cutting edge javascript frameworks, Web Components is clearly going to enhance web developer ecosystems in ways impossible to foresee.

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!

The official WC3 introduction to Web Components.
WC3 documentation on Web Component use cases.
News on Web Components via Google+

Time for Popcorn!

As I’ve written before, Popcorn.js is a javascript library that brings a temporal dimension to the web. So far, the web has been a predominantly 2d medium. While WebGL brings the possibility for 3d graphics to the web, Popcornjs makes me think time itself could become the web’s natural third dimension. What does this mean in practical terms?

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.

Mozilla Thimble

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?

Suddenly, not only would new Webmakers be learning how to make web content and javascript widgets they can share, they’d suddenly be learning how to create their own web markup! What was once the domain of standards bodies is now accessible to anyone and everyone.

Of course, this implies a fourth content type I’d like to propose for Webmaker: discrete and embeddable javascript widgets.

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.

X-Ray Goggles

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.

Conclusion

I’ll be exploring this collection of ideas (teaching javascript, asset inventories, showcasing galleries of widgets, buttons, and badges, etc) in more detail in another post.

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.

Webmaker Planning Season: “We know we’re winning if…”

It’s planning season over at Mozilla, and Executive Director Mark Surman is leading a discussion on their next year of Webmaker programming.

On the Webmaker mailing list, Mark continues the discussion in a number of threads. One line in the thread ‘2013 plans: audience‘ stood out where he wrote:

“We know we’re winning if: more and more people use, expect and demand the technical and creative freedoms offered by open technologies. We want 5 million users, 1 million webmakers and 25,000 mentors by 2014. (<–this still feels a little unambitous)”

I’d like to explore the qualitative aspects of the question regarding ambition. I think this is an important question to get right because of how core it is to telling the Mozilla portion of the Webmaker story.

I love the work Doug Belshaw is doing on defining web literacies! From the current wiki version of the web literacy white paper he’s working on:

“At it’s most basic, ‘literacy’ is the ability to read and write something. As we’re focusing on Web Literacies the ‘thing’ that we’re reading and writing is the web. In addition to this, however, as people become more literate we expect them to think critically and be able to look at the world from more than one perspective. For someone to be ‘literate’ they have to be aware that they are literate and be accepted within a wider community of literate peers.”

This actually got me wondering about other definitions of ‘literacy’ which led me to discover something interesting.. the UNESCO definition of literacy. UNESCO is of course the United Nations Educational, Scientific and Cultural Organization. They define literacy as:

“the ability to identify, understand, interpret, create, communicate, compute and use printed and written materials associated with varying contexts. Literacy involves a continuum of learning in enabling individuals to achieve their goals, to develop their knowledge and potential, and to participate fully in their community and wider society.”

If we want to discuss ambition, the UN isn’t a bad place to start. 🙂 I kept digging and found some other interesting things.

The UN’s ‘Official Source of Literacy Data’ sounds useful.

UNESCO’s ‘vision of literacy’ seems very compatible with Mozilla’s emerging vision of web literacy.

UNESCO has something called the ‘Education for All Movement’ that publishes a yearly ‘Global Monitoring Report’. The focus of their 2006 report was on literacy.

Chapter five of this report entitled ‘Why Literacy Matters’ seems highly relevant to this discussion. The opening blurb:

“This chapter explores the case for literacy,especially for youth and adults. It summarizes the foundations of the right to literacy through a review of international agreements, noting that literacy is both a right in itself and an instrument for achieving other rights. The chapter then reviews the broader benefits that result from literacy, in human, economic, social and cultural terms. Since literacy is a key outcome of education, it is difficult to separate the right to literacy from the right to education or the benefits of literacy from those of education.”

Here’s a link to the 11 page pdf for chapter 5. Definitely check it out, and for fun pretend every instance of the word ‘literacy’ is actually ‘web literacy’:
http://www.unesco.org/pv_obj_cache/pv_obj_id_27E513F7C7BDB44895365357CC85266EE2FD0200/filename/chapt5_eng.pdf

One thing that’s clear while reading this document is just how much research has gone into the impact of literacy!

Which begs the multi-million dollar question: What is the impact of web literacy specifically?

Given that the development of the web platform is a moving target, the impact of web literacy itself becomes a bit of a meta question relating to how we as a civilization deal with accelerating technological change. This isn’t just Singularity stuff.. this is who of humanity gets to benefit from the Singularity stuff. But I digress…

What’s striking to me about UNESCO’s education initiatives is how steeped they are in old paradigm thinking regarding education. Their 2013 report, in progress, is titled ‘Learning and Teaching for Development’ and lists curriculum, assessment, and achievement as priorities. Very 20th century. (They’d probably love it if FirefoxOS came bundled with a proprietary MOOC.)

While UNESCO acknowledges the importance of digital literacy, they lack the understanding and expertise to develop the metrics necessary to measure it.. let alone inform the UN’s policies impacting digital citizenship. This expertise must come from the bleeding edge where maker culture is rapidly prototyping the future of learning.

Moving forward, I think comprehensive research around web literacy along measures of socioeconomic impact should be a priority. This task is perhaps too big for Mozilla to take on alone, but potential for partnerships in this endeavor abound.. and the UN’s data on global literacy (linked above) might be a strong starting point for exploration.

All of this probably doesn’t help us come up with metrics for Webmaker success in 2013, but would certainly help frame it as an impactful initiative that makes the case for an Open Web more tangible to the world at large.

Sooo.. here’s my take on ‘how we know we’re winning’ at Mozilla!

We know we’re winning if:

  • More people see technology that doesn’t ‘work like the web’ as either fundamentally broken or unfinished prototypes of web technology. (Qualitative..)
  • Webmaker is used as a tool that expresses learning beyond web literacy. (Potentially hard to quantify.)
  • Webmaker becomes a channel that amplifies Mozilla’s ability to mobilize responses when the Open Web is being threatened. (Quantifiable!)
  • Webmaker development bridges the literacy gap with the Mozilla Developer Network and then swallows it whole! (Raawwwrrr!!)