Why people historically love Apple: Their nearly maniacal control over product development leads to a stable system which behaves predictably.

Why people historically hate Apple: Their nearly maniacal control over product development leads to an expensive, closed system that doesn’t work with industry standard software and other technologies.

Why people hate Apple now: They are betraying their historically good qualities by releasing beta-like products (not to mention Microsoft-like) which cost a fortune and don’t deliver.

…bad algorithm for reception quality, upgrade to new iOS kills contacts, etc…

Having recently attended The eLearning Guild’s mLearnCon, I made it a point to speak with and listen to attendees and presenters involved in app development. There were two distinct camps: enterprise level solutions and quick and easy dev. The enterprise level evangelists included people like Robert Gadd of OnPoint Digital and Dave Smelser of Intuition. These guys know what they’re talking about. Their companies design custom mobile apps tailored to your specific needs. Robert’s enthusiasm for mobile technology is infectious, and he spews industry know-how like a broken faucet. Dave knows all things BlackBerry. Intuition’s deep involvement with financial industry clientele necessitates excellence in RIM’s secure mobile technology. If I’m deploying a native app that grabs content from a secure server, and it’s centrally controlled by a system admin, I’m talking with one of these guys.

There were quite a few sessions and discussions around quickly developing apps by leveraging skills you’ve already got. This essentially boiled down to developing a web app in HTML, JavaScript and CSS. Richard Clark of NextQuestion, B.J. Schone of Qualcomm and Chad Udell of Float Mobile Learning were among my favorite presenters. They each had a unique viewpoint on app development, but they all essentially said the same thing: do what you know. You can develop an app using older (proven) scripts and languages. Think ’90s and you’re starting to get there. Everything needs to be very lightweight and simple. Use only web-ready images. Put your code and your text content in separate files. The code calls text strings when and where needed at run-time.

The content is my main interest. When I help plan for, implement and deploy global initiatives I need to know where the content is. Storing text content in a file on it’s own is always good practice, regardless of the technology. It’s especially wise when developing an app requiring a small file size and intended for an international audience.

Here I am at mLearnCon. I arrived last night, and I started in at 7 am today beginning with words from Executive Vice President and Co-Founder Hedi Fisk. Tomi Ahonen is kicking things off with the keynote address right now, and then it’s off to listen to Float Mobile Learning’s Chad Udell talk about “Design Approaches for Adapting Content for mLearning.” I’ll update throughout the day as I’m able to fill you in on any goodies that I come across.

8 points from Tomi Ahonen

Design Approaches for Adapting Content for mLearning by Chad Udell (FloatLearning.com)

Mobile devices need to understand context in order to present useful information at the right time. E.g. Kit from Knight Rider. Michael couldn’t care less what the temperature is outside when there are three armed men inside the building where the bomb is.

Categories of Contextual Design

System aware

• Adapt to device-specific interaction techniques (touch v. multitouch v. cursor v. terminal)
• Different display on different screens
• Functionality specific to delivery platform

Network aware

• Account for diffsi n network access and bandwidth
• Using local device storage when offline

User aware

• Inferring intent
• Personalize content based on usage history
• Integrate social data
• Provide varying levels of service and data access

All in all, a good session.

20 mLearning Tools in 60 Minutes by BJ Schone from Qualcomm

BJ went very rapidly through 20 tools, ranging from SMS- and browswer-based to web and native apps. Those that I found most interesting and helpful were as follows:

Adobe Device Central
Strength: simulates a testing environment where you can view content on a variety of mobile devices
Comment: yes please, that will save a lot of time and harassing people for their phones

PhoneGap
Strength: build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Android, Palm, Symbian and Blackberry SDKs
Comment: apparently Apple doesn’t mind the way PhoneGap compiles Objective C

Clickatell.com
Strength: first and largest SMS gateway; enables websites and apps to send and receive text messages
Comment: SMS works on 90% of all user phones

Titanium
Strength: free, open-source application development platform that allows you to create mobile apps using web languages
Comment: another way to make apps and roll them out to multiple platforms, ah ya

QR Code Generators / Readers
Strength: codes can be read and interpreted by many mobile devices
Comment: very interesting that this came up as a means of learning, actually quite applicable (used in the Smithsonian)

Layar
Strength: augmented reality browser that allows users to see digital layers in physical spaces
Comment: this is the wave of the future, when do we get these in our occipital lobes?

mobiSiteGalore
Strength: mobile website builder that allows you to easily build, publish & share a full-fledged mobile website that is guaranteed to work on any mobile phone
Comment: and another multiple platform publisher

Takeaways

1. Mobile is the fastest growing technology in the history of the world.
2. It’s a matter of when you’ll get on the bus, not if.
3. Developing apps (especially web apps) is not terribly complicated. Development can be done in familiar languages and then compiled properly via a host of online services.
4. Because apps require small file sizes, it is very good practice to store information is small text files. Thus, getting at content for translation purposes should be straightforward.
5. Controlling privileged content remotely is essential to security. Mobile devices are easily lost, so content should be accessed securely from a remote server and dumped into the app framework at run-time.
6. Richard Clark has some good info here: http://rdclark.github.com/mlc10/

The conference was great. I enjoyed the sessions and MOSH (Mobile OS Help) pit. Meeting with people whom I follow on Twitter was also nice. I’ll do it again next year, I think.

Whether you are developing in a CMS, creating a Flash module or typesetting a print document, getting your text content into a separate tagged file is the first step to success. With Open XML’s increasing ubiquity, XML has become the standard tagged file format to use for everything from InDesign content exports to scratch developed web sites. XML is a great way to store, share and distribute text for a number of reasons. First, XML will typically be encoded as UTF-8, the international encoding standard which pretty much supports every language. This ensures, or at least makes probable, that characters will not corrupt when your creative is localized into disparate language families. Second, it is simple to parse and isolate text for extraction, translation and automated re-insertion. That leads to the third point which is that having your text content isolated from the rest of the creative allows the translators to focus on what they do best without requiring any technical expertise. Similarly, styles and functionality built around the text can be preserved independently, which makes rebuilding the creative much more efficient.

Example of external XML in Flash.

I just saw this on TechCrunch.

Today at the Google I/O conference in San Francisco, Google showed off a preview of a major new product: the Chrome Web Store. Yes, this is a an app store for the web. In the image you see above, those big icons in Chrome are apps.