LRN - The future of design in educational technology
If you've been watching twitter the last few months now, you'd notice a few things with regards to elmsln:
- We tweet back and forth with @oerschema and @lrnwebcomponents accounts a lot
- @hey__mp, @mmilutinovic13 and I have been talking non-stop with people about #polymer and #webcomponents
- We haven't been talking a lot about ELMS:LN proper
So what's happening? Have we moved onto a new project and let ELMS:LN hang out? NO!
At our DrupalcampNJ sprint, we started to toy with the idea of how we go about building HAX, a concept we've discussed during the past 2 drupalcampNJ's now and each time we try to work on it hit a wall. A phrase came up though that completely changed our thinking and set me to work on code. That phrase was "The front end design should be driving the backend API, not the other way around".
Forever, we've gone through a process like so:
- Make a design / mock up of an idea
- See what we've done on the backend
- Start to chunk the mock up into parts that match what the backend has dictated
- Get a design that is MOSTLY the same but not the same as the original
We needed a technology to solve this and so many other architectural front-end design issues we've faced over the years. We want to remain agile with such a large platform / scope and after building the Studio tool in Angular, realized that while it provides a better user experience, the developer experience was slow, not reusable, and hard to reproduce. In other words, unsustainable.
The rise of Webcomponent architecture
I've been blogging on other platforms / producing youtube videos about webcomponents so you can check the links for them but the gist is that in 2014, google proposed to the W3C this idea of allowing developers a way of defining their own html tags. The specification is actually 4 specifications working together and has been an idea that's slowly been growing over the last 3 years.
So why are we jumping on this now?
Well, we're tired of reinventing the wheel and webcomponents offer the same level of code modularity on the front end that Drupal has afforded us on the backend. Polymer, a library we use to build our webcomponents, also has provided a way of filling in the gaps in browser support. From the videos below I hope you start to see just how revolutionary these workflows are.
I encourage you to watch / read through the postings below on how to get more involved in the LRN project and expect to see it implemented in the core of ELMSLN soon. This truly will unlock the ability to do well communicated instructional design oriented custom "html" elements across solutions (elmsln, drupal or otherwise). ELMS:LN will have 1st party support for LRN, not the other way around, to ensure maximum flexibility and adoption by the educational technology community at large.