Case Study: Using a Wiki in Research

Wikipatterns – Table of Contents

By Peter Higgs
Senior Research Fellow, Creative Digital Industries National Mapping Project
Queensland University of Technology
Brisbane, Queensland, Australia

I started managing a three year research project for the ARC Centre of Excellence for Creative Industries & Innovation, a research institute within Queensland University of Technology (QUT) in mid 2004. Even though I have been involved establishing and running with multimedia CD ROM content production since 1992 and the internet development since 1995, I never established a website for the creative industries national mapping project: there was no point! Establishing the traditional university passive “marketing” website for the project would have required the development of an extensive brief to the “publishing” division where every thing we wanted to say would have to be thought through, then there would be a series of extensive meetings which would generate concepts and revisions. All of this would have finally lead to a static website that no-one would want to visit, least of all me. Updating it would have been a similar nightmare. And none of this is a criticism of the publishing department. The procedure is perfectly appropriate for any large organization needing to communicate with 30,000 to 40,000 students and 10,000 staff.
However the project I headed was one of about half a dozen around the world investigating definitions and statistical techniques for measuring the characteristics of what are called the creative industries. Each researcher has slightly or very different definitions, and every country has different conditions under which industrial activity and occupation statistics are classified, collected and disseminated.

Our project was cross discipline by nature involving industry experts, economists and statisticians with our project partners contributing to the research directly and also by being part of the research steering committee. However, for the first year the collaboration aspects of the project were constrained to periodic meetings, emails and phone calls which are very unsatisfactory as a way harnessing group expertise and contribution capacity.

Instead I spent that year (amongst many other things) clarifying my requirements on ways to augment the project’s capacity and influence through collaboration. I spent quite a few nights looking into various software and web based solutions that could possible address them: FTP and webDAV servers, collaborative document web sites and, through using wikipedia, with wikis which seemed to be closer to what I needed. I investigated establishing a wiki using a spare MacG4 I had at home as a server and the only solution close on paper to meeting my requirements, that also seemed to be within reach of my limited technical skills, was confluence. I used the experience of setting up the wiki and using it for a couple of weeks to clarify the requirements and to better express to management why a traditional web site approach would be inappropriate.

It may worth revisiting these as they could be useful to other researchers looking to establish a wiki.
Objectives of the National Mapping Research Project Wiki.
The wiki needed to provide a forum with the combination of information, participation and functionality that will attract and retain the interest of the researchers and consultants active in the field of the creative and cultural industry mapping and economic impact research.
The wiki needed to not only publish information on the project and make available to others the resources from it but it needed to also:
Encourage and facilitate discussion and agreement on approaches to taxonomies and strategies.
Provide a focused forum for the sharing of drafts, papers, reports and statistics within the field.
To harness the knowledge and willingness to contribute that is dispersed throughout the research and consultant community and to thereby establish a critical density of talent, effort, review and resources.
Allow the project’s contracted participants to contribute in the day-to-day work, discussions and decisions that interests them and at the time and place they are able to contribute.
To substantially reduce or eliminate the frustration that project partners feel at not being up to date, not being able to participate more fully and not being able to derive the short term or even ephemeral outputs they may have a requirement for.

To establish the CCI National Mapping Project as one of the world’s pre-eminent fora in the field of creative and cultural industry mapping research.

I knew from experience that meeting these objectives would require a combination of technology capability, content that was seen as valuable, clean functional design, and an approach or aesthetic that empowers, attracts and energizes the contributors. These last factors are very difficult to achieve and to assess in advance. By getting one of the other factors wrong it is easy to undermine the empowerment factor so that it cannot be achieved. Furthermore it is possible to meet the capability, content, design requirements and still not achieve the emergence of the empowerment factor. But it needs to be strived for.

Following on from the articulation of the objectives for the project wiki the technical requirements were established:

Sophisticated handling of Users, Groups and Access Permissions.
Having spent six years managing a research project and software company in the field of rights management I knew how critical it was to have as a foundation for the wiki a sophisticated capability of access and usage management which would require the application having an above average functionality for handling Users, Groups and Access Permissions. It would have been a bit ambitious to hope that any existing wiki solution would also have implemented a rights expression language.

I determined that at a minimum the wiki and its supporting environment needed to be able to support at least four levels of access:

Role Capability
Anonymous public: Will not be able to edit pages or make comments but will be able to see most of the site as this is the only effective way of engaging new active participants.
Self-enrolled researchers and practitioners in the field Are able to see, edit and comment on most parts of the site.
Able to add and edit pages, resources and forums.
Project partners, contractors and consultants Are able to see, edit and comment on most parts of the site including the project administration area.
Able to add and edit pages, resources and forums.
Project Administrator Manage user logins, authority levels, page and global access levels.
It was likely that at least half of the users of the wiki would not be QUT staff and so the use of QUT LDAP connected authentication system was problematic. It was not feasible nor desirable to provide QUT access accounts to all possible project contributors or even a select number of them. And to require a formal approach of “please request an account and we will issue you one in a couple of days” would reduce the number of people able to engage with the project.
All aspects of the wiki had to facilitate the stages of project engagement
The wiki was seen to be critical method with which to establish virtuous cycles which would lead to it becoming a viable dynamic community. The wiki needed to support the natural stages that people go through when they engage with a community, project or product.
Stage Description
Attraction The Wiki needed to be “infectious”, it needed to support google and other site ranking services to ensure the Wiki has prominence when relevant criteria are searched for. It needed to support short and human readable URLs to its pages unlike content management systems.
Interest Once the site is reach the “seeker” needed to be attracted to stay and explore more.
Desire The Wiki needed to be engaging so the seeker explores more deeply into the structure of the site and develops a strong commitment that the wiki can provide meaningful solutions to the seekers needs.
Action The Wiki needed to encourage the seeker to engage, commit and contribute to the content on the site.
Retention The Wiki needed to be “sticky”. It needed to provide real, social and psychological benefits to return to the wiki often, to participate, contribute and possible integrate into their day to day workflow.
Expansion The Wiki needed to be “infectious”, it needed to encourage and support the existing participants to bring in and engage other researchers and contributors who can enrich the project.
The wiki needed to encourage and facilitate true multi-directional collaboration in a number of ways;
Editing (with version histories) of pages
Comments and threads

Adding of sections, pages, resources and attachments.

Addition of other spaces for other project which may be highly similar or in a related field.
Federation with other projects through RSS and cross linking.

Ease of Use: the thin end of the wedge

I knew from experience that the emotive appeal and the ease of use of the wiki would be critical to the success of the project. The usability of the wiki had to be such that anyone can feel at ease contributing without them thinking they are damaging the system or even worse thinking they have to be html coders. It was essential that the wiki was not technically daunting or block in any way the naïve user from the act of making their first, simple contribution of perhaps making a comment or fixing a typo or correcting a defintion.

With each contribution they make they gain more confidence and might start to explore how to make their posting look as good as some of the other through say bullet points or table formatting.

Addressing the “why nots”

Of course getting any new approach approved is rather interesting and there are the normal question of well, why not just use the corporate website. That was pretty easy to address. The next question, obviously from the IT department was, “well, we already have a content management system, why not use it?”

“Why not use our existing Content Management System”

A competent Wiki will almost certainly include a content management system layer but the users will never see it or be aware of it. I know of no existing CMS that has built in the functionality needed for a wiki. And even if it did chances are that it would be unsuited for tailoring to meet the requirements of a wiki especially that of the ease of use. It is the psychology of the tool that is critical: CMSs are used, configured and controlled by technologists to support their objectives. Wikis on the other hand are tools focussed on the needs of end users and should require even less technical sophistication than using a word processor. It would take an exceptional amount of work to make a cms into a competent wiki.

Getting it accepted into a corporate environment

Approval was obtained to move the prototype I was running at home onto a linux server within the Creative
Industries faculty with a 50 user license from Atlassian. Within a couple of months there were three or four additional spaces on the server for other projects within Creative Industries. The NMP space increased to about 120 pages pretty quickly and the management team started to use it and refer to it.

Word spread, the QUT IT department obtained an enterprise licence of confluence and jira for them to use internally with a view to at some stage rolling it out for teaching and learning.

How are we using the wiki?

The wiki has been in use within QUT now for just over a year and is essentially still in the first generation of usage being fairly straight forward: the site has areas on the project background, objectives, and findings. A resources area includes links to reports and other projects. There are lots of tables and links.

But the real expansion in the usage of the NMP wiki has come from its flexibility and availability to be used for projects that have a high coordination requirement within a relatively short time frame. Putting together tenders and proposals for research consortia has grown the number of spaces on the server to almost 20 with the number of registered users approaching 200. In more traditional uses aside from projects, PhD candidates have established spaces as semi-private blogs that are narratives of their research journey.

We haven’t yet connected the wiki to an external database for more sophisticated reference book management nor has it been integrated with the LDAP server for authentication. But these will happen soon.

The server is managed (when required) by a QUT IT specialist who uploads and configures the server and any updates. No other technical assistance has been sought to date so augmentation has occurred only when the non-technical manager (myself) could find a solution to a pressing need. So the addition of macros and other plug-ins has been relatively slow as there has not been enough free time to evaluate and test them. We have implemented a couple such as the repository plug (amazing!) and the formating plug-ins. Being able to read excel and word files have made it much easier to post content especially formatted spreadsheets directly in a page.

The wiki as eResearch Infrastructure

The second generation of usage we envisage as using confluence as the foundation or infrastructure for delivering a number of eResearch services that are currently too technically challenging for the non-technical researchers or too specific a requirement for a smallish group to be justified supporting.

QUT’s ARC Centre of Excellence for Creative Industries & Innovation is conducting a significant range of research ver the next five years into the nature of creative industries and creative innovation, social networks, the cluster effects and the creation and evolution of participatory media. To conduct meaningful research often requires sophisticated web based systems where the behaviours and responses can be established and observed. But as budgets are tight it is important to be able to share and re-use not just the technical code components but also the processes, and procedures.

One way to achieve this is could be to use confluence as a foundation service and source or develop the other functionality required on top of confluence including new interface metaphors without detracting from its basic wiki appeal.

Research Publications, Reference and Citation Management

University research is changing in many disciplines, including creative industries. Subject matter is getting more and more complex, published material is doubling every X years. Managing your sources, key points, prioritizing and grouping references and citations used to be just hard. But with Multi-discipline teams becoming more the norm; how does a team of researchers communicate, share and efficiently manage their research source material; both original material and that from others, how do they share and preserve a link to the things they think are excellent, insightful or just well phrased and which might be useful, if not this week, next month or even next year. Online services such as, and, and applications such as Adobe Acrobat’s catalog function, EndNote and DevonThink Professional (for you Mac users) can help don’t really get to the heart of a networked, group based research material resource.

The existing electronic holdings within a department of reports such as journals, articles, case studies, books could have their meta data entered into the register either manually or through pulling in references via DOIs, citation links or ISBNs. The NMP project has a relative large holding of some 1000 or so government reports that are not on standard citation systems and these would have to be entered manually.

Why is this important? To facilitate the searching and browsing of relevant research within a domain and most
importantly to aid the researcher community to accrete over time its knowledge and its knowledge of the knowledge.

Researchers within a field would be encouraged to register their own reports into a structure database with a simple forms front end which would include links to the download of electronic copies.

Additional functionality would allow electronic copies of reports that are held on internal repositories to be available online to authorized users . They can access the report and be able to add layers of additional information such document page and paragraph level tags (folksonomy), allow a section or paragraph of the native document such as PDF or word to be marked up for extraction, commented on and automatically resaved onto the server.

Authorized users could then search for the specific tags and harvest the relevant marked-up extracts and their
references, perhaps store them in databases and then collate them into a report with citation management. Ideally this usage is then reflected back into the research archive so that you can keep track of what has been quoted.

The closest I have been able to identify is the [NeuroScholar system |^] which is obviously optimized to the requirements of neurology research. It would be excellent to be able to adapt the NeuroScholar source code which is available under an LGPL, to the more general research document requirements and to put it onto confluence.

Project and Team Management

Confluence currently supports dynamic task lists, but research always requires more sophisticated project planning, team and task management. At the simplest putting a project proposal together with short deadlines requires online project management, task delegation, collation and reporting. And very often this has to happen in the midst of very full calendar.

The NMP project is looking for an online project management service similar to that currently offered by BaseCampHQ but ontop of Confluence to facilitate the establishment and planning of projects and the tracking of tasks, people and resources.

It is possible that Atlassian could be the best organization to provide this by re-skinning a subset of JIRA Atlassian’s bug and feature management tool that is the sister application to the Confluence wiki.

Network Enhancers: People, Organisations and Projects

The ARC Centre of Excellence for Creative Industries & Innovation (CCI) at Queensland University of Technology currently has a number of research projects that require it to either establish forums for the creation and exchange of new and existing digital content or to facilitate the growth of communities of practice such as the networks between small firms and sole practitioners of different creative disciplines who could team up for a short term project.

CCI believes the answer to better understanding (say) the dynamics of Creative Industry clusters may lie in providing a Web 2.0 petri dishes: “networking sandboxes” or a “linkage enhancer” which are combine the functionality of a “growth medium” and also provide a rich source of anonymized or pseudo-anonymized data of the interactions for research analysis. It has proposed the development of a hybrid system built on top of Confluence which is part research infrastructure, part linkage conduit and part team management.

For individuals and companies within a community or discipline members the linkage enhancer would act similarly to or ORKUT with ways to discover and maintain links with people with specific talents, products and projects in a specific domain.

Communication within the community would be facilitated through an escalation of online forums such as the traditional functions of a wiki: newsgroups, blogs, newsletters, chat and email.

Linkages between individuals, the companies and projects they have worked with or worked on would be maintained by using more structured data handled by the system (similarly to LinkedIn and but once a profile has been established, actions provide the data necessary for keeping the profiles up to date.

For firms or individuals wishing to locate a person or company with a specific skill or history of working on a project then this can be discovered through the directories built into the system.

Where the a team is formed either to develop a proposal or to execute a project, the management of the team, the milestones and tasks and the communications within the team would be facilitated by the online system. In this respect the Linkage enhancer would have similar functionality to a lightweight version of groupware.

All the time the system is managing the tracking and reporting of the activities and interactions on a number of levels some anonymous, some pseudo-anonymous and some fully identified according to system, research and user preferences.

In this way the system would update profiles with project and participation details that are suitable for publication to the public, to peers and prospects. Research on the network effects and the growth in interaction activity can be conducted from the wealth of data that would be captured.

The deployment of the Linkage enhancer would be via local industry groups and associations hopefully with the support of local and state government. If as envisaged, the system is truly distributed then those groups wishing to provide a customized and special focus enhancer could do so without reducing the effectiveness of the linkages and network building with other disciplines and regions.

Handling, presenting and commenting on Structured Data

The majority of research requires the development and use of specific term most often terms that are part of structured hierarchical category or classification schemes.

Developing an accurate scheme is critical for segment analysis purposes as:

It is very difficult to capture, store or perform statistical analysis on measurements of things that cannot consistently be described. This enables use.

Measurements of things are only useful to other parties if the other parties know what has been measured and how it has been measured in order to permit these measures to correspond to their own approach. This requires comparable units of measurement for the objects that have been described in common. This enables re-use.

A well-structured category scheme enables the patterns and the relationships buried in diverse and large populations and collection to be seen.

Classification Registries/ commentaries
To fulfill its objects the National Mapping Project has established databases containing the hierarchical records of existing standard classifications for industry of employment, occupation of employment and qualifications. These are all then mapped to an abstract classification spine to allow a more unified view and their consistent use in analytical programs.

It is difficult to communicate these cascades as there are many levels and many dimensions.
Outliners such as those supported by the OPML project allows a pagetree like view of a single classification structure. But confluence does not currently support the display of OPML files from its content plugin so we are currently working to develop such a plug in. Even when this is available it will still be difficult for another research to comment on a specific point in a cascade or to suggest an alternative.

Visualizing the links between different releases of a classification or between different types of classification is difficult using drawing programs and near to impossible any other way currently. Integrating and optimizing the functionality of something like the Hypergraph plugin which uses the GraphXML with an OPML XML or a direct link to a XML based classification registry service could also be an approach.


The experience of the last year in implementing and expanding the use of Confluence has left no doubt to the substantial benefits of a well engineered, enterprise wiki over using a traditional web server approach. Even at its most basic level of implementation and usage, Confluence allows researchers to take direct control of the publishing and communication with their collaborators and community with a minimum of distraction.

The full potential of the wiki approach will begin to be realized when the things that previously required dedicated sophisticated application to achieve can be delivered simply and effectively by adding functionality onto Confluence. Extending the functionality through utilizing common resources, attracting a higher proportion of the interaction from a growing proportion of a research community and facilitating this in a federated seamless manner will generate substantial positive network effects. One mechanism to accelerate the research community’s adoption of Confluence and other advanced wikis would be to establish focused online communities to discuss the usage and possible research specific enhancements. This should also include opt-in listings of those wikis used for research along with case studies of the impact of the wiki on the research.