EWTE

This page describes the outcomes and objectives of a short project funded by the Wikimedia Foundation UK (during the second half of 2014), see https://wikimedia.org.uk/wiki/Wiki-based_teacher_education_and_resource_development.

Objective

Mediawiki is already used to host Open Educational Resources (OER), such as Wikipedia (which is possibly the most widely used OER overall). However, the use of mediawiki to develop and host more complex resources, particularly for structured resources (such as textbooks) is still limited. Mediawiki could be a suitable platform for collaboratively producing and hosting teacher education resources, including a potential platform for open textbooks (whether these are teacher education resources or otherwise). However, our previous research around the ORBIT project has highlighted some of the obstacles to this. Through work undertaken as part of the EWTE project, aimed to further develop our mediawiki practices to make it a more suitable platform for hosting structured open educational content. There could bring potentially very significant gains to the OER community, and possibly leads to a far greater adoption of mediawiki in that area.

Mediawiki and Open Educational Resources

Three freedoms.

Content organisation. One of the areas where we experienced difficulties were in the area of content origanisation. Wikipedia's "unit of content" are encyclopaedia articles. These articles have relations with each other, but they do not form "linear sequences". Other other types of educational materials, such as books, manuals, courses (including professional development courses) have a linear order. Typically such content would be organised as a set of pages, with appropriate navigation between pages. Other than doing this manually, by default, mediawiki does not provide such facilities. However, as part of this project, we developed a number of options to better structure content (see below).

Access. Mediawiki is a strong platform in terms of providing multiple ways of accessing content, including PDF, mobile, and ZIM.

The concrete goal of the project is to develop a number of extensions to mediawiki, that will significantly enhance the usability of the platform for creating teaching and learning materials in Higher Education, and particularly for teacher education. We expect the outcomes of this project to be immediately applicable to other wikimedia sites (including wikibooks).

Overarching outcomes. Through our proposal the wiki movement would gain ground in formal Higher Education, particularly in the area of teacher education, and for the use of mediawiki to produce professional open wikibooks. We feel very strongly about the benefits of collaborative teacher resource development, and this projects helps us to take this message out to other departments in the UK. The outcomes will have an impact in a variety of educational contents, both in the UK, and internationally.

Concrete outcomes. The overall specific outcomes of this project are:

1. Greater engagement of University of Cambridge staff and students with mediawiki, particularly within teacher education. This is measured through additional (University or Faculty) projects adopting our existing mediawiki site to host their resources (such as a teacher development programme for Raspberry Pi.
2. Greater engagement of UK and international Higher Education staff and students with mediawiki, measured through increased use of discussion on facebook and twitter.

In accordance with the goals, the specific technical deliverables are as follows:

• Section numbers. A mediawiki extension that allows section numbers to be prefixed with strings, together with documentations. Implementation of this extension on our wiki.
• Project specific page banners. A mediawiki extension that the adding of project specific banners to wiki pages, in order to be able to mark a set of pages as belonging to the same project or set of pages.
• Wiki navigation between pages. If feasible, and extension that allows better navigation between individual pages in a collection. Otherwise a briefing document on our implementation (together with mediawiki Templates) allowing our approach to be replicated more easily.
• Better searching. A briefing document on the more advanced search options within mediawiki, aimed at the Higher Education sector. An implementation of these search options on our wiki.
• Assessment of pdf generation. A briefing document on mediawiki to pdf workflow options, aimed at the Higher Education sector.
• Collaborative options. A briefing document on real-time collaboration on mediawiki, aimed at the Higher Education sector.

Content organisation

During the ORBIT project, we developed a number of features for our mediawiki on an experimental basis, which as part of EWTE, we developed into proper extensions, with documentation. These include:

Section numbers.

When creating longer documents, it is important that each section has a unique number. In educational materials, sections usually have a number, that uniquely identifies it. In mediawiki, section numbers within pages are just numbered incrementally (1, 2, 3, ...). Ideally the usual page section numbers (1, 2, 3, …) would be prefixed with a chapter number (say “5”, to give 5.1, 5.2, 5.3, …; or say “A”, to give A.1, A.2, A.3). This stems also from our experience with OER4Schools, where the use of our longer documents (sometimes numbering 100s of printed pages) has been confusing during e.g. during workshops because of the lack of unique section numbers across several pages. (“Let’s look at chapter 5, section 3.” - “No, not this section 3, go to chapter 5 first, then section 3.” vs. “Let’s look at section 5.3.”).

We developed a simple mediawiki template that allows existing section numbers to be prefixed with strings (together with the CSS extension). To use the template on this wiki, see basic documentation provided here Template:SectionHeadingPrefix. In brief, e.g. {{SectionHeadingPrefix|A.}} a section called

• 1.1. Section title

appears as

• A.1.1. Section title

For details about how to install this on other wikis, see OER:Documentation.

Project specific page banners.

On our wiki, different "projects" have different “page banners”, i.e. a section at the top of the page that identifies the project. Compare e.g. ORBIT, and OER4Schools. In order for projects to choose to place their outputs on a departmental site (let along a University wide, or wikibooks), they need to have their own identity within that site. Otherwise it is simply not acceptable to project stake holders. Compare e.g. ORBIT and OER4Schools with a page on wikibooks, e.g. [[1]]: On ORBIT / OER4Schools the page banner appears above the page title, while on [[2]] the page title appears at the top, with the book title effectively appearing below the page title.

For the ORBIT project, a mechanism was developed to achieve this, but it used the 'site notice’, so it was not possible to have site notices. Moreover, the implementation require modification of the actual source code modification, which made it difficult for us to upgrade our wiki installation. Part of EWTE, the implementation was adapted, to no longer affect the site notice, and to work as an extension, with out the need to modify the source code.

On this wiki, you can use

<topcontent>
Page header content
</topcontent>

Typically, this is used using a template, see e.g. Template:EWTE, so that the same page header content can be placed on all pages belonging to a project.

To use <topcontent> on another wiki, see OER:Documentation/customextensions for installation instructions.

Wiki navigation between pages.

As detailed above, it is important to be able to group pages into sequences. Compare OER4Schools or DEFT with a page on wikibooks, e.g. [[3]]: The wikibooks page creates the navigation manually:

{{navigation|Book=Primary Mathematics
|current=Working with fractions
|previous=Fractions
|next=Decimals}}

which during our project work on ORBIT and OER4Schools we have found very hard to maintain. E.g. the insertion of a new page (or the renaming of an existing page) requires the bordering pages to be updated. Moreover, a list of all pages needs to be maintained separately.

We currently have two mechanisms for this, one which uses the collection extension, and the other one uses semantic mediawiki.

Using the collection extension for navigation

A simple solution is to use the book creator extension to produce a book, and then to use the saved book page as a template for navigation, see EWTE/booknav. Advantages are:

• This method is quite simple to use, and builds on using the book creator. Users can use the interface provided by the book creator to create their collections.
• It also means that books cannot just be viewed (as a set of wiki pages), but also exported, using the mechanisms provided by the book creator. The pages are thus grouped on the wiki, and can be exported as such.

However, there are a number of disadvantages:

• Adding a page to a set of pages requires the book definition to be updated.
• While it's easy to edit the book (and thereby the navigation), and this may already be familiar to users, every time the book is saved the <noinclude> statements need to be added again to the book definition, for the navigation to stay properly formatted.
• The page itself does not 'know' that it's part of the book, and can 'behave' accordingly, e.g. it's not possible to add "previous" and "next" navigation to pages.

Using semantic mediawiki

We currently have a mechanism (relying on the semantic extension) that allows several wiki pages to be grouped into a collection, displaying a navigation menu on each page, see e.g. OER4Schools. As part of this project, we have documented our work, allowing the replication of this on another wiki, see EWTE/nav for an example, and Category:PageGroupTemplate for documentation. The advantages of this approach are:

• Flexible creation of navigation, as simple as adding a generic template (Template:BasePageGroupNav) to each in a set of pages (and sub-pages) to create navigation.
• The page itself 'knows' that it's part of the book (and where it is in the book), and can 'behave' accordingly, e.g. allowing for 'previous' and 'next' links.

The disadvantages of this approach are:

• It does require a number of extensions to be installed (semantic mediawiki, as well as functions for arrays).
• It does not integrate with the book extension, when in principle the functionality is similar.

For more information, see OER:Documentation.

General usability

• Better searching. We did some user testing, and the wiki search came up as something that users found confusing, and not really useful for finding the content they were looking for. We currently use a Google custom search, but the integration into the wiki is not ideal. We would like to explore options for searching that allows our audience to find relevant content more easily.
• Collaborative options. We would also like to explore options for real-time collaboration, such as the collaborative editor or togetherJS.
• Visual editor

Better searching.

We did some user testing, and the wiki search came up as something that users found confusing, and not really useful for finding the content they were looking for. We currently use a Google custom search, but the integration into the wiki is not ideal. We would like to explore options for searching that allows our audience to find relevant content more easily.

How did we do this? → See LocalSettings.custom.php and “../custom/extensions” directory.

The Mediawiki search future is customized. It display the results of the standard search engine conbined with the results of Google. This is done using the "GoogleSiteSearch" extension. See the file LocalSettings.custom.php to see how it's configured.

A briefing document on the more advanced search options within mediawiki, aimed at the Higher Education sector. An implementation of these search options on our wiki.

Visual editor

The visual editor is now working as part of the installation.

Collaborative options.

A briefing document on real-time collaboration on mediawiki, aimed at the Higher Education sector.

Access

Assessment of pdf generation.

Assessment of pdf generation. We currently generate our own multi-chapter pdf (using a set of scripts), as we have not found the pediapress pdf generation suitable for our type of content. We would like to explore what other pdf production tool are being worked on, and would like to feed Higher Education requirements into that process.

A briefing document on mediawiki to pdf workflow options, aimed at the Higher Education sector.

• Assessment of pdf generation. We currently generate our own multi-chapter pdf (using a set of scripts), as we have not found the pediapress pdf generation suitable for our type of content. We would like to explore what other pdf production tool are being worked on, and would like to feed Higher Education requirements into that process.

Offline

• ZIM

Mobile

• Mobile

m.educ

Additional

MLEB

Setting up a mediawiki

See OER:Documentation for some hints on how to set up the wiki.

Issues remaining

• PDF toolchain does not always work
• ZIM generation has issues e.g. due to parsoid.
• Navigation could do with better integration between book extension and semantic.
• Video integration, e.g. hosting videos on "commons".
• A new issue: Uploads. We've struggled with upload in the past, e.g. ".ppt", and ".notebook" files.
• It would also be good to explore possible integration of the site e.g.

Links to similar discussion on this wiki

• OER:Documentation
• ORBIT/Development
• http://www.sciencemedianetwork.org/wiki/Mediawiki/orbit/ORBIT3