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.

Like, not Love

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.

Architecture HAX-ing

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.

News Flash: JS is SLOW

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.

Introducing Vallista

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.

A Vallista Editor

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.


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.

Open and Free

There’s never been any point in the conception of this project where I didn’t want this to be free and open source. My heart says that if I can make something that makes the world better or makes someone happy, well, that’s enough. Money doesn’t really motivate me. Joy does.

That said (and this may be walking towards TMI Land), I have personal issues with believing that as a person I’m only worth what I can do. That my only value as a human being comes from what I can produce.

It’s a really ugly thought that’s brought all sorts of misery to me and my family. Separating my want to make fun stuff that helps people from “please love me I made you something” is a weird and twisted thing.

When it comes to making money on this, I may have to resort to helping implement, support or selling to someone who has the same values I do who can support the effort long-term if development becomes a burden.

However, all this is speculative. I have to, you know, build it.

The GitHub projects for the Plugin and framework are incoming (currently on my drive, hidden amongst the Unity experiments). It’ll get up online eventually.

What the hell is a Vallista?

The name is temporary and is an inside joke from Our Saint of Java, based on the series of novels by Steven Brust. Vallista is something like a cross between a very large lizard and a beaver and is known for creation and destruction. I believe the quote is “Vallista rends and then rebuilds.