Making the Institutional Business Case for Introducing Learning Design Tools

Gayle Calverley Abstract: This paper explores constraints around institutions, particularly in respect of the potential for effective uptake of LD tools within institutions. It seeks mechanisms that may reduce the balance of effort so creation of UOLs based on LD is more justifiable in institutional contexts. It attempts to illustrate how apparent similarity between what are substantially different contexts can mask potential LD benefits. This can affect adoption of LD either through LD-based tools or through vendor-reliance of an institution. The role of teams of LD experts, not affiliated to mainstreaming work in an institution, is also examined. Particular attention is paid to how they are contributing to reducing institutional load in providing the type of support described. This may help increase eventual uptake of individual LD developments.


INTRODUCTION
One aspect of LD as a specification is to allow institutions and users to be free of vendor lock-in, by allowing explicit description of existing learning practices to be transferred between systems (Koper, 2005), (Olivier & Tattersall, 2005).However, interoperability specifications do not take account of the fact that many institutions voluntarily accept, or proactively agree to, a certain level of lock-in when they decide on a learning system for mainstream implementation.This means vendor lock-in is a selectively chosen reality for many institutions and needs to be worked around (SIRU, 2004).In contrast, lock-in is well understood in the interoperability community, and is worked towards as something that can be prevented for the benefit of all.
This creates an environment where different arguments are necessary for initiating mainstream use of interoperable tools.Once introduced, users can start to recognise potential for new ways of working allowing the benefits of interoperable tools to be more quickly realised.These new ways of working are where the value to an institution will initially lie.
Research Groups and Specialist Area Developers in institutions usually operate under different restrictions and funding constraints.In a more formalised research and development role, they are often freer to work with or on development products that may not be in the focus of their own institution for mainstream exploitation.There is more potential for trials and piloting small scale adoptions of the tools they conceive (Practical examples of this are described in abundance in Koper & Tattersall, (2005)), and their role in producing appropriate products to break down institutional adoption barriers should not be underestimated.
However, mainstreaming their work even within their own institutions is unlikely to lie entirely within their own power.Many of the issues encountered face different solutions from a technical perspective than when faced by an institutional consumer.These differences continue to represent real obstacles to wider adoption of LD tools by tutors and developers outside of structured research or independently funded projects.This paper explores the role of Specialist Developers and Research Groups in meeting these challenges.

PLACING VALUE ON INTEROPERABILITY
Immediate institution-vendor issues include that the direct cost of purchasing and continued support from any given vendor may be high, and there are risks associated with changes in provision on which an institution may become reliant.
Yet the Benefit Realisation Management (BRM)[1] (SIGMA, UK) investment required to make an implementation successful, is far more significant to the long-term embedded costs to an organisation.This can often raise the local situation to being pro-active towards a particular vendor or style of working.Implications arise for the ability to introduce interoperable tools into such an environment if these are viewed solely as a mechanism for keeping open the potential to switch to a different system at some future point in time (SIRU, 2004).
The overhead of continually monitoring material in an interoperable fashion, against a potential undefined future change, can be high when it is not ingrained into a daily benefit related to the way an organisation works.Organisations already coping with high daily loading will frequently prefer to assume a point-of-change risk (long-term future) over what may be seen as an empty additional requirement on their daily processes (managing today).Institutions will also be unlikely to promote use of tools that encourage their staff to deliberately promote multiple systems of the same type where this is not supported by a clear business model.
Where interoperable functionality is required for other reasons, the development onus will most probably be returned to the vendor and may provide the base for ongoing choice of that vendor.The increasing wish of institutions to out-source major development is partly reflected in the number of commercial educational-based companies that originated as spin-off enterprises from institutions [2].

ENSURING TECHNICAL CLARITY
Within institutions, there remains confusion between the rich functionality and potential that interoperability specifications offer, when compared to existing vendor models of learning in use.Commonly, content export models, such as those linking material held within a local system to its associated vendor system tools, are not conceptually separated from LD models related to roles, activities and environments, and how these rich learning designs may be exchanged between systems.This is partly due to the capacity for existing vendor systems to provide limited aspects of the LD model alongside some transfer and ordering functions.There is also a pervading misconception, at academic and management levels, that open source is equivalent to non-proprietary which is equivalent to free.In addition, open source continues to be viewed as less expensive despite the support costs in terms of people it requires.Equally, there appears to be no direct concept associating open source with proprietary examples.
Clearly better more-tutor oriented tools, education, and more demonstrations will go some way to alleviating this.However, the point is currently significant to wider adoption of LD tools where users believe the model they are currently working with is incompatible with, or offers equivalent functionality to, what they already deem sufficient, in relation to their current level of investment in any particular system.More bluntly stated; 'What is the point of offering tools for added functionality, e.g.better ordered content, if the user believes the system already supplies it?'New tools must be established as offering benefit over and above what has already been accepted as effective in the current environment (JISC 07/00, 2000).This makes it difficult to determine clear benefits for introducing beneficial ancillary tools into mainstream institutional use, particularly where the primary mechanism is through discussions with learning-oriented staff.

POTENTIAL BENEFITS
Consequently, promoting LD tools on the basis of interoperability specifications and prevention of vendor lock-in is unlikely to be sufficient to appeal to a mainstream environment where support for adoption across all staff will be high.Similarly, transfer of course material or re-structuring in terms of a sharing model may not be of interest to institutions whose courses and materials constitute a major commercial asset or key revenue stream.
But if tools can be introduced on a basis of added-value, they will soon highlight what current systems in use can and cannot do within any particular set of scenarios.This potentially raises expectation and quality standards beyond the restrictions created by settling for and developing along with the current 'best of breed', even where this model is very responsive to individual client needs.It may also be viable to up-skill vendor-oriented development staff within institutions by extending their capacity to work with related non-vendor tools.
For some institutions, the ability within LD to record and transfer courses across teaching staff may hold some interest.This is compatible with the process of LD being to translate current practice into an explicit form that can be used by others, and where appropriate automated.This may offer better potential to co-ordinate and streamline team-teaching of courses each time the course is run, such as for reuse with different tutors.Completeness of the course record may be significant, depending on what functionality staff already have automated access to.
Similarly, the ability for a single member of staff to record his or her course once, and then adapt it to different student groups, or for later transfer to a colleague for sabbatical cover, may also be appealing.But once more, this should be viewed in the context of what staff are already able to do within the systems currently available to them, and with what effectiveness.
Initially, automation, instead of hand micromanagement of courses, may not be the main reason for adoption of LD Tools.Allowing the staff to record their day-to-day working practices, and to understand those practices better will be a far better selling point.In future, what now presents as minor subsidiary benefits, such as the ability to print off lesson plans, may also have key adoption advantages within specific user groups.

RESEARCH GROUPS AND SPECIALIST AREAS
The situation described so far still allows for adoption by research groups or area specialists who are capable of their own technical and development support.Many of these groups are already active in initiatives to make existing tools more attractive to tutors and institutions.These groups have a significant role to play in using the specifications via the tools to raise the pedagogy vision; to improve the concept of what is possible.It has been demonstrated that careful design of tools can also help to raise awareness of how the specifications work among developers using the tools [3].These areas of work are necessary precursors to tackling the mainstream issues, in that they provide moves away from existing system constraints by encouraging creativity.
The UNFOLD communities of practice [4] have been effective in progressively raising European understanding and adoption of LD across the wider educational community [5].At Valkenburg in February 2005, eleven of the first demonstrable user-produced LD Units of Learning were created by UNFOLD CoP members within a 36 hour timeframe [6].This step represents an effective outcome because it directly demonstrates the capacity of the new tools to be used by non-experts to produce useable material, at a functional level, within a realistic timeframe.
Although it is acknowledged that the tools developed so far will remain developer oriented, extending the interfaces to include advanced graphical and template concepts is a welcome step in beginning to reach tutors.This will allow the next generation of tools to be designed to incorporate a range of pedagogic models.It remains unclear whether these tools will layer their own implied models of learning over and above the specification approach that has encouraged their development.If so, these tools will still need to demonstrate niche enhancements, or effective new development interfaces to existing institutional architectures, to ensure a role for their adoption.Continuing to minimise implicit pedagogical models in tools still remains important.
Discussions within the CETIS [7] special interest group community (2005) question whether or not these types of tools are ever likely to be 'ready' for use at a tutor level, as opposed to with development team support.There seems to be provisional acceptance that Level A use may be feasible, where Level B & C use will almost certainly remain at the developer support level.This questions whether Level B and C tool designers should work towards providing specific tutor-level interfaces at this early stage.These discussions create an appropriate point to examine the findings of interim systems, targeted at the tutor level, to gauge the readiness of the sector for introducing this level of development.

EARLY ADOPTION FINDINGS FROM LAMS
One early gain for LD, has been the LAMS (Learning Activity Management System) system [8,9].LAMS was timely in being the first exemplar [10] to visually draw together diagrammatic designs for learning plans into a system that could then activate the intentions of the tutor into a real-life course example.The role of the system as an exemplar stemmed from it being originally 'based on' rather than compliant with the specification, and so it did not originate as a fully interoperable model.The system's richness in tooling areas has also added to its general appeal among practitioners who have trialled the system.LAMS continues to be an emerging player.Speculation exists within the development community as to whether LAMS can achieve a simplified interface for IMS LD Level B and C that is capable of allowing tutors to do useful things.This follows LAMS commitment to building an import/export feature for LAMS based on IMS LD Level A requirements by July 2005.LAMS also officially became open source software under a GPL licence on April 13 2005 (Kraan, 2005).
LAMS is currently being evaluated in the UK [11] for its usefulness to practitioners as a prototype activity-based learning design tool.Preliminary use with tutors by Smart (2005) suggests that: 'using LAMS helps teachers to visualise the learning process which enables them to design and reflect on the online learning activities they give their students.Given that sequences are so easy to change tutors are continually tweaking and improving the learning experience.It also links the design process to underlying pedagogical theory.'However, an early report by Masterman (2005) indicates that unexpected issues for adoption of systems such as LAMS are still arising.This may suggest wider implications for use and adoption of LD Tools, despite the positive initial gains demonstrated from episodes such as that described by Smart (2005).For example, from a self-selected group of competent e-learning practitioners it would appear that benefit perception does not match practical application of the available tools when considering their use with actual groups of learners.In fact, these perceived significant benefits become minority considerations.Specific examples include the ability to personalise learning, the capacity of e-learning to support asynchronous and distance learning, to facilitate the sharing and reuse of learning resources, to foster collaborative learning and to promote novel forms of communication.While Masterman's participants imply that many learners are not yet ready for the active learning opportunities afforded by e-learning, Masterman acknowledges there may remain constraints within the participants' own thinking that have not been sufficiently explored.She questions whether: '…people perceive the benefits but do not yet feel comfortable about changing their personal pedagogy?Or are they constrained by the prevailing culture and/or curriculum (for example, are individualised learning and personalised support incompatible with collaborative learning experiences?)?Or, are the appropriate tools not yet widely available in participants' institutions?Finally, if, as implied in participants' responses, many learners are not yet ready for the active learning opportunities afforded by e-learning, how can they be "scaffolded" towards autonomy, and can LAMS take a role in mediating this progression?' The final report of the evaluation of LAMS (Masterman & Lee, 2005) as an activity-based e-learning tool concentrates more on specifics of how LAMS can support a range of pedagogical approaches within the context of effective practice, and technical recommendations for hosting the system to support its initial uptake period in a stable way.Further studies were recommended to examine the learner's perspective on LAMS, administrative functions of LAMS, technical issues involved in hosting LAMS locally and attrition among participants within the duration of the study (with a view to reducing this factor in future work).Additional significant comment in terms of acceptability to teachers included that: 'The adoption of LAMS within an institution would almost certainly entail an increased workload for teachers, but with time and experience this load could be expected to lessen.' 'LAMS appears neither to have compromised learning outcomes in comparison with the existing learning environment nor to have resulted in dramatic improvements in achievement.However, using LAMS to raise the level of learning outcomes was not a prime consideration for practitioners.Rather, they perceived its benefits to lie in increasing learners' motivation and in encouraging participation by more reticent students.Feedback obtained … from learners suggests that some appreciated the independence and freedom to work at their own pace, while others did not like the linearity of LAMS sequences or wanted more direct feedback on their progress.'

DEVELOPERS REQUIREMENTS OF LD TOOLS
Adoption of new tools in developer circles does not come without its own requirements.Initial discussions [8,12] on prototypes have indicated that some polarisation in functionality of developer tools is already occurring at this early stage.Forms-and graphical-based editors form interesting cases.
Graphical tools have been awaited and welcomed for their strengths in visualisation of learning design, but they potentially represent a one-way creation.It is possible to use the graphical tool to develop a learning design that is valuable and implementable.However, the process is not reversible.Due to the complexity of reverse mapping, it is not yet feasible to take an existing design and translate that design back into a graphical representation.This means although tools may assist staff to visualise their own work, it may be harder to visualise a design that is transferred from elsewhere or created in a different tool for which the original representation is not available.This has implications for being able to generate a fully interoperable transferable environment for academic staff.If some of the greatest benefits for day-to-day use of LD by tutors lie in access to the graphical representation of learning designs, this could actually promote lock-in to particular tools!Two things are happening with forms-based editors.At one level, streamlining improvements are being suggested to bring presentation of forms and tabs in these types of editors to more closely fit the order presented in the LD specification.This also includes correcting the editors to match functionality that may (or may not) be available in the specification but does not match the current editor behaviour.More significantly, in terms of community divergence, some developers have highlighted a need among certain groups for an Expert Mode in graphically-based tools to allow direct editing of the XML source.One tool, RELOAD [13], has already foregone its ability to offer codebased authoring in favour of adopting development techniques that, among other functions, allow a learning design viewer to be incorporated.
An incorporated graphical viewer, as in RELOAD, shows how LD tool usability can be improved for non-developers.This is helpful for effective display of a UoL under demonstration circumstances.Figure 1 shows a pre-prepared route that suggests 'seamlessness' between creation and display to the audience.Representations of the Unit of Learning for each role are made available for viewing with a single click.This may be less useful for certain developer groups requiring detailed code-based technical functionality but is key to winning over more academic-oriented users.This makes CopperCore, in its current form, likely to be less appealing beyond the developer community, in terms of demonstration and recruitment of academic users.However, CopperCore has played a pivotal role in the technical process and as a proof-of-concept tool.This in part is because CopperCore is an underlying engine, whose release contained a demonstration set of tools including a run configuration tool and a player.The intent of the developers for this release was not to supply real tools; use of CopperCore beyond the developer community will require production level tools.
Description of this contrast is largely only significant at this stage because of the disparate skill levels, daily work objectives, and expectations of the target community, which combines highly technical development staff at one end, and tutor-based users at the other.Understanding this distinction now, allows developer requirements to be placed more effectively against user group conflicts that may later appear.

CONCLUSIONS
Interoperability and 'Making explicit daily practice' are insufficient drivers for the academic and institutional communities to see sufficient tangible benefit, over the increased loading this would offer on a regular basis.Yet people are attracted by the potential for technically integrating previously disparate parts of their work.Developers are generating a number of initiatives to make LD work more appropriate to institutions and tutors as the end users, but there appear to remain significant obstacles before the benefits of learning design can be mainstreamed.Evaluation studies of related systems suggest that the community is intellectually ready, but not yet practically capable of taking on the concepts promoted in anything but a minor capacity.The situation within individual institutions creates a complex impact on the capacity of individuals to respond.These two factors must be handled together to create niche entry points and 'grow' the environment to anticipate a higher level of performance, capacity and support on a practical basis, at the level of day-to-day handling.Developers need to continue recognising parallel varied development in the tool arena as being necessary for this end, and work in conjunction with change programmes in institutions that recognise existing organisational constraints.Together, these can go some way to aligning the support case against long-term business need.

Figure 1 .
Figure 1.RELOAD Learning Design Player demonstrating an automatically configured IMS LD Unit of Learning from Tutor and Student views

Figure 2 .
Figure 2. The five Coppercore GUI and Command Line Interfaces required to set up a Unit of Learning run for demonstration