Adapt Learning Community: Removing dependencies and making Adapt Framework (core) standalone

There are some aspects that we have not covered in this post, as a decision and action needs to be made and carried out sooner rather than later. Please feel free to get involved in this discussion if you have any ideas to the approach in making the Adapt Framework standalone and removing the dependencies in core, extensions, themes and components with each other.

Aim/Problem

The relationship between the framework and the vanilla theme is wrong. For people who want a custom theme it is not maintainable, we need to constantly update the custom themes with changes that go into vanilla (we rely on another theme just to work).

If you create a new theme from scratch, some core variables have to be defined in order for the components to build, such as @item-body-text-color-hover which is required by certain components. These variables may not be wanted or required by the theme used, but must be set nonetheless.

Proposed Solution

As a priority there should be a core/minimal theme added to the framework. The point is that the framework (and all components/extensions/menus/themes) should function without any dependencies on any of the others.

All the major or common “global” variables, such as @primary-color, should be moved to the core of the framework. These values can then be used directly by the core of the framework and any components, extensions, menus or themes require them.

Future: Structural vs. Presentational Variables

This is only an immediate step in the right direction. The approach in which the components are structured is something that needs to be looked into to make sure they are consistent with each other, contain their own variables and don’t rely on a theme for anything.

Going forward, everything to do with the layout of any components, menus or extensions should be contained within their respective /less folders. For example, the CSS that creates the layout of the Matching or Slider components should be contained within those components’ LESS files.

Any structural variables to do with layout (e.g. display, float, position, visibility, transform etc.) should already be defined in the core of the framework and can used by the components.

Any presentational variables that do not affect the layout (margins, padding, colour, font, borders, backgrounds, wrapper widths, buttons etc.) should be defined in the theme and more importantly only used within the theme files to avoid unnecessary dependencies.

Nils,

I agree that the current dependency on Vanilla is wrong, and that any 'global' LESS variables, i.e. variables on which the core framework and plugins are reliant, should absolutely be added to the framework itself. I guess then the values could be overridden by the theme themselves.

I'm coming from the perspective of a developer though, and keen to implement a solution which would minimise the risk of introducing breaking changes, as recently happened with the release of v2.0.4.

Brian

Show parent | Reply

Hi Nils,

I support the concept of separating the 'boilerplate' theme (i.e. anything required for the framework to load), and the more presentational aspects.

I'm not a front-end developer, so not the best person to discuss the fine details, but as a user, I want the following from the theme/theme structure:

I'd like the course to build/run without me having to install a theme (for me, a theme is purely aesthetic - it shouldn't be a requirement).
I'd like to be able to easily switch out any *compatible* theme without repercussions.
Plugins which have any kind of UI should contain their own 'boilerplate' theme, and display without any custom styling from the end-developer.
Looking to the future, I'd like to see truly modular theme elements, which could be used by non-technical users to create pretty custom-looking courses with minimal/no front-end knowledge. Here I'm thinking developers will have the ability to create individual 'packs' of fonts, colour palettes, iconography, possibly layout/padding/structural elements, UI element animations (button rollovers etc.). These could then be combined in any combination to give quite a lot of power to non-techies. Quite how a theme would be created using this idea, I'm not sure - it may require some manual work on the side of the users (in terms of having to download, unzip, place in a folder etc.). Ideally we'd get to the point where we have an online interface to do this.

Just a few ideas... :)

Show parent | Reply

Hi Nils,

I've been meaning to get back to this post for a while and wanted to share how we have approached theming at Appitierre.

We've reduced the time it takes to theme really custom themes and still enable the flexibility of plugins to have a set of defaults to fall back on. Our approach falls in-line with a number of recent web development techniques in modular design. One particular approach is the Atomic Design Pattern which, can be seen here. It's all about breaking the theme down into smaller chunks and finding the smallest atom/element and building up. These elements can be re-used over and over again, including both the HTML markup and CSS.

What's great about this approach is that it works perfectly when plugins are involved. We've managed to reduced our LESS footprint by over half and has meant we've brought more structured code blocks into our plugins. I posted something in more detail about this a while back here.

It does mean re-writing the whole theming engine in Adapt but for us it made sense as we've implemented theme customisation into our authoring tool. Now we change the colours once and are able to switch themes without having to edit the colours again. We're actually able to build most of our themes base line colours in under 5 minutes. We never have to have custom plugin styles in our themes as the atoms in our design approach are used instead. Theming becomes easy and fun without missing out certain elements.

Structural vs. presentational variables did cross our thoughts but was quickly dis-guarded as some properties could be seen as both presentational and structural. This also leaves a gap in allowing users to customise themes and colours without structural guidance - after all HTML should be followed by CSS.

Happy to share some code on what an atom, molecules and organisms would look like.

Thanks,

Daryl

Show parent | Reply

Hi Nils,

As of 27th of July 2016:

* handlebars are in core

* ie8 transparency assets are in core

* default loading gif is in core

* vanilla font is in core

* core can handle having fonts, assets and nested less folders

* theme.json screenSize > config.json > LESS as @adapt-device-small, @adapt-device-medium and @adapt-device-large - so we can now specify devices sizes in one place (once the less is correct)

* this behaviour can be greatly expanded to allow more json > less variable value declarations

Next steps:

* Get front end developers to agree on the minimum less footprint (variables, basic structure, basic icon and font declartions) to go from the vanilla theme into the core - preferably with as few abstractions as possible

* Allow multiple themes to be installed together (this would allow for divisions such as: variable abstractions / mixins + branding + project related amends etc and allow for greater reuse)

* Have a developer + front end team look at the way the current themes are used and produce a few examples of simple vs complex themes on which to base others

The goals:

* Expand the theme production community

* Allow the framework to build without a theme so that we can concentrate on raw behaviour

* Give a basic boilerplate for themeing

* Allow the theme to be more theme associated rather than being a necessary structural component

Ollie.

Show parent | Reply