General considerations - Mirroring - file size extension - email interface - W:Mediawiki OER export - [Edit]
Contents |
This set of pages is a collection on "mediawiki accessibility". They are mostly my own experiments, and stem from a general interest in low-bandwidth accessibility (c.f. e.g. Web Design 4 Low Bandwidth). So "accessibility" here isn't used in the general sense of the definition, c.f. wikipedia:
Accessibility is a general term used to describe the degree to which a product (e.g., device, service, environment) is accessible by as many people as possible. Accessibility can be viewed as the "ability to access" the functionality, and possible benefit, of some system or entity. Accessibility is often used to focus on people with disabilities and their right of access to entities, often through use of assistive technology.
Instead, it is used in the more specific meaning in the context of the "digital divide".
The main issues with mediawiki (and sites using mediawiki, like Wikipedia and wikieducator) are
Some of these issues are harder to solve than others. But they are all solvable, and would contribute to making great existing wiki content much more widely available.
The available mediawiki skins (including the default wikipedia skin) do not meet low bandwidht recommendations for page size (about 25k-75k per page).
For a (proof-of-concept) example for an optimised skin, see Mediawiki access/Monobmo, and Mediawiki access/Monobmo/nocss.
Also, skin selection: Mediawiki access/SkinSelection, Mediawiki access/SkinSelection/monomix.
For further info about mediawiki on mobile: Mediawiki access/Mobile (both as application, web app, and mobile friendly skin)
Skin considerations for mobile: Mediawiki access/Mobile/Skin.
Also, skin selection: Mediawiki access/SkinSelection, Mediawiki access/SkinSelection/monomix.
Often, we need to move contents of a wiki around. Strategies are described here: MWM. But this is all 'by request' (i.e. not dynamic as and when needed), and it's only 'unidirectional', i.e. the resulting copy cannot be edited without causing branching from the source.
A better system: For instance, we could consider a system where the mediawiki web front end can be devolved from the server. (I.e. the web front end just using the API onto the storage layer.) This means you could then install a rich front end anywhere, and still interact with the wiki. C.f. Mediawiki_mirror for a read-only (basic!) implementation. What would be even better is if on submit (and also on read) only the differences were transferred. (Maybe together with a page hash for safety, with an option to merge changes where this can be done without conflict.) That would make the whole operation very low bandwidth. (C.f. also Talk:Mediawiki access.)
See Mediawiki_mirror, MWM, mvs
A related issue is having an 'individual mirror', i.e. a 'mirror' or a copy of the wiki, that sits on your laptop, and is used by only one person.
C.f. Offline mediawiki for some comments, and mvs for a workable, cvs like system, as well MWEclipse.
Also see Mediawiki access/Mobile for using mediawiki on mobile (including as stand-along app, which effectively is a 'personal offline mirror').
Should all be selectable for anonymous users, c.f. e.g. Mediawiki access/SkinSelection.
c.f. also http://usability.wikimedia.org/wiki/Main_Page .