Re: Initial code review - General Questions
by Sven Laux - Tuesday, 3 September 2013, 9:46 AM

Hi Mark,

thanks for your post and congratulations on the first ever post!

Daryl and Fabien will respond in more technical detail but I wanted to add the following thoughts on custom components in particular:

As we mentioned, one of the first things for us to do is to design and plug-in architecture. This will help lower the barrier to entry for developers in particular and we'd like to encourage everyone to build components (interactions), without necessarily having to know the complete Adapt codebase.

This means that whatever the structure of components is right now, it will almost certainly change and I'd be keen to hear your thoughts on how this could work best.

Ultimately, I would like components to be plug-ins, which could be added to the authoring tool on the touch of a button. Examples of this are the Ubuntu Synaptics package manager and the most recent changes to Moodle. 

This means that each component/interaction would consist of at least two parts: 

  • the data entry bit (i.e. the bit, which plugs into the CMS and tells it what data is required and how to capture this)
  • the output renderer (i.e. the part of the output framework, which takes the data and renders it as part of the e-learning package)

Further to this, I would like the package to contain metadata, e.g. the technical requirements such as which browsers the component works on, who maintains it, what the dependencies are etc.

There would be two types of interaction components:

  • Core Adapt Learning components (core meaning authoring front end + output framework), i.e. components which are shipped directly with the base install/package of adapt and maintained centrally. These would have to adhere to an agreed tech requirements spec e.g. in terms of browser capability etc.
  • Community components, i.e. components, which have been created by the developer community and are available as plug-ins to the core but not directly part of it. Much like with how the Moodle community works, these components may be integrated into the core over time or stay community plugins.

I hope this makes sense.