Mobile and Enterprise Applications: Answers Questioned

I've been talking a lot about mobility with customers over the last several weeks. It's top of mind with the release of the Mobile SDK 1.2, which makes it simple to create mobile applications for just about anything. Some common themes from customers:

• Mobile use cases are different. Many (if not most) need to be quick logging of activities. It's not working through a complex business problem on your iPhone.
• An analogy from consumer software is Foursquare versus Facebook. Foursquare is fast, designed to get a user in and out of the application in seconds. Facebook is designed to hold your attention for minutes (heck, hours if you're stuck in the airport).
• Like Foursquare, there should be no barrier to the end user for mobile data entry: logging a sales activity, a shipment, an idea. And geo-location tags make that even easier. 
• Like Facebook, users will need to connect with others in the company. And almost all users need some kind of document library available. That generally dovetails into social media business requirements.
• BYOD just makes sense, it's ultimately much easier for most businesses to support, and is one less thing to manage. So HTML5 will be a natural design choice for a lot of this...even more so as the specification and support evolves.

Ultimately, progressive companies want to use mobile trends as a competitive advantage. Obviously, mobile personnel become more productive. But capturing more data, and more accurate data, will eventually lead to more agile, productive businesses. And that's where it gets interesting...

Random thought of the day.

As an avid news consumer with daily commute time to keep me captive, I spent time over the summer experimenting with the best ways to catch up on daily events on my iPhone. Sure, I love my iPad, but when I'm standing on a crowded train, my iPhone is easier to hold and control. Besides, I'm almost never without my iPhone at home or on the road - I have more moments to steal some productivity with my iPhone than any other device.

Last summer, Scribd announced Float, which on the surface looked perfect: a single user interface for any content I want. No more Twitter hyperlinks to poorly designed websites, or trying to manage everything with Google Reader. One app, one place to go, finally.

One problem: the app didn't work.

I downloaded Float on my iPhone 4 the day it launched, and quickly setup a few key content feeds from the list. While not everything on the web was accessible, it was a good enough selection to get get started. On the first day, it seemed to crash and close every second article or so. Many articles failed to load. But, hey, it just came out, so I gave them some slack.

Over the next week or two, it seemed that Float had an update to push every day. Every time, stability seemed to get worse. The user interface had a confusing preview feature you could kind of use by sliding over the article, and that itself would crash the application on occasion. After about 2 weeks, I grew tired of the constant updates, user interface, and instability. So I stopped using it.

In December, Flipboard launched their iPhone app, about 5 months after my Float experience. Flipboard for the iPad may be the most elegant piece of software I've ever used, and the iPhone app promised the same 1-stop interface Float had promoted. So I tried it.

The iPhone interface is every bit as spectacular as the iPad experience. The smaller form factor requires some design changes, of course, but the user features and the content presentation are outstanding. The presentation of my Twitter and Facebook content may never replace the iOS clients for those applications, but the ability to present the content linked in my social feeds is unparalleled.

So I use Flipboard, and I'll never go back to Float. Flipboard wasn't the first to market, not even close. But they did it right, which ultimately was more important than being first.

Lesson learned.