Dear Bjoern and Savithri, This is a challenge close to the hearts of all WikiEducators and We've been thinking hard about how to move this forward.
At least at a technical level -- this is solvable, but its quite complicated and will certainly need a fair bit of funding to get this right. Optimising the CSS for use on low bandwidth would be relatively easy to solve -- and in fact this may already be the case. When logged in - any user can change their preference settings to use different skins. I've not researched this, but it shouldn't be too hard to optimise one of the existing skins for low bandwidth browsing. Lets hope that there are some CSS gurus in our community that might want to give this a try. Perhaps you know of someone who has this technical knowledge -- see if you can encourage them to help out <smile>. Wiki's are unique in the sense that they are dynamic. Literally every second someone around the world could be editing something. So this makes replication a little more difficult. For example, if we have a local installation of WikiEducator in Uganda -- how will the Uganda WikiEducator synchronise with edits around the world. Benjamin Mako Hill of the Free Software Foundation has developed a promising proof-of-concept for history sensitive branching and synchronisation of wikis: http://wikimania2007.wikimedia.org/wiki/Proceedings:BMH1 So at least from a proof of concept perspective -- this would be doable. However, is not a trival exercise and would need considerable funding to get this operation. That said, it would be a huge advance for the free knowledge community in widening access to knowledge. Perhaps we should collaborate on a funding proposal to secure the funding to get this work done. I'm pretty sure that the Wikimedia Foundation would also be very interested in solving this challenge. Cheers Wayne On Thu, 2008-06-05 at 06:28 -0700, Bjoern wrote: > Dear all, > > first post to the list - hello to you all. > > This is a post partially in reply to Wayne Mactintosh's presentation > http://www.wikieducator.org/Wayne_Mackintosh’s_Presentation#.283:25.29_The_Big_Issue_for_Africa_.E2.80.93_How_do_you_get_Access.3F > regarding access for Africa, and your comments on "Are all Open > Educational Resources Equally Free?". > > The issues raised are very important, and I would like to make some > practical suggestions. In my view, issues like web disability access > are quite well understood, with relevant standards etc. However, low > bandwidth access really hasn't come into the mainstream yet, and > remains poorly understood. > > A good example for guidelines and recommendations are Aptivate's low > bandwidth web-design guidelines, which are available here: > http://www.aptivate.org/webguidelines/Home.html > > If you look at the top ten tips, you'll see that a maximum page size > of 25kB is recommended. Wikieducator is currently about 150KB, and > would take about one minute to load for typical user in a developing > world university. > > Quite a bit of this is due to the css and javascript of the MonoBook > skin (which is used by most mediawikis). So there's a real opportunity > here to have an impact by optimising the MonoBook skin. Perhaps even > modifying the mediawiki code, so that the javascript is only loaded > when needed. > > Unfortunately I don't have resources available to just get on with > this, but perhaps this could somehow be addressed in a community way? > > A second (more involved) area of interest is 'wiki replication', i.e. > to create a fully functional replicas (say of Wikieducator) within > local area networks. This would be a full copy of Wikieducator, that > can be read and edited on the local area network (of a university in > the south), i.e. without international bandwidth constraints. The > various 'replica' then synchronise themselves as and when permitted by > the international connection. Of course the goal would be a fully > functional copy, that allows both read/write and resolution of > conflicts etc. > > This is of course not a new idea, and it's also a complicated problem. > However, it is very relevant for low-bandwidth access, and perhaps one > could come up with some initial pragmatic solutions, that have less > than the full functionality. For instance, one could replicate the > content 'read-only', while 'edits' still take place on the main wiki, > but in a bandwidth optimised way (perhaps also with traffic shaping, > so that bandwidth is available for this). This could give many > institutions instant access to Wikieducator and Wikipedia. (In fact, > Wikipedia of course has a distributed system of servers.) > > Of course one would start with a pilot project, to see whether those > ideas really address some of the issues at hand. But if it works, it > won't just make Northern content more accessible, but it could really > make Southern content more visible, and also enable South-South > content sharing much more viable. > > I wonder whether there is critical mass to build a consortium around > some of those ideas, and to see what's needed to make this happen. > > Looking forward to your feedback! > Bjoern > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "WikiEducator" group. To visit wikieducator: http://www.wikieducator.org To visit the discussion forum: http://groups.google.com/group/wikieducator To post to this group, send email to wikieducator@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] -~----------~----~----~----~------~----~------~--~---
