A Table of Features

F2201, Technological Features Map.

Name of Programme:……………………………….

CourseID:……………………………

Table summary

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

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].