Adapt Learning Community: Themes

Hey everyone, as we had a brief call with the Kineo team this week I just wanted to put up one of the discussion points which we had.

We talked about the re-structuring of files and one of the items which was raised was the inclusion of "Themes" and the folder structure, should we only allow one theme per course or allow the user to include multiple themes.

This could really add great benefits to an author who would like to create 1 course, with the option of having multiple skins.

For example a course author creates a module on Health and Safety, but wishes to sell this to multiple organisations. Having the same course with the option to pick the main skin upon publishing would allow him/her to maintain one set of core files but re-brand quickly. Also meaning one place to edit content and one place to fix issues for multiple clients using the same course.

This also fits in nicely with the plug-ins idea, people could install new skins from the community.

One of the points which was raised was that theme folders could become quite large, and if for example an author had 15 skins downloaded, we wouldn't want all skins being included in the publish output.

One way around this would be to configure which skin is being used and only include this in the publish output, something which should be technically possible.

I thought I would open this up for discussion to see what everyone else thought about this.

Regards

Alan

Hi Alan,

thanks for raising this. My thoughts so far were that themes would essentially be plug-ins in the authoring environment.

This means that:

the authoring tool could be shipped with one or more standard themes (if we wanted to do this and have the time)
anyone can easily add new themes to their installation and ideally the community codebase
it's easy to customise a themes and create new ones on the basis of existing ones

My thoughts were that the published output would only have a single theme, so users would need to choose the theme for the output as part of the authoring process.

Is this in line with your suggestion? If so, I fully agree and it's already on the list of requirements.

This functionality would, however, exclude the ability to publish a course with multiple themes at once and switch themes at runtime. At least for now this seems sensible but keen to hear what others think.

Thanks

Sven

Show parent | Reply

I think that allowing multiple themes in the folder structure allows for a non-destructive way to customise an already existing theme. This follows the Wordpress-style method of customisiation.

Assuming the following structure:-

/themes/
- /theme-name/
  - /css/
  - /js/
  - ...etc

As a course creator I can download a community theme (for instance 'Corporate') into my themes directory and the create a copy of that theme ('copy_of_Corporate'), allowing me to modify the copy while still maintaining the original intact. If there was a global setting of the theme name then I could switch between the themes to compare them.

Once I'm happy with my theme I could feasibly rename it and upload the new theme back to the community.

The down side is that a course creator could download many themes into their /themes/ directory, bloating their source project. I think this is something that we need to handle during the Publish/Build step, maybe by only allowing the currently selected theme to be published.

Show parent | Reply

Hi Sven,

I'm very keen to see the requirements list. Could you publish that? I'd like to review it in preparation for the workshop next week.

(apologies are probably in order here, I'm reasonably new to the e-Learning world so my use of lingo is probably wrong!)

I think there are a number of questions about themes here which are dependent on the publishing approach.

I can envisage two publish mechanisms

1. Direct publishing to a LMS managed by the host of the Authoring Environment - not necessarily a SCORM compliant package - I'd imagine a Theme here could be picked up from the LMS itself.

2. Publish a SCORM zip file and upload to an LMS - in this instance the theme needs to be embedded with the course.

I suspect we may find differing priorities here.

Secondly, who is able to create themes? Do we expect someone who's creating a course to be able to create a theme? (I'd guess no) What level of customisation are we talking about when we talk about theming? (Colours & fonts only or logos, masthead images and background graphics too?) Do we need to spin off a Theming Engine project?

I'm not very keen on giving end users the ability to switch themes when they're completing some learning. My perception is it's a gimmick that doesn't really add value, rather it's more distracting. I'm willing to be persuaded though!

Ryan

Show parent | Reply

Hey Ryan,

I think creating a switchable theme for the end users is something we would not create as, like you said is a gimmick.

A theming engine is something we've played with and we can show you a little prototype. But, as a company we've found it's only really great for a simple art directed course.

All of our courses have had some bespoke styling done to them after applying or theming tool.

Daryl

Show parent | Reply

Hi,

I’d like to have a centralised versioned store of themes to pull from and apply to any of my courses, then when I publish the course the versioned theme is pulled from the repo and bundled into my course package.

This means that I could publish the same course with any theme from the following 3

Blue Theme v1

Red Theme v1

Green Theme v1

So when I come back and edit the course that I published I should be able to quickly fix a spelling mistake in the course add a little bit of text and republish – even though at this point Blue theme has moved onto v7 (I can still re-publish in Blue v1 or take the latest v7). The same could also be true for the course, as I could have published v1 of the course and sent it to the customer with v1 of the Blue theme, but I used the same course and made other changes to make it v3 and published that and sent it to another customer.

If we agree on the above we are going to have be pretty tight on versioning for everything in the system and store the versions of everything in the published output (and online).

So I’d agree – let the author choose the theme to publish and only allow a single theme per published course, keeping the complexity of versioning and theme/course management in the editing environment

Show parent | Reply

Adapt Folder Structure.pdf

Sounds like we're all in agreement that Themes should be replaceable. I've gone one step further and taken Menus to be like Components, Plugins and Themes. I think a publisher can pick from a selection of modules and change them like Themes can now be.

This will allow one course to be written that has different styled Menus.

I've attached a PDF outlining our initial thoughts on folder structure. We've been over this with the guys from Sponge and will look over this in Derry next week.

Over on the left is the folder structure we're thinking of using. On the right will be the compiled, ready to deploy, minified version of the course.

Let me know any thoughts.

Daryl

Show parent | Reply

In the interest of keeping theming simple and easy for front-end developers to read, edit and save in a consistent manner, I think that themes as a plugin is a great idea. Taking it one step further, it'd be great to have individual files corresponding to each component. For example in the [themeName]/css folder structure indicated in the pdf, you can have mcq.css, hotgraphic.css etc.

These files could act as little snippets of the overall whole, which could be compiled and output as a single file on publish. The upside of this would be that if you needed to edit the theme of a specific component, you wouldn't need to hunt through 2000 lines of css to find it, you could simply look in the small css file corresponding to your component.

Fabien

Show parent | Reply

This is where SASS will do this for us. Theming is up to the developer to style how they choose. I know that SpongeUK have mentioned using SASS and this was also the CSS preprocessor we would use. By using the SASS @import mixin we can have as many files as you like.

However a developer who doesn't know/want to learn SASS could simple use one or many inidividual CSS files to achieve the same result.

These files should sit in the themes folder structure under /css. This is then up to the developer as to whether they use the available Grunt command or use SASS to compile their CSS into [themeName].css.

This will allow minimal http requests for the final release version of a course. It should also be expected that the original SASS files be left in a theme folder for development/amends.

Daryl

Show parent | Reply

Hi,

I'm in agreement with what we've captured in Mark's and Daryl's summaries.

Fabien's post made me think quite carefully about the scope of a theme and how this works with component plug-ins. I think there is a difference, which will force us to leave some theming bits in each plug-in package rather than in the core output 'theme'. I've tried to illustrate this in the following scenario:

We have identified the following plug-in types (amongst others): components (= interactions) and themes. We ought to make it possible for the community to write each of these types in isolation, ie. developer A could write a new 'rounded edges brown / wood effect theme' (bad example, I know), while developer B might write a new multiple choice type interaction.

Either should be able to work in isolation of the other and the new MCQ should be able to take the basic styling from the new theme plugin without the developer knowing that this even exists. Naturally, the interaction component would still need some CSS / styling, which would be embedded in the component package.

Likewise, a theme should work without having to deal with all possible component plug-ins, especially once we have a community codebase (with millions of great plugins :-).

I therefore think the key thing would be to determine the scope of the core theme and how this applies to an interaction plug-in and also package some CSS etc with the plugin itself - but have a well documented interface between the two and guidelines on how to code either.

Hope this makes sense. Thoughts welcome!

Sven

Show parent | Reply