Mediawiki/orbit/ORBIT3

From Bjoern Hassler's website
Jump to: navigation, search

A bit of reflection on what we'd like to get done in mediawiki. The things we would like to do come in several different flavours:

Some of this work has now taken place, see http://oer.educ.cam.ac.uk/wiki/EWTE and http://oer.educ.cam.ac.uk/wiki/OER:Documentation. Bjoern 17:28, 3 January 2015 (UTC)

1 Concrete goals[edit]

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). During the ORBIT project, we developed a number of features for our mediawiki on an experimental basis, which we now want to develop into proper extensions.

2 Higher priority, assuming that they are doable now[edit]

2.1 Upgrade[edit]

  • Our first goal is to assess the difficulty of this process, and compatibility with the mediawiki upgrade process, as well as to assess impact of our current solutions in terms of performance. Having assessed the options, we would like to improve/(re-)implement the following:
  • The most important thing is to assess our wiki for upgradability. We have had some custom design, and some modification to the skin, and possibly to the code, and we would like to assess whether we can upgrade, and make these solutions more upgrade friendly
~1 day to setup the wiki in a way I can upgrade it more or less automatically
~0.5 day per each update (~ every two monthes)
~1 day should be necessary to migrate the current old version to a cutting edge version (but visual customisations could take longer, depending if we are lucky)
  • We also need some performance testing. I don't think we've got a bad server, but have problems with speed, e.g. when doing edits. It's probably not a wiki issue as such, but we could do with some testing, to make our wiki snappier.
~1 day
~1 day (maybe a browser autodection would be better, this is in addition easier to configure). What is important to notice, is that you will be probably able to re-arrange a few articles.
  • Explore togetherJS.

2.2 Visual editor and Zim[edit]

~ 3 days, assuming we have a more or less workable toolchain and this is not too complicated to get external videos. Really not so easy to guess at this stage of the dev. Would wait.

2.3 Section numbers[edit]

  • Section numbers. When creating longer documents, it is important that each section has a unique number. We would like to be able to prefix the usual page section numbers (1, 2, 3, …) 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). 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.”).
  • If Javascript solution is possible: Related to this, we would like to be able to (optionally) prefix the "session number" (which is arbitrary) to the wiki generated section numbers, so that section numbers don't appear as 1, 2, 3, but as 2.1.1, 2.1.2, 2.1.3
~1 day

2.4 Banners[edit]

  • 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. http://oer.educ.cam.ac.uk/wiki/ORBIT, and http://oer.educ.cam.ac.uk/wiki/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. We have an existing mechanism for this, but it uses the 'site notice’, so we cannot have site notices, and it relies on an actual source code modification, which makes it difficult for us to upgrade.
  • If javascript solution is possible: On our wiki, different "projects" have different page headers, i.e. different boxes that show the project name. The have to come above the page title. Compare e.g. http://orbit.educ.cam.ac.uk/wiki/ORBIT, http://orbit.educ.cam.ac.uk/wiki/OER4Schools. This is really important for branding: Different projects needs to ahve their own identity. We have a mechanism for this (and we paid somebody to do this), bu it uses the 'site notice' at the moment, so we can't have site notices. (We don't need this to come through in the API, as we can adjust the html generate there.)
~ 1 day

2.5 Navigation between pages[edit]

Scope: Assess our implementation of this, and optimise it if possible (1 day)

2.6 Searching[edit]

  • 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.
  • We need to have a more user friendly way of searching. We did some user testing, and the wiki search came up as something that users found a bit confusing. I know there's a lucene extension as well. We just don't have the time to put this in and experiment.
~2 days


2.7 pdf[edit]

Advice on:

  • 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.
  • Customise buttons in editor, e.g. to include strike through, some boxes, and include, noinclude - if this is still needed given the visual editor development
~1-2 day for a few easy features, but this really depends of what you want to do with this buttons.

2.8 Collaboration[edit]

  • Collaborative options. We would also like to explore options for real-time collaboration, such as the
    • collaborative editor or
    • togetherJS.

Scope: Explore the above features, and decide whether to use them or not. (1 day)

3 We would like to try this when they come out of beta[edit]

Things that are in beta or coming soon, where we would like to be moving with releases as quickly as possible, such as

  • the visual editor
~ 0.5 day
  • better pdf output (with parsoid I guess), that allows us to use e.g. to display some sort of boxes (in HTML). We just need to be able to mark some text as 'special' in some way (e.g. some background info, or an "educator note"). With the pediapress book extension, that just wasn't possible.
~ 1 day, but still not available for now.
  • We would also like to explore conversion of html5 to wiki text, to have a better way of importing documents into the wiki (where we generate html e.g. from word docs; the OO wikitext export has too many issues)
This is a lot of work.

4 Lower priority[edit]

  • the collaborative editor when it comes out - that's not so urgent for us, but when it happens
Sorry I don't get the idea:(
THere's an etherpad / google docs style editor for wikipedia in the making, allowing concurrent edits. But it's further off than the visual editor!

5 Things for which we have solutions already[edit]

We would probably want to spend a little bit of time discussing what we are doing. But these are low priority, because we have workable solutions already.

  • Export to static html. But e.g. the DumpHtml extension seems to be unsupported at the moment. Plus we'd need something we can run incrementally. And we really need something that works reliably, and gives good quality output. I have developed something (that uses the API), but it needs a bit further work. Overall, it's not that hard, but we just need to pull a few things together. (We need static html, so that we can give people offline versions, which is essential for Africa. Once we have static html, we can then also render to ebook and ZIM, which is also important, and which we would like to integrate into our workflow.) I have working demonstrators for this, that I can show you (and that are linked from my recent blog posts). But we don't have anything reliable. (C.f. also Mediawiki mirror. We also want to put this html onto memory sticks, so need to have a version that's not case sensitive, i.e. will work on FAT32.)
  • Let's look at the book extension, which allows the definition of books, for print. It allows you so structure a book, i.e. bing together a set of pages in a certain order. We would like something like this for the wiki itself. E.g. look at at our OER4Schools resource, here: http://orbit.educ.cam.ac.uk/wiki/OER4Schools/Introduction_to_whole_class_dialogue_and_effective_questioning
    • The page is just a wiki page, at best a sub-page of OER4Schools. However, in our programme, it's session 2.1. The side menu shows where it fits, plus a "next session" / "previous session" button. It does what we want - but it's all written in semantic wiki stuff. We would really like somebody with a bit more skill to tidy this up (and make it efficient), so that other people can use it for putting their own programmes onto the wiki.
  • We've also experimented with the ORBIT skin so that the 'edit' (etc) tabs are in a different position, so make more space for the page header. It's not really ideal, and needs more work (we also didn't know where to put the search box, so that needs addressing). We would probably also want to revisit the css that we used for our site design. We like the design, but some modifications to the vector skin were necessary, which is difficult in terms of our upgrade path. It would be good to see what we can just do with css, and share those instructions with the community.
  • It would also be great to have the left menu more dynamic. One of the reasons we have the big right menu (e.g. on http://orbit.educ.cam.ac.uk/wiki/OER4Schools) is because the left menu cannot be dynamic.
  • Hiding 'edit tabs' for users who are not logged in. We are hiding 'edit tabs' for users who are not logged in. There's still a "Log in" box, but for the person using our site occasionally, this makes the site look a lot cleaner. We felt this was needed to make the site look as professional as possible. We have got a mechanism for this, but would like to future proof it.

6 Links to similar discussion on this wiki[edit]

The blog posts are recent, but much of the other stuff goes back a bit - but the issues are still the same!