me
Call for feedback: authoring tool requirements
by Sven Laux - Wednesday, 5 February 2014, 11:02 PM
 

Hi,

this is a call for feedback to the entire Adapt Learning community. We'd like to encourage everyone who is watching or contributing to let us know your opinions on the attached document(s).

The documents capture the requirements we have gathered for the Adapt authoring tool. Both documents contain the same data - we have provided two formats (mind map and tabular) to suit your preferences.

The requirements have been organised as follows:

  • By release (see below)

 

We have identified two releases:

  • Version 0.1
    The first release we can call an 'authoring tool'. It will be extremely basic and is aimed at an audience of authors, who have access to developers (and are expected to use their help working with this release). This user group might think of themselves as early adopters and may (hopefully) have an interest in shaping the tool.
  • Version 1.0
    The first version of the Authoring Tool product aimed at non-technical content authors. With this version there is no need to have developers involved.

There will be several releases between 0.1 and 1.0. We intend to enhance the product progressively, by delivering sets of requirements listed in version 1.0 as interim releases and thus build towards version 1.0 incrementally. At this stage we have not planned the order of sets.

We also have identified requirements, which we do not plan to accommodate by the time of our version 1.0 release. These form the product roadmap. In summary, we intend to build these into the product over a longer amount of time.

 

We would like to gather any thoughts, comments, questions and advice from you (i.e. the community). Please post any thoughts and responses as a reply to this thread. We may then reorganise your responses into separate threads for purposes of making the discussion easier.

When commenting, please mention the requirement ID (e.g. SPR-INST-001 etc), so we can refer back without any confusion.

 

The documents will be sent to the projects Steering Group for sign-off. We intend to reach this point by the end of February. The sooner you can comment, the better in terms of us considering your feedback.


Many thanks in advance and we look forward to hearing your thoughts!
Sven

Picture of Darren Hockley
Re: Call for feedback: authoring tool requirements
by Darren Hockley - Thursday, 6 February 2014, 4:10 PM
 

Hi Sven

Thanks for sharing the specification.

I found myself making notes of things I thought were missing, only to cross them off when I discovered them later in the document. So, clearly a lot of background work has gone into this – well done to everyone involved so far.

 I am pleased to offer my input in no particular order (apologies if I raise things that have already been covered and I missed them) or are already covered in a less obvious way:

 (this one is probably a given but) Adherence to latest coding standards/security protocols. Once fully adopted we (and I’m sure many other users) will have a significant investment of IP residing on the hosted environment. Knowing this will be as secure as possible i.e. from hackers etc. will allow me to sleep at night! I know much of this will be covered by the set-up/lock down on servers/hosting arrangements but the coding of the tool will also be very important.

  1. (this one is also probably a given but) the authoring tool itself with be responsive, not just the outputs it produces?
  2. Ability to organise/sequence content/pages into a non-linear learning sequence.
  3. CCR-ASSM-005 is important. We regularly get asked to limit the number of times a course/assessment may be taken to a given number of attempts (say 2 or 3 times) so a feature like this would be useful.
  4. At V1 I noted several areas for preview. Will a preview option be available at all content levels (course, pages, articles, blocks, components, etc.) so developers can incrementally view what they’ve been working on and then view it all together?
  5. I see SCORM 1.2 mentioned, and also TINCAN. Assume output options will also include SCORM 2004?
  6. Will the developer be able to define specific output to some of the optional SCORM elements of 1.2 and 2004/TINCAN?
  7. ADM-TEN-006 allows a view of audit logs which is great. Presumably these features would be filterable (users, projects, courses, dates, etc) and exportable as a CSV for further manipulation/onward transmission.
  8. We’ve often included a ‘Course Map’ button in our solutions that present a learner with an automatically generated navigation map to allow learners to jump to a section of a course; particularly useful for refresher training. We’ve included course level behaviours to control how this works (always visible, only visible once course completed, never visible).
  9. Options to include enhanced accessibility features with content (user ability to select different background colours, text font, size changes within the content).
  10. Options to include audio controls within published content so users can set their preference.
  11. Publish options to exclude certain media types (such as audio) - e.g. if a user wishes to create a 'thin' version of content.
  12. Course level ‘resources’ feature. Works in a similar way to the glossary feature CCR-LSUP-002/003 but content includes weblinks or content included within the course (pdfs, etc.)
  13. Interactive and context sensitive help throughout the authoring tool.
  14. Ability to set a course level review date on published content to remind the author which courses are due maintenance (useful for courses that cover content with limited currency such as induction, compliance, etc.)
  15. Ability to import a PowerPoint, word document, etc. to create a skeleton course which can then be enhanced within the authoring tool (maybe covered by CCR-CRS-015).
  16. Ability to set reviewers a deadlines/send automated email reminders when approaching deadline/past deadline.
  17. Licensing: options to push courses/content (including later versions) cross tenancy based on tenancy license settings.

I’ve assumed any items not delivered in the V0.1 release would naturally drop into the Must list for V1.0?

Thanks

Darren

me
Re: Call for feedback: authoring tool requirements
by Sven Laux - Friday, 7 February 2014, 4:45 PM
 

Hi Darren, thank you very much for the feedback and great to hear you think we've been thorough!

It's superb to have such a detailed review from you. Quick responses below -please say if you would like us to elaborate on any of the responses.

  • Security: yes, agreed. It would be good to provide some detail around how we approach this. I will raise it as a separate item.
  • Item 1: we have discussed this among the team and have reached consensus that the effort of making the tool responsive outweighs the advantages. In short: no, the tool will very likely not be responsive.
  • Item 2: organising content into a non-linear sequence. A lot of this can be achieved via menus applying an appropriate content structure. The missing bit is probably the more exploratory navigation (e.g. a link from one component in the structure to a different component somewhere completely different). We can add this requirement although it would be good to explore some use cases around this as it may raise navigational challenges (which could lead to building something more akin to a web CMS)...
  • Item 3: CCR-ASSM-005 - noted. It's reflected as top priority (must) for the very first release.
  • Item 4: short answer is yes
  • Item 5: the thinking on this item is that SCORM 2004 is last in the list of tracking priorities and we questioned whether this was at all necessary. Keen to take feedback but would say highest priorities are SCORM 1.2 followed by Tin Can.
  • Item 6: this has not been thought through in full detail. Our approach is to implement a reasonable default behaviour first and then fine tune with configuration options and additional functionality.
  • Item 7: ADM-TEN-006 - yes. Sorting, filtering and exporting lists will be standard patterns, which we will develop into the tool and which are required for enterprise products.
  • Item 8: it would be great to see an example in more detail. We are currently building out the 'jump to component' functionality and (at Kineo) have built prototype functionality to search components by metadata + offer navigation.
  • Item 9: Paul, Daryl, would you be able to respond to this point, please?
  • Item 10: Yes, this is captured (very badly) in the requirements under CCR-WOW-019 - and probably needs expressing much more clearly.
  • Item 11: Interesting. Will add this as a new requirement to be prioritised.
  • Item 12: Yes, this is captured with CCR-LSUP-001 but we probably need to capture web links separately.
  • Item 13: ALL-WOW-004
  • Item 14: Interesting new requirement. This would fall into the roadmap (i.e. beyond 1.0) as there are similar requirements in that section.
  • Item 15: Not covered. CCR-CRS-015 only applies to courses previously exported using the tool. Suggest adding this to the wish list?
  • Item 16: This is an additional requirement around collaboration (thanks!)
  • Item 17: Interesting thought and may well align with catalogue thoughts Ryan had. Ryan, Tony, are you ok to follow this up with Darren in more detail, please?
  • Yes, items not delivered in V0.1 would be 'musts' for V1.0 unless we decide consciously to descope them.

Thanks again for your thorough review and feedback, Darren!
Sven

Picture of Ryan Adams
Re: Call for feedback: authoring tool requirements
by Ryan Adams - Friday, 7 February 2014, 11:35 PM
 

Just to chime in briefly on a couple of points here.

I think that while we might explicitly rule out committing to a fully responsive (small-screen mobile friendly) editing interface I think it's important to support smaller screens (like 7" tablets) and touch interfaces.  We anticipate a lot of people will use iPads to edit courses, and clearly touch screen tablet devices are the future of computing.  I'd expect our first release to enable editing on touch screen devices (I'll definitely be trying it on my Nexus 4!) though obviously it'll be optimised for a typical "desktop" experience.

On the licensing front, I think we'll need to spend some time understanding the use case so we can properly support it. We certainly expect to be able to share content across tenancy boundaries, but as yet we've not defined the mechanism for it. Our approach to defining permissions means we can grant anyone on the system permission to see content (see some stuff on policies here: https://github.com/adaptlearning/documentation/blob/master/02_authoring_tool/05_architecture/multitenancy.md#policies - that document is probably in need of an update to reflect our development so far). 

We've also separated the concept of an asset store (or catalogue) from the core of the authoring tool.  The authoring tool will be able to push to and pull from the asset store, so an alternative approach would be for multiple tenancies to share content via it. We expect the asset store to be a plugin, so the default (likely simple) implementation could easily be replaced by a more comprehensive solution (including, say, a shopping basket implementation).

me
Re: Call for feedback: authoring tool requirements
by Sven Laux - Monday, 10 February 2014, 1:14 PM
 

Hi Darren,

just to say that I have created the following 'issues' on Github following your review:

The two other items (9 + 17) can be captured after we have engaged on the detail.

Thanks
Sven

Lisette Ligtendag
Re: Call for feedback: authoring tool requirements
by Lisette Ligtendag - Sunday, 9 February 2014, 1:29 PM
 
Hey Sven, I’ve read the list with authoring tool requirements it really looks great. Thanks you all for such hard work. I do have a wish for the road map (perhaps it is for the long distance roadmap :-) ) . . But I think if you design for learning it is a must have. It would be very nice to make error pattern analysis this allows you to determine whether students are making consistent mistakes. And also to make Learning Paths as a result of this analysis. Thus, when a student/pupil makes consistent mistakes he is given the right instructions, based on those mistakes. To do this one has to design questions and answer alternatives to make this possible. For example: someone learns basic computations. After instruction he is given some exercises. By doing those basic computations one can make for example three kinds of mistakes. Let’s call them (creatively :-) ) A,B and C. For the first question, one chooses answer alternative 1 if one doesn’t get it and is making errors of type A. For the second question, the same holds true for alternative 3. For the third question, idem for alternative 1. So if a student chooses alternatives 1,3,1 in succession he consistently makes error type A . If so, I would like to alter the learning path for this student to give him feedback and instruction about the specific error. It would be nice if the program does this automatically for the learner. So, not just telling him to read article x, but directly lead him to article x. Kind Regards Lisette
me
Re: Call for feedback: authoring tool requirements
by Sven Laux - Monday, 10 February 2014, 10:05 AM
 

Hi Lisette,

thank you for the suggestion. It's very well explained!

I could see this type of functionality also being useful for delivering initial diagnostic and branching scenarios.

I have created an 'issue' on Github at: https://github.com/adaptlearning/adapt_authoring/issues/287

This way, it can be freely discussed and we won't loose track of it.

All the best and thank you also for your great feedback and encouragement.

Sven

Picture of Mark Fletcher
Re: Call for feedback: authoring tool requirements
by Mark Fletcher - Monday, 10 February 2014, 4:01 PM
 

Hi Sven,

The authoring tool requirements are looking in great shape. Below are some questions I have about some of the features.

  1. WYSIWYG authoring environment - Which rendering engine (for example, Chrome Blink) will the authoring environment visual display be based on?
  2. Video files - Will be possible to create interactive videos? Tools such as Tumult Hype are starting to include the ability to include JavaScript functions in videos.
  3. Will users be able to import questions using the GIFT format?
  4. I notice that the authoring tool will allow a user to crop an image (CCR-­‐WOW-­‐013) will they also be able to apply transparency to images?
  5. I see that the authoring tool will enable users to embed Captivate files (

    CCR-­‐WOW-­‐018) but what about content from Articulate (Storyline / Studio)

Cheers,

Mark

 

Picture of Dennis Heaney
Re: Call for feedback: authoring tool requirements
by Dennis Heaney - Tuesday, 25 February 2014, 7:17 PM
 

Hi Sven,

As discussed, I reviewed the requirements with a view to highlighting areas where the design team could exempt themselves from consideration of how something might work on a tablet device.

Some of the items below are a little repetitive, and perhaps obvious in some cases, but hopefully will come in handy.

In general, adding assets (video, audio, and images) to components should be possible if the asset has already been uploaded, or if the asset is added from a remote repository, rather than uploaded from the user's device:

CCR­‐WOW-009: Able to add content images to relevant components
CCR­‐WOW-011: Able to upload multiple versions of a graphic for use in different contexts
CCR-AMGMT­‐008: Able to upload background images
CCR-AMGMT­‐009: Able to change re-upload background images
CCR-AMGMT­‐024: Able to upload content images
CCR-AMGMT­‐025: Able to change re-upload content images
CCR­‐WOW-015: Able to add audio files to relevant components
CCR­‐WOW-015: Able to add video files to relevant components
CCR­‐AMGMT-­016: Able to upload themes
CCR­‐AMGMT-­017: Able to change (re-upload) themes
CCR­‐MEN­‐003: Able to upload a custom menu
CCR­‐LSUP-­001: Able to add/remove file resources
CCR­‐OVR­‐001: Able to add a zip archive which will be extracted as part of the publishing process and override core Adapt code files
AUTH-DEV-001: Able to upload files to override core code
CCR­‐WOW­‐018: Able to embed Captivate files

With publishing, it might be possible if we're publishing to a remote location, but otherwise, doesn't make much sense to worry about how a tablet will handle these:

CCR­‐CRS­‐014: Able to export a course    
CCR­‐CRS­‐015: Able to import a course    
CCR­‐PUB­‐001: Able to publish a project that produces SCORM 1.2 conformant tracking
CCR­‐PUB­‐002: Able to export a course as a SCORM zip file
CCR­‐PUB­‐003: Able to publish my project as a TinCan package
CCR­‐PUB­‐004: Able to publish the course in a non-tracking web format
CCR­‐PUB­‐005: Able to publish the course in an compressed/minified format
CCR­‐PUB­‐006: Able to publish the course in an uncompressed format
CCR-TRAN-001: Able to export all language content in a packaged format suitable for translation agencies to work with
CCR-TRAN-002: Able to import a translated language content package into the same course
CCR-TRAN-003: Able to import a translated language content package as a new course

I don't think we should be too concerned at this point about supporting editing of images on a tablet:

CCR­‐WOW-012: Able to resize images
CCR­‐WOW-013: Able to crop images
CCR­‐WOW-014: Able to compress images

The next one might be ok - it'll be a challenge in any case:

CCR­‐WOW­‐007: Able to edit inline whilst previewing output

This one might involve logging to console, or a child window:
AUTH­‐DEV-­007: Able to see a technical log of course actions in preview mode

Aside from that, I'm happy with the requirements document. I just have a query about the following ticket:
CCR­‐WOW­‐023: Able to message users to prevent accidental deletion of content items
Can you clarify what this is, exactly? Is it as straightforward as an IM to informally alert a user not to change something, or does it involve locking content also?
       

Picture of Darren Hockley
Re: Call for feedback: authoring tool requirements
by Darren Hockley - Tuesday, 25 February 2014, 7:58 PM
 

Hi Sven

I know there has been a lot of discussion around features to build multi-lingual content. But will the tool itself be designed to support multi-lingual authoring?

Factoring this into the early design wouldn't be too complicated if thought through now, and the actual screen translations can come later.

Regards

Darren

me
Re: Call for feedback: authoring tool requirements
by Sven Laux - Tuesday, 25 February 2014, 11:03 PM
 

Hi Darren,

very quick answer: Yes, the tool is designed to be multi-lingual. We understand this is a necessity in order to make the Adapt authoring tool viable globally and for enterprise users.

Sven