Jim loves working our booth!

I attended a session that had a panel made up of members from large educational publishing companies. A member in the audience asked the panel a question:

“Do you think that open source educational content is a threat to you?”

The panel adamantly responded that they do not see this free content as a threat. They do not think that these free content providers have high quality content, and do not think that teachers have time for content curation. I did not agree with their stance on this.

As a developer, all I could think of was the successful open source software that many of us use today, such as Firefox and WordPress. I’m sure there were many people who doubted the quality of open source software before it became popular. I attended another session where I was introduced to Khan Academy, a free online provider of “over 3200 videos on everything from arithmetic to physics, finance, and history and hundreds of skills to practice.” Conference attendees unanimously thought that Khan Academy provides both good and bad content. In my own research I came across MIT OpenCourseWare. MIT provides lecture notes, exams and videos to the public free of charge. This site convinced me that there is a way to provide high quality content for free. Teachers may not have time for content curation, but I can see organizations made specifically for this purpose in the future.

In closing, I think we will begin to see more and more free educational content providers in the future. Educational publishers should be aware and warned of the current and future threats of free content. Am I wrong?

Content Types and Content Models

Defining content types enables targeted searching, targeted processing, and integration with desktop applications and other external systems. The CMS can be configured to recognize your content model and enforce specific activities based on the content type.

Metadata and Classification

Metadata enables you to describe and classify your content using terms that are familiar to your users. This makes finding content easier and enables the automations of business-specific processing. The system should be designed with consideration of how that metadata will be captured and stored in the CMS.

Searching

Since most “out of the box” CMS systems provide only basic search capabilities, understanding who will be searching for content (and what kind of content they will be seeking) will help you determine if you will need custom search forms and whether they should have advanced capabilities (e.g. pre-filled value lists, more intuitive graphic controls, etc.)

Workflow

A workflow engine within your CMS enables you to control the routing of documents, often resulting in increased efficiencies. In addition, workflows can support automated processing or integration with other tools (such as authoring tools or production systems) to further increase efficiencies.

Security

Your CMS enables you to control content security by providing groups of users with specific privileges (e.g. read-only, edit, delete). These security groups can also be used to influence the available search forms or workflow access for the users, so you want to define it before you implement those features.

Legacy Content, Data, and Digital Assets

Converting these items in order to bring them into the new system can be a very large effort, especially if you are implementing a structured content model (i.e., XML). Addressing this up front ensures that you aren’t slowed down by an add-on migration effort later.

Business Process Change

Early analysis will help you project and plan for business process changes; and as your project progresses, you will find more opportunities to streamline and automate. Change can cause uncertainty, so managing the change from the outset with effective communications and training strategies (that fit your company culture) is key to a successful rollout.

Resource and Organization Changes

Planning for this shift in resources (and using change management) will help transition to entire organization smoothly. In some cases, role-based training helps employees transition into their new process. In other cases, the processes are so different that new roles (and skill sets) are required.

Stakeholder and End-User Acceptance

In addition to the traditional change management activities, a user-centric approach to system design and implementation turns users into evangelists. Keeping users and other stakeholders fully engaged in the implementation is a critical factor in ensuring overall acceptance.

Long-term Planning for Support and Enhancements

Budget and time constraints usually require that the team get the biggest bang for their buck. Even if the team can get all of their initial requirements into the first release, changes in market, corporate direction, and internal processes often require updates to keep the system effective, so be prepared to make enhancements.

 
For any journey, navigation is key. Before you start on your CMS implementation journey, take some time to plot a careful course (and don’t forget to pack your GPS!)

Cross-platform mobile development, the white whale of the mobile developer.  Cross-platform mobile development can mean many things to many people.  In my opinion as a developer, for an application to be cross-platform, it has to hit these three points:

• Have a single code base
• Building a new feature means it will be available on all targets (devices)
• The user will have the same experience across targets

As a developer, being able to hit all three of those bullet points would be the holy grail of mobile application development.  So is it possible?  To quote Reverend Lovejoy, “short answer ‘yes’ with an ‘if’, long answer ‘no’ with a ‘but’”.

What challenges are there?

First, maintaining a single code base, while possible, can be very challenging.  Having a single code base implies that you would be able to literally copy and paste your mobile web app code to your Android/iOS app and vice versa.  This is challenging because your mobile device has different functionality that it can make use of (camera, phone, etc) that your web browser will probably never have.  In order to have your code go between the two worlds seamlessly, abstraction must be your friend.  Be able to determine your current target and deliver functionality based on its capabilities.

Second, what about building a new feature?  In some instances, a new feature can easily make its way across mobile web and native apps.  However, there are other instances where this is far more challenging.  For example, suppose you wanted to implement Facebook authentication.  On the mobile web, this is pretty straight forward.  You get redirected to Facebook, you log in and they redirect you back to your web page.  In a native app, using the same code, this becomes very difficult.  While you’re technically still in a browser in the native app, redirects can’t work the same because you’re code is within this ‘shell’ that gives the appearance of a native app.

Last and possibly the most important, user experience must be the same.  On your mobile web app, users will easily tolerate a delay of a few hundred milliseconds, because it’s almost expected.  On a native app, everything is expected to load instantly.  Not only that, scrolling, page transitions, all UI interactions must be as smooth as the operating system that your app lives in.  While that sounds easy, if you’re writing a cross-platform mobile app in a language that is non-native to the OS you’re delivering to, these are all struggles and they become quirks that your users will be quick to point out.  It’s one thing to build your app for the state-less world of the web, but persisting that same web code to a native mobile environment is a whole new animal.  Often transitioning that code to native mobile apps is obvious to the user and hurts their experience.

Should I even bother?

Cross-platform mobile development isn’t all doom and gloom.  The key to delivering a great cross platform app is determining how complex your app will be, what kind of experience you want to deliver and weigh those against the amount of time you have for development.  If your app is very complex, does a lot of advanced UI interactions and needs to use a lot of device specific APIs, perhaps a native app or hybrid web/native app is preferred over a pure web app.  On the other hand, if you’re simply presenting content and have a very simple UI, you could go all web app without much of an issue.  I think Ben Sandofsky (@sandofsky) said it best, “…shell apps come from the wrong mentality.  They start from ‘how do we reduce the effort’ instead of ‘how do we deliver the best product’.  Great products require more work.  They require commitment, attention to detail and leaving your comfort zone.  Shortcuts are just a distraction.”

Markus Falk put together a nice chart to compare the technical features of more than 30 mobile frameworks available. Check out his chart to get started.

After going through technical specs, we settled on 6 tools that we thought might do the trick: PhoneGap, Appcelerator, Appcelerator with Cloud Services, SproutCore, Corona, and Unity. To make our final selection, we researched some additional criteria that helped us figure out which tools we could pick up quickly, and which tools we thought we could support best. Here are the results:

Client Frameworks

These frameworks are designed to help you build native applications without an external or cloud server.

Client & Server Frameworks

These frameworks integrate servers with a native application.

Game Frameworks

These frameworks are designed for game programming. These include physics engines and generally do not support native user interfaces

Updated December 7, 2012

Recently, we built a mobile app using PhoneGap. One of the better things to come out of it is a skeleton for future mobile app development for iOS and Android projects. We were able to bundle both the Eclipse project and Xcode project files together.

This can be helpful in getting started quickly. Or for keeping your code simply organized. Either way we recommend versioning any work you do and this gives you a place to start.

New – Get the Latest Code

The ZIP file (28MB) including PhoneGap 2.2.0 built with Google API 16

Older Versions

The ZIP file (4.5MB) including PhoneGap 1.7.0 built with Google API 15

Loading in Eclipse

You’ll need to setup the Android SDK, API 15 and ADT plugin prior to using the project.

The easiest way is to extract the ZIP file anywhere on your computer and then Import an existing project into your workspace.

Loading in Xcode

You’ll need to download PhoneGap anyways and run the installer.

Just double click on the xcodeproj file in assets/howdyworld.xcodeproj.

How it Works

Takes advantage of the fact that Android doesn’t compile or look for code in its assets folder. The assets folder is where you store the web code. So we can put the Xcode project in the assets folder. This way you can have one root folder sharing common web code for separate devices.

In addition there’s some JavaScript to switch Cordova/PhoneGap JavaScript files per device. This matches on the navigator.userAgent testing for “android” or “iphone”. Feel free to extend this.

Do it yourself

Create the project first in Xcode. Follow the instructions to setup the project like normal. So now you have an Xcode structure like:

Your Xcode project filesystem, before

Then you want to create an Android project in Eclipse. Follow the standard procedure. But this time, when it comes to creating the assets/www folder. You’ll call upon the Xcode project. Drop the structure including the /helloworld, /helloworld.xcodeproj, and especially /www into /assets.

Your Eclipse project filesystem, including your Xcode project

After you setup the projects there’s the small issue of switching the cordova JavaScript library. In the index.html file you’ll want to add some JavaScript that detects the navigator’s user agent (navigator.userAgent) and then check if it’s android, iphone, or anything else. Then do a document.write() for the script tag and the appropriate scripts

Further Research

I am always happy to hear better ideas. This was fast, quick, and got us running immediately. We really wanted to save someone else a few smidgens of time.

Get Some More

Come check us out at mLearnCon in June. We’ll be talking about PhoneGap and how we used it. With an eye toward how to best take advantage of PhoneGap and what it means for your development.

Introduction

These days everyone is looking to port their existing application(s) to mobile devices.  Some of those folks are using tools like RhoMobile, PhoneGap, Appcelerator, etc. to write their applications with HTML5/JavaScript/CSS and then port the same code base to various mobile phone platforms with minimal to zero extra effort.  In a perfect world, your PC browser and mobile browser would be identical and you could safely assume a bug in the desktop app will be reproducible and require the same fix as on a mobile device.  Unfortunately this is not the case and the reality is that with all the wide variety of mobile devices out there.  Even if you are fortunate enough to write your app once and deploy it to various mobile platforms, chances are a bug specific to a particular device will crop up and as the developer, you will be tasked with debugging it.  Some browsers, like Safari in iOS, have tools similar to the webkit inspector found in webkit based browsers on the PC, but even that can only tell you so much.  And what about all the other mobile browsers out there, how are you supposed to debug those?  Thanks to a simple tool like Weinre (pronounced winery, or weiner, which ever you’d prefer) you can use the familiar webkit inspector tools with your mobile apps.  For the sake of this article, it will be assumed that you have a HTML5/JavaScript/CSS application on a mobile device ready for debugging, using a PC and have Java installed.

Let’s Start Debugging Already!

First, download the Weinre .zip file from https://github.com/callback/callback-weinre/archives/master.  If you’re using a Mac, you’ll want to make sure you grab the Mac specific .zip file.

After extracting the contents of the .zip, we’re now going to start the Weinre server, which will handle requests from the debug client and debug target (your mobile device).  By default, the server will run on port 8080.  If you want to run the server on a different port or somewhere other than localhost, refer to http://phonegap.github.com/weinre/Running.html.  To start the Weinre server:

Java –jar /path/to/weinre.jar [options]

There are numerous options Weinre can be launched with, but for this discussion we’ll focus on the most basic.  This will give you a Weinre server running at http://localhost:8080.  For Mac users, you’ll want to follow the Mac specific instructions found toward the bottom of this URL: http://phonegap.github.com/weinre/Running.html.

This next portion is dependent upon what your mobile application looks like.  You’ll be adding one JavaScript file to your application, but to actually debug on a mobile device, you’ll have to re-deploy the updated app to the device.  Add the following script to your mobile application:

<script type=”text/javascript” src="http://localhost:8080/target/target-script-min.js"></script>

Now, deploy your app.  I’ll wait…

With your mobile device on the same network as your PC, open a web browser on your PC at the following URL:

http://localhost:8080/client

Launch your newly deployed mobile app and if all goes well, in your PC browser you should see your device connect to the Weinre server as a ‘target’.  You’re now ready to begin debugging your mobile application.

Troubleshooting

Depending upon your app and network setup, you may have trouble binding Weinre to localhost.  If that’s the case, I like to execute weinre with the “–boundHost -all-” option to see what hosts Weinre thinks are available.  Then with your target (mobile device), visit each host at the port Weinre is running on.  When you successfully find a page that works, use the host name in the script added to your app instead of ‘localhost’.

For more advanced troubleshooting, refer to http://phonegap.github.com/weinre/Running.html.

Important Weinre Notes

Weinre gives you almost all of the webkit inspector tools you need to debug your application, aside from JavaScript breakpoints (you’ll have to use the console to execute code or write print statements in your code).

For those concerned about security, please refer to http://phonegap.github.com/weinre/Security.html.  Weinre has absolutely zero security wrapped around it.  If you need to debug a mobile web app, please consider the security issues of adding the Weinre debug script to public facing applications.

For The More Tech Savvy

If you’re thinking to yourself, “Weinre is pretty cool, but I want to debug my mobile app with the full webkit inspector tool”, you’re in luck.  That is, you’re in luck if you own an Android phone and have the Google Chrome Beta browser installed (at the time of this article, only Ice Cream Sandwich phones support Chrome Beta) as well as Chrome installed on your desktop.  With Chrome Beta for Android, you have access to full webkit debugging on any website, mobile or not.  Here’s how to get started:

• Make sure you have Chrome installed on your desktop as well as your Android phone.  You will also need ADB from the Android SDK.
• On your phone, enable USB web debugging (Settings -> Under the hood -> Developer Tools)
• On your PC, issue the command:  “adb forward tcp:9222 localabstract:chrome_devtools_remote”
• Open your desktop Chrome browser to localhost:9222
• You will now see a list of all URLs open in your phone’s Chrome browser
• Click on any of the links to activate the inspector in the browser for that particular URL and start using that site on your mobile device to debug.

For remote debugging help, refer to: http://code.google.com/chrome/mobile/docs/debugging.html

By authoring content in a structured fashion you can separate your content from its presentation. This allows content to be presented in different mediums such as online, eBook, mobile, and traditional printed materials, all without rewriting content or copying and pasting. Structured content also allows you to mix and match your content in order to new different products.

The technology that powers behind structured content is XML. There are a variety of tools and technologies available for managing, linking, and transforming XML. But XML is just the technology behind the scenes, it is much more important that your authors understand the content, leave the XML for the technicians. Authors can still use tools that they are accustomed to (e.g. Word), but they will need to follow the style and structure guidelines in your templates. Below is an example piece of content that utilizes a structured content template.

As you can see, the template is very straightforward and easy to follow. There is nothing technical about authoring in a template like this.

These outputs only scratch the surface of what is achievable when you author your products as structured content. Imagine what else is possible when you can reuse and re-purpose your content so easily. New products and new mediums become much less of a burden and you will always be ready to support new consumer platforms and devices.

Having had the opportunity to work with an educational publisher that approached this problem from a different standpoint, we think there’s a better way.  Adopting a single-source approach to your content makes it easier to add new digital capabilities to your current offerings.

Single-sourcing means writing the content once – irrespective of any product or format – and then using this same content for all the print and digital formats.  The solution we built for this educational publisher enables authors and editors to work within their traditional workflow process to create and edit content using MS Word.  Once the content is finalized, it is automatically converted to a format that is both semantic and presentation-neutral (XML).

Their solution then enables them to take this single content source and automatically create three different formats: a print format (InDesign), an eLearning format (SCORM/Flash) and an eBook format (ePub).   The resultant layouts can be “tweaked” if necessary, although changes typically are made to less than 5% of their overall output (in many cases no changes are needed at all).

When originally adding their first digital capability, this publisher tried to use the print format as the basis for creating the eLearning format.  However, they quickly recognized the inefficiencies and issues inherent in this approach and saw that they needed to change the way they approached writing their content.  Adopting a single-source content approach has enabled them to create brand-consistent products in multiple formats faster and more efficiently than before.

You have less control over how your materials are presented on an eBook reader compared to traditional text. The diagram below “eBook Limitations” points out some of the traditional print features that you will lose when moving to most eBook formats. (No custom headers, No custom fonts, No custom footers, No text in margins, and no pagination control).

One of the major decisions is what to do with your margin content. You will need to decide if the information in the margin is necessary and if so, find another place for it. For example, if glossary definitions are in the margin you can move them in-line to the end of the chapter. Or, if “Helpful Tips” are in the margin, you can move them up to below the chapter title, or after the introductory paragraph.

Something else to take a look at is if your content refers to page numbers. This does not work in eBook because every reader will paginate your content differently. Instead of instructions like “Refer to diagram 17c on page 239”, use something like “Refer to diagram: ‘Food Pyramid’” and remember to place the diagram close to where it is referenced.

These are some of the more significant limitations that you will encounter when moving to an eBook format. Please look forward to future posts that will dive deeper into this topic. If you have any questions or advice from personal eBook experiences please leave a comment or email me.

Moodle is an open source LMS, written in PHP that can use a number of different database back-ends such as MySQL and SQL Server.  It provides a lot of functionality right out the box including a role based user system (teachers, students, administrators, etc) as well as a , enrollment, course setup/delivery, assessments, grade tracking, user forums, SCORM compatibility, and much more.

Given the rich feature set of Moodle, it allowed our client to get their LMS up and running quickly and gave them time to focus on what matters most, their content.