Hi All,

Last time I posted about how Appitierre are using Article Styles to divide different types of learning content. In this post I’d like to share how we’ve made theming even easier by changing the way the UI theme engine is setup.

The latest release of the Framework’s vanilla theme has specific component/menu styles (like mcq.less) that are held by the theme. For us at Appitierre made Adapt not as pluggable as we needed it to be, straying from the concept of pluggable architecture and functionality.

While experimenting with the theme architecture over the last 10 months we came to the conclusion that we need an approach to our UI that reflected the seamless experience of moving from our platform to Adapt content. We felt that all areas of our platform should reflect the idea of a coherent learning journey. As a result our themes have undergone a complete re-write.

Initial work showed us that we needed first to document every piece of UI across our platform and Adapt. We spent most of a week breaking apart each piece so it could be categorized and so we could establish where elements held similar attributes, functions and styling and where they did not.

Three simple questions helped us with categorzing UI elements;

1. What does it look like?

2. What is its behaviour?

3. What does it do?

Asking these questions of each piece of UI helped us see where they shared common attributes or styles. If a UI element became too different from another we broke it out into its own element.

A Slider component wasn’t slider.less any more. Instead it was made up of 6 different UI elements. Althought it sounds more complex it actually simplifies themeing and gives us a ‘kit of parts’ with which to build any new UI. This fitted in with our new view rendering layer as the UI elements produced here, are also our UI elements in code (we'll post about this soon).

So, how many UI elements do we have? A lot! What it means to “theme” is to actually change the look and feel of our courses. Not having specific Component files in the theme means we’re able to affect similar UI elements without being specific or locked into certain plugins. This modular approach is becoming more and more important when designing larger apps/frameworks and is well suited to Adapts plugin architecture.

The built-in theme editor in our Authoring Tool allows our Learning Designers to change colours, fonts and even add branding elements without needing technical skills.

On a performance note - LESS file sizes (after compression) have over halved. Our modular approach standardized variables and patterns used across different components. We need to edit less (ahem) LESS files to theme successfully. What does this mean for end users? Quicker, lighter downloads and an enhanced experience with our platform. For developers; a streamlined theming process that has greater flexibility and is more robust.

So where do Appitierre go from here? Currently it’s been deployed across all of our clients to great success - but we’re still refining a few things (we find or add a new UI element). Themeing has improved for both clients and developers. The starting point for new themes has increased and they don’t need as much time spent on them. Once we’re happy with a fully fledged theme we’ll be speaking to the core developers on the Adapt Framework to see where we can fit this in, if something like this would be beneficial.

Thanks,

Daryl