Watched and blogged about Apple's enterprise and development media event, yesterday. The event was about what I call "Touch" products (iPhone and iPod Touch).
One thing which struck me is that Phil Schiller started the enterprise section of that presentation with some comments about Stanford. Now, I'm not one to favor the customer-based model of education. I still see Stanford as being about knowledge more than about financial profit.
Still, this all got me thinking: What if we started using Apple's Touch products in the classroom? Distributing and sharing documents around the group as we are working on diverse projects. Streaming lecture material (audio, video, slides) directly to learners' handhelds on which they can take notes. Synchronous and asynchronous chats. Collaborative editing. Task management...
For that matter, even Microsoft Exchange could make sense in this context. Some campuses already use it for faculty but it'd make perfect sense to have push email, calendars, and contacts on school devices. Secure connections. Global address list. Remote wiping if the device gets stolen or lost.
Even the application distribution system (using the App Store), which may make some developers cringe, could make some sense for schools. Controlling which applications are on school devices sounds awful from the perspective of many a tech enthusiasts, but it could sound really good to school IT managers.
In this sense, Touch devices could make more sense than traditional laptop programs for education. Better battery life, somewhat lower cost, better security, easier maintenance... A Touch program could even have some advantages over newer generation laptop programs, especially in terms of "control."
I know, I know... I'm sounding like a Pointy-Haired Boss. I'm surprised myself. I guess that, as an ethnographer, I tend to put myself in someone else's shoes. In this case, it happens to be the shoes of a school administrator.
Of course, I prefer Open devices. In this sense, Google's Android would satisfy my Open-loving side more than Apple's Touch products. It's just that admins tend not to like openness so much and they're the ones who need to be convinced.
And with the Apple "Touch" products it's not only about technology and administration but also very much about the great user experience. The "Touch" products are addictive and therefore motivating
An early prove of concept I have designed/developed shows Moodle on a "Touch" device. As a "webapp" with the "Touch" look and feel - not as a normal Moodle site in the browser. I am going to show the prototype on the Moodle conference in Heidelberg next week.
Course:
Book (modified book interface):
Quiz:
An early prove of concept I have designed/developed shows Moodle on a "Touch" device. As a "webapp" with the "Touch" look and feel - not as a normal Moodle site in the browser.
Urs - can you explain more about how you developed this as a webapp? Did you use the iPhone SDK? I assume it's running as a client app on the Touch device, correct?
Please share links to whatever you demo at the Moodle conference!
This is very exciting.
Urs - can you explain more about how you developed this as a webapp? Did you use the iPhone SDK? I assume it's running as a client app on the Touch device, correct?
Please share links to whatever you demo at the Moodle conference!
"webapp" I have written in quotes because the Moodle interface on the "Touch" device looks and feels like other apps on the "Touch" devices. There is no specially developed app. The interface part is a theme with CSS hiding or changing Moodle page elements. So it's a special theme to adopt the look and feel of Moodle pages for the "Touch" devices.
The book module I have rewritten to deliver "Touch" specific data. Either the TOC or the page content and not both at the same time.
The iPhone simulator as a part of the SDK I will use to show Moodle in the iPhone over a beamer. And I will have my iPod Touch with me
It might be interesting to find out, if the ability of the "Touch" devices to store data in an own DB on the device can be used for working offline.
The book module I have rewritten to deliver "Touch" specific data. Either the TOC or the page content and not both at the same time.
The iPhone simulator as a part of the SDK I will use to show Moodle in the iPhone over a beamer. And I will have my iPod Touch with me
It might be interesting to find out, if the ability of the "Touch" devices to store data in an own DB on the device can be used for working offline.
Hi, URS. This sounds really cool. So you wrote a Moodle theme for use with Touch devices, correct? Would you please provide a link to this theme? I'd like to know as much as possible about Moodle and Touch -- this could be huge.
Martin D. (and all the other developers)- I'm sure you're aware of the $100 million US dollar iFund, announced last Thursday. Any chance the Moodle community can tap into some of those funds??
Martin D. (and all the other developers)- I'm sure you're aware of the $100 million US dollar iFund, announced last Thursday. Any chance the Moodle community can tap into some of those funds??
Hello Urs Hunkler
are you still developing it?
Kind regards
Carlos
are you still developing it?
Kind regards
Carlos
I've got the iPhone SDK installed right now, and so far it looks very nice.
From the programmer's point of view, it's just another set of Xcode project templates. I'm not a Cocoa/Objective C expert, but Xcode/Cocoa (especially Interface Builder, which isn't fully functional in the beta SDK) is pretty sweet -- as long as you don't mind limiting your code to Apple products. That's not a big deal in this segment; the Touch devices are pretty much it, at least until someone starts shipping Android products.
A couple of things I've heard and learned concern me, though.
1) Apparently there's no way under the current SDK to have a application run in the background. Some of the cooler educational applications I can imagine would really work better if they could talk to a server all the time, or at least check in every few minutes. Some have said that this is due to the limited processing power of the Touch devices, but I'm not convinced that's it. For one, the ARM processors in the Touch devices are more powerful and have more memory than the ones I used to run Linux on in the early 90s. For another, the Touch devices don't seem to have a problem decoding and playing music files (a fairly compute-intensive process) while in the background, so clearly the capacity is there.
I suspect this has more to do with avoiding competition for the (lucrative) SMS market than it does with processing capacity. It just seems a shame to have "always on" Internet access, then prevent the device from actually making use of it.
2) Applications are (reportedly) sandboxed from talking to each other at all. That makes some sense from a security standpoint, but is going to make it vastly more difficult to write any kind of mashup or add-on (for instance, a working spam filter for the Mail application).
3) This is the biggie: "No interpreted code may be downloaded and used in
an Application except for code that is interpreted and run by Apple's Published APIs and built-
in interpreter(s)."
Domain-specific languages (DSLs) are mini-languages that are designed to solve a specific problem. They're pretty easy to write in some languages (especially Lisp but also in some modern scripting languages, such as Ruby). The advantage of a DSL is that you can create a mini-language which makes sense for the problem (or which makes sense to your users). An example that's been around for a while is the MIDI protocol for controlling electronic instruments. While I wouldn't necessarily hold MIDI up as a GOOD DSL, the idea is there -- MIDI uses terms and concepts with which its users are already familiar, rather than having them poke values in registers and hand-control oscillators. SCORM and IMS Learning Design might also be called DSLs, in a way.
Just about every education app I can imagine would benefit from some kind of scripting. I don't know that I'd want to spend a lot of time writing a cool education app only to have some idiot lawyer at Apple (such as the one who wrote that clause) decide that my DSL was an "interpreter" and ban it from distribution (especially since the App Store is the only way to distribute your code).
I was excited by the SDK at first. Now, not so much.
From the programmer's point of view, it's just another set of Xcode project templates. I'm not a Cocoa/Objective C expert, but Xcode/Cocoa (especially Interface Builder, which isn't fully functional in the beta SDK) is pretty sweet -- as long as you don't mind limiting your code to Apple products. That's not a big deal in this segment; the Touch devices are pretty much it, at least until someone starts shipping Android products.
A couple of things I've heard and learned concern me, though.
1) Apparently there's no way under the current SDK to have a application run in the background. Some of the cooler educational applications I can imagine would really work better if they could talk to a server all the time, or at least check in every few minutes. Some have said that this is due to the limited processing power of the Touch devices, but I'm not convinced that's it. For one, the ARM processors in the Touch devices are more powerful and have more memory than the ones I used to run Linux on in the early 90s. For another, the Touch devices don't seem to have a problem decoding and playing music files (a fairly compute-intensive process) while in the background, so clearly the capacity is there.
I suspect this has more to do with avoiding competition for the (lucrative) SMS market than it does with processing capacity. It just seems a shame to have "always on" Internet access, then prevent the device from actually making use of it.
2) Applications are (reportedly) sandboxed from talking to each other at all. That makes some sense from a security standpoint, but is going to make it vastly more difficult to write any kind of mashup or add-on (for instance, a working spam filter for the Mail application).
3) This is the biggie: "No interpreted code may be downloaded and used in
an Application except for code that is interpreted and run by Apple's Published APIs and built-
in interpreter(s)."
Domain-specific languages (DSLs) are mini-languages that are designed to solve a specific problem. They're pretty easy to write in some languages (especially Lisp but also in some modern scripting languages, such as Ruby). The advantage of a DSL is that you can create a mini-language which makes sense for the problem (or which makes sense to your users). An example that's been around for a while is the MIDI protocol for controlling electronic instruments. While I wouldn't necessarily hold MIDI up as a GOOD DSL, the idea is there -- MIDI uses terms and concepts with which its users are already familiar, rather than having them poke values in registers and hand-control oscillators. SCORM and IMS Learning Design might also be called DSLs, in a way.
Just about every education app I can imagine would benefit from some kind of scripting. I don't know that I'd want to spend a lot of time writing a cool education app only to have some idiot lawyer at Apple (such as the one who wrote that clause) decide that my DSL was an "interpreter" and ban it from distribution (especially since the App Store is the only way to distribute your code).
I was excited by the SDK at first. Now, not so much.
I think a couple of universities in the USA have already adopted the Touch devices. Here's a link to an article about Abilene Christian University's adoption.
http://www.engadget.com/2008/02/26/acu-dishing-out-iphone-ipod-touch-to-all-incoming-freshmen/
http://www.engadget.com/2008/02/26/acu-dishing-out-iphone-ipod-touch-to-all-incoming-freshmen/
Recently I was on a panel discussion in Arizona at a conference where a fairly well placed Apple executive was present. I had a chance to ask him some questions on Apple's support of touch devices and the huge promise they have for online learning. I love my iPod Touch and was interested in a few things like why Flash objects on YouTube load, but they don't within a Moodle course. Ditto with QT movies. In typical non-committal Apple style he just grinned and said, "stay tuned".
Was that before Steve Jobs talked against Flash?
What some people seem to be assuming is that Apple wants to position its own solutions (possibly, an interactive version of QT, but maybe just something standards-based, including H.264) as appropriate alternatives to Silverlight and Flash.
Of course, with the SDK out of beta at the end of June, we may expect a number of things to happen in that timeframe.
I think YouTube is actually transcoding the videos to a different format for Touch devices.
It doesn't seem like it would be difficult for a Moodle server to detect a Touch device and pipe any videos through a background VLC (running in server mode) to transcode them to some Touch-compatible format (of course, you'd want it to cache the transcoded video so you didn't take the processing hit every time -- maybe the cron job could even look for new videos and hand them off to VLC as needed).
'Course, that would require a dedicated server; it wouldn't work on a shared web host.
It doesn't seem like it would be difficult for a Moodle server to detect a Touch device and pipe any videos through a background VLC (running in server mode) to transcode them to some Touch-compatible format (of course, you'd want it to cache the transcoded video so you didn't take the processing hit every time -- maybe the cron job could even look for new videos and hand them off to VLC as needed).
'Course, that would require a dedicated server; it wouldn't work on a shared web host.
Now that I think about it, ffmpeg would be a better choice (actually, I think VLC is using the ffmpeg libraries).
'course, good support for that would require sending selected moodle developers a nice sampling of Apple Touch/iPhone gear, with a test account included so they can test/tune the video download performance over the real network.
Absolutely.
I know they have a new US$100 million fund to develop commercial applications. It'd be nice to see them throw some funding toward free educational applications.
I know they have a new US$100 million fund to develop commercial applications. It'd be nice to see them throw some funding toward free educational applications.
You may be right Tony on the special codec YouTube has for Apple devices, and Alexandre I think you're also right on the money about Apple planning something to compete with Silverlight and Flash. Maybe something welded onto QT.
I did learn today that SumTotal is apparently using the new touch SDK in its Toolbook 9 product, now in beta. If we could create an iPod plug-in for activities developed with Toolbook like programs that would be most cool. I just love this iPod Touch, totally awesome technology. If all that would take to make this happen is a few developers having their own iPod Touch... that can easily be arranged.
I did learn today that SumTotal is apparently using the new touch SDK in its Toolbook 9 product, now in beta. If we could create an iPod plug-in for activities developed with Toolbook like programs that would be most cool. I just love this iPod Touch, totally awesome technology. If all that would take to make this happen is a few developers having their own iPod Touch... that can easily be arranged.
If all that would take to make this happen is a few developers having their own iPod Touch... that can easily be arranged.
Makes me wish I were a coder...