F2201, Technological Features Map.
Name of Programme:……………………………….
CourseID:……………………………
Table summary
FEATURE / Hi / Med / Low / NotesProfiles
Forum
Messaging
Chat
Content delivery
Test& Survey
Video
Audio
Tracking
Virtual Classroom
Whiteboard
Agenda
Customisation
Support
Client technical requirements
Usability
Additional feature…
Index
F2201, Technological Features Map. 1
Table summary 2
Index 3
Introduction 5
Explanation of table’s elements 5
Features 6
Characteristics 6
Hi / Med / Low 6
Notes 7
Explanations and didactic environment examples (this document) 7
Note about users test 7
Profiles 8
Registration procedure 8
Personal info 8
Forum 8
Forum manager 8
Message clustering 9
File attachments 9
Web based forum/client based forum 9
Moderation 9
Export/saving 9
Submitted posts editing 10
Email alert 10
Messaging 10
Messaging tool types (asynchronous communication) 10
Chat 11
Selective chat 11
Export/saving 11
Moderation 11
Chat options 11
Content delivery 11
Delivery/Fruition 11
Type 12
Authoring tools 12
Location 13
Delivery time (downloading time) 13
Access protection 13
Online test and surveys 14
Supported questions 14
Interface interactvity 14
Answer editing 14
Timing 14
Feedback to user 14
Answers report 14
Video 15
Frame rate 15
Dimension 15
Delivery 15
Audio 15
Quality 15
Delivery 16
Tracking 16
User tracking 16
Reports/statistics 16
Standards 16
Virtual classroom 17
Recording 17
Session scheduling and invitation 17
Application/screen sharing 17
Online content publishing 18
Content pre-uploading/publishing 18
Moderation tools 18
Whiteboard 18
Refresh delay 19
Colours 19
Tools 19
Number of users at the same time 20
Agenda 20
Agenda Management 20
Visualization Options 20
Customisation 20
Privileges 21
Graphic 21
Support 21
Help structure for users 21
Help structure for administrators 22
Interactive help 22
Documentation 22
Client-Server technical requirements 22
Client connection requirements 22
Client player requirements (and required plug-ins) 23
Required plug-ins 23
Usability 23
Accessibility 23
Graphic 24
Credits 25
Introduction
In this section of the document you’ll find now a table which has been designed as a practical tool for the assessor who’s in charge of evaluating the so called LCMS / e-learning platform.[1]
The aim of this short introduction is to explain and justify the ideas of DLAE staff about approaching this part of the evaluation process.
As everyone knows, in the moment we are writing, there is a load of different products with similar functions and features, developed by small and big companies, institutions and also by single experts of e-learning.
In the last years, a lot of efforts have been made to compare, evaluate and judge all these different LCMS.
In our process we did not collect all the existing platforms, nor we took ‘the most common ones’ and compare them point by point. We already do this during our day to day work, every time we choose or develop a product for an e-learning course.
We do believe in the fact that a book like this is not the right tool for a traditional comparison who can say: in the Platform A you can have forum, chat, file sharing, and in Platform B you have video, chat, and so on.
A multimedia and interactive website, updatable every week, maybe better (see for instance the very interesting EduTools website at http://www.edutools.info/course/compare/index.jsp).
Therefore, we wanted somehow to enter in the assessor’s shoes and so we imagine him not as an expert of the whole e-learning process. He can’t be. Obviously, we need a staff of evaluators, but we imagine just one (or at least two) of them moving to the evaluated company/institution to do the interviews and to see what happens face to face.
In a case like this, the assessor needs an easy-to-use tool who can be at the same time exhaustive as it can[2] and helpful.
Explanation of table’s elements
Features / Characteristic / Hi level / Med level / Low level / Notes / certification[FEATURE NAME]
Features
The table was designed by a group of very different people: we involved engineers, system administrators, didactical experts, teachers, content managers and graphic designers. It was really interesting to see all the different approaches and points of view fighting and finding common paths and fields to mainly define what are we talking about.
The most critic element of the work is, in our mind, the object: the object and its name, which, referring to the table is in the first column, in the brown lines.
That’s why we could stop only on the term ‘features’, which is the most generic and, for instance, in some language as Italian has a very wide range of translations.
In our scheme, feature means “something that’s present or not” in a platform.[3] So, in the same field you’ll find very different things as forum and audio, where forum is a service and audio is a media.
We are aware of the critics that a classification like this may receive, for many reason, from the aforementioned lack of homogeneity to the fact that things like live sessions includes other elements which are in the same column. But, for a practical aim, we warily decided to separate the whole and its sets and consider the sub-characteristic of each one separately.
Characteristics
Here too, the homogeneity leaves space to the attempt of considering as much parameters as possible of the feature we’re talking about.
The answers we need when we, i.e., are talking about the video are the replies to the following questions:
- when a video can be considered as good?
- how can I measure this goodness?
- and good for what use?”
Obviously, every different kind of object needs different parameters of comparison: you cannot compare three chats in terms of kilohertz. It’s also useless to keep every possibilities for each parameter (24 frames per second, 23, 22, and so on).
That’s why we decided to keep only three different ‘degrees of goodness’.
Hi / Med / Low
At the beginning, the fist step was just to say, for every characteristic, if it’s present or not. In this way, the table could be just made of checkboxes meaning nothing more than YES or NO, as in a binary system.
On the other side, as mentioned above, other features has some kind of characteristic that can be almost infinite to consider in every possibilities. You can think about the moderation in a forum, where you can have a lot of different kind of filters and controls (i.e. the moderator read every message then send it to the forum, he can filter only few users, he can just send messages to ‘calm’ the rude users, or just be present or not…).
The adopted solution is to keep only three degrees: high, medium and low, again using terms with a very wide meaning and use, so can be as good for FPS as for number of colours.
The last question of the three above, “and good for what use?” found its answer in the ROWS paragraph.
Notes
These are just additional explanation for the single characteristic mentioned.
Explanations and didactic environment examples (this document)
Even this is not into the table, this part is fundamental as an explanation of what we meant with every feature and his levels. We tried to draw relations between these ‘technical’ parts and some didactic example/environement, just to let assessors and the course manager easily understand when something is good and for what.
As everyone can imagine, the evaluation of how ‘good’ can be a chat, a video or a whiteboard means nothing if you try to do it in a ‘superlative’ perspective. The evaluation must be relative, but relative to what? To the use you make of it? To the kind of course you’re talking about?
Our choose is to draw evaluation tools that put in relationship the features and their characteristic with a didactic environment, to give an explanation of them in a context, as an example.
For instance, video quality is measured in frame rate (usually from 24 fps to 4): but a perfect TV quality video transmission is what I need when I’m just doing an on-line lecture of math? In this case, video is important just to see the face of the teacher, and to get an idea of him, of his expressions and gestures.
So, in which case do I need a very good quality? Maybe in matters where the practical things to teach are important to be shown and seen, e.g. in a course for surgeons...
Therefore, the notes are explaining these connection with examples of possible use of the features.
Note about users test[4]
This is just a small first step to introduce a wider consideration about every kind of courses evaluations:
E-learning develops itself in the innovative field of the digital communication. Evaluations have to be so flexible to be favourable to innovation and not to stop in all directions: technical and methodological.
It is very difficult, and may be useless, define once for all that a feature (or a way to develop it) is good or not: users, use conditions, technologies, methodologies to be developed in the next future may be so various that any statement based on a formal metric system may be true in a specific e-learning context and wrong in an another. So we think that a reliable evaluation of an e-learning course has to be developed through two steps:
· a previous analytical enquire that allows the evaluator to understand in the deep how the course is organized and to remark the critical characteristics;
· a system of tests that will involve all main kinds of potential users (teachers, students and tutors and so on), planned on the basis of the “critical points” risen from the previous analysis.
Final users have to test it and under the supervising of a staff of assessors and evaluators you can get back a true idea of what’s working and what has to be changed.
In our DLAE case, the problem therefore is:
- control that before that a course was realized the designers did user tests, so control the relative documentation and results;
- if those tests were not made before, make interviews with the involved staff (teachers, students…) to keep their opinions and their own evaluations.
Profiles
Efficient profile creation and management is a central issue of every e-learning environment which has to manage users before content and services. A satisfactory users’ profiling involves creation of users’ groups profiles (administrators, teachers, tutors, moderators, help desk, etc.) and setting of different permissions according to groups profiles.
Registration procedure
An integrated registration procedure is needed in case of large communities of users to be registered to different online courses [high level]. For instance, if one platform is to be used by a whole university offering e-learning programs and courses provided by various institutes/departments it should have both registration by administrators and auto registration by students. In both cases some features are useful in order to spare time for data checking, e.g. filters for correct spelling (numbers, e-mail, etc.), possibility of country/city/.../age/... selection, etc. Automatic e-mail feedback/confirm for successful registration and personal account should be given in any case.
In case of a small community of online users a registration procedure managed by course/platform administrators only could be sufficient, i.e. in case of an experimental online or blended course taught by a single professor or in case of an online environment as support for a f2f course [medium level]. Administrators (or professors, tutors, etc.) would get all users’ data, create personal accounts and have them send to students (via platform automatic service or via personal emails).
If the content can be accessed by every web users and no services (e.g. interaction/authoring tools) are available, no registration procedure is needed [low level].
Personal info
A rich personal information area should be available in case of lots of users with various access profiles to be managed and when interaction among users has to be supported [high or medium level]. For instance, if an online course has to be provided to a medium size group of students which are supposed to discuss or collaborate to attain the course goal it is convenient to facilitate interpersonal relationship by giving the students the possibility to introduce and describe themselves and to look for classmates with similar profiles and interests.
In case of a very large community of users which are almost only interested in individual use of content and services the availability of personal area could be much less important [low level]. However, the case in which the administrator has to be contacted for password changing has to be avoided in favour of an automatic procedure.
Forum
In almost every e-learning context and even if the focus is on synchronous interaction or on individual content fruition, the forum is considered a tool which cannot be missing. It is probably the most used tool in e-learning environment for supporting asynchronous communication between users
Forum manager
A typical academic context, which is expected to manage different users enrolled in different courses, would require the possibility of creating different forums according to different courses or learning groups/communities [high/medium level]. In some platforms this feature could also be integrated in the groups creation tool instead of being integrated in the forum. In this case, as soon as a group environment is created it should be possible to create and manage group resources and services belonging to the group (e.g. forum, chat, content repository, etc.).
One single forum for a whole learning community/course could be sufficient in some learning contexts, e.g. in case of a single small group to be managed or in case of the focus being synchronous interaction or individual learning (i.e. with no strong learning goals in terms of interaction between users) [low level].
Message clustering
High level posts clustering features are by this time considered as “standard” for instructional designers and e-learning users whenever the forum tool is important in an online course. Also newbie can get easily and rapidly used to a threaded forum with a clear interface and visualization facilitations [high/medium level].