Defeated by technology

I joined Mike Caulfield’s  Federated Wiki Happening on Wednesday, along with about another 30 people. Wednesday went well. I created my bio page and contributed another page (the first assignment), had a good look round and was fairly confident that I understood the basic principles.

Since then it has all gone ‘pear shaped’. Thursday and Friday whenever I logged in I was taken to Ward Cunningham’s page, although this had my name at the bottom of it. I could not access my own pages; this meant that although I could see what everyone else was doing through Ward’s pages, I could not contribute.

Yesterday my page was reset and this morning I managed to get in to my site, although I had to start again with setting up my bio page (not a big deal). Everything was fine for about half an hour and then I found that if I clicked on my own page, I was taken to another participant’s page. I have not been able to resolve this and again it means that although I can read everything, I can’t contribute my own writing. I had forgotten how extremely frustrating, even stressful, it is to be defeated by technology.

My experience with wikis

I am not new to wikis in general. I have extensive experience with PBworks and some with Wikispaces. I have probably edited a wiki page on most days of each week for the past 6 years or more. The majority, but not all these wikis have been used to collaboratively work on research, which has involved editing each other’s writing and collaboratively sharing and building up reading and other resources. I also have a family history wiki, to which any member of my family who wishes to can add information, and I have set up, managed and contributed to a wiki for a large and complex project, which involved producing training materials for teachers working with children on the autism spectrum. Finally I have experience of working in community wikis. I have always found working in these wikis trouble free.

I was excited by the idea of Fedwiki as I thought it might add a fresh perspective to my existing practice.

Fedwiki

There are a few things about Fedwiki, that even with my inability to work in it so far I find interesting and attractive – that’s why I’m hanging in here for now.

1. The fact that it is federated, i.e. each person has their own site, from which they can link to other people’s sites and select or reject edits of their own pages. Mike writes:

….we don’t write on each other’s pages. If you don’t like my edit, just don’t fork it back. That gives me permission to try to write the page I think is best. It gives you permission to reject my changes

2. Idea Mining. Federated wiki is not a blog. Even though there is reference to ‘collaborative journaling’ the intention is that pages will be created by participants to share a quick pass at an idea. This idea can be connected to, captured and extended by others.

We suggest a fruitful approach to journaling in wiki might be Idea Mining, the translation of things we read, see, and think into named ideas and examples that we can connect to form larger and more various thoughts. 

3. In line with the notion that Fedwiki is not a blog, we are discouraged from formatting posts – the idea being that they can then be more easily reused and repurposed. That makes sense. We are also discouraged from adding comments. Edit by adding or amending information, but don’t comment. That’s great too as it keeps the focus on the idea being considered and away from personalities and individuals.

4. I particularly like the idea that FedWiki is a neighbourhood – not a community, nor a network – but ‘The people that you meet when you are walking on the street each day’. Your neighborhood shrinks and grows based on your interaction with it, what you look at and who you read. Mike Caulfield describes it as a Sesame Street neighbourhood.

The Sesame Street neighborhood is transactional and accretionist. It’s event-driven. As you walk through the streets near your house you bump into people, and these people form your neighborhood, by virtue of you bumping into them.

So, I can see how Fedwiki could add to my existing experience of using wikis for collaborative writing. The big difference is that each person is on their own site, whereas in all the wikis I have used in the past, a group of people collaborate in one site.

All I need to do now is to be able to access my own site, without any hiccups and then I’ll be away. In the meantime, I think I’ll write here.

Wikis for project management, research and personal use

This year the tool I have used the most to support my work has been a wiki. I have found it an invaluable tool, for both working in small research groups and working in large and small project teams.

My wiki of choice is PBWorks – although I am also familiar with Wikispaces, but only through the work of others, i.e. other people have set them up and registered me as a user. I started using wikis in 2008. I can’t remember now why I chose PBWorks in preference to other wikis, but think it must have been because at the time it appeared more intuitive and easier to use.

I have created 15 PBWorks wikis and am a user of another eight.  Only one of these is an upgraded site (i.e. paid for, because we needed more space for the project). Working on a wiki is not all ‘plain sailing’, but for me the advantages outweigh the disadvantages.

Things that I still find difficult are:

1. The way the formatting changes when you copy from a document into the wiki or copy into a document from a wiki page. The loss of formatting can be time consuming to correct.
2. I sometimes have problems constructing Tables in a wiki page.
3. I sometimes think an embedded discussion forum would be useful. I think Wikispaces has one – but PBWorks does not. It is possible to embed an open source forum, but it feels a bit ‘messy’.

I should say at this point that I have never attended any of the online training sessions offered by PBWorks, so I probably don’t know what I don’t know 🙂

Things that I really like:

1. The potential for promoting collaborative and/or cooperative working, with open sharing and the breakdown of hierarchies. This is of particular benefit in project work. In a project I am working on at the moment, the project team, project funders, project evaluators and prospective clients all have access to the project management wiki – which means that the working process of the team is visible to all. This of course means that whether the team is meeting its deadlines is visible to all, but it also means that the work and efforts of the team, the questions they are grappling with and the complexity of the task are also all visible to everyone. This helps to break down any ‘them and us’ thinking.
2. The fact that all the documents being worked on are in the same place and it is possible to keep track of which version is being worked on. I can still remember those days of working in a group on a research paper and getting in a terrible muddle with sending edited versions and drafts by emails which crossed each other – the stuff of nightmares!
3. The fact that it is possible to include multi-media, so that audio, video, PowerPoint presentations and so on can all be accessed in the one place. A wiki can be a colourful and lively space.
4. That a wiki can be for anything. I also have a personal family history wiki, where I have collected stories from the family, old photos and even audio interviews with older members of my family – the best is my mother, now in her mid-80s singing. She still has a lovely voice and remembers all the words of the old musicals.

Things I have learned about wiki management:

I manage most of the wikis I work in, so over the years I have become better at setting them up in a way that makes them easier to use, although people new to wikis can find still them intimidating.  These are some of the things that I do to help ‘wiki novices’ to navigate the wiki more easily.

1. If it is a wiki which will be used by people who are unfamiliar with wikis, then an attractive welcoming front page, with images and colour can help to draw people in.
2. I usually have a ‘Start Here’ page, which explains how to use the wiki to get the best out of it, the protocols, etiquette etc. for that particular wiki.
3. I offer to help via email or Skype. Skype is a useful tool for talking through wiki navigation.
4. A ‘Sandbox’ page can be useful i.e. a page where people can play and try things out without worrying whether they are going to ‘mess up’ the wiki pages.
5. It is very important for the person managing the wiki to ensure that navigation is, and remains, as easy as possible. This means keeping the wiki tidy through ongoing ‘wiki–gardening’. For most wikis, this means ensuring that folders are well organized and that documents are always placed in folders (particularly important for projects where there are a large number of resources). It also means keeping the Sidebar tidy and well-organised.
6. For wikis which are used to share large numbers of resources, then it is helpful to keep the Sidebar to a minimum of pages and to use each of those pages as a Contents list to linked pages (a bit like designing a website).
7. It also helps to ask people to identify themselves when editing a page  by preceding their edit with their initials and the date in brackets. If there are not too many people in the wiki group, each person can also edit in a different coloured font, which makes them immediately identifiable. The ‘strike-through’ tool, is also helpful in ensuring that what has been edited out remains visible. In Word, this would be equivalent to ‘Track Changes’.

What have I forgotten? What do I not know? There is bound to be something, if not a lot, but nevertheless, wikis have been my most useful tool this year.

Update 23-11-16

Further information about how to use wikis for project management has been provided by Randolph Preisinger-Kleine

http://www.discuss-community.eu/working-on-lifelong-learning-projects-3/item/286-using-wikis-for-project-management.html

Openness and Research

In an interesting recent post Stephen Downes  has pointed once again to the four elements that  ‘distinguish a knowledge-generating network from a mere set of connected elements.’  – Diversity, Openness, Autonomy and Interactivity and Connectedness.

I have been thinking about the question of  ‘Openness’ quite a lot in relation to research networks. Currently I am involved in a community of e-learning researchers – ELESIG and have co-authored a paper which explores the issues being faced by the community following withdrawal of funding. This paper has just been accepted (subject to amendments based on the reviewers comments) by the International Journal of Web-based Communities.

I am also currently working with John, Matthias and Roy Williams  from the CCK08 course on a research project to investigate learner preferences for communicating in blogs or discussion forums.

In his post Stephen wrote the following about the need for ‘Openness’ in a network

Openness – does communication flow freely within and without the network, is there ease of joining (and leaving) the network? In a community, this means, are people able to communicate with each other, are they easily able to join the community, are they easily able to participate in community activities? In practice, what one will observe of an open community is that there are no clear boundaries between membership and non-membership, that there are different ranges of participation, from core group interaction through to occasional posting to reading and lurking behaviour. If a community is open, then it sustains a sufficient flow of information to generate new knowledge, but if it is closed, this flow stagnates, and no new information is generated.

I’m wondering just how open is open, particularly in relation to researchers. The problem is that too much openness could invalidate the research, couldn’t it?

For the paper that has just been accepted, my co-author and I have worked in isolation from the ELESIG community. I think only two other members of the community (403 members) even know that we have done some research based on the work of the community. As yet nothing has been shared, despite the fact that the community has been set up with the explicit purpose of sharing research.

In the research that John, Matthias, Roy and I are working on, related to the CCK08 course, we startedoff with very good intentions. John set up a community wiki on the Community Ning site and invited others to join us. Currently we are designing a questionnaire and we quickly realised that we would not be able to openly discuss this design process with the community for fear of invalidating the research – the community is the very group that we hope will respond to the questionnaire. So we have moved to another wiki, in order to design our research. We intend to post our findings to the community wiki and hopefully stimulate discussion.

So I’m wondering if ‘Openness’ just doesn’t work in research communities, or have I misunderstood what Stephen meant. I seem to remember reading somewhere (although I can’t find it now) that Stephen was encouraging more ‘Openness’ in research communities, but how exactly would this work?

Dilemmas, dilemmas!