Should academics manually create course websites?

(There is a response/attempted clarification to comments on the following by Stephen Downes in another post)

The focus of the following is not the “evil” LMS. That’s another argument, and I agree with much of it. The question here assumes that your university is going to use, or even require the use of, an LMS. Given that, should the institution expect or even allow academics to manually create course websites in the LMS?

This question arises out of my last post reflecting back on some decisions made back in 2000/2001 and how that compares to existing common practice. Especially in connection with Mark Smither’s recent problems with MOPPS post.

Back in 2000/2001 the Webfuse system answered this question with a no. Staff could still create their own site, but a default course site was automatically created for all sites. Academics could further modify this default course site, but the didn’t have to create it.

The rationale was that having academics manually create the course websites was inefficient, resulted in poor quality outcomes, and limited the ability for institutional control and evolution of the minimum level of service. The following expands on this rationale and relates it to recent experience of using Moodle. Based on the combination of experience with Webfuse and Moodle, I’m tending to answer no. Institutions should not be expecting academics to manually create websites.

What do you think? Are there institutions that don’t expect this? What do they do?

It is Inefficient

A long time ago, I used to teach Systems Administration. One of the lessons we tried to teach in Systems Administration was “if you do something more than once, automate it”. I recently had to create a Moodle course site from scratch. It was a simple (some might argue simplistic) site, by no means stretching the capabilities of Moodle. But creating even this simple site, I found annoying and inefficient.

The site used the weekly Moodle format and had 10-12 weeks. Each week basically followed the same structure: a pointer to the study guide chapter for that week, a pointer to a discussion forum specific to that week, a reminder to complete a journal entry for the week, and occasionally a reminder for another assessment item. This means that to create the course site I was essentially repeating the same steps for each week. I had to perform the same steps with the Moodle web interface for each week.

Setting up the entire site probably took me three hours. After becoming more familiar with Moodle course site design, the majority of the time was spent on the manual process of implementing the design. This was quicker because I did it on a Moodle instance running on my laptop. Trying to do it on the live institutional server could have at least doubled this.

It gets worse

I’m an advanced computer user, a designer and modifier of e-learning systems, and an experienced academic who’s been doing e-learning since the early 90s. I am not like most academics.

The academic I was working with, if left to their own devices, would have expended more than a week on this task. This would have included becoming familiar with Moodle, figuring out the options in terms of course design and then performing the low level tasks to implement the site. Even worse, this academic is probably middling in terms of skills. There are a significant number of academics at my current institution that would have taken longer. In fact, I heard a number of stories of academics earlier this year spending weeks getting their first Moodle course sites up and going.

The implications

Multiple this out for an entire university with 500+ courses, and there’s a significant expenditure/wastage of resources. Remember, this is for perhaps the simplest, minimum course site you can create. Nothing fancy.

As more course sites are created in Moodle, subsequent terms won’t be quite so bad as academics will tend to copy the previous course site and make some modifications. But this creates other problems addressed below.

Poor quality outcomes

Have academics manually create default course sites also contributes to poor quality course sites. There are two main reasons:

1. Missing skills; and
   Creating a good quality course website requires a good mixture of skills in teaching, technology, design, communication and other skills. Few academics have the right mixture of all of these.
2. Human error.
   In creating the simple Moodle course site I had to perform the same sequence of steps 10 or 12 times. I’m almost certain that I made a minor mistake in at least one of those repetitions. Depending on the nature of those mistakes, they will come back in the future and cause more inefficiencies, especially if they involve the incorrect date for an assignment. An academic with a more limited understanding of Moodle is perhaps even more likely to introduce mistakes due to human error.

Limited institutional control

This is may not be a big problem in some universities, but increasingly in the Australian higher education sector institutions are being held accountable for the quality of the education they offer. This is translating into an explosion of minimum service standards (the MOPPS Mark Smithers talks about) where the institution identifies an organisation wide set of minimum standards for course websites.

In my experience, the expectation for most of these service standards is that the academics will translate those standards into features on their course websites. Some will argue this is so they can apply their local expertise to develop contextually sensitive implementations of the standards. It is argued that considering the standards helps encourage more thinking about course design by academics. In my experience it mostly leads to compliance and task corruption.

Either way, it is up to the academics to translate the standards into an actual course site. Given the difficulty and inefficiencies identified above in creating course sites, the potential for misinterpretation of the minimum standards, the potential for those standards to badly designed or communicated to academics, and the imbalance in importance between teaching and research it is no great surprise that academics collude to comply and compromise the standards.

Based on this argument, If the aim of an institution is to control the minimum quality of the institution’s course websites, expecting academics to manually create course websites is both inefficient and ineffective. It won’t work.

Limited evolution

What’s worse, is if the institution then decides that those minimum standards have to change, either to solve a problem or improve the quality. They then have convince the academics to make these changes. Once an academic has a course site, the common approach is to simply copy what has gone before. Any changes in minimum standards that require significant changes to the basic structure of a course site has little or no chance of widespread, successful adoption.

One solution

This post briefly describes the alternative that was implemented within the Webfuse system in 2001 and also a prior aborted attempt.

Default course sites and wizards

There is now a version 2.0 of this section.

The following is the next section from chapter 5 of my thesis. This one describes attempts made to provided a functionality within Webfuse that improved the quality of the default course websites, without increasing workload for academic staff and while retaining some elements of autonomy.

Sadly (to me anyway) the institution in which this work evolved has gone backwards.

Default course sites and wizards

As described in chapter 4, the initial assumptions built into Webfuse was that a course website would simply be an empty page. From this single, empty page it was assumed that each individual teaching staff member would then draw on the variety of page types (hypermedia templates) provided as course website building blocks by Webfuse to construct their course website. Very quickly it became obvious that the majority of academics did not have the time, inclination, or skills to engage in this sort of design and construction process. Those staff that did have this combination of skills often wanted to use other tools or approaches with which they were already familiar.

In addition, it became obvious that a significant percentage of the tasks associated with creating a course website were fairly low-level tasks, often involving reuse of information and resources already provided. These observations led to the practice where support staff created initial default course sites by manually editing the initial empty course sites and uploading standard information (e.g. course synopsis, staff contact details etc). However, these course sites were of limited quality, failed to encourage further enhancement from academic staff, and required significant workload from faculty administrative staff. It is within this context that it became necessary to better support the concept of a course and encourage greater engagement with course sites from academic staff.

During 1999 an initial attempt at addressing this problem was commenced as the “Wizard” project. Briefly described in Jones and Lynch (1999) the Wizard project planned to provide an interface based on the Wizards common to Widows programs of the late 1980s. Such an interface would walk the academic through a series of questions about their course, the provided answers would be combined with the Webfuse page types to create a course site. A particular focus of this plan was an adopter-focused development approach, however, due to organisational uncertainty and limited development resources, this project did not move beyond the prototype and planning stage.

The next attempt to address this problem was the creation of an automated and expanded default course site approach for the second term of 2001. This coincided with the broader roll out of CQU’s new student records system. This new default course site approach was made possible by the expanded Infocom web team, the improvements in the Webfuse process and code-base described in previous sections, and was the primary task of the author during the first half of 2001. The automated and expanded default course site approach evolved to consist of the following components:

1. An expanded default course site;
   As described in more detail below, the single empty page default course site was replaced with a much expanded site consisting of five separate sections, containing a range of course related data and services within a re-designed interface. Each offering of every course offered by Infocom would have a new default course site.
2. Integration with existing data sources;
   Much of the data used in the creation of the default course site was drawn upon from existing, organisational data sources created by other processes.
3. Automatic creation;
   The creation and population of all default course sites was performed by running a script that, given the details of a specific term and year, would existing information, Webfuse page types, and related scripts and create default course sites for all courses offered by Infocom.
4. A copying process; and
   Teaching staff could further modify the default course site by adding additional course information and services. Rather than re-add these additional features for each subsequent term a copying process was developed by which staff could specify what they would like to copy to the new course site.
5. Support for a real course site.
   There continued to be a number of teaching staff who wished to create their own course website with other tools. Each default course site had support for an optional “real” course site This added another area of the default course site in which the staff member could place their own course site.

Figure 5.1 is the home page for a default course site from July 2001. This home page formed the top of the hierarchical structure of the default course site. Underneath the home page there were five sections:

1. Updates;
   The updates section provided a function that allowed teaching staff to provide and store course wide updates or announcements. The titles and post dates of the most recent updates were also visible from the home page.
2. Study schedule;
   This section provided a week by week breakdown of the course, its topics, content and assessment.
3. Assessment;
   Provided access to details about the course assessment. By default this would summarise for each assessment item, the title, due date and percentage of the overall assessment.
4. Resources; and
   All remaining course resources and services were made available via this section. By default this included a link to the course profile (syllabus) document, details of the course textbook(s) (including a link to the university bookshop, and, if used, a discussion forum or mailing list.
5. Staff.
   This provided both the personal details of the staff teaching the course as well as an area restricted to the teaching staff used for discussion or sharing resources. The personal details of teaching staff included name, contact details and where available a photo.
   If the teaching staff in charge of a course decided to create a real course site, then a sixth section was added under the default course site home page. The teaching staff could upload and manage their real course site within this section.

Figure 5.1 – Home page for a Webfuse default course site (July 2001) – click to make bigger

.

As identified in chapter 4, since Webfuse was a faculty system, not an institution system, there were organisational, political and technical limits on how well it could be integrated with institutional systems. These limitations continued to exist post 2001. Consequently, the default course site creation process included a number of work arounds and could not achieve all of the automation and integration desired. For example, study schedules had to be manually entered, even though the course profile (syllabus) already contained such a schedule. It was not until 2008 that CQU’s distance education publications process included a semi-automated process for the provision of electronic versions of course study guides.

The default course site process did create some initial and on-going disquiet around questions of academic independence, consistency and institutional identity. This was particularly a problem for academic staff wanting to create their own course sites. Of the 99 course sites created in the first term of the expanded default course site approach, 8 courses had a real course site. Table 5.4 summarises the total number of default course sites versus real course sites created by Webfuse from 2002 through 2009.

Table 5.4 – Comparison between default course sites and real course sites (2002-2009)

Year	Total courses	Real course sites	% Real course sites
2002	313	27	8.6%
2003	305	29	9.5%
2004	329	16	4.9%
2005	299	15	5.0%
2006	297	15	5.1%
2007	251	4	1.6%
2008	225	2	0.9%
2009	211	0	0

One advantage provided by the expanded default course site approach was the ability for the institution to exercise some control over the minimum level of service provided to students. Changes to the expanded default course site occurred through two means:

1. Institutional or strategic direction; and
   If the faculty identified some information or a service that it thought should be part of the minimum level of service to students it could implement this minimum standard across all courses via the default course site process. For example, from the second half of 2001 through 2002 all Infocom courses were required to have a course barometer (Jones 2002) to provide a mechanism to capture student feedback during a term.
2. Adopter-focused and emergent development.
   The Infocom web team modified the default course site operation in response to lessons learned from supporting academics using the system and observing what innovative staff added to the default site. This is in line with the adopter-focused and emergent development practices discussed in previous sections.

Due to the foundation provided by the Webfuse page types and templates it was not necessary for all default course sites to have the same structure or the same look and feel. Theoretically, every course site could be completely different. The flexibility of the default course site idea was tested in 2007 with the creation of a “Web 2.0″ course site (see Figure 5.2). This “Web 2.0″ course site was implemented as a Webfuse default site using Webfuse page types, however, using a different appearance and structure to a normal default site. This site is a “Web 2.0″ site because all of the functionality (discussion, wiki, blog, portfolio and resource sharing) were provided by freely available Web 2.0 tools hosted on external sites. Webfuse used RSS feeds generated by these external tools to create and maintain the course site. Students used these RSS feeds to remove the need to visit the course site at all.

Figure 5.2 – Web 2.0 Course site (2007)

The confusion of small and big changes

Over the last couple of days I’ve enjoyed a small discussion that has arisen out of some comments Kevin has made on my blog. This post is an attempt to partially engage with the most recent comment. I echo Kevin’s conclusion, I’d love to hear anyone else’s take on this.

The unanswered question

The main point I’d like to discuss is the question of small versus big changes. I have an opinion on this, but there’s not enough evidence to suggest that it’s an answer. The basic question might be phrased as: How do you improve the quality significant improvement in the quality of L&T in universities? You could make this much more general, along the lines of “How do you change organisational practices?”, but I’m going to stick with the specific.

I’m familiar with two broad responses:

• Revolutionary (usually top-down) change; and
  This is where the necessary change is identified by someone, eventually they get agreement/the ability to implement the change through some sort of change management process. This usually involves some big change. e.g. the adoption of a new LMS for a university, trashing the LMS and adopting WPMU for L&T, adopting university wide graduate attributes, requiring every academic to have a formal teaching qualification etc. Or even more radical, the death of universities and their replacement by something else.
• Evolutionary (usually bottom-up) change.
  Small-scale changes in practice, usually at the local level.

Kevin’s comment gives a good summary of the common problem with the evolutionary change approach

In my experience, especially at a large institution, taking the “small changes” route is the road to perdition. For me, this means I have to engage in a million little negotiations to get the small to accumulate to something significant. At the rate I’m going it will take me two lifetimes to bring about real change in the English Department.

As I mentioned above and indicate by the heading for this section, I don’t have what I would call an answer. I have an argument for the approach I would take and some evidence to support it, but I don’t think I can call it “the answer” (yet).

What I think is the answer

Last I year I gave a presentation called Herding cats, losing weight and how to improve learning and teaching (slides and video are available). In that presentation, the analogy used is that revolutionary change is like herding cats and that evolutionary change is like losing weight. Using this analogy I argue that the herding cats approach to improve the quality of teaching at a University has not worked empirically and that there is significant theory to explain why it will never work. That same theory suggests that an evolutionary approach informed by lessons learned from weight loss, is much more promising.

The general solution I suggest is one slide 200 or so (it was only a 60 minute presentation) and goes under the title “reflective alignment” and can be summarised as

All aspects of the learning and teaching environment are aligned to enable and encourage academic staff to reflect on their teaching with the aim of achieving 3rd order change.

Framed another way, the teaching environment at a university encourages and enables academics to be changing their thinking and practice of teaching. That is essentially do what they do now, make small changes each time they teach a course, but rather than changes that are not constrained by the same ways of thinking about teaching.

Having academics continually making these sorts of 3rd order changes (within an institution that encourages and enables them to make those 3rd order changes) will result (I think) in radically different and significantly improved learning and teaching.

When small changes won’t work

Like Kevin, I think that universities relying on small changes to improve learning and teaching will not work. Mostly because the university environment does not encourage nor enable the type of small scale changes that are required.

In the herding cats presentation a large part of the time was listing the parts of the university teaching environment that actively prevents the type of 3rd order change that is necessary. In fact, much of the bleating in posts on this blog are complaining about these limitations. Some examples include:

• Rewards that favour research, not teaching.
  No matter how many formal teaching qualifications an academic is forced to acquire, if they get promoted (both at their current and other universities) through the quality of their promotion, then they will focus on research, not teaching.
• Pressures arising from quality assurance and simplistic KPIs.
  Since the mid-1990s I’ve observed that it is only the courses with large failure rates or student complaints that get any attention from university management. Students, like most people get scared when their expectations aren’t meant. That means if you try something innovative students will complain. In addition, if you try something innovative you might have problems, which management hate. If you try something different, you are more likely to have to waste time responding to “management concerns”. The presentation references research showing that this is preventing academics from trying innovative work.

  With the rise of quality assurance and corporate aproaches to management, this trend is getting worse.

• Removal of autonomy;
  As I’ve argued in a couple of posts top-down management is removing academic autonomy and perhaps purpose and subsequently reducing academic motivation.
• Constraining systems;
  Increasingly universities are using information systems to perform learning and teaching. Those systems are designed on particular assumptions that limit the ability to change. The most obvious example is the LMS (be it open or closed source). This recent post includes discussion of this point around the LMS.

  The people, processes and policies within universities are being set up to use these systems. If you use something different, you are being inefficient.

• Simplistic understandings of innovation.
  When it comes to understanding innovations (e.g. something as simple as a new LMS), universities have naive perspectives of the adoption process. As recognised by Bigum and Rowan (2004) this naive perspective assumes that the innovation passes through the adoption process largely unchanged, which means that the social must conform with the innovation.

  i.e. As the institution starts to adopt Moodle across all its courses, Moodle can and should stay exactly the same. You only need to show people how to use Moodle, nothing more. If what they want to do is not supported by Moodle, then they need to conform to what Moodle does, regardless of the ramifications.

My argument is that all of this and other factors within a university environment actively prevent small changes having broad outcomes. The university environment is actively discouraging 3rd order change and isn’t even very good at achieving 2nd order change.

But small change can’t make a big difference

Ignoring all that, people still get stuck on the idea of lots of small change creating really big change. They are wrong.

To justify that, first let me draw on people recognised as being much smarter and more important than I (Weick and Quinn, 1999)

The distinctive quality of continuous changeis the idea that small continuous adjustments,created simultaneously across units, can cumulate and create substantial change.

The main reason people have trouble with this idea (I think) is that they think that the world is ordered and predictable. That the world is an ordered system. If you make a small change, you get a small effect. However, when you’re talking about a complex system, small changes can create radical outcomes.

I don’t have time to expand on this here, it’s talked about in the presentation I mentioned above. Anyway, Dave Snowden and any number of other people make this point better than I.

Big and small change in the wrong place

Here’s a new idea. One of the reasons why I think most universities are failing to improve the quality of their teaching is that they are focusing on big and small change in the wrong places.

In my experience, most universities are trying to make big improvement in teaching by introducing big changes in what academics do. Use a different system, use a different pedagogy, radically change your teaching so you are constructively aligned, get a teaching qualification etc. But at the same time, there is no radical change in the how the teaching environment works. There are no solutions to the above problems with the environment.

What I am suggesting is that there should be big changes in the environment to enable small changes on the part of the academic. In fact, in the presentation I argue that the aim is to help the academics do what good teaching academics have always done (Common, 1989)

Master teachers are not born; they become. They become primarily by developing a habit of mind, a way of looking critically at the work they do by developing the courage to recognise faults, and struggling to improve.

References

Bigum, C. and L. Rowan (2004). “Flexible learning in teacher education: myths, muddles and models.” Asia-Pacific Journal of Teacher Education 32(3): 213-226.

Common, D. (1989). “Master teachers in higher education: A matter of settings.” The Review of Higher Education 12(4): 375-387.

Weick, K. and R. Quinn (1999). “Organizational change and development.” Annual Review of Psychology 50: 361-386.

The Wf Framework

Yet another section from Chapter 5 of the thesis describing the various changes made to Webfuse in the period from 2000 onwards. This one (very briefly) describes the Webfuse framework for dynamic web applications.

You can see the impact of this experience in the development practices I’m bringing to my work in PHP and Moodle. There are early glimmers of MVC and the Wf Framework in BIM and the indicators block.

The Wf Framework

The absence of support for dynamic web applications is the second lesson identified in Chapter 4 from the development and use of Webfuse from 1997 through 1999. Rather than just being a publishing environment the Web was becoming an application development environment. An external consultancy during 1999 that required the development of a web-based helpdesk interface, led to the development of the Wf framework for Webfuse. The Wf framework was based on the Model-View-Controller (MVC) framework, made use of the data mapper pattern described in the previous section, and was used to develop 65 dynamic web applications.

Originally proposed during the 1980s for the development of graphical user interfaces, the MVC framework allows a single object to be presented in multiple ways with each presentation having a separate style of interaction (Sommerville 2001). Gamma et al (1995) describe MVC as a triad of classes used to build user interfaces in Smalltalk-80 and draws on a number of patterns including Strategy, Factory, Observer, Composite and Strategy. The MVC architectural pattern has since become widespread through its use in a number of web application frameworks.

All dynamic web applications using the Wf framework used a URL of the format

http://hostname/object/objectName/method/methodName/?param=value

For example, the URL for the “Staff MyCQU” application’s course history method for the CQU course COIS12073 was accessed using the following URL

https://webfuse.cqu.edu.au/wf/object/StaffMyCQU/method/CourseHistory/?COURSE=COIS12073

To parse and handle this URL the Apache web server was configured to use a Perl module. That module used the WebfuseFactory class to identify and call the appropriate application controller (i.e. matching the objectName – StaffMyCQU – from the URL) and calls the appropriate method (i.e. matching the methodName – CourseHistory – from the URL) of that controller class. Any parameters (e.g. COURSE=COIS12073) would be passed to that method and the controller would also perform authentication and access control checks to ensure that the user had permission to perform the requested method. The method in turn would normally consist of creating a model class (CourseHistory), a view class (CourseHistory_View), passing the model to the view, and using the view to generate the HTML to send back to the browser.

Sommerville (2001) argues that the inherent complexity of frameworks mean that it takes time to learn how to use them and that this can limit their use. Experience within Webfuse in the early 2000s reinforced this perspective as new developers, familiar with the simpler coding approaches of web “scripting” common at this time, took some time to grasp and see the value of this complexity. The consistent metaphor provided by the Wf framework also clashed somewhat with the Perl (the scripting language used to implement Webfuse) ethos of “There is more then one way to do it” and the tendency for Perl developers to “do it their way” (Jones 2003). However, as shown below (especially in Section 5.3.6 on Workarounds), the consistent metaphor and other advantages provided by this additional, initial complexity provided an important part of the ability of Webfuse to respond quickly and effectively to organisational requirements and changes.

References

Gamma, E., R. Helm, et al. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Massachusetts, Addison-Wesley.

Jones, D. (2003). How to live with ERP systems and thrive. 2003 Tertiary Education Management Conference, Adelaide.

Sommerville, I. (2001). Software Engineering, Addison-Wesley.

Object orientation and design patterns

The following is the third in a sequence of sections from chapter 5 of my thesis. These sections are describing the changes made in the development and support of Webfuse from 2000 through 2004 (and a bit beyond). This post very briefly describes the adoption a design patterns influenced, OO design.

The biggest challenge I faced in moving from Webfuse to Moodle was returning to a procedural approach to software development. Not just the movement from OO back to procedural, but from a system where I was deeply familiar with 900+ classes that provided a lot of low level and high level services for “e-learning” to a collection of procedural, spaghetti code where there was no clean separation of services, no easy way of finding which part did what. Of course, part of this difficulty was simply my newness to Moodle.

I am wondering what the implications might be for Moodle if it were to have been based on a “better” OO design.

Object orientation and design patterns

While the initial design rationale for Webfuse (Jones and Buchanan 1996) mentions that object-orientation is one of a number of approaches known to maximise adaptability the initial Webfuse implementation did not make use of object orientation. The key ideas of object-orientation arose during the 1960s, but it was the early 1990s before Fichman and Kemerer (1993) argued the object-orientation was the leading candidate to become “tommorow’s dominant software process technology”. With object-oriented design, system designers analyse and design in terms of objects or “things” – instead of operations or functions – with an executing system made up of interacting objects that maintain state and provided operations that manipulate that state information (Sommerville 2001). Proponents argue that object-orientation is an approach that helps avoid the labour intensive need to build all code from scratch due to its support for constructing software systems through the assembly of previous developed components (Fichman and Kemerer 1993). The independent encapsulation of state and operations enables this reuse and reduces design, programming, and validation costs and also reduces risk (Sommerville 2001).

However, programming with objects is complex and in the case of large and complex systems some of the ramifications are not yet fully mastered or understood (Szyperski 1999). Recognition of this problem contributed to significant interest in the identification, abstraction and use of design patterns to the problem of designing object-oriented systems. In perhaps the most important book on design patterns, Gamma et al (1995) argue that design patterns make it easier to reuse successful designs an architectures by expressing proven techniques in ways that are more accessible to developers and by allowing choice between design alternatives. A pattern is ‘a generic approach to solving a particular problem that can be tailored to specific cases. Properly used, they can save time and improve quality’ (Fernandez 1998). Sommerville (2001) argues that while patterns are a very effective form or reuse, they do have a high cost of introduction in that they can only be used effectively by experienced developers. Given a particular object-oriented design issue, a design pattern will name, abstract and identify key aspects of a common design structure, describe when it might or might not apply given other constraints, and discuss the consequences and trade-offs of the pattern (Gamma, Helm et al. 1995).

The use of object-oriented design and design patterns in Webfuse consisted of the following inter-related uses:

1. Object-oriented wrapper around database operations;
   Differences in how data is structured makes the transfer of data between relational databases and objects creates significant complexity (Fowler 2003). A solution to this complexity is a layer of software that isolates the two schema, a layer commonly called a data mapper (Fowler 2003). Work on the Webfuse “data mapper” began in 1999 and became a foundation for many of the remaining applications of object-oriented design.
2. University classes;
   A number of classes were created to match common objects within the University which Webfuse had to manipulate. For example, the People::Campus class provided state and operations around CQU’s various campuses.
3. Support classes for Webfuse page types;
   As the first part of a planned move to convert the Webfuse page types to a complete object-oriented based approach, a range of support classes were implemented. These classes replaced the use of procedural code within new page types. The length of an average page type was reduced from 1000+ lines of code to less than 250 lines. The move to an object-oriented page type process was never completed due to a focus on other developments. The OO page type process was intended to provide the ability for a single web page to be produced by a combination of multiple page types, thus addressing the first lesson identified in Chapter 4.
4. Dynamic web applications;
   To address the second lesson identified in Chapter 4 a framework for developing dynamic web applications was developed based on a model-view-controller framework. This work is described in more detail in the next section.

By 2010, the Webfuse code-base included 900+ classes, 65 dynamic web applications and a 190+ test harnesses. The test harnesses were mostly developed from 2001 through 2003 when the combination of the Webfuse agile development process, the increasing use of object-orientation, and a resourced Infocom web team enabled the adoption of test-driven development. Most importantly, the design patterns influenced adoption of object-oriented design provided the ability for the Webfuse adopter-focused, agile development process that resulted in the following developments.

References

Fernandez, E. B. (1998). Building Systems Using Analysis Patterns. Third International Workshop on Software Architecture, Orlando, Florida, Association for Computing Machinery.

Fichman, R. and C. Kemerer (1993). "Adoption of software engineering process innovations: The case of object orientation." Sloan Management Review 34(2): 7-22.

Fowler, M. (2003). Patterns of Enterprise Architecture. Boston, Addison-Wesley.

Gamma, E., R. Helm, et al. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Reading, Massachusetts, Addison-Wesley.

Jones, D. and R. Buchanan (1996). The design of an integrated online learning environment. Proceedings of ASCILITE’96, Adelaide.

Sommerville, I. (2001). Software Engineering, Addison-Wesley.

Szyperski, C. (1999). Component software: Beyond object-oriented programming. New York, Addison-Wesley.