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:
- 1 Things that are possible now, but we don't have the time to implement without further assistance
- 2 Things that are in beta or coming soon
- 3 Things that are possibly a bit outside the current development trajectory.
- 4 Further out: Import / Export
- 5 Links to similar discussion on this wiki
1 Things that are possible now, but we don't have the time to implement without further assistance
Things that are possible now, but we don't have the time or staff to implement right now, but would really like to have, such as
- use of the mobile version http://m.something.
- 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.
- We probably 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.
- Customise buttons in editor, e.g. to include strike through, some boxes, and include, noinclude.
2 Things that are in beta or coming soon
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
- 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.
- the collaborative editor when it comes out - that's not so urgent for us, but when it happens
The above features would really help us get acceptance for our mediawiki-based approach in academia, so they are important to us, and to promoting the platform at the University of Cambridge.
3 Things that are possibly a bit outside the current development trajectory.
The background to this is that we are trying to use mediawiki to host our OERs. There's lots of reasons why we think that makes sense, and I think mediawiki could also be used for open textbooks. But, we do need a few things to get the usability right, and without these, we'll never get full acceptance for our educational applications. Some of these would be:
3.1 Export to static html.
Maybe this should have come under (1), and I know that there are solutions out there. 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.)
3.2 Sets of pages with logical order
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.
3.3 Prefix section numbers with something
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
3.4 Custom page headers and appearance
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.
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. Plus it's not returned in the html produced by the API. So we'd like to have a better way of doing this.
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.
3.6 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.
4 Further out: Import / Export
There are a few other things that would interesting to do. One is the idea of export/import between different wikis. In principle this is possible, but there's a sort of 'namespace' issue. For sake of argument, I may want to export a bunch of pages (called "1","2","3") from (say) the "cycling wiki", to the (say) "transport wiki", where they need to be called cycling/1, cycling/2, cycling/3. More over, images from the cycling wiki used by those pages would also need to be moved (and renaming them so that they don't clash with what's already on the transport wiki). Another use case would be to migrate the whole cycling wiki to a subsection of the transport wiki. This may sound a bit specialised, but actually, we've had to do it a few times. And it fits with our ideas of "technical freedom" of OERs. (C.f. MWM.)
There's also a case for some commandline tools for mediawiki (c.f. Offline mediawiki, mvs). Sometimes you just need to make some bulk edits, e.g. fixing spelling. I have experimented with the mediawiki emacs mode, various APIs, and made various scripts. It would be nice to have a more coherent solution here. The stuff I have works for me, but it's not very portable. Also the mediawiki emacs mode does mess up pages in certain circumstances.
The wiki export in OpenOffice is not that great. Plus it never handled images. A simple way of getting OO/word documents onto the wiki would be great. Of course, not something that handles all possible formatting tricks, but something that just gets the basics right. (It may be possible that this becomes obsolete by parsoid. Discuss...)
5 Links to similar discussion on this wiki
The blog posts are recent, but much of the other stuff goes back a bit - but the issues are still the same!