It fascinates me how fast the internet and everything related to it moves. The speed of change is the main factor in why I've pushed for Offline Moodle to be developed and organised the way it has been. In this post I want to talk about the need for Offline Moodle, hopefully I can keep it brief, and encourage discussion on the points I raise. I'm certainly not saying I can read the future and I'm totally open for the idea that I've misunderstood or misread something. I just find it interesting to plan ahead and see if you can be even half right.
So what am I babbling on about?
Well basically many people say that Offline Moodle is going to be obsolete in a short amount of time. They point to the spread of wifi and broadband across the world and the advancing technology that is bridging the previous gaps in supply to remote regions etc. We can also see that mobile devices are really quickly gaining ground on their fixed counterparts and becoming more and more web enabled.
So everyone tells me that within a few years Offline Moodle will be a moot point.
Fair enough I say, I can't argue with all that because it's true. As far as I understand it, while the UK is lagging behind in mobile broadband for various reasons, plenty of other countries are streaming ahead and making sure there is a wifi connection just about everywhere in just a few years time.
The thing is I think this is making Offline Moodle more important not less, and here's why.
At this point the internet as far as I can tell is working much like mainframes used to with big expensive main servers supporting dumb terminals. The web servers and database backends are generally pretty powerful compared to their web browser terminals. That status quo lasted I think for around 20-30 years. My history isn't that great on this point so maybe I'm out by quite a bit. What I do know is that since the introduction of the PC with it's developing power and enhanced features compared to the dumb terminal all we've seen is a massive growth in what is generally done on the client. right now even though networks have improved greatly, few applications run entirely in the mainframe. Most now share much of the processing between the mainframe and the client and some do it entirely on the client.
I can only see that this trend will continue on the web and in fact I see that we're already preparing for this. AJAX and it's ilk started the trend. Google is a prime example of taking this further with their Google Gears technology which now makes the Google Docs suite available offline. It's a no brainer that they've targeted the Web Browser to act just like the OS does for desktop apps and I can imagine other players will join the fray with similar solutions.
So the main overriding reason for needing an Offline Moodle is that as internet technology progresses it's expected that more and more of the 'work' will be done by the client with the web server in the background integrating the work from the client back into the whole.
There are other important reasons for having Offline Moodle since there are groups that will not have unrestricted internet access for many years if ever, these include soldiers, prisoners and other groups working in places where good unrestricted internet connections aren't so easy to come by like those people working on oil rigs or at the bottom of the ocean.
But the hey day of Offline Moodle will, I believe, start once web browsers begin to take on more of the load of delivering the application.
So when it comes to Offline Moodle I see that pretty soon people are going to tire of slow connections and pages loads. They're going to expect much faster and responsive pages that do much more. There is much that can be done from the server and Moodle is working to improve it's load times etc but it won't be enough. More will have to be done on the client.
So why didn't we just implement a Google Gears plugin or something?
A bunch of reasons really, although it would be a fantastic idea. The main reason is that I certainly can't predict which solution is going to take off. All I can see is that it's getting closer and closer to being a reality. some of the reasons were not wanting to dictate to the Moodle technology which technolgoy (Gear, Adobe Air etc) should be used and how it should be done but, to be honest the main reason is that Moodle (along with most apps) wasn't quite ready to support it yet in my view.
I see it as simply a web service that's required no matter which way you look at it. Whether you implement a traditional web service or another approach you're really just trying to hav ea main server on the web and an app that runs on the browser and they need to talk, share and work together happily. This means you need a standard suite of tools to make this happen.
- Communication: A secure and reliable way of talking to each other
- Data sharing: a standard way to get data and files in and out
- Error handling: Things will go wrong so take care of the users and their data
I don't like reinventing the wheel so the first thing to do was look at what was already in place.
For communication we could just use curl but that's inheerently insecure. We're using that for getting the incremental backups off the ground but we need a layer of security and an xml rpc or soap type layer in place to save hassle. Thankfully Moodle Network can provide this. It's young but in time should provide what we need.
Data Sharing was always the big challenge. It would be a big task to write our own solution and backups were already in place and did most of what we needed. The only thing is that offline solutions will put pressure on the networks they use and transporting large files is not a good idea. So we needed to break the files down into smaller chunks. Incremental downloads is part of the solution and is being developed right now. We also want to cherry pick which items should be transferred so the others can be left on the server until required.
Error handling will be addressed as the project goes along. Right now we're just using off the shelf components so that we don't introduce errors due to changes and for ease of upgrade to ensure each component is the latest stable build.
Rather than write our own client app and then have a new codebase to maintain I thought let's just package up Moodle so that we don't actually have any maintenance issues in this regard. All we have to do is keep up with the latest version of Moodle and then over lay the minimal Offline enabled code we have on to it. We then package it into a web server and database environment and create an installer (wndows and mac) or an install process (linux) and away we go.
The reason for this in some ways clunky approach. Flexibility. In my experience if you try to hit a moving target then you better have lots of ammo and the ability to move to where you can take the best aim. The approach we're using has the ability to adapt to most situations I can think of and basically run from anywhere that moodle can run. The enhancements we're making are aimed at improving Moodle first and then making an Offline version of Moodle possible. So the incremental backup work has firmed up the backup process making it more reliable and easy to develop and fix but also added new functionality useful to all administrators not just those using Offline solutions.
My hope is that now we have a better way of getting data from a to b it'll be easier to develop what ever solution is necessary for offline work. Because backup and restore is implemented for all modules, early signs are that it should thus be possible to make offline capabilities available for all of them.
Is the answer Google Gears?
It would be great if it could be, given the weight and experience Google can throw behind it. I was thinking about it over the weekend and the main problem I see at the moment, hopefully there's a way around it, is that there's now way to get files from the web server to the browser. Getting data there is not a problem that's what it's designed to do. What about Google docs you ask, yeah well as far as I understand they're virtual documents stored in a database. You can download them but they have to be translated to physical files first. Therefore since they're just data they can happily be stored in Google Gears. Right now though we have no way of making pdfs, microsoft office documents, mp3s etc into data rather than files and storing them in a way that won't crash your web browser.
thinking about it that's not necessarily the biggest problem in the world. maybe you just say that you can only access files when you're online and the rest is available when you're offline.
I just think that now we're in a better position we can think about these issues knowing we now have solutions and can put something real in place.
Update: 19th September 2008
I just found n article abut
google gears one year on. I thought it might be an interesting reference. Particularly their approach to standards. If gears does adopt standards such as html 5 sooner than the browsers it's installed in then it would certainly make adopting these standards much easier and help all web apps improve quickly. Let's hope it is true.
I've also just come across an article which covers some of the
fantastic results for the OLPC project as useful background.
Update 2nd February 2009
I really like Google Gears, especially now that I've been using it in Google Docs among other things for a while now. There are also those trying to package a web server, database and gears solution.
Mozilla Prism is one example. I've also learnt that similar technology may become part of the
html five specification. is So soon we may no longer have to bundle a web server and db to provide offline apps. Fantastic!!
OK then, what do we need to do to take advantage. That's something I've been thinking about for a while. For me it's about adopting programming standards and approaches that both make mobile and offline applications possible but also improve the reliability and performance of Moodle core aswell.
Therefore I’d just recommend we work closely with Moodle to make it easier for the client side code to interact with the page. By this I mean the pages delivered by Moodle are difficult to manipulate to the degree that you’d like if you were developing a rich internet application. It’s also difficult to ask specific questions of the system so you can then display them on the page. Again it’s not so easy to just ask simple questions like ‘get me the posts for this forum that this user can see’ or ‘what are the latest news articles for this course’.
Currently in Moodle you can ask the question but the answer you get is written as html for a page. It isn’t something you can then combine with other information and manipulate easily. An analogy I’d use is that you ask a question. You just want a straight answer, one sentence. What you get is a lot of info you don’t need about how to present your answer. All this is several paragraphs long. Not only did it take long to write but it fills up your inbox because it’s sent as an image that’s 10mb. So you can’t copy and paste the answer, you have to load up the image and re type the answer. Basically things like asking and answering questions of Moodle need to be efficient in any Gears type approach, be aware of the limited network bandwidth available. You also need to be able to use the info for what you want not what Moodle has designed it for.
Developments focused on addressing these needs will prove very beneficial when you try to increase Gears use because you basically need to be able to ask the server lots of questions and get lots of info back in a short time. Then you need the power to manipulate the page to show the answer to the user. You also need the ability to do the reverse and get Moodle to store info etc. So making this easy within Moodle is a task that needs to be addressed whether it’s offline or mobile moodle we’re talking about.
Don't think this work will only benefit Offline/Mobile Moodle. Work like this will benefit the whole of Moodle making it more responsive, easier to develop and more robust.
I believe the Moodle 2.0 release will go some way towards this goal however I haven't seen the code and don't know in practice how far it will have come. I do know that what I'm suggesting is really about constant maintenance much like keeping a room or house clean. You just need to keep on top of it.
So in summary, I would begin use of gears and develop the knowledge within the community of its use and how to develop with it. I would also address issues within Moodle that will present themselves as Gears use (or any other similar solution) scales up.
edit 20100326
I've been receiving requests for the latest version of the Offline Moodle installer. It's 56mb so too large to email and I'd rather people just had access to it rather than having to ask. So I thought I'd go ahead and put it up on my gdocs account as
Offline Moodle v0.4 Setup.exe. Follow the link, click download (56mb), and then Download anyway. Aplogies for taking so long to post this. the main reason is down to competing priorities. We love offline moodle but it's not the only project we love so I've been pulled onto other things since. Before releasing I wanted to review the installer to make sure it was ready for release. I didn't get time to do that so I didn't feel condfident releasing. Yep, I'm paranoid, I test everything, and then sometimes even test again.
Anyway I've sent the file to several people who requested it and never had any complaints so I assume it must work well. I've also been using it regularly as a one click moodle installer and php environment and I haven't found any problems with it. So now you have access to it. The code is 2 years old. If you'd prefer a more up to date version, or would like to customise it I've explained
how to create an offline moodle so you can create your own.
In terms of using it we've tried to make it self explanatory. Please comment here if you have any specific questions. Also be aware there are refinements we wanted to make but didn't get time. A lot of the ideas are about making installing and starting it up easier. Currently it's not as seamless as we'd like.
In terms of getting courses in and actually using it we used the Moodle backup process. We haven't put synchronisation into this version. We've kept things simple. What you get is a pre installed moodle that's ready to run. All you need to do is add courses to it by restoring courses to it or creating them yourself within Offline Moodle.
It's built to be run from a usb or other detachable media aswell as running direct from your hard drive. YOu can literally plug it in to any windows based device and run it as normal. The only thing you have to do each time you move it is click an option to tell moodle where it's installed. Again, we'd like this automated. We don't want students to be worrying about these technicalities. We just didn't get time to address this.
I'm looking forward to hearing how you guys get on with this. I hope it's helpful. Let us know what uses you find for it.