We have a pool of around 30-35 iPhone users at my work location that we’ve been studying. From our studies and our interactions with other smart phone users, one thing has become abundantly clear: burdensome security policies are a showstopper for most users. Roughly 80-85% of our users have refused to install the corporate security policy on their iPhone (which would require an 8-character alphanumeric password to use their phone), choosing to forgo accessing business applications and services on their phone rather than have to constantly log into their devices.
While many people contend that security and usability are diametrically opposed and there’s no good solution here, I’d argue that’s not necessarily the case. Certainly from the user’s perspective the security policy is unworkable. Typing an 8-character alphanumeric password on an iPhone’s virtual keyboard takes most users 10-15 seconds. But given that most iPhone interactions are less than 60 seconds long, that’s 15-25% of users’ interaction time right there. Unlike laptop use, the time to enter the password isn’t amortized across an extended interaction. Plus in most cases users are accessing functionality that isn’t business related (taking a picture, posting on Facebook, checking Twitter, etc.), so they perceive the password as unnecessary.
From my company’s standpoint (and from pretty much any corporate / government standpoint) the need for security is clear: the company has financial, ethical, and legal obligations to protect company data that may end up on phones. In our case, the 8 character password requirement appears to derive from an Italian privacy law (DPR 318/1999) that the CISO’s office decided to apply as the least common denominator worldwide.
So why don’t those two requirements (easy access to devices/services from users’ standpoint; security and protecting data from my company’s standpoint) conflict? Well, they admittedly do to some extent with the current security mechanisms we have available on smartphones. When all you’ve got is blanket password access to restrict data, you don’t have much wiggle room to balance competing desires. But there’s no reason that smartphones can’t be smarter (sorry) about which applications and data need to be protect (business applications) and which don’t (Twitter, camera, weather, stocks, etc.).
Why is it that, at a time when smart phones are increasingly useful for both personal and business uses, that I can’t tell me smartphone which are which? I currently have the security policy installed on my iPhone, but I’d be much happier if I could restrict access to the small # of applications that are for business rather than to the whole phone. Technically that’s feasible, it’s just that iPhone OS, Android, etc. don’t support it yet. And that’s frankly where I think we need to go, particularly as computing devices increasingly move away from the model of “owned by your company and administered by IT” to “owned by you and used on behalf of your company”, which is where smartphones are largely now and where I suspect other devices will go. How long will it be until we get a subsidy from our companies to purchase our own computer that we’ll own and administer ourselves? Citrix is doing it now.
So if you know a mobile OS developer, tell them to drop me a line. We’d like to help them make their OS friendlier to both personal and business use.
Now that the very large technology company I work for has joined the iPhone Developer program I created an external project page to start showing off some of the mobile work we’ve been doing.
A short summary of the project:
Email is a primary application for the latest generation of smartphones, yet many mobile email clients are designed essentially as smaller versions of desktop email clients. Mobile email use, however, differs from desktop email use. While desktop email users may spend significant amounts of time reading and writing messages, mobile email users typically focus on triaging their messages to determine what’s new, what they can delete right away, and what’s important enough to handle immediately. Everything else they defer until they a desktop or laptop with a full keyboard and larger display. We set out to build a mobile email client that would better fit how users actually handle email on mobile devices.
The page has a more detailed description of the project, some images, and a video of the prototype user experience.
Watching Apple’s press conference coverage today, I couldn’t help but marvel at Apple’s mastery of product buzz. In the lead-up to today’s event they said barely anything about what they were announcing, and yet the tech world was all atwitter (often literally) about what they might announce.
Apple’s marketing prowess aside, I find the iPad technically intriguing yet functionally a bit of an open question. From what I can see of the industrial and user experience design it looks Apple to the core: very slick, very elegant. And yet I find myself wondering whether I really need one that much.
I’ve already got a laptop. Several of them, in fact. And despite the fact that Steve Jobs likes to disparage netbooks, I suspect that my Lenovo S10 (which I’ve turned into a dual boot Windows 7 / Ubuntu Netbook Remix device) is a better travel computer than an iPad would be because I usually travel for business and my netbook handles most of the business tasks I need to do. The iPad? Not so much (although with the increasing prevalence of web tools for work I suspect it’ll increasingly be more useful for work), in large part because the device runs iPhone OS instead of OS X.
I’ve also got an iPhone, so I’m already able to access the Internet while mobile. And watch / listen to media on airplanes (albeit with a smaller screen than the iPad offers). And the iPhone fits in my pocket. The iPad? Not so much.
I’ve also got a Kindle. The first-generation Kindle, in fact; I bought it after a conference in Italy where despite bringing 3 books with me I almost ran out of things to read. And I like the Kindle’s size, display (very easy on the eyes), and battery lifetime. I can get roughly 2 weeks of use out of my Kindle without charging it. 10 hours of battery for the iPad is nice, but not in the same league. And cell service for the Kindle is included in the price; no monthly fee.
So while the iPad seems like a very nice device, I’m not sure I’ll be getting one for myself once they’re available. Unless, of course, I drop by an Apple store to play with one and they’re just too cool to resist.
At the very least I now have another opportunity to leverage my hard-earned iPhone development skills.
We’ve been smartphone use for over a year now, and one of the lessons that I think anyone building a mobile application needs to keep in mind is speed. Yes, one of the great things about smartphones is that people carry them almost everywhere, providing pervasive access to information. But as a consequence, people employ their smartphones in situations where the real world constrains their use: you can’t hold up the line at the grocery store when it’s your turn to checkout, the airline will not delay closing the boarding door while you finish that email, etc. In addition, the limited input and output capabilities of smartphones mean that users are likely to defer anything too I/O intensive until they reach a desktop or laptop.
In studying smartphone users, we’ve discovered that most interactions are less than a minute (60 seconds) long. Checking the weather, checking out new email, looking at Facebook status updates, reading recent tweets, snapping a quick pictures: all short (and typically intermittent, but that’s different post). If you break that time down, it includes physically accessing the device (typically a few seconds if the device is a pocket or purse), initializing the application (a few seconds for a native app, more in the 8-15 second range for a web app), and then completing the particular task (doing the actual “work”).
Thinking about speed for your mobile applications has (least) two consequences. One, you want to focus on the core functionality provided by your application, because people are unlikely to spend the time to navigate to the more esoteric information or functionality provided by your application. Remember, if it takes too long to do on the smartphone users are likely to just wait and do it on their laptop or desktop.
Two, you want to think about the initialization and work times typical for your application (there’s not much you can do for access time without providing wrist mounts for your users). On the initialization side, native apps tend to be significantly faster to initialize (and use) than web apps. HTML5’s support for offline application and data caching is making headway on reducing the time overhead, but native apps are still faster. On the work side, structure the user experience so that users can quickly get to information or functionality they’re likely to want without making them wade through intermediate levels. If completing a task is likely to take longer than 60 seconds, provide users with a way to easily suspend their work and resume it later on (even on other devices; that’s also another post).
Unfortunately, the need for speed sometimes has consequences you can’t directly control. We’ve seen that roughly 80-85% of the smartphone population we’re studying would rather not use their smartphones for IBM work if it requires installing the IBM security policy. To these users, suffering the 10 second hit to type in a password just isn’t worth it: that’s 15% of their 60 second interaction time right there. And since most things our users do with their phones aren’t business related, they’re taking that time hit on actions (checking the weather, taking a picture) that aren’t even work related. So until smartphones get smarter (ahem) about separating personal and business information and functionality, the need for speed may be a general barrier to the use of smartphones for business. But in the meantime, make sure your application is part of the solution, not part of the problem. Support speed.
The seriously large technology company I work for is starting to take mobile more seriously. I’ve been working to distill some of the lessons we’ve learned around how to design effective mobile user experiences so that I can share them internally. I figure as long as I’m drafting blog posts for internal distribution I’ll share the non-confidential lessons here as well (if nothing else it’ll give me an excuse to dust off this blog again). Most of these lessons are drawn from studying a pool of iPhone users at work, but some are drawn from other sources as well. Let the sharing commence…
Part of this summer’s brain candy was John Birmingham’s Weapons of Choice, a free Kindle book from Amazon. I’ll confess I started it with very low expectations, particularly since I’d seen Final Countdown as a kid and figured the book would be a tired retreading of the same theme. However, I was pleasantly surprised; the book was fun and energetic and Birmingham did a good job of moving the plot forward. As summertime action brain candy it was a great diversion (particularly when acquired free). In fact, I enjoyed the book enough to actually purchase the sequels Designated Targets and Final Impact.
The second was even more enjoyable than the first, but the last (the completion of the trilogy) was the weakest of the three. I was left with the impression that the author realized he had a few too many plot lines open to complete the series expeditiously and summarily ended several of them between books 2 and 3. That wouldn’t have been necessarily that bad, but in this case one of the plot lines tied to a major event that book 2 had spent most of its time working toward. Still, all in all a good trilogy for summer reading (and enough to remove most of the stigma that Final Countdown had attached to wartime time travel stories).
What else is new?
I received a copy of Judy Estrin’s book Closing the Innovation Gap free at work. I’d missed her talk and heard good things about it, so figured I’d make time to read the book. I have to say, I was thoroughly underwhelmed. Estrin takes over 200 pages (granted using a large, well-spaced font) to essentially make just two points:
- Researchers could explore more if they had more money and a longer time horizon.
- We need to make science and math a higher priority in schools.
That’s pretty much it. And despite the length she doesn’t back up those points with much evidence. For example, she keeps using computer science as her example for a field that started off with a lot of exploratory work funded by DARPA and laments that there isn’t as much funding now for broad exploration. However, she ignores the fact that due to the inertia of the deployed systems we have it’s harder to make a practical impact with broad exploration (for example, what was the last truly new operating system you encountered?). Is it really the case that throwing more money at computer science research would necessarily result in more innovation? How would she then explain Apple, which I would argue is very innovation yet dumped Apple Research way back?
Estrin also doesn’t really make any concrete policy suggestions either. Sure, researchers would love more money and scientists think teachers need to incorporate more math and science into the schools. That’s great, but how to get to there from here? Saying where you think society needs to go is only part of the battle; you also need to strong arguments for why that’s the right direction and a plan for getting there. The book falls short of providing either.
Bottom line, I was disappointed by this book. Management would have been better off buying us all copies of Good to Great.
Another free Kindle book down. This time it was Silent in the Sanctuary by Deanna Raybourn. Did I somehow miss the Romantic Mystery category of literature growing up? I don’t think I ever really encountered the genre until Amazon started doling out free Kindle books. But since then I’ve read Julia Spencer-Fleming’s In the Bleak Midwinter (which I have to confess was good enough that I paid for some of the sequels), Julie Garwood’s Murder List (which unfortunately had very two -characters), and now Raybourn’s book. I’d rank it between the two; the characters were very well drawn (Raybourn did an great job of making them compelling and believable), but the balance between mystery and romance tilted a bit too far to the romance side for my taste (it seemed like the mystery was there to drive the romance forward, versus the romance adding an extra element to the mystery). Others mileage will obviously vary, but I think for now I’ll pass on reading the sequels. Still, it definitely qualifies as a fun summer ready.
I finished two more of my free Kindle books but then acquired three more. I’m not sure if that counts as progress or not.
The two this time were Julie Garwood’s Murder List and Alan Furst’s The Foreign Correspondent. Of the two, Garwood’s book is the weaker. Murder List belongs to that unfortunate category where the author attempts to communicate how their characters feel by telling you rather than by portraying it through the words and actions of their characters. As a result, I never really clicked with the characters and didn’t get as immersed in the book as I might have otherwise. On the other hand, it’s very light going that requires minimal brainpower, so it’s not a bad thing to read to relax before bad after a long day.
I enjoyed The Foreign Correspondent much more; Furst does a very good job building up a compelling picture of both his characters (the foremost of which is an emigre Italian journalist) and his setting (pre-WW II Paris). While there’s not a lot of dramatic tension (there isn’t exactly danger around every corner or bullets flying everywhere) and the ending is a bit abrupt, setting the story right before the outbreak of WW II does a good job of maintaining a low-level of tension throughout the story that pushes things along. The reviews on Amazon suggest that is one of Furst’s weaker offerings, so I’m intrigued enough by this book to plan on eventually checking out some of his more highly rated works.
I got WiFi working on my Lenovo S10 running Moblin v2 (the beta) with a little help from the Internet. The sticking point is the Broadcom driver, which isn’t included in the distribution by default. The following two posts helped me work the requisite magic:
- Glen Gray’s blog has a walkthrough of the necessary steps to build and install an RPM package with the driver. The walkthrough is for the Dell Mini 9, but the s10 requires the same Broadcom driver.
- A comment on the Moblin website points to Gray’s instructions and also lays out the necessary commands to restart wireless.
Between those two I was able to get Moblin to allow me to turn wireless on then connect to my home (WPA2) network.
jeff pierce 