Review of communication and community tools

The process of choosing a suitable platform for the SCoPE community was unexpectedly complex! Our Project Plan provided an overview of the key considerations for technology and access, outlined in chapter 3. However, our preliminary research (Currie & Wallace, 2005) did not yield any existing community platforms that satisfied these most important criteria:

• easy to use
• flexible
• customizable
• good communication tools.

As discussed in earlier, as part of the preliminary research all eLINC staff members were invited to participate in a full day of discussions about SCoPE. Three main topics related to community platforms were discussed among the eLINC technical design team.

1. Immediate needs to prepare for pilot

2. Rationale for choosing open source or proprietary or both

3. Exploration of software choices

Inherent in these topics were preferences around design approaches and the importance of teams and developing a common language. As expected, the technical support staff was the most vocal in this discussion, and they felt that building the software in-house would be the best solution. The basis for this preference was that SCoPE project could benefit from the resources and learning that had already been invested in the SFU Co-op Learning Community (SFU's Co-operative Education Learning Community). Furthermore, everyone felt that the development of a robust open-source community platform would be a valuable educational contribution.

With the help of eLINC staff, I drafted user requirements in fall 2004. Jason Toal, Experience Designer, in particular, encouraged me to think about the various roles and levels of access and interaction, and to describe typical actions through use case scenarios. The requirements, outlined in Appendix II, are divided into program and user, each focus affording an opportunity to revisit core values and goals, and translating those into look and feel, and functionality.

The user requirements outline basic roles, and several use case scenarios to convey typical user interactions with the community environment. While the scenarios did not present terribly sophisticated interactions, there were several features that did not present themselves in existing platforms. For example, it was important to support the transition from lurker to active participant. At any moment that a visitor to the site feels compelled to contribute to a discussion, there should be a simple process to quickly join/log in, then resume engagement. We felt strongly that members should choose to join SCoPE because they see something of value to them in the community. If potential members are attracted to a topic-based discussion, whether by invitation or incidental, there should be no requirement to undergo administrative tasks like creating user accounts or registering for events before given an opportunity to explore the benefits to them.

The user requirements document also outlines several options for forum participation and subscription to topics of interest. A system that accommodates various levels of participation is important, realizing that a newcomer needs a very basic level of understanding of these options, but a more seasoned community member would be interested in a more advanced level of customization and management.

Overall, the user requirements reflected the recommendations generated through the focus group sessions. At the time, the user requirements document was published in a Wiki we assumed it would continue to expand. However, it was felt that it had enough detail to inform our choices about a community platform. As mentioned earlier, the technical support staff at SFU’s eLearning Innovation Centre felt that building the software in-house would be the best solution, especially given that we could benefit from the resources and learning that had already been invested in the SFU Co-op Learning Community (SFU's Co-operative Education Learning Community) . Furthermore, the development of a robust open-source community platform would be a valuable educational contribution. Despite some exciting beginnings in this direction (see Figure 2), the time and resource commitment to software development seemed prohibitive and ultimately the focus turned back to finding an existing platform that would suit our basic criteria. With a continued interest in customization, going with open source software became an important selection criterion.

Figure 2 Early mock-up of the community environment prepared by Jason Toal

(Toal, n.d.)

The next platform considered was Sakai (Sakai Project). As open source software there was potential for customization, and Simon Fraser University had recently become a partner in the Sakai Educational Partners’ Program (SEPP). This program was rapidly attracting interest among post secondary institutions, and SCoPE was envisioned as an integrated unit within the community structure that already had an active discussion related to Sakai development. The SEPP project manager agreed to this proposal and a separate SCoPE workspace within the SEPP project environment was established. However, after experimenting with that arrangement we concluded that the administrative structure was too complex, primarily in the areas of permission levels, registration, and sharing resources and access across worksites required for separate community activities. Expanding to create new seminar discussions could only be achieved by creating additional worksites. This would become problematic for sharing resources across worksites and for providing members easy access to additional worksites. That process proved to be very time-consuming, as well as falling short of serving our needs.

In addition, at that time the Sakai forum tool was not fully developed. In fact, at that time a mailing list was favoured over the forum tool for the Sakai development community. While the model had many advantages, we recognized that the reasons we were considering this platform were more strategic than for how closely the technologies supported our user requirements. The SCoPE workspace remains available for experimentation, much like a separate special interest group.

At this stage we turned to TikiWiki as a possible platform. TikiWiki had recently been selected by LIDC staff for other community projects, such as Academic Relations (Academic Relations, n.d.), a resource site for faculty , and any design and development work could be shared across projects. Aside from being feature-rich and flexible, the structure suited community activities; forums and resources were centrally accessible, and there was potential for a good resource management system. 

The discussions about community platform again turned to the resources necessary to prepare for a launch. TikiWiki was by no means an out-of-the-box solution, and with LIDC staff committed to so many community projects, it was clear that the SCoPE launch would be delayed. At that point we returned our original list of options and recommendations for community environment software resulting from our research during Phase 1 of the project (Currie & Wallace, 2005). We had outlined the advantages and disadvantages of building in house, using an out-of-the-box community, or using open source solutions. We had also targeted two open source projects: Sakai and Moodle, yet we had not explored Moodle in any depth.

Moodle stood out as satisfying most of our user requirements. Furthermore, it has a well-established open source community, and is flexible enough to allow members to invent and share new uses. The disadvantage was that it adhered to a fairly rigid course metaphor, and we were concerned that it would also require considerable resources to transform Moodle into a community environment. However, it was clear that it could be our best choice and a proposal was submitted to the eLINC management team.

On June 7, 2005, a full year after the initial project proposal was submitted, we were given the go ahead to develop SCoPE in Moodle. This delay in selecting a community platform seemed like a major setback at the time. Fortunately, Moodle took (literally) 8 minutes to install. I have one of two administrator accounts, allowing the access privileges necessary to deal with day-to-day operations. Others who have worked on branding and customization have found it to be straightforward, and the site has required very little maintenance by the LIDC technical support staff. So while our search for the appropriate community environment was extensive and drawn out, the flexibility of Moodle and maturity as an open source project meant less time devoted to installation and initial set up. With minimal development resources we have been able to incorporate changes necessary to make SCoPE feel like a community rather than a course space. This is discussed in more detail in chapter 7.

Through this process we certainly learned that it is important to select tools that match your specific community requirements and context. It is also important to be realistic about programming costs to build from scratch, and while there is value in overlapping projects in terms of development, it may not be the most efficient route if each community has specific development needs. Also, if extensive resources are invested in on platform, it becomes even more crucial that an appropriate platform is selected in the first place. And finally, there is no single ideal community platform so it is important to plan for a good foundation to build as new uses and needs emerge.