Project Vallista

A few years ago I created a couple of implementations of Adapt Learning & Authoring for an organization. I remember being absolutely astounded by the product and the group that had put it all together.

I think I was most impressed because I’d been trying to do something similar for years. Not build course creation software — At this point I’d been through five or six iterations of my own. I mean Open Source. See I’ve added little projects and plugins and the like (including one for Adapt that badly needs updated), but never anything like the scope of Adapt.

This was not for lack of trying! I’d floated the idea of Open Sourcing my ALI Framework years before and met with heavy organizational resistance. There’s a story there, but it’s probably not worth telling.

Adapt brought this all back to the surface. I found myself looking at the things I didn’t like about Adapt — not flaws or bugs, but core architectural and behavior features of the product that I liked but didn’t love.

For instance, Adapt uses a web page-like scroll down for more content. It makes a lot of sense in terms of what people are used to in web pages. However, I felt like the cognitive load saved by reusing a standard scrolling page metaphor was overshadowed by how easy it was to scroll past a mandatory element. Sure, you can add flags and buttons and banners (oh my!) but that’s not solving the problem.

I also felt that the two column layout, with each component being an isolated element got old quickly. Sure I could (and did) mitigate that with cool image, parallax and layout enhancements, but it never really popped. Adapt courses depend entirely on their text-based content, and less-skilled authors tended so suffer from more boring courses.

In the end, Adapt courses could be useful, educational, attractive — but they could never be immersive. No one was ever going to full-on jaw-drop over an Adapt course.

Adapt was created at the tail-end of the “no-framework-as-framework” movement. jQuery was still king for selecting DOM and animation. Backbone.JS (you know, where underscore… er, lodash came from) was what all the cool kids used to build applications and Adapt was no different.

In the most simple of terms, Adapt takes a collection of JSON files as Backbone collections, which feeds it’s JavaScript rendering through, Pages, Articles, Blocks and Components, which in turn build HTML and manage individual state, with global state in another Backbone collection.

It’s how we used to do things, but by the time I was implementing the Adapt solutions, the React tidal wave was well underway and, while I didn’t love React, I did wonder if React and it’s ecosystem could have sped up and enhanced the product.

But about the same time I learned about the Headless Authoring Experience — HAX and discovered Web Components, which HAX was built from. Round this point in time, Web Components were niche tech; React devs sneered when you brought them up, conspiracy theories abound about how google was pushing them on everyone for some nefarious reason that was never quite real. I met some wonderful people who worked on HAX and the WC spec on Twitter and promptly fell in love with the idea that I could create my own HTML tags.

I think one of the last things that solidified my thinking around this was a tweet/experiment someone (in)famous did comparing rendering and browsing speed of JS-based UI’s VS plain old HTML. They built two examples using Twitter data for 100,000* tweets: One using a JavaScript-based (React, I think) render with all the bells and whistles that are supposed to make JS views superior, and another in plain HTML.

In every conceivable way, the HTML was superior, despite the significantly larger file size of the HTML solution. The moral of the story (or so I gleaned) was this: Browsers are REALLY, REALLY GOOD at rendering HTML. They would actually prefer you dump huge HTML blocks on them.

Real name pending: Vallista started life as a StencilJS experiment, building a design system out of Web Components to eventually be used as a eLearning Framework.

The idea that struck me was that the slot metaphor was supremely useful for modern Editor UI’s. There are few people who do not understand the concept embodied by Legos, Tinker Toys and the like: Everything has places that snap together, each end to end.

Web Components, on their own, take that idea and also allow for nesting — so blocks that fit into other blocks.

Take a TextContent block. It’s got one job, display text and maybe an inline image. Every block has a “Background” slot that takes any other block. So our TextContent block could take an ImageBlock in its background slot and create an overlay, or take another TextContent block with faint, pull quote text.

With the right design controls (margins, alignment, color, opacity) very complex layouts could be assembled with this same block metaphor.

There’s also nothing to say that slots have to be visible. Slots can behave like decorators, altering the behavior of the block they’re slotted into, both in-terms of JavaScript behavior and CSS behavior. Add a “Parallax” block to an ImageBlock and you have a parallax background image in your TextContent.

Any course authoring software that wants to make authoring easy for Instructional Designers needs an editor.

I originally planned a React/Electron based editor but I’ve grown disillusioned with Electron-based solutions. The more I thought about it, the more sense a Headless WordPress or Sub-Process PWA in a WordPress install made sense.

So many of the details are handled inside the WP system (auth, routing, data, REST, etc.) and building a React-based PWA on top of WordPress’ REST API makes a ton of sense. WordPress is Open Source, approachable and anyone in IT has used it and can implement it. There are even hosts who have custom configurations just for WP.

Also, it lets me forget the foundational stuff and work on the editor without thinking about anything else, at least at first.

Challenges

I’d be lying if I said I wasn’t intimidated by a large undertaking performed on my own personal time. A project like this is a labor of love and joy. However, it doesn’t take much to take that joy and make it just another chore.

For instance: I’ve been mulling over this idea for over a year, with multiple starting points littering my drives like open graves. Balancing my life, my sanity and maintaining some joy are going to be a special challenge to me.