Association for Learning Technology Online Newsletter
Issue 8 April 2007   Friday, April 20, 2007

ISSN 1748-3603

Cover Page »
Contents
Feature article
BBC suspends free interactive learning service
Better networked learning
Case studies
A mass collaboration approach to e-learning
Project updates
HEAT
Conference reviews
EDUCAUSE Learning Initiative (ELI) 2007
24 Hours to secure collaboration on interoperability
CAL07 Review
ALT news
Same role, new job title
Chief Executive's report
Director's report
Forthcoming events from ALT
News from the Netherlands
Publications from the SURF e-learning website
JISC Updates
New publications from the JISC
Subscribe / Remove
Privacy policy

ALT Website

ALT-N online
Past Issues
Issue 7 January 2007
January 27, 2007
Issue 6 October 2006
October 30, 2006
Issue 5, July 2006
July 11, 2006
Issue 4 April 2006
April 27, 2006
Issue 3, January 2006
January 30, 2006

More Issues »
Better networked learning
From theory to praxis to software design
by Michael Feldstein

In a recent issue of ALT-J, Goodyear, de Laat and Lally (2006) argue that it is difficult to cultivate conversations between learning theorists and practitioners of online education because of a kind of linguistic impedance mismatch:

[T]heory-praxis conversations require some shared language and common ground — without which it is difficult to see how mutual understanding and influence can be achieved. Such shared language and common ground can be hard to find. Practitioner experience gets represented in ‘war stories’, case studies, vignettes or teaching tips—which are not easy to connect to theory. Meanwhile, research produces evidence and theory that can be hard to connect back to the particular, situated concerns of the practitioner (213).
As a result, despite explosive growth in both practical knowledge about teaching online on the one hand and cognition and learning research on the other, we see relatively little cross-fertilization. Teachers are getting little benefit from the theoretical advances in cognitive psychology and related fields, while theoretical research is likewise seldom informed by the growing knowledge base of the networked learning community.

Interestingly, there is a very similar communication gap between practitioners of networked learning and developers of virtual learning environments (VLEs). I would argue that, despite great advances in the field of software development, most of the major advances in VLEs—and almost all of the widely distributed advances—have come from the development of generic software tools such as discussion boards, weblogs and wikis. The pockets of educationally informed software design that we see are generally the exceptions that prove the rule. There are many reasons why this is the case, but one major reason is the widely known problem of the linguistic impedance mismatch between software users and software developers. Just as war stories, case studies, vignettes and teaching tips can be difficult to translate into theory, they can also be difficult to translate into software architecture. This general software design problem is exacerbated in the realm of educational software by the fact that educational best practices tend to be highly contextual and difficult to deconstruct into a small number of concrete and regular workflows. For example, it is much easier to write down all the possible steps and paths necessary to support the online purchase of any book than it is to write down all the possible steps and paths necessary to support conducting various types of online educational conversations.

Consequently, VLE designs tend to be relatively lightly informed by praxis. Likewise, networked learning practitioners are limited in terms of envisioning how the VLE should work because they often do not know what is possible. With both communication challenges, the solution is to develop a linguistic form that works for both communities. For the latter situation, use cases have become an increasingly popular form for building a conversation between people who understand the processes that the software is supposed to support and people who understand how the software works. For the former situation, Goodyear, de Laat and Lally proposed that pattern languages could serve a similar purpose. I will argue that these two linguistic forms can be bridged to support a unified community of theorists, practitioners, and software designers, to the benefit of all three fields. However, in order to accomplish this goal the communities of learning theorists and networked learning practioners must embrace the pattern language form and extend it to a level of granularity that is sufficient for writing use cases based on the low-level patterns.

From top to middle: pattern languages
Christopher Alexander, who coined the term pattern language, was a rogue architect. In a field heavily dominated by aesthetic theory, Alexander built his own work upon the simple observation that beautiful buildings tend to survive while ugly ones get torn down. Throughout the world and across cultures, the buildings that are left standing after hundreds or thousands of years tend to be the ones that are regarded by visitors as having some deep aesthetic appeal. Alexander set out to deduce the cross-cultural, cross-historical principles of architectural praxis that these buildings embody. In the seminal work: A pattern language: towns, buildings, and construction, he and his colleagues invented the linguistic form of the pattern language to express the lessons they learned from their studies (Alexander et al 1977). Since then, pattern languages have been developed to capture practical knowledge in fields ranging from object-oriented software design to organizational development to fashion design. Within the realm of education, pattern languages have been created to articulate practical knowledge in areas such as pursuing a doctoral degree, developing a teacher education program, and designing a web-based course, among others.

The crucial addition that Goodyear, de Laat and Lally contribute is that pattern languages can also map the insights derived from at least some types of learning theory (specifically, network analysis, content analysis, and social analysis). They translate previous research into the pattern language form, resulting in an organized collection of best practices for facilitating online discussion that is usable by practitioners. For example, they provide the research-backed recommendations to “provide access to feedback material on how the group is working” and “monitor and adjust overlap and gaps between individual and collective learning processes” during what they term the “middle phase” of a networked learning program (p. 220). While it is unlikely that all forms of learning and pedagogy research will translate to the pattern language form equally well, this work, nevertheless, represents a significant step forward in terms of theory-praxis conversations.

However, the recommendations provided in the study are not at the level of granularity required to help guide the design of software that supports these best practices. How would one design a VLE that affords teachers monitoring and adjusting overlap and gaps between individual and collective learning processes? What would such a system look like? The recommendations do not provide enough detail for us to know. Interestingly, however, this is not a limitation of the pattern language form itself. The pattern language articulated by Alexander and his colleagues can scale in terms of the scope of problems and solutions it describes from patterns regarding the distributions of towns within a region all the way down to the details of windowsills in a home. Because these patterns always include references to related patterns, high-level patterns tend to reference successively lower-level patterns, down to whatever level of granularity the authors think is necessary. Pattern languages regarding networked education should similarly be able to achieve finer granularity, to the point of providing some guidance for software designers. For example, in their Moderation Strategies Pattern Language wiki (n.d.), Shirky et al have:

  • high-level patterns, e.g., “maintain editorial (or administrative) control,”
  • mid-level patterns, e.g., “treat users and members differently,”
  • low-level patterns, e.g., “make login optional.”
At this level of granularity, we can begin to envision the functional requirements for a software system that supports best practices. The next step is to translate those functional requirements into technical requirements for the software developers. (For further information about pattern languages, see the website at the end of this article).
 
From middle to bottom: use cases
The term “use case” was coined by a computer scientist named Ivar Jacobson in the mid-1980s (Jacobsen 1987). However, much of its contemporary form can be attributed to the work of Alistair Cockburn, one of the initiators of the Agile software development movement. Like Alexander and his colleagues, the Agilists have eschewed many of the formalisms of their field in favour of a more anthropological approach. They believe in close and frequent collaboration between the software developers and the users of the software. Use cases play an important role in that collaboration.
 
At its simplest, a use case describes the steps that one or more actors goes through to complete a process. It doesn’t even have to describe a software-enabled process, although that is the most common application of use cases. For example, Cockburn (2001, p. 5) provides the following steps for use case involving a person getting paid by the insurance company for a car accident:
  1. Claimant submits claim with substantiating data.
  2. Insurance company verifies claimant owns a valid policy.
  3. Insurance company assigns agent to examine case.
  4. Insurance company verifies all details are within policy guidelines.
  5. Insurance company pays claimant and closes file.
Other data, such as preconditions, triggers, and alternate paths, are often included as part of a use case, but the heart and soul of it is the narrative. One can imagine similar narratives written for the “make login optional” use case in the Moderation Strategies Pattern Language. It should be possible to map low-level design patterns to high-level use cases as a method for operationalizing the patterns.
 
Like design patterns, use cases can nest, with high-level use cases referring to others of increasing granularity. For example, step two in the use case above could have its own use case describing the process for verifying that a claimant owns a valid policy. Likewise, software-focused use cases can include components of the software system in the use case. Therefore, if we imagine that step two of the use case above was actually completed by a self-service online application, the more granular use case might look something like this:
  1. Claimant submits claim input form via web interface component.
  2. Policy validation component confirms claimant’s policy has “active” status.
  3. Policy validation component confirms claimant’s policy is relevant to claim type.
  4. Policy validation component passes validation confirmation to web interface component.
  5. Web interface component displays claim filing confirmation message to claimant.
The narrative provides an opportunity for the experts in the business process and the software developers to have successively more detailed conversations about what needs to happen in the software, until it reaches the point that the developers understand the technical requirements for supporting the use case. For this reason, use cases are increasingly widely adopted for software development. We use them at Oracle and, importantly, the IMS incorporates Cockburn-style use cases in their charters for the development of instructional technology standards.
 
An engine for innovation
Goodyear, de Laat and Lally (2006) have shown that we can translate theoretical research into empirically validated best practices through design patterns. Suppose further that we can then translate those best practices into software design through use cases. If so, then we will have a complete process for driving learning and cognition findings into the fabric of our networked learning programs, both in teaching methods and in software design. If an organization such as ALT were to create a peer-reviewed design pattern repository that included high-level use cases mapped to the appropriate low-level design patterns, then software developers and technology standards groups could use that repository to improve their designs and help to set development priorities. Requirements for user interface conventions and interoperability standards could be identified much more easily. It would even be possible to evaluate the quality VLEs based on their support for the design patterns and use cases in the library.
 
This would not be easy to achieve. To begin with, pattern languages and use cases are both difficult to write well. They require skill and practice. In addition, the conventions for writing both forms are relatively loosely defined — and no conventions currently exist for translating design patterns into use cases. Both the skills and the conventions required would have to be woven into the professional training of the participating academic disciplines. Furthermore, there would have to be a strong commitment by software vendors, open source projects, and standards-making bodies to incorporate the use cases into their business processes. They would then need to report adoption of particular use cases back to the community, and work with the other stakeholders involved to make sure that the content being produced is useful for software and technology standards development purposes. The payoff, however, could be substantial. At long last, we could have an engine to drive innovation broadly in the field of networked learning.
 
References
Alexander C, Ishikawa S, Silverstein M, Jacobson M, Fiksdahl-King I and Angel S (1977) A pattern language: towns, buildings, construction. Oxford University Press.
 
Cockburn A (2001) Writing effective use cases. Addison-Wesley.
 
Goodyear P, de Laat M, and Lally V (2006) Using pattern languages to mediate theory-praxis conversations in design for networked learning, ALT-J 14, 3:211-223
 
Jacobsen I (1987) Object-oriented development in an industrial environment, ACM SIGPLAN Notices 22, 12:183-191
 
Shirkey C and various unknown authors (n.d.) Moderating strategies pattern language [Online]. Available from http://social.itp.nyu.edu/shirky/wiki/ [Accessed 14/3/07]
 
Web sites
Anatomy of a pattern language:
http://www.designmatrix.com/pl/anatomy.html  
 
A pattern language for doctoral students:
http://csis.pace.edu/~bergin/patterns/DoctoralPatterns.html
 
e-Learning patterns
http://elearn.pri.univie.ac.at/pca/project.aspx?n=Patterns
 
Michael Feldstein
Principal Product Manager, Academic Enterprise Initiative
Oracle Corporation
Michael.Feldstein@oracle.com


Printer Friendly Version »
Created with Newsweaver