Hi,
I have had a stab at capturing the components and concepts of the authoring subsystem. Please see attached.
This is a straw man to add to and amend. I will capture what we talked about as the scope of the minimum viable product in a further post.
Sven
Hey Sven,
Thanks for sharing this. I have a couple of quick first questions:
I guess I was distracted by some of the technical discussions were were having when those details were added!
I'm interested to hear what feedback others in the community have on this document, especially so after you've posted the details of the minimum viable product.
I'm interested in what people think about how we intend to group courses - the document captures the idea of grouping using tags - we also spoke about favourites and "my recent courses" which are features I believe most users would expect to begin with. Are there other approaches that people would like to suggest?
Den
Sorry, I should say "Projects" rather than "Courses" in that last paragraph.
Is it too late to switch our language to talk about courses instead of projects?
Comments on the diagram to follow shortly...
I agree with the idea that the output of the authoring environment creates a course and not a project. After all, a single project might require the creation of multiple courses.
I also take your point about there being more to a project than what is created in the authoring tool, although perhaps there is might be an argument for any workflow manager element to deal in the language of 'Projects', 'Clients' and so on to help ensure effective housekeeping of output. You could achieve this outside of the tool though so perhaps one to discuss.
This is a useful document for starting a conversation, but I'd like to separate out the software components of the system from the behaviours and characteristics of those systems.
For example, is Tenants a system or a behaviour that the system needs to support? I'd then like to prioritise those characteristics. I'll take that as a task to create a first draft of this for this week.
Dennis is working on a review of our technology options (I'm pretending to help), and an outline of the required sub-systems will help with that review.
I think it would it be useful to break out some of these things into User Stories where possible, so that we can get some context on what exactly behaviour is needed.
For Example:
As a Course Author, in order to provide a branded identity for my course, I want to be able to override the default style with a custom style.
A user story provides context in as much as you have person that needs the feature (As a ...), the reason/rational for the feature (In order to ..) and
the end goal (I want ...)
We carried out some requirements gathering a few years ago when we were considering creating an authoring tool for our Flash framework. Much will still obviously be relevant although there is probably some trimming of the workflow elements that we're requested due to them being particular to our way of working. I can share our 'wish list' see how closely those match to the straw man you shared Sven I can also shape those into one of the user stories.
We should also be able to use this information to generate a 'user story' of a designer working for an e-learning service provider who is creating a course and engaged in the process of using the tool for scripting, building (and collaborating with other disciplines) before passing for custom styling outside of the tool environment.
Hi Chris,
indeed, and we generated a huge pile of user stories last week, I think Mark is collating them at the moment. I think this is an attempt to summarise the requirements at a very high level. I think we can point at a set of high-level software modules that the authoring tool needs to comprise and these would be delivered as part of an agile project using user stories.
Additionally, I like to question everything (sorry), so I'm now thinking, why would a content author need to worry about branding a course, they're more focused on ensuring the content meets the learning requirements. Shouldn't the system just know what customer the course is targeted at and brand it accordingly?
And now I'm wondering if the tool needs to know about customers and how it might manage styles...
/me wanders off to think about that for a while
Ha! Don't apologise! I think that "why" is the greatest word ever created.
At Sponge we need to be able to separate the concept of the learning requirements from the branding, but also heavy customised individual blocks and components. This is definitely a key factor for us.
The ability to apply a custom theme would address this and indeed we're pretty sure that even in its current state Adapt has a lot of the flexibility to allow this.
I'm not certain that Customer is the right noun for it (it fits for us, however I'm sure there are also non-commerical users too), but if we could name and tag our custom themes then that would be really useful.
Have you ever worked with user personas? I did once on another project and it help us to connect with the requirements of our target markets without having them available face-to-face.
Good stuff. I shall continue to question.
Interestingly, I was just reading this morning about User Stories, personas and why they're not very good (I've used them extensively in the past).
This is a very interesting article http://alanklement.blogspot.co.uk/2013/09/replacing-user-story-with-job-story.html
Thanks Ryan,
Probably getting off topic now, that article was an interesting read but I don't really agree with his line of thinking for a couple of reasons. Its a shame his blog doesn't accept comments.
I've always understood a story to represent a promise for a conversation with the requester; that's why they are short and lack the details. He describes that the conversation isn't happening at his place of work then he says he gets problems with features being build wrongly. Also his stories tend to focus lots on the "I want..." and not very much on the "so that.." whereas the motivation is the most important part, it lets you challenge what is being asked for by asking questions without losing sight of the end goal.
I'm sure he has his reasons and if his new way of working is getting results then great, but his conclusion that user stories discourages team communication is just plain wrong. I'd rather say that a team that doesn't communicate will have problems with user stories.
Cheers Dennis, Ryan and Chris.
Agreed we should separate out software components and behaviours and characteristics and thanks for taking that on, Ryan.
To position the document, it was meant for the purpose of sparking up this debate. It includes all sorts and types of things at the moment. I find it helpful to look at the more standard deliverables such as users, user stories, sub systems, requirements and architecture against this type of document later on to make sure we haven't missed anything.
Dennis, here a quick answer to your questions:
Hope both of these make sense. We may not build any functionality (especially for the second item) but it would be good to consider these when designing the architecture.
In addition to the diagram, I'll aim to produce a document capturing thoughts / meanings of all the items on the sheet ASAP. Will upload here for further discussion.
Ryan, I'm open to changing the nomenclature away from project. I agree that project is not quite right. You have put forward some very good reasons. However, I feel there is something about 'course' that doesn't quite fit. For instance, we often call it modules, resources etc. The word course summons something quite big, containing a logical sequence. I think the industry has moved away from this notion and is now looking at smaller chunks. As a challenge, can anyone come up with suitable alternatives before we agree on 'course'?
Thanks, Sven
I know there is a lot of buzz around 'resources not courses' but to me this is misleading. Resource is often a supporting item to a course to allow you to complete a task, that includes additional information of course takeaways. It's all a bit passive.
SCO isn't right as not everything will be tracked or live on an LMS.
Let's go full circle, turn the clock back 10 years and go for Learning Object ;-)
Hi,
We've worked really hard to inform our users that a course is a container for Activities and Resource and that a course is not just the output of their Authoring Tool of choice. (this then helps tie into course and activity completion for reporting)
Activities are - Quiz/Assessment/SCORM pcakages/etc.
Resources - pdf/word documents/hyperlinks/images/text content/etc.
The authoring Tool that we currently have calls the content that you are working on a Project, when you publish that project you publish as a SCORM package (multi or single SCO) or a basic Web package. The package is a zip of the pages and resources that are contained within that project.
Maybe we could call the published package an Adapt SCORM/TIN-CAN/Web/XXX Content Package.
I'd like to stick with project (as it is a container for all of the content) and the published output is somehow associated with the word Apapt to differentiate it from the output of other authoring tools.
Hi Mark,
How does course and project differ for you guys? If a course is a container for activities and resources then what's a project - the live activity being created in the authoring environment which will be published?
Sorry, probably being a bit dense.
Paul
Hi,
The project is what is being edited/created in the Authoring Tool environment, once it gets published (typically as a single SCO SCORM Package). It then gets uploaded into a Course in the LMS as an activity.
We have several examples of LMS courses that have multiple SCORM packages.
As a total aside a lot of our customers call the SCORM packages e-learning - don't ask me why, it was before my time (but it seems to work for them), I don't think it's a good idea.
Right, I see what your saying. I was assuming that the reference to course was in some way related to the authoring tool and not the LMS.
For us, we win a project and then create courses as part of that (which are also typically single SCO packages uploaded to a course as an activity).
Hi Paul,
We talked a lot about tagging/labelling projects, so to relate several projects together for a specific customer you could use the same tag/label - similar to the way you tag email in gmail.
That method should give us a lot of flexibility with searching for an associating projects.
Hi Mark,
We use the term Course in the same way, as a container for one or more activities.
The term Course communicates that there is an end goal or achievement to be attained, SCORM packages and other activities help the Learner achieve that.
I can also see that the term Project fits in the domain of Authoring as you could possible have an empty Project maybe containing just Assets: its not a Course yet, but once you have finished, then the published output of the Project is a Course.
