If you’ve been paying attention to twitter, I’ve been rambling on and on about 1 thing lately. #Webcomponents / #Polymer. Depending on the tweet I use one or both. It’s not that I’ve left the #drupal community or converted elmsln over to a different platform; it’s that I’ve found a design paradigm that I can’t un-see.

Webcomponents

Let’s back up a bit.. What are Web Components? Webcomponents (of which you can find many on the webcomponents.org community site) are moving along as a recommended W3C specification (hasn’t 100% stabilized yet but it’s been in the works since about 2014 when Google really started pushing the idea and currently all major browsers can support them via polyfills or javascript filling the gaps). In other words, really smart people that meet to discuss the direction the web should go have said that all browsers should natively support the concept and are largely in agreement about the way to do it (very different from when they were proposed in 2014 with no route to implementation).

Webcomponents aren’t actually 1 standard, they are 4 standards that when paired together, make web components possible. If you are interested in the 4 specific standards you know how to google but TL;DR version:

Webcomponents are made up of Custom Elements that are Imported into the page

This is a fancy way of saying a <custom-html-tag-like-this> can be added to any webpage like this <link rel=”import” href=”../custom-html-tag-like-this/custom-html-tag-like-this.html”>

Modern browsers implement a “shadow dom” approach meaning that it renders the contents of custom-html-tag-like-this.html meaning that it doesn’t need a compiler like Angular or other web framework in order to render (which means much faster then them at doing so), then at run time sees the <custom-html-tag-like-this> tag and goes “Oh, I should throw this in its place!”. Shadow Dom also enables “scoped CSS” which basically means that elements present themselves exactly like they do in documentation as opposed to influenced by global CSS.

Browsers have all agreed (to varying degrees of implementation thus far) that these make sense

This isn’t really that different from the HTML5 <video> tag as far as how the browser processes that to build a player to run the video

What’s in a custom-html-tag-like-this.html file?

That’s the best part, everything required for just that single tag to do it’s magic. So you get a very clean file that has dependencies (since webcomponents can reference other webcomponents), css for this component, normal looking html (though it could also be other <custom-tags-that-you-made> since they stack just like normal HTML), and javascript to define custom properties and functions.

We’ve been working on many but I think lrndesign-blockquote is one of the most straight forward examples we’ve produced thus far. This allows us to wrap the <blockquote> element in a structured way so that we can provide new options / attributes. This will allow our end users the ability to write something like:

<lrndesign-blockquote decorate quote=”It was the best of times, it was the worst of times” citation=”An old dusty book”></lrndesign-blockquote>

and have it show up in the browser like it does here.

Polymer

So now that we have working knowledge of what a Webcomponent is we can jump ahead to Polymer. Polymer is a google backed community / open source project that effectively helps solve the chicken and egg issue of developing against new standards:

Chicken: Developers will only implement the standards browsers have

Egg: Browsers only implement the standards developers will use

To combat this (and provide general efficiency when building) Polymer has created what are known as Polyfills, or javascript that fills in the gaps in browsers to support different aspects of a specification. These Polyfills progressively enhance IE 11, Edge, Firefox, and Safari in order to make them able to support all aspects of the Webcomponent specification as best they can. The idea being that these training wheels can be taken off / modified as the other browsers implement the 4 parts of the webcomponent specification.

You didn’t mention Chrome or Opera

Correct, because all aspects are natively implemented in both which means your webcomponents you produce run crazy fast in Chrome and Opera, as if it’s no different from normal HTML!

Polymer also comes with a Command Line Interface and some other efficiencies when building webcomponents that make it much faster then building without. Basically a single command of polymer init in a blank folder asks you prompts and then starts downloading and positioning code in the right places.

Then running polymer serve –open and polymer will start a mini-webserver to serve up your element as a documentation site like this one. It’s pretty damn magic and incredibly easy to get oriented to.

So this is all on your generally less-technical ELMS:LN blog because…

Because we’re working actively on building out our own series of custom HTML elements intended for ELMS:LN but we are planning and developing them in a way that they will be usable by any educational or non-educational solution. These tags will all be open source individually and packaged in a way via our ontology that allows for remix and reuse in amazing ways.

LRN – Webcomponents for learning

We’ve prefixed these tags with three letters to make them very easy to read and say as a sentence: LRN. This also is abstracted from “education” so that we can share terminology and design needs with training and mooc communities of practice. You can see demonstrations of our current tags we’ve built through our webcomponents.org organization page.

lrn is broken into 4 levels of tags which you can read about in our ontology documents. These are:

lrn – an instructionally focused group of elements

lrndesign – a design focused group of elements

lrnsys – a behavior / system layer group of elements

hax – lrnsys tags which are more repurposable then even lrn so named differently

Together, we can build a well documented style guide for the expression of educational concepts that will have no system specific boundaries. These elements can be loaded into any system connected to the internet so long as the tag definitions are imported. In ELMS:LN we are obviously doing this via a Drupal integration, but there’s nothing stopping us (or you) from running these in any other solution you can come up with!

Design elements (lrndesign) are abstracted from logic (lrnsys) and purpose (lrn) driven elements. Instructors / instructional designers would then be able to write an html tag that has the exact purpose of what is instructionally significant about what they are trying to write instead of constant translation of concepts and assets to code tags. It also will allow us to build a method of content construction we are code naming HAX (short for headless authoring experience).

Video showing our shared future

This is a video I shot just as I was about to make a new webcomponent. It jumps in right at the point that I’ve copied an existing one and renamed it, so it’s a bit of jumping around talking through what works and how it works while at the same time me just coding / fixing some issues that pop up. We’re always looking for people to join us both as developers and idea people sharing how they could utilize something like this best for their needs. Let us know what you think!