Best practice
The following best practice recommendations are given to developers and instructors based on results and insights from ALS case studies and lessons learned during development. More details can be found in the report "Best practices in the use of awareness techniques in e-learning".
Activity Notifications
Recommendations for developers- Provide tools through which users can be notified about events taking place in the various workspaces they participate in. Where possible, provide a central point from which users can access notifications for all workspaces collectively.
- Support different levels of summarization of notification information, to allow for quick overviews and account for potential scaling problems.
- Allow users to manually configure the settings governing which notifications they receive and how (either directly, or through profiles that control the same).
- Support both “pull” (i.e., from within the LMS) and “push” (e.g., through RSS feeds, or emails) models for the retrieval of notification information. When multiple models are supported, allow users to maintain different configurations for each.
- Design notification representations so that they capitalize on the semantic and interaction metaphors users are familiar with.
- If an event- / activity- notification tool is available in your LMS, make sure it is accessible from within your course site, and that it provides information specific to the course. Do the same for group- / project sites. If such a tool is not available, you may want to consider manually replicating some of its functionality for the main course site (e.g., by sending notification messages when important changes in the course workspace take place).
- If the event- / activity- notification tool supports the presentation of information collected from all the course- / project- sites a user participates in, consider making the tool part of the user’s standard personal workspace. You may even consider making the output of such a tool part of the “default” information displays users encounter when they log into the system.
Establishing Identity
Recommendations for developers- Provide tools that allow users to easily create and maintain a learner profile. Allow for free-form content in the profile, in addition to any structured content that may be supported.
- Allow for course- / site- specific content in the user profiles. Alternatively, allow users to set different access rights for different portions of their profile.
Recommendations for instructors
- Encourage learners to create their own learner profile and to explore the profiles of their peers, especially prior to group formation and in early stages of group interaction.
- Lead by example, maintaining your own profile, and ask teaching assistants to do the same where applicable and possible.
- Enable learners to maintain course-specific profiles; where support for this is not provided by the LMS, consider the use of “free content” tools, such as wikis.
Presence and Availability
Recommendations for developers- Provide synchronous communication tools that transcend course boundaries, thus allowing users to communicate and interact in the context of multiple learning tasks simultaneously. Automatically manage the associations between users, so that members of courses and groups have immediate access to each other, without lengthy and cumbersome processes for establishing first contact. Allow for the categorization of “contacts” on a per-course and group basis.
- Provide availability indicators that encompass learning information, and especially learning disposition of users.
- Where possible, allow users to manage their availability information on a per-course and group basis.
- In displays of user presence and availability information, make it straightforward and easy for users to initiate communication with one or more peers, using any of the synchronous and asynchronous facilities available in the system, and applicable to the peers’ presence and availability.
- If the LMS does not support the sharing of availability information, consider encouraging users to utilise standard facilities to partially replicate the functionality (e.g., through personal status messages, or dedicated wikis that users update themselves)
- If the LMS does not support synchronous communication between users (or the tools provided are too rudimentary to be of real utility), encourage students to make use of external, widely used tools (e.g., instant messaging applications) and share their contact information with their peers. As the process of initiating and discontinuing contacts with others is a complex social process, you may want to also provide a minimal set of recommendations on how this can be approached in the context of a course; this especially refers to the discontinuation of contact once a learning task is complete.
Awareness of Learning Status and Learning History
Recommendations for developers- Provide facilities that enable users to keep track of their learning progress. Allow users to identify / express their current learning status, if possible both by structured and free-form means.
- Provide facilities for individuals and groups to review and maintain their learning history. Enable instructors to indicate items that serve as milestones in the learning progress, so that they can be emphasized when presented as part of learning histories (thus, opening the way to principled summarized views of said histories also). If possible, provide ways to automatically synthesize group learning histories from the individual histories of their members.
- For non text-based communications, provide the possibility to record and replay communication sessions for later reference.
Use of Course- and Project- Boundaries as Context Information
Recommendations for developers- Directly support the creation of groups and dedicated workspaces intended for small-group learning tasks, in the context of a course. Where possible provide facilities that enable the centralized maintenance of several group workspaces by course instructors. Where possible differentiate between workspaces for temporally limited, ad-hoc tasks (with a typical lifespan of a few hours) and workspaces intended for more longitudinal learning tasks (with a lifespan potentially equal to that of the course with which they are associated).
- Where applicable, make the LMS tools “aware” of the presence of group- / project- workspaces (e.g., so that they make available specialized functionality when included in such workspaces, or that they make use of related information when operating at the course level).
- Provide dedicated workspaces for group learning tasks, and allow users as extensive as possible control over their use and maintenance.
- Where special support by the LMS is not present, consider using the standard facilities (e.g., normal sites with custom access privileges) to the same effect.
Awareness vs. Privacy
Recommendations for developers- Where applicable, provide different levels of abstraction for potentially privacy infringing awareness information, with each higher level providing a more abstract / summarized (and, thus, less privacy-infringing) view of individuals’ activities. Consider using a level of abstraction that balances between privacy protection and comprehensiveness of provided information as the default one.
- Explicitly respect course- / project- site boundaries in the flow of notification information (e.g., group-internal notifications should not be available to anyone other than the members of said group).
- Provide users control over privacy settings in relation to awareness information, especially in terms of which of their activities, and at what level of abstraction, can be communicated to others. Instate reciprocity mechanisms to prevent users capitalizing on private activity information received from others, without contributing their own information back to the community of peers.
- Encourage users to allow for detailed notification information to be exchanged.
- Abstain from basing course assessment on user activity “visible” through event- / activity- notification mechanisms, to foster “natural” sharing behaviour, and prevent the undertaking of “fabricated” activities with the goal of mark manipulation.
Awareness in an Authoring Context
Recommendations for developers- Provide the functionality to create groups within the authoring environment. Authors should be able to set group privileges for specific types of users.
- Provide the functionality to create lessons. These should belong to either an individual author, or a group (the latter thus permitting collaborative authoring). Lessons should be formed of items. Each item can have tags applied to it. Provide adaptation specific tags exist, such as type and adaptation metadata. Collaboration on a lesson or item should be permitted in the form of any subset from {collaborative editing of items or tags, tagging, commenting, rating}.