Skip to content.
Sections
Personal tools
You are here: Home » Features » Can web service technology really help enable ’coherent diversity’ in e-learning?

Can web service technology really help enable ’coherent diversity’ in e-learning?

Scott Wilson
Last modified 05 Jul, 2005
Published 31 Jan, 2005
Scott Wilson explores technology and pedagogy and suggests that a service oriented approach to system design could lead to greater pedagogic diversity

I've often been asked to defend a statement I once made that using a service-oriented approach to system design could lead to greater pedagogic diversity. Well, we often say silly things, but rather than duck back under the parapet at Castle Geek, I thought I'd take the time to express my rather naive notions of how technology and pedagogy interact, and why I think ultimately some of our technical platform choices are going to impact pedagogy more strongly than perhaps is realised.

What are web services?

Web services are a new way of creating applications, particularly when we want to make use of functions that are distributed around a network. This isn’t a particularly new idea in itself – email is a sort of ‘web service’ and has been around for ages – but it does make use of some new technologies, particularly XML for structuring text as data and http, the Internet protocol used by web browsers.

In a service-oriented world, we divide software into two types; applications and services. Applications are things that people interact with, and have some sort of visual interface. Services are things that Applications (and other services) interact with, and have an interface that is all about exchanging data.

In practice this isn’t a really strong distinction, so its better to think of them as roles; for example, when you use your Email application to get mail, the mail server at the other end is acting like a Service. When the person managing the email server logs into it to configure the various options, it is acting like an application.

The most important point is that when we use the term “interface” that this can have two meanings – something that is an interface between people and software (user interfaces) or something that is an interface between two pieces of software (machine interface, or web service), and the latter is the one we’re mostly concerned with here.

By providing web service interfaces instead of just serving out a user interface, we allow more flexibility in how the functions of software can be used. For example, instead of having to use a special email client depending on which email server you are using, you can use a client of your choice for connecting to any email service.

Before delving into the specifics of e-learning services, lets first take a look at some existing examples of ‘web services’: RSS, iCalendar, and IMS Enterprise.

RSS: Sharing and aggregating news

RSS has a variety of acronyms and versions, but roughly speaking this is a specification that allows the owner of a website, weblog or content repository to announce new items they have published. The list of items is called a feed, and contains information such as when the item was published, the title, a summary, and the link to where the full item can be seen. Feeds are published on a site at a particular location, which can be used by an application called an aggregator to read the feed and display it along with any others it is aware of.

There are a great many aggregator applications out there, some web-based and some that run on the desktop. A common feature of an aggregator is that, rather than you having to go to each site you are interested in, find the ‘new’ section, and read to see if anything has turned up since you last looked, the aggregator does all this for you. It goes to every site it has a feed for, combines the results, and lets you know what’s new.

Here’s an example of what an aggregator looks like; this is Shrook, an aggregator for Mac OS X:

From left to right, the columns show how I’m organizing my feeds, the feeds (‘channels’) themselves, the items in the selected channel, and the summary of the item I’ve selected. In this case, I’m browsing through the latest items published by Wired magazine.

I’ve told Shrook where to find the feed for Wired by first looking at their site – the feeds are listed on the site - and then adding in the feed address to my Library of feed addresses.

Shrook shows me all the feeds I’ve added, and checks to see when new items have been announced, and can flag them up to me by putting a star next to them, so I can see at a glance which of the sites I’m interested in have new content I may be interested in. I can then look at the summaries in Shrook before deciding whether an item is interesting enough to visit the site for. For research and journalistic purposes this can be a real time-saver.

As well as desktop aggregators like Shrook (and Sharpreader for Windows), there are also web-based aggregrators, which range from large commercial-style services to more specific collections such as the RSSXpress site offered by UKOLN, which aggregates feeds from JISC services and projects:

RSS isn’t just used in this way, however; because it is a fairly simple XML file that any site can publish, all kinds of uses have been discovered for how to combine RSS feeds with the features of various other sites and applications.

For example, there is a new trend of “Podcasting”, which involves publishing RSS feeds with audio files attached to them, which can then be aggregated by music devices like the iPod, or audio-aware aggregators such as iPodderX

A number of organizations now publish these augmented audio feeds, including the BBC, which is podcasting the Radio 4 series In Our Time, and Heineken which has begun podcasting music showcases.

This ‘unintended use’ aspect is important, because it hints at how services with an educational flavour could also give rise to novel learning experiences.

Stephen Downes has an article on his website that describes RSS from an educational perspective, and makes useful reading; however here I just want to use this as an example of a Web Service in use today that captures some of the possibilities we’re interested in.

iCalendar: Sharing and aggregating schedules

Another handy type of web service alive today is iCalendar. iCalendar is somewhat odd in that it uses a format other than XML, but is otherwise quite similar in principal to RSS. ICalendar is a simple file format for exchanging calendar information – dates, events, recurring events and so on. These files are then made public via a URL, so that a different kind of aggregator can go find them and display the result.

There are two main ‘aggregators’ that tend to be used for iCalendar, one is the Mozilla suite of applications, especially Sunbird but also Firefox with the Calendar add-in, and the other is Apple’s iCal application that comes with Mac OS X. There are plenty of others around as well as these, however.

In action, iCal is a fairly typical sort of calendar application, except that rather than look on a single server for calendars, or store calendars internally, iCal can ‘subscribe’ to calendars published on the Internet, and it can also publish your calendar if you have some web space available. iCal in action looks like this:

iCalendar files can be published by individuals or by organizations; in the screen above “CETIS Events” is an iCalendar file provided by the CETIS website, allowing events and conferences to be integrated into personal calendars; the others are mostly calendars published by individuals from iCal or Mozilla Sunbird.

All kinds of scheduling information can be shared in this way; the website has links to hundreds of public calendars for everything from sporting fixtures to band tour dates, all in iCalendar format.

IMS Enterprise: People and Groups

Originally developed to enable the exchange of data between institution’s student information systems and their VLE, the Enterprise specification from IMS provides a web service technology for working with XML data for groups such as courses and modules, and the people who are members of those groups.

Unlike RSS and iCalendar, Enterprise augments the http protocol with additional commands using the SOAP and WSDL technologies developed by W3C. This means that the interface for the service has a range of available commands for reading, creating, updating, and deleting groups, people, and memberships, either singly or in batches.

A typical deployment pattern for Enterprise is for the student information system to provide a service, and for elearning applications to consume the service, enabling them to gain access to module structures and current enrolments. However, there are already other applications of the technology, for example to support classroom registration, and in combination with iCalendar to share both course descriptions and their associated timetables (see the SWEET Project for more information).

Enterprise is one of the first education-specific web service specifications, but others are likely to follow.

There are other technologies as well as these I’ve mentioned, for example the Atom protocol for working with entries in weblogs and forums, the SRW/U protocols for conducting searches of repositories, and the OAI-PMH protocol for aggregating metadata from repositories, but I hope you get the general idea.

The trend we are interested in is the decoupling taking place here between how a person or organisation provides the service, and how other people choose to consume the service. They can use completely different applications, platforms, languages and so on, providing they both abide by the same set of rules – in the cases above the RSS, iCalendar, and IMS Enterprise specifications.

There are a lot of different technologies and approaches that are used to make Web Services happen – the most common acronyms being SOAP, WSDL, ReST, http, XML, UDDI, and RDF. There are some important differences in the ways that services are exposed and consumed at a technical level, but they all share a common approach, which can be characterised as having distributed functions that are shared according to some sort of “contract”.

What is the e-Learning Framework?

So far we’ve looked at some existing web services and seen how they are used, sometimes beyond the original conceptions of their designers. It isn’t a massive stretch to see that:

  • some existing web services have educational uses
  • web services with educational purposes are being developed
  • there are some elearning functions we can make into web services

The e-learning framework is the efforts of JISC, DEST Australia, Industry Canada and others to start putting together a ‘palette’ of elearning features that services can be used for. In some cases, such as Timetabling, this may involve using iCalendar; in others, such as Assessment, there isn’t anything out on the broad web yet that is suitable, so the e-learning framework partners are investigating standards and commissioning development work to see what would be useful.

The idea is that anyone wanting to develop an e-learning application can look at this ‘palette’, select the services of interest (either to consume or provide), download toolkits provided by other developers to help integrate the service, and then incorporate them into their application.

Using this ‘composite application’ approach, it should be easier for an elearning developer to combine all kinds of useful features in such a way that they support the educational objectives they are seeking to support, but without having to develop everything from scratch (and inadvertently locking their users into only being able to work with their application).

The ELF is, at present, a collection of things:

  • A list of functions that can be provided as services, which can be used to plan systems
  • Toolkits to help developers of applications to provide and consume services
  • Contracts – interfaces and standards – that providers and consumers can use, either referenced from international standards organisations, or provided by research projects

The range of services considered by ELF (current list) is far wider than news alerts, and covers areas like accessing and modifying student and course information, reading and posting to forums and weblogs, creating and accessing course reading lists, searching for learning objects, sequencing learning activity, reporting grades, accessing and scheduling classes on timetables and a whole range of other functions.

Standards play an important part in services, as they form the common contract between the provider of a service and anyone who wants to consume it.

For example, an institution may want its MIS database to provide a service that lists current descriptions of courses; if this service provides data in a unique format, then any consumers of the service, such as e-learning tools, will only work at that institution. However, if a standard format is used, then tools developed to work with the service will also work in different organisations.

Note that standards here are enabling this decoupling of the design of the tool from the design of the services on which it depends, which is the first step in creating greater diversity in the user experience.

Enter Pedagogy

Pedagogy is often expressed as sets of models of practice; for example, problem-based learning, outcomes-based learning, constructivism, Laurillard's conversational model, and others (Beetham). Ultimately, however, all such models, when applied to e-learning, result in a relatively discrete set of technology choices.

This is perhaps less of a complete free-for-all than is often imagined, especially when constrained by resource issues, the impact of organisational and administrative models, and the need to get technical interoperability working between system components to make things happen.

In this context, pedagogic choices in e-elearning can be categorized as follows:

  • Interaction mode
  • Connection mode
  • Engagement mode
  • Structuring device
  • Structural affordance
  • Workflow

This isn't meant to be an exclusive list, but serves to allow me to illustrate some of things that are potentially amenable to being manipulated to support pedagogic choices.

In each section below I'll try to see each of these choices from one of the views described in the JISC publication, Effective Practice in eLearning, which describes three views on pedagogy - associative, constructive, and situative. These views are not mutually exclusive, but instead imply different kinds of priorities for practice. The following definitions are taken from the publication:

The associative view is characterized as “Learning as acquiring competence”, and emphasizes: - Focus on competences

  • Routines of organised activity
  • Progressive difficulty
  • Clear goals and feedback
  • Individualised pathways matched to prior performance

The constructive view is characterized as “Learning as achieveing understanding”, and emphasizes: - Interactive environments for knowledge building

  • Activities that encourage experimentation and the discovery of principles
  • Activities that encourage collaboration and shared expression of ideas
  • Support for reflection and evaluation

The situative view is characterized as “Learning as social practice”, and emphasizes: - Participation in social practices of enquiry and learning

  • Support for development of learning skills
  • Dialogue to facilitate the development of learning relationships

Interaction Mode

e-Learning can be delivered through a browser, through a desktop application, vicariously (teacher uses Powerpoint, students don't have computers), through multiple interacting applications (the individual desktop as the delivery mode), through a mobile device, or through a dedicated static device. Different modes afford different kinds of e-learning, generally the dimensions of interest are:

  • visual capacity (screen size and resolution, colour vs. mono, refresh rate, 3d capability)
  • audio capacity (mono vs. stereo, surround sound, 3d "positional sound")
  • mobility (fixed, semi-mobile/portable, fully mobile/personal)
  • responsiveness (desktop applications tend to be a bit snappier than those that run in web browsers, and can “push” as well as “pull”)
  • gestural capacity (desktop applications have more control "widgets" than HTML, many mobile devices such as phones don't have pointing devices like mice or trackpads)

Current e-elearning systems are, on the whole, tied rather heavily to the browser as the interaction mode. This affords good visual capacity, often rather poor auditory capacity (by habit rather than capability), limited mobility (PCs or laptops only), and relatively sparse responsiveness and gestural capacity (point and click to pull information).

This choice affects the kind of e-learning experience, and tends to showcase the visual capabilities of multimedia content. Other modes, such as mobile phones, or dedicated desktop applications, tend to emphasize other factors.

The Associative View of Interaction: The teacher needs to have a clear idea of the instructional approach for each unit of learning, and the interaction model used should support that approach. If possible, the teacher should be able to choose the interaction mode, so some units could be delivered using a browser-based tool, and others using a mobile device as is appropriate.

The Cognitive View of Interaction: Learners need to be able to explore the subject and to interact with the environment in ways that allow them to experiment and reflect. Learners should have some choice as to how they interact, perhaps allowing them to select their own tools so that they can manage their own structuring of their interaction and reflection. Gestural richness may be a crucial feature of the interaction mode.

The Situative View of Interaction: The environment needs to support the learner so that they feel better able to participate and to develop their identity. The interaction mode needs to emphasize communication above all, and is more important than factors such as richness of presentation capability.

Designing e-learning features as services and data rather than directly as websites or web-based applications has certain advantages in terms of repurposing those capabilities for different modes of interaction (which can still include the browser).

Depending on the choice of pedagogy, a service can be accessed by a web browser, an application on the desktop, a mobile device, or some other interaction mode. This is easier to achieve by first decoupling the user experience from the data and services that support it, which is at the heart of a service-oriented approach.

The Web Services model certainly affords us greater flexibility, but it ultimately rests on developers and designers making good use of the "non-standard" modes, especially as these other modes have certain additional development costs associated with them.

I personally think the time is right to look long and hard at the desktop again, and to reinvent e-learning applications as "aggregators" of services provided by a range of organisations, rather than "viewers" onto an organisational perspective.

Connection Mode

Some interaction modes are connected all the time. Some are never connected, like a standalone learning centre PC with a multimedia CD-ROM. Many are partially connected over time, as the user changes contexts, for example: the "road warrior" with a laptop chasing elusive Wi-Fi hotspots, the rural user with single-line dial-up that prevents them answering the phone, or a mobile phone user on a train that goes through tunnels or into rural areas where there is no service coverage.

A second dimension of connection is the distinction between synchronous and asynchronous connectivity. Synchronous modes enable "real-time" interaction, where users have a virtual "presence" that can be shared with others that are connected, like in instant messaging software such as AOL AIM and MSN Messenger. Asynchronous connection is more like email, where there is latency between initiating and responding to communication. Many environments tend to mix these two types - for example, by supporting both forums and instant messaging.

e-Learning can be designed to support a range of connection modes, but has tended in the mainstream to be based around the permanently-connected mode, which inhibits its usefulness for the partially-connected (that is, most of us).

Designing for the partially-connected mode changes the whole design strategy around e-elearning, and I'm still surprised that relatively few e-learning systems have taken this into account.

The Associative View of Connection: The mode of connection may be an important part of how an activity needs to be delivered; sometimes it will be important for the tutor to engage synchronously with learners during class time, at others they may need to be able to prioritize how the interact, which means asynchronous activity. The mode of connection may need to vary, therefore, depending on the learning design in use.

The Cognitive View of Connection: Learners have different approaches to learning and may need different connection modes, in general the mode of connection should be learner-centric, so that learners can engage with the material according to the way that suits their situation. From this perspective, the partially connected mode seems very attractive.

The Situative View of Connection: Communication and having a virtual "presence" within a community are important aspects of learning, and the connection mode should provide the best opportunities to engage and communicate. At the same time, it's important that learners don’t get bombarded with communication if they don’t want to, so being able to selectively disconnect is an important feature.

Partial connectivity creates a particular problem for Web Services - if all the features of e-learning are exposed over the Internet as web services, how can users operate partially-connected? Well, the answer I think lies in enabling network-capable applications that can connect and cache, such as desktop News Aggregators or applications like iTunes. Unlike web browsers, desktop applications are generally quite good at working offline, as are devices such as handheld computers that "sync" when a network cradle becomes available.

Structuring devices

e-Learning applications all structure information and features according to some ruling mechanism. In many typical VLEs today, the structuring device used is the Module or Course; that is, the organisational unit within which education can take place. This isn't a given, however; it is perfectly possible to imagine structuring using time (categorised by week, perhaps) or by topic of interest, or by the persons involved.

Choosing a structuring device can profoundly impact on how learners relate to a system, and how teachers can operate it too. The "module" approach, for example, seems to sit well with the administration of courses, but can seem artificial when there is a strong overlap between organisational units. This is especially the case when the structuring categories are strongly enforced and discourage cross-membership or cross-linking of tools or materials.

When the various manifested aspects of e-learning- course structures, weblog entries, forum topics, content, resource lists, etc - are made available as Web Services rather than as zones within a web application, then the job of structuring is left in the hands of the designer and developer of an elearning system.

Forums can sit apart from courses, or be integrated within them; reading lists can be organised by person, by course, or by the week the resource is mentioned. People can be sorted into courses by enrolment, or listed by interest, or other factors. Basically, the choice of structuring is blown wide-open for the designer of an application or environment to make their own choices based on how they think this is all best achieved.

The Associative View of Structure: Structure is very important; tasks for learners and teachers need to be analysed and routines of organised activity created, and these should be the focus of how the learning environment is structured. The pathways and relationships between units of learning should be exposed and used as the basis for providing instructional information, feedback, goals, and for sequencing progression for learners.

The Cognitive View of Structure: Structure is very important, and should enable learners to explore, interact, and experiment. Learners should be able to move between "units" in a relatively unconstrained manner in order to fulfill their learning goals and to make their own connections between concepts. Support should be independent of formal course structures, so that learners can receive coaching and feedback regardless of their discovery path.

The Situative View of Structure: Structure is very important, and should enable learners to interact with both one another and with teachers and other models of competence. The environment should be structured around the social organisation of learners, enabling people to find others with similar interests, goals, or desired capabilities regardless of formal unit organisation. At the same time, the environment should not be overwhelming, and allow the capabilities of the environment to gradually unfold as the learner gains confidence.

Below is an example showing some simple web services - providing XML data for groups, forums, and resource lists - and how those services can be utilised within two different approaches to structuring the learning context.

If we were making this today, we might use Enterprise for the groups, Atom for the forums, and RSS for the resource lists.

The top one is a fairly traditional sort of VLE view, with a tree-view of modules and units linked to a forum view and resource view filtered on the current selection.

The lower view shows the same services in a less module-centric view, where all the forum entries are shown in a single "message centre" rather than divided into modules, and resources are divided up into tabs by module.

structure

These are both rather “associative” in approach; perhaps we could take a more cognitive view and organize the information by constructing a topic map? If so, would we distinguish between messages and resources or just attach both types to each node on the map? Then again, perhaps we want to further emphasize the associative view further, and add in class schedules for each group as well as resources and conversations. If we wanted to take a more situative approach, we could perhaps augment or replace the groups view with a people-network model, using something like Friend of a Friend (FOAF ) as a basis for connecting people together.

There are many possible approaches we could take even with this extremely basic information, and I still find it quite surprising that the vast majority of VLEs structure things in almost exactly the same way!

Its worth noting as an aside that this structuring we’re discussing here is more involved than using ‘portlets’ or frames to display different bits of user interface in particular parts of a browser window, as we also have changed the dynamics of how the elements on the screen interact, and how the information is aggregated and used.

We could go further, and link together the tools with the structure, so that Week 1 has a Forum, Week 2 has content, Week 3 has another Forum and so on. We’ll cover this sort of organizing principle in the section on “Workflow”.

Well, it can be argued you have these choices already - by making your own VLE from scratch! However, having the capabilties made available as services within the environment makes it possible to not only do this once (and more cheaply), but do it many times even within a single organisation without causing all kinds of administrative and IS management issues.

Using Web Services enables structuring choices to be at least partially decoupled from the data sources and services in the environment, and this allows considerably more diversity without sacrificing either the principles of interoperability and adherence to standards, or having to "mess around IT services" every time you have a bright new idea about organising things differently.

Structural affordance

As well as structuring of the overall experience, an e-elearning system creates a model for the user where some things are easier to do than others - what I'm calling structural affordance. For example, the open-source VLE Colloquia always presents the discussion forum for an activity as the first thing that a user interacts with. Although it also supports resources, the order in which these two features are presented encourages engagement with the forum feature first, which has implications for how learners and teachers interact with it. Other VLEs often show the list of resources first, or show a layer of tools to choose from. These design choices are important at guiding users towards certain kinds of behaviour.

The Associative View of Affordance: Teachers should have a clear instructional approach for each unit of learning, and should ensure that the most appropriate features for each unit are promoted and easy to access. Some other features should be switched off or demoted so they do not impact on learner performance. Features should be afforded, therefore, on a unit-by-unit basis.

The Cognitive View of Affordance: Learners should be able to explore the subject using a wide range of features that support their way of engaging with it. Richness of interaction capability is important, and the environment should provide easy access to as many different features as possible, that engage a range of sensory modalities and cognitive approaches.

The Situative View of Affordance: Communication is a key aspect of learning, and the environment should promote features that enable people to connect and share ideas, and allow them to express their identity with others.

In a Web Services model, affordance is in the hands of designers to model as they see fit; given a palette of available services (resources, forums, weblogs, chat, search, etc) designers can promote those features that they feel will result in a better use of the application, and demote or simply not include features they intend to discourage. Again, this assumes that there is capability - both technical and in resourcing - within the organisation to actually create an application and connect it to the available services.

Workflow

Workflow can mean a range of different things, but in this article when I discuss workflow its as the means by which activities are structured and sequenced.

For example, an activity may define participation (who’s taking part in the activity), roles (what they do), and resources (what they have to work with). A group of activities can be connected in a sequence, for example:

  • Activity 1: Read the background materials
  • Activity 2: Discuss and answer a set of questions in groups
  • Activity 3: Write notes in your journal about what you’ve discovered

These three activities have a linear sequence, but you can imagine workflows that have branching sequences, workflows that do not have explicit ordering (‘do these three things in whichever order you want’) or sequences that start linear, have a branching middle section that then return to a linear sequence at the end. There are many possible ways to construct a set of activities, some much more complex than others.

The Associative View of Workflow: Teachers should have a clear instructional approach for each unit of learning, and should be able to express this approach in terms of the flow of activities, branching conditions, remediation, completion conditions, roles and so on. In some cases this may be necessary on a unit-by-unit basis, in others there may be a particular workflow ‘pattern’ that needs to be repeated for any unit within a particular course, level, or unit type.

The Cognitive View of Workflow: Learners should be able to explore the subject in a fairly unconstrained way, and workflows, while important in providing guidance through a subject, shouldn’t be too prescriptive. Learners may want to construct their own flow of activities, or choose from a set of workflow options depending on their preferred style of learning.

The Situative View of Workflow: Workflows can provide an important supporting role in assisting learners in managing their engagement with the subject. However, wherever possible workflows should encourage interaction and group working and communication rather than simply provide a solo ‘page turning’ experience.

Workflows can be implemented in applications in two basic ways – either embedded within the application logic, or dynamically driven from a workflow description. The former is the most common, and in the case of most VLEs this is a sort of unordered choice of activities, usually pre-selected by the tutor. For example, a system such as WebCT will provide a wide palette of “tools” that can appear in any module’s ‘space’, but which can be turned on or off by the tutor. The tutor cannot define the order in which learners interact with the tools.

An exception is the LAMS system, which supports dynamic workflow with a visual editing tool that allows designers to organize the sequence of activity by dragging and connecting ‘tools’ such as discussion, quizzes and so on.

Whether workflow is embedded or dynamic is itself a pedagogic choice; for example, should units of learning have different workflows, or should there be a standard approach taken within a particular cohort or subject group?

From a technical viewpoint, workflow poses a number of challenges. As far as embedded workflow is concerned, a service-oriented approach fits quite nicely as it enables the designer of an e-learning application to access services in a sequence of their choosing. However, dynamic workflow is much harder to implement, and requires a lot more work. There are efforts underway in this area, such as LAMS and the IMS Learning Design specification, which provides a standardized format for expressing a learning workflow.

There are considerable technical challenges in making a dynamic workflow present a coherent experience to the learner, especially when the tools involved have very different user interfaces, and in making tools that are themselves capable of responding to dynamic workflow requests.

In future, the combination of dynamic workflows and web services should enable much more interesting, flexible, and responsive learning experiences , and this is a topic of considerable interest within the e-learning community, both in public education and commercial training sectors.

The Old World and the New

So, taking all the areas we’ve looked at above, how do the “Old World” of our existing technology and the “Brave New World” of web-service driven environments compare?

Old World

Brave new World

Interaction mode

Browser

Anything

Connection mode

Always-on

Always on or partially connected, depending on inter- action mode used

Structuring device

Module/course

Whatever works for you -time, topic, popularity,level, people

Structural affordance

You get to choose which tools show up in your course area in the VLE

You have complete freedom to select promote and demote whatever tools are available, and how you connect them to the structure

Workflow

Sequencing is either non- existent or limited to primitive show- and-hide, and roles are built- in along "teacher" and "student" lines. Typically the same workflow is offered to all learners

You can make up your own rules, roles, sequencing, and processes, and perhaps change them later on, even while an activity is running. Workflows can be created on a group or individual level.

ELF and the Economics of Diversity

While anyone can at present examine the variables described above, and design some sort of system that provides the kind of learning experience they desire, the bottom line is, well, the bottom line. Software development is expensive, and learning environments usually operate within an administrative context where it is necessary to integrate with processes in the wider organisation. For example, not everyone can afford to go and build a LAMS or a WebCT!

Web Services are a useful technology for connecting a learning environment to organisational data and processes, and for integrating various kinds of common functionality. The e-Learning Framework sets out some patterns for doing this that will bring down the costs associated with including this common functionality within the learning environment while also supporting open standards. Toolkits and guidelines are being produced throughout the life of the e-Learning Programme.

Ultimately what this means is that when learning technologists and practitioners ask their technical people to modify or create an environment in line with the sort of choices I described earlier, the answer should not be an automatic "no", but instead come down to the point where adding features, changing structuring and so on is a task which can be effectively delivered within a reasonable sort of timescale - measured in weeks of resource time instead of months or years.

Not everyone will be able to afford to build a learning environment from scratch. Some will be interested in building new e-learning experiences by connecting applications they already have to available Web Services, however, many institutions, for entirely different reasons, will probably end up with some sort of commercially-supported system. Why? Simply put, pedagogic diversity has a price.

Doing what everyone else does is cheaper than designing and implementing your own pedagogic vision - although the web services approach certainly makes it considerably more affordable than it used to be. The benefits still have to be sold to management, and some bright spark has to be employed to go off and write the code that knits all the services together and presents the kind of experience that the designer envisaged.

I hope this article helps defend, at least partly, my rash assertion about pedagogic diversity, and explains some of the rationale for the e-Learning Framework, standards, and Web Services in e-Learning.

 

Supported by JISC Supported by CETIS
Powered by Plone