e-Literate

Present is Prologue

Author: Michael Feldstein

  • Moodle Mobile vs. Blackboard Mobile Learn: Web App vs. Native

    I was incorrect when I wrote that Moodle Mobile would have an Android-native client. Carlos Kiyan, a member of the Moodle Mobile team, clarified for me over Twitter that Moodle Mobile is a web app which has, for the moment, focused on WebKit-based browsers. (Both the iPhone and Android have default browsers that are WebKit-based.) Sorry for missing that; I should have looked at those videos more closely. Meanwhile, Kayvon Beykpour of the Blackboard Mobile Learn team has written a blog post that talks about their decision to go with native clients.

    As you might expect, each team thinks their approach is better. The Moodle Mobile team thinks that the web-based approach is more portable and will allow them to reach more smart phones. They think that the main gap between web-based and native apps is working offline, and they have developed offline caching for their app using a third-party product. (HTML 5, which both Google and Apple are promoting, will support offline capabilities, but it is not clear when this will be practically available in mobile browsers.) The Blackboard Mobile Learn team claims that native apps will allow them to provide a better user experience. To be honest, I don’t know much about mobile app development and have no intuitions about who is right. I have been impressed with the quality of Google’s Buzz mobile web app, but I don’t assume that the approach will work for everything that you’d want to do in an app. We’ll have to see once the Blackboard Mobile Learn team has their app out whether they are doing interesting things that a web app can’t do.

    Regarding portability, there’s a long term and a short term issue. In the short term, Blackboard will have a Blackberry app while Moodle won’t. I suspect that the market share for Blackberries among college students is pretty low, even in the United States. On the other hand, it’s not always about numbers. If, for example, you have an important executive education program offered by your business school, then Blackberry support will matter a lot. In the long term, I suspect that the web app approach will be more portable and allow the developers to keep up on more platforms with fewer resources. But we’ll see. This is a very young market.

    Update: It appears that Blackberry plans to have a WebKit-based browser in the near future.

    Later Update: Carlos Kiyan pointed me in the direction of this article, which outlines the pros and cons of both native and web app approaches.

  • Moodle Mobile Now Developing an Android Native Client

    Well, I guess it’s mLearning Week here at e-Literate. Just a day after I noted that the main difference we are aware of between the Moodle mobile clients and the forthcoming Blackboard Mobile Learn client is that Blackboard plans to have native apps for Android and Blackberry, the Moodle folks announce progress on a native Android app. Let the arms race begin!

    Update: I have just been informed by a member of the Moodle mobile development team that both the iPhone app and the Android app are, in fact, web apps and not platform-native apps. That wasn’t obvious to me at all on casual viewing (especially with the iPhone, where I have no first-hand experience and didn’t recognize the browser chrome). It will be interesting to see how much of a difference that makes in terms of user experience, particularly with Google and Apple both pushing HTML 5.  Anyway, the mobile web app has been tested for Android, but is not Android-native.

    By the way, the helpful people at Blackboard’s P.R. firm referred me to this study at Ball State University showing that, as of about six months ago, 38.5% of their students own smart phones, and 18% (or roughly half of the students with smart phones) owned iPhones. No word on the Blackberry/Android breakdown, which probably has changed in the past six months anyway due to the new Android phones on the market. I am quite sure that there is a lot of variability from school to school, based on demographic, socio-economic, and geographic factors.

    There’s actually some interesting mobile work being done by University of Cape Town in South Africa, but it focuses on text messages rather than whizzy smart phone apps. (I strongly suspect that UCT has a lower percentage of smart phone users with unlimited data plans than Ball State does.) I’m looking into the possibility of getting a guest post on this topic at some point. (That’s a hint, Stephen.)

  • Moodle Mobile vs. Blackboard Mobile Learn

    Blackboard just announced the planned availability (in June) of Blackboard Mobile Learn:

    Blackboard Inc. (Nasdaq: BBBB) today announced plans for Blackboard Mobile Learn(TM), an application that will bring two-way teaching and learning to mobile devices, creating an interactive mobile learning experience for students and teachers on the go.Blackboard’s existing Blackboard Mobile Central(TM) application already delivers a mobile campus experience that includes news, events, maps and sports among a range of student life and service options.

    Blackboard Mobile Learn will take the next step by bringing the classroom experience and learning content to the mobile environment, arming campuses with a high quality option to quickly meet the growing demand from students who want to do more with their smart phones and other Web-enabled devices.

    From what we know so far, the main difference between this and the Moodle mobile offerings is that Blackboard plans to have native clients for Android and Blackberry while Moodle so far only provides a Java-based client for non-iPhone mobile phones. (Does anybody have market share data on smart phones for the college aged demographic?) We won’t know if there are actual functional differences until Blackboard releases more details.

  • It's Official: The Sakai Foundation is Hiring a New Executive Director

    The job description is here. If you are thinking about applying and have questions, feel free to ping me.

  • Understanding the Sakai Product Council

    If you have never been involved with an open source project, one of the great sources of mystification (and anxiety) for you might be how a group of people spread out all over the world with a wide range of motivations can come together to work on a complex project and produce something coherent and useful. Of course, we know that such things do happen. (For a beautiful illustration of it happening under conditions of extreme lack of visible coordination, watch Jon Udell’s classic analysis of the evolution of a Wikipedia page, Heavy Metal Umlaut.) We know that it can work. But, from the outside, it’s hard to understand how.

    The truth is that there is a wide range of governance structures that work for different open source projects, and none of them are particularly mysterious once you come to understand them better. Some projects, like Moodle and Linux, have structures that bear some superficial resemblance to normal management structures in that they have strong central managers who make a lot of final decisions. I say “superficial” resemblance because, in many cases, these managers are acting as part traffic cop and part adjudicator, rationalizing contributions and suggestions for direction from all corners of the community more than they are giving top-down commands.

    Other open source projects, like Sakai, take a more distributed approach to management. When they can, they tend to modularize the development so that small groups can work largely independently from each other and can reduce the coordination required to those areas in which their pieces have to work together, either from a technical perspective through integration or from a functional perspective through, for example, common user interface conventions. For those functions where cross-module decision-making has to happen, the community develops mechanisms that look a lot like a representative democracy. In some cases, community members will vote directly on an issue that needs to be resolved. In other cases, they will select representatives to work together in a small group to work through the issues. Just how much (and what kind) of coordination is required depends on a number of factors. Software that has a significant user interface generally requires more coordination than software that does not. Programs where the modules share a lot of technical integration interfaces or services also tend to require more coordination than those that do not. Projects that are in the beginning of their life cycle tend to require more coordination those that are mature.

    Over the years, the Sakai community has tried a number of different coordination structures. One of the most recent innovations (and experiments, really) is the Product Council (PC), of which I am a member. What follows here is my own personal meditation on how the PC came about, what function it is attempting to serve and how successful we’ve been at it so far.

    (more…)

  • Moodle for iPhone Demo

    Here’s an interesting (and unusually high production value) video of an iPhone mobile interface for Moodle:

    Moodle also has a Java-based cross-platform mobile client which is not as pretty but seems to have decent functionality. (My impression is that this is fairly similar to the state of affairs with Blackboard’s mobile clients.) You can see screen shots here.

    In the long run, we’re going to need to think seriously about creating more teaching and learning affordances that are mobile-specific rather than just creating mobile interfaces to existing LMS capabilities, but this is still a good step down the road.

  • Sakai 3: The Benefits of 'Everything is Content'

    One of the more radical departures that Sakai 3 makes from traditional LMS design is that everything in the system is treated as content. A traditional LMS is an aggregation of tools—discussion boards, grade books, test engines, wikis, assignment drop boxes, etc.—each of which has its own data model in a relational database. It’s really a hodgepodge of separately designed tools that are knitted together through a user interface layer and a few common services. In contrast, Sakai 3 is being built on top of the Apache Jackrabbit reference implementation of the Java Content Repository (JCR) standard. Everything is treated as content, including grades, test questions and answers, discussion threads, syllabi, personal profiles, chat messages, and so on.

    This approach has some benefits in terms of shoring up common weaknesses in LMS designs. But, more profoundly, it also leads to some pretty fundamental changes in the way that learning environments can work, thanks in large part to the strong and growing adoption and maturation of useful content integration standards.

    (more…)