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.

Over the course of a few weeks, we built an engine that took our client’s XML content (and all of their complex learning interactions) and generated an HTML5 output that could be used in the browser on a desktop, tablet or mobile device.  While the final product looked great and all the interactions functioned, the problem was we ignored a key element:  that interactions on a mobile device are fundamentally different than those on larger screens.

We quickly learned that mobile interactions, especially in a learning environment, need to be thought of differently than their desktop counterparts.  For example, a simple drag and drop interaction, which works well on large form factors, doesn’t translate to a mobile device.  What we learned is that when targeting a mobile or tablet device for educational content delivery, screen size has to be a factor for determining what interactions the student is presented with.  What works well on the desktop needs to be approached differently or left out of the mobile product all together.

Devices such as smartphones and tablets have introduced new, unique, and creative ways for students to consume content.  For organizations already delivering online learning via Flash, the predominant question is how to deliver that same content on mobile devices.

One of our clients has been using Flash exclusively to deliver their learning materials online.  Flash makes for a great student experience because you can create learning materials with interactive content, animations and videos.  But as great as Flash works on the desktop, it works poorly on mobile devices (if it works at all).

Because mobile is where more and more students are turning (they want to learn on their iPads, Androids, and iPhones), the best format in which to deliver content across all of these platforms is HTML5.  But, how can this be accomplished without rewriting all of that content that is currently being delivered in Flash?

You may think that since this client’s online products are all delivered in Flash that they are going to have difficulty delivering to mobile devices, but they are not.  Because all of their learning content is single-sourced, they are in a position to move to new distribution technologies with relative ease.  Rather than having to worry about rewriting content, they can focus on creating the HTML5 output desired and shorten the time needed to deliver their content to mobile devices.

It is important to our client to have offerings for these new platforms in order to satisfy the needs of their students and generate new revenue.  By single-sourcing your learning content you can distribute your content across an increasing number of platforms with ease.  If you don’t single-source your content, you may be stuck in an old technology that limits your reach and revenue potential.