Digital Cre8or wiki: First wiki pages

My first attempt at creating some structure and content

I have set up some pages in accordance with our discussion about the core structure of our wiki. They can be found at:

https://www.wiki.ed.ac.uk/display/digitalcre8tor/Home

I have started to develop the content for Module 1, so I would be grateful if you could have a look at this, and let me have any comments, ideas etc. I would hope to get Module 1 finished by the start of next week so we can use it as a sort of template for the other 4 modules.

 

Digital Cre8or wiki: House rules

What should we cover in the house rules?

The literature suggests that it is fairly important to establish some house rules early on in the design of a wiki, and these should be added to and amended later on, in the light of experience, and feedback from the community.

What type of house rules might be appropriate for our Digital Cre8tor wiki?

Some areas that spring to my mind include:

• Encouraging positive feedback and constructive criticism of other community members' work, which they have published on the wiki
  
• Regard for intellectual property and copyright when publishing media on the wiki
  
• Respect for other members of the wiki community
• Everyone has the right to comment on the structure, design  and administration of the wiki
• House rules may change from time to time
• Community members will be consulted about changes
• Roles of members of the community (e.g. administrator, tutor, associate, student etc)
• Who has final decision?

What do you think about these areas? Do you have any to add? Please post your comments on the blog.

Digital Cre8tor wiki: Developing online learning activities

A five stage framework for developing an online learning community

Salmon asserts that in order for online learning to be a happy and successful experience, learners need to be supported through a structured developmental process.  Salmon goes on to suggest a five stage framework to facilitate this process:

1. Access and motivation - The system is setup and students access it. They are welcomed and encouraged by the moderator.
   
2. Online socialisation - Students begin to send and recieve messages to and from each other. The moderator assists by helping students to familarise themselves, and build bridges in the cultural, social and learning environments.
   
3. Information exchange - Students engage in searching activities, and personalise their environment. The moderator faciltates class tasks and support the use of learning materials with the wiki.
   
4. Knowledge construction - Students interact using newly acquired knowledge and skills. The moderator facilitates the collaboration process.
   
5. Development - Students become responsible for their own learning, and build on what they have learned. The moderator continues to be supportive and responsive.
   

Mitchell suggests that the first two of these stages, Access and motivation, and online socialisation, are critical to the success of classroom wikis.

Feedback questions

• Do Salmon's 5 stages seem reasonable to you? 
  
• If not, what problems do you see with them?
• Are all, or indeed any of them, really necessary?
  
• If so, how might these 5 stages be incorporated into the design of our Digital Cre8tor wiki?
  
• Are there shortcuts we can take with the 5 stages, without undermining the effectiveness of the course?
  

Please let's have your feedback. This is a very important topic which is fundamental to the success of collaboration with the wiki.

References

Digital Cre8or wiki: Basic structure

Some thoughts about the basic structure of our wiki

Further to my posting last week about design considerations, I am thinking along the lines of a 3 part structure as follows:

1. Information about the Digital Cre8or course
   
2. The Digital Cre8or community
   
3. Digital Cre8or course content

Part 1: Information about the Digital Cre8or course

This section is likely to include the following information:

• Welcome to students
  
• Course overview
  
• Course description, aims and objectives and learning outcomes
  
• Detailed Course syllabus
  
• Course structure
  
• How the course works
  
• The role of the wiki in the course
  
• Wiki structure
  
• Course administration
  
• Where to find help information
  
• Who to contact
  

Any other suggestions?

Part 2: The Digital Cre8or community

This section is likely to include the following information:

• Welcome and Introduction to the Digital Cre8or community section
  
• The house rules
  
• Individual home pages for each community member (staff & students)
  
• Community resources 
  
• Introductory activities

Individual home pages are where course members will post information about themselves and upload media files (eg assignments and personal work) for other members to view and comment on. Course members will also be able to blog in this space on issues relevant to the course.

Community resources might include useful links or media that course members have found and wish to share with the community.

Any other thoughts about what might be in this section?

Part 3: Digital Cre8or course content

This section is likely to include the following information:

• Welcome and introduction to the course content section
• Introductory activities
• Core course module documents
  
• Essential online course resources (media files, presentations, links etc)
  
• Details of student activities
  
• Details of student assignments
  
• Details of equipment and support available in Resource Centres
  
• Suggestions for further study

Have I left out anything here? More generally, are 3 sections enough or do we need a 4th section to deal with orientation and support for using the wiki? Or can support for the wiki itself be accommodated within the other 3 sections? Which would be clearer/easier for the students to follow?

Pllease let me have your thoughts.

Digital Cre8tor wiki: What our students think about wikis

Focus groups

As part of my research into student experiences of wikis and podcasts, I spoke to a couple of focus groups made up of, Edinburgh University students, about their experiences and attitudes.

The wiki focus group were asked about what would encourage, or discourage them from using wikis. The responses were as follows:   

What would encourage you to use a wiki?

• easy to find
  
• easy to use
  
• searchability of content
  
• usefulness, reliability and sufficiency of content 
  
• regular maintenance and keeping up to date of content
  

What would put you off using a wiki?

• difficult to find (eg. buried deep withiin a MyED channel)
  
• difficultly with getting straight to the information you need
  
• too much information
  
• unreliable or abusive content
  
• too much effort to maintain (from moderator's point of view)
  

So what can we take from this for the Digital Cre8or wiki design project. The obvious questions we need to be able to answer would seem to be:

1. How do we make the DC wiki easy to find and easy to use? Is MyED really a problem, or is it possible that this group is untypically biased against it?
   
2. Are we satisfied that students will be able to find the content the need easlily?
   
3. How do we define which information is relevant and which is not and how do we get that across to the community?
   
4. What should be our mechanism for controlling the content? Should an administrator be moderating it or should we allow the community to moderate itself? Are we less exposed to abuse because we are a private wiki with access controlled by registration, than we might be if we were open to the world?
   
5. How do we ensure content is up to date? Is this perhaps more likely to be a problem once the course has been around for a while, rather than while it is new.
   
6. How will we know that our wiki users are satisfied with the experience of using it?
   

Can you suggest answers to these questions? Great - let's hear them. Are there other related issues that you are aware of? Let's hear what you think.

Digital Cre8or wiki: Setting up a pilot wiki

11 steps to a successful wiki pilot

Mader proposes 11 steps to a successful wiki pilot. How might these steps apply to our planned Digital Cre8or project?

1. Establish a time frame

Madar suggests 3 months (1 semester) as an adequate timeframe for getting a new wiki off the ground. This includes time for people to get familiar with it, move content relating to the pilot goal into it, and reach the pilot goal. Mader suggests a further 3 months fo the completion of the entire pilot, including setting up, technical integration, and testing. The actual time frame will depend on factors such as size of organisation, and attitudes towards using new tools. A wiki can take anything from a week to several months to get started.

2. Make it representative

Mader advises, "Include groups that are representative of typical projects and activities within your organisation." This helps to build relevant examples and replicable strategies that can help when you want to expand wiki use to other groups later on. 

In the context of Digital Cre8or, groups could include the following: students with little or no multimedia knowledge, students with some multimedia knowledge, staff who will be supporting the wiki, staff with expert knowledge in multimedia,  staff with training skills and experience.

 

3. Keep it compact

Mader suggests keeping the pilot size small enough that it is possible to work closely with each pilot group. This enables us to respond to potential  problems and provide timely guidance.  

4. Choose participants carefully

Madar advises using multiple types of users in the pilot, and not simply tech savvy users, in order to avoid the possiblity of retricting the appeal of the final product to enthusiasts. It would be useful also to include the sceptical as well as the converts.

5. Seek or be sought?

Should we advertise for volunteers for our Digital Cre8or project, or should we hand pick them? In view of the small number of perticipants required, perhaps it would be more practical to hand pick them. 

6. Wiki with a purpose

What is the purpose of our Digital Cre8or wiki? We have already talked about hosting relevant course materials, and enabling collaboration between course members. What are we talking about specifically? Are there other ways in which our wiki can facilitate teaching and learning of digital media skills?

7. Define house rules

Mader suggests starting with a set of guidelines for content, conduct and community and posting them prominently on the wiki.  These can be used as the basis for a more detailed set of house rules informed by the experience. Mader recommends the Sony Ericsson  Developer World wiki's house rules  ( http://developer.sonyericsson.com/wiki ).

 

8. Personal spaces

Mader recommends setting up personal spaces for individuals and groups, which can be used as a means of helping community members gain familiarity with the wiki. Personal space can be used to post information such as:

• Contact details (email, phone, IM)
  
• Personal Blog and website
  
• Biographical details
  
• In the case of DC wiki, Examples of work (images, audio, video etc)
  
• In the case of DC wiki, Course submissions
  

Any other suggestions or comments?

Mader says blogging in personal spaces should be encouraged, and in fact, blogging on class and project work is a requirement of the DC syllabus. It also helps to build rapport between community members, and get to know each other, and develop editing skills.

9.  Never an empty page

Mader advises that when new pages are set up, the page author should create scaffolding, or a template as guide to others as to what content is expected on the page. This could either be a set of section headers or a set of brief guidelines on information to be contributed.

10. Make it a magnet

Suggestions from Mader include:

• When responding to enquiries where the answer is on the wiki, send email link to it
  
• Put content on the wiki that can only be found there

These should help to get people into the habit of looking on the wiki

11. Be firm and think long term

This item is about avoiding the temptation to slip into old habits of organising certain sorts of activities such as meetings, even if it seems awkward at first. I'm not sure how applicable this might be in terms of coordinating a course through a wiki.  Will people use the wiki to collaborate, or will they be tempted to go outside the wiki and use email, or face to face communication? Would it be a problem if they did, and if so how? Will they request paper copies of documents rather than accessing documents online? Should we be flexible or should we be firm about encouraging students to engage with the wiki?

Once again, your feedback on the items listed above will be greatly appreciated, regarless of whether you agree with them or disagree with them. Let's get a dialogue going.

Digital Cre8tor wiki: Obstacles to wiki adoption

Obstacles to wiki adoption: How do we avoid them?

Mader identifies a number of wiki user behaviour patterns that can often interfere with a wiki functioning as a living, breathing, functioning collaborative tool. Mader describes these as anti-patterns. More information about anti-patterns can be found at:

http://www.wikipatterns.com

Examples of anti-patterns include:

The Do-it-all

One person gets very enthusiastic about the wiki and tries to do everything. The result is often that other users give up and leave it to this one person. One suggested remedy is to encourage the do-it-all personality to give active support to others rather than doing it all.

The Over-organiser

The over organiser has a tendency to take what people have contributed and rearrange it in a way that makes sense to them, but not necessarily to anyone else. This may invole moving or renaming pages without consulting anyone. These consequences are that people cant find content and start to lose interest in the wiki. Often, OverOrganisers act with the best of motives, and don't actually realise that whjat they are doing is disruptive. One possible solution is to encourage the OverOrganiser to suggest changes through comments and through discussion with all community members, arrive at an agreed plan for changing the arrangement and naming of pages.

WikiTroll

WikiTroll behaviour is where somebody consistently expresses general negative

criticisms with the result that other contributors are discouraged from productive collaboration. Trolling tends to happen less when the identity of the poster is known to other community members. Sometimes those posting negative comments don't actually realise that they come across so negatively.  One suggestion for dealing with WikiTrolls is to quietely suggest that they address their criticisms to specific points, and attempt to be positive and constructive in their criticism.

Sandbox

A sandbox is a place where people can practice using a wiki away from the real experiencce. This may seem like a good thing, but it can also be counterproductive as it creates a false impression of the wiki experience or re-inforces te idea that a wiki is somewhat difficult to use. 

According to Mader, it is better to let new users practice creating and editing content by creating their own personal space. Collaboration would be introduced at a later stage of involvement. With Digital Cre8tor, we may want users to create content using multimedia tools at the earliest opportunity, in order to develop confidence with using the tools within the context of the wiki. This might start with personal introductions using the media of their choice.

Empty pages

Empty pages discourage people from adding content. Nobody wants to be the first to contribute, so it stays empty. And the longer it lies there empty, the less likely it is that anyone will contribute. It is helpful when creating new pages to add content or scaffolding to suggest what type of contributions from other users are expected, and actively invite other users to contribute. If people create pages with no content, it should be gently suggested to them  that they put something there to encourage others to do likewise.

  

All-wiki-all-the-time

There is a danger of being too enthusiastic to the extent that others feel they are being pressurised and uncomfortable, and are therefore put off from using the wiki - especially if it is a big change from the way they are used to working. It is better to ensure that people are comfortable usung the wiki, before pushing tasks on to them that they may find too challenging at first.  What is the best way for us to manage this?

Manager Lockdown

This is when someone in authority decides to exercise hierarchical, top down control over content, rather than peer management. One consequence is that people become reluctant to contribute content for fear of editing the wrong page, and possibly upsetting someone in authority. However, there will be certain pages in the case of the Digital Cre8tor wiki where the content is fixed (eg course content), and where it would be undesirable for people to edit the content. There is a balance to be drawn. Where do we draw the line between what users can change, and what mechanisms do we use to make it work?

Too much structure

There is a danger of anticipating a structure before there is any content to fill the structure, with the consequence that the wiki looks messy, disorganised and with a lot of empty pages.  This can also make it difficult to find information and put users off using the wiki.

To start with the structure of the wiki should be simple, with the homepage serving as a simple table of contents. Only introduce a new level of content when the volume of content justifies it.

So for example, in the Digital Cre8tor content pages, we may start off by assigning a single wiki page to each module, but as the content grows, there may come a stage where a single page is required for each lesson in each module. Ideally, a request or suggestion for such a change should be peer driven, rather than imposed unilaterally by administrators.

This is just a short list of examples of common obstacles to effective wikis. Further examples of wiki anti-patterns can be found at:

 

http://www.wikipatterns.com

Feedback and discussion

• Do you recognise any of these anti-patterns?
  
• In your own personal experience, are there any other anti-patterns that you have identified?
• What steps can we take in the early stages of the development of the DC wiki to try to prevent them?
  
• How do we prevent ourselves from slipping into anti-patterns?
• Which anti-patterns pose the most serious threats to the effectiveness of the Digital Cre8tor wiki?

Digital Cre8or wiki: Design considerations

Wiki design

Woods & Theony describe four dimensions of wiki design:

• Architecture of information
  
• Plotting navigational paths
  
• Using templates for content page design
  
• Adding visual themes
  

Taking these four dimensions as a design framework, what design criteria and specifications should we be thinking about in the case of the Digital Cre8or wiki?

General considerations

One early consideration is likely to be, 'to what extent is the wiki design to be devolved to the Digital Cre8or wiki community, and to what extent should it already be in place for them when they join?' To put it another way, what is the best way to achieve the balance between giving the Digital Cre8or community a sense of ownership of the wiki, without wiki design considerations getting in the way of the student's learning goals? One approach would be to apply a light touch to the designed environment at the outset, but be open to suggestions and proposals from members of the community as to how the four design elements might be improved, for the greater effectiveness of the course.  Woods & Thoeny suggest starting with something simple and allowing the design to emerge organically as the wiki is used. The eventual design may not become obvious until it has been used regularly and users start to complain about aspects of design.

Architecture of information

The Digital Cre8or course suggests its own fairly rigid structure. There are 8 modules, each with its own  distinctivive content, which does not belong under any other module:

• Digital audio
  
• Digital images
  
• Movie language
  
• Digital Video
  
• Storytelling with animation
  
• Sharing through optical devices
  
• Sharing through the Internet
  
• Sharing multimedia through presentations 
  

In addition to those, there will be other components which will either be self contained or might be closely connected with the content of several of the DC modules. Possible examples include:

• Welcome and introduction
  
• House rules
• Information about community members 
  
• General information about the Digital Cre8tor course
  
• Health & safety content
• Intellectual property and capyright content
• Instructional materials for software required for projects
• Features on digital media techniques (in various formats)
• Published media projects by members of the community with comments
• Course glossary

Other supporting categories suggested by Woods & Thoeny, which may or may not overlap with those suggested above, include:

• Explanatory pages (rules & practices)
  
• How to add content
  
• Site map
  
• List of users
  
• List of project groups using the wiki 
  
• Template examples
  
• About us (info about who created the wiki)
  
• FAQs
  
• Copyright and content licensing

A key part of the wiki structure will be the interlinking of all relevant parts of the wiki to each other.

Each content page can also have a tag applied to it, enabling content to be referenced under alternative taxonomies (see Categories below). 

Plotting navigational paths

Front page

The front page should:

• Tell people what the wiki is about
  
• How to find what they want
  
• Take them as directly as possible to relevant content

The Digital Cre8or wiki is primarily content focussed. The front page should say what content is being created and how it is organised, perhaps with some examples. The front page should also spend some time encouraging community members to contribute as often as possible. The Digital cre8or wiki is also envisaged as a community wiki and should reflect the interest of that community with news, events,and by giving prominence to digital media.

Section pages

The Digital Cre8or modules will form the main sections. Some of the other headings discussed above may also suggest themselves as section headings. Sections may or may not require specific information or instructions  or house rules.

Categorising pages

Categories may also be referred to as tags or tag clouds. Categories allow alternative taxonomies, to that used for the main architectural structure,  to be applied within the wiki. For example, categories would make it possible to group all relevant content under a tag such as  'video' or 'instructions' etc.

Planning headers, footers & left hand navigation 

These can usually be generated automatically by templates (see Confluence documentation). Wikis tend to follow website conventions for left hand navigation, which often link to general housekeeping functions such as:

• Support web
  
• Support guidelines
  
• Open questions
  
• Search
  
• Recent changes
  
• Notifications
  
• User registration
  

Effective headers

• Can be used to lay breadcrumbs
  
• Can include list of tags
  
• Jump and search box in top right hand corner
  
• Let users edit page in text mode
  

Above all, it is important to understand how people are using the wiki in order to get the most out of headers. Can people find what they want easily? Make sure we are getting good feedback by making feedback link prominent.

Planning footers

A page footer might include the following: Edit, WYSIWYG, Attach, Print, Raw view,  Backlinks, History, and More actions.

Using templates

See confluence documentation.

Adding a visual style

Using visual content such as themes, personalisation and images can look much more professional, and add interest to the content of the wiki. However, it should be applied with care, so as not to overwhelm the users, or make content difficult to access.

Themes and skins

Themes, also sometimes known as skins, are a collection of settings which include colour, fonts, backgrounds, text size, page layout  etc. They are used to set the look and feel of the page. Skins affect the 'personality of the page, so it is important to give some thought as to what sort of 'personality' we want the Digital Cre8tor wiki to project to the prospective community. Should it be creative, arty, geeky, studenty, serious, fun, simple, etc? Themes are usually provided with the wiki software. They can be ceated by the user, but bear in mind this involves extra effort and an understanding of CSS or XSLT.

Using Colour

Colour can be used to aid navigation, by giving certain parts of the wiki a distinctive colour identity. For example, parts of the wiki used for course content could be one colour, while parts used for more social/community based activities could be another. Care needs to be taken not to overwhelm content by makin unwise colour choices, especially with backgrounds.

Personalisation

The Digital Cre8or logo should appear where relevant, particularly on those pages hosting DC content. The University crest already appears on all the University hosted confluence pages.  Some thought should be given as to the size at which the logo is presented (certainly not so large that it detracts from the page content.

Other iconography such as Favicons can help to make tools and links easier to find, and thereby make the wiki more usable.

Feedback

It would be useful to get your feedback on these questions and and other design considerations discussed above. Please reply using the comments box.

• Taking these four dimensions as a design framework, what design criteria and specifications should we be thinking about in the case of the Digital Cre8or wiki?
  
• To what extent is the wiki design to be devolved to the Digital Cre8or wiki community, and to what extent should it already be in place for them when they join?
  
• What sections should the wiki contain?
  
• What categories or tags should be applied to pages?
  
• What supporting pages should be provided as a bare minimum?
  
• What should be the general look and feel? (eg colour, mood, etc.)
  
• How should the content be split up?
  
• Any other views?