Mobile developer news roundup #1: The phablet era, UX lessons from restaurants, Evernote’s 5% problem, Android and OpenJDK, and Solitaire’s secret history

We’re in the phablet era now

Chart: Time spent on mobile grows 117% year over year.

Click the graph to see it at full size.

Venture capitalist Fred Wilson looked at research firm Flurry’s State of Mobile 2015 report and took note of the chart above, which shows that the greatest growth in time spent on mobile came from “phablets” — those large phones that blur the line between phone and tablet — and wrote:

There’s not a lot new in this data to be honest, but it confirms a lot of what everyone believes is happening. We are converging on a single device format in mobile and that’s driving some important changes in usage. We are in the phablet era.

Everything I needed to know about good user experience I learned while working in restaurants

Waiter and cook working in a restaurant.

At the Neilsen/Norman Group’s blog, Everything I Needed to Know About Good User Experience I Learned While Working in Restaurants lists the many things that you can learn from restaurants and apply to your applications, from designing for both new and expert users to interaction design and error handling to community management.

If you’re not familiar with the Nielsen/Norman Group, they’re the “Monsters of Rock” of user interface and experience. Their principals are:

The cautionary lessons of Evernote’s “5% problem”

An out-of-focus Evernote icon.

Evernote used to be my go-to note-taking app in 2011. I worked across platforms, and I loved that I could start a note on my laptop, continue on my iPad, and then later make tweaks or addenda on my phone. But as time went by, it got buggier and increasingly less usable to the point where I abandoned it worse and buggier until I abandoned it in annoyance.

Their note-taking app got buggier as the company tried to expand so that they had offerings that would appeal to as many people as possible. Therein lay their problem: as their own former CEO put it, people at Evernote conferences would go up to him and say that they loved the platform, but used only 5% of what it could do. The problem was that there was a different 5% for every person. They spread themselves too thin, lost their focus, started half-assign their product lines, and in an attempt to please everyone, ended up annoying them.

Keep calm and carry on developing Android apps

The classic 'Keep Calm and Carry On' poster.

You may have heard that the ongoing legal battle between Oracle (who own Java) and Google (who own Android, which is Java-based) has led to Google’s decision to move from their proprietary version of the JDK to Oracle’s OpenJDK. You may be concerned, but you probably shouldn’t be. It may cause headaches for Google and Android mobile phone vendors, but as Android developers, it shouldn’t really affect you.

As Android developer and online tutor Tim Buchalka puts it:

We write our code accessing the same libraries, and things just work. Of course its going to be a decent chunk of work for Google to get this all working so that we dont have to worry about it, but if anyone has the resources to do it, Google do.

What do you need to do as an Android developer? Absolutely nothing, its business as normal! You dont need to change anything in your development process and it may well be that when Android N arrives you won’t have to either. So fire up Android Studio, and get back to coding!

A story you might not know about Microsoft Solitaire: it was created by a summer intern!

Screen shot of Microsoft Solitaire on Windows 3.1

Is Wes Cherry a bit annoyed that he never got paid to write one of the most-used applications of the Windows 3.x/9x days? He once answered “Yeah, especially since you are all probably paid to play it!”


Pivoting is the sincerest form of flattery (or: What the Android team did when the iPhone was announced)

Photoillustration of a woman photocopying an iPhone.

Relax, Fandroids. I kid because I care.

Cover of 'Dogfight' by Fred Vogelstein.“As a consumer, I was blown away,” says Googler Chris DeSalvo in a quote from Fred Vogelstein’s book, Dogfight, upon seeing the now-legendary January 9, 2007 Stevenote when he unveiled the first iPhone.

“I wanted one immediately,” DeSalvo continues. “But as a Google engineer, I thought ‘We’re going to have to start over.’

According to the Atlantic article The Day Google Had to ‘Start Over’ on Android, an excerpt from Dogfight, Google’s big concern at the time was Microsoft. It made sense at the time: They seemed to be making the right moves. If you remember those days, Windows Mobile 5.0 was the third revision of their mobile operating system, and true to the general rule about Microsoft revs, it was finally good enough. They’d lined up an impressive array of nearly 50 hardware partners, including HTC, who’d end up shipping the most WinMo phones, and the big coup: Palm, whom they’d convinced to build phones that ran WinMo. Their OS featured mobile versions of Office. The industry rumblings were that Microsoft would end up eating away at the dominant phone OS player at the time, Symbian. “Microsoft comes out fighting when threatened,” the conventional wisdom said. “Remember what happened in the browser wars?”

Here’s what was considered to be the game-changer that would make Microsoft a serious mobile threat: the Palm Treo 700w

Palm Treo 700w phone

The Palm Treo 700w.

The best smartphones of the era followed a design template that had been defined years earlier by the Blackberry: screen at the top, physical keyboard at the bottom, augmented by some kind of device to move the cursor (first a scroll wheel, then a D-pad, and optionally, a stylus).

Then this happened:

(If you haven’t seen it before or in a while, watch it again. You can almost feel the audience’s excitement in the opening moments, as Steve teases them with hints of what he’s about to announce. You can also feel the envy when Google’s Eric Schmidt comes onstage at the 51-minute mark — remember that he was on Apple’s board then.)

From the article:

On the day Jobs announced the iPhone, the director of the Android team, Andy Rubin, was six hundred miles away in Las Vegas, on his way to a meeting with one of the myriad handset makers and carriers that descend on the city for the Consumer Electronics Show. He reacted exactly as DeSalvo predicted. Rubin was so astonished by what Jobs was unveiling that, on his way to a meeting, he had his driver pull over so that he could finish watching the webcast.

“Holy crap,” he said to one of his colleagues in the car. “I guess we’re not going to ship that phone.”

Another key quote, this time from Ethan Beard, one of Android’s early biz dev people:

“We knew that Apple was going to announce a phone. Everyone knew that. We just didn’t think it would be that good.

With the announcement of the iPhone, the Android project, whose members had been working “sixty-tp-eighty-hour weeks for fifteen months — some for more than two years” made a pivot whose effects we’re still feeling today. The BlackBerry-like phone that they’d been working on — codename “Sooner”, with a physical keyboard, no touchscreen, and a general “me-too” design — was pushed aside. They filed mobile phone-related patents galore in September 2007. The iPhone forced them to rethink the OS and phone design, and from that came a new design, codenamed “Dream”. This pivot would require them to delay their first release by a year, and the end result was the HTC Dream, released in October 2008.

HTC Dream phone, shown in landscape mode with the sliding keyboard extended.

The HTC Dream.

As you can see, the Android weren’t so sure about all of Apple’s design decisions, hence the physical keyboard and trackball. Today’s phone designs tell you how those choices by the Android team worked out.

I’ll close with an observation based on the article by John “Daring Fireball” Gruber. He may be Apple’s freelance PR guy, but he’s often right, including in this case:

Remember a few years ago, at the height of the “Android is a ripoff of the iPhone” controversy, when Android supporters claimed that the similarities were just some sort of amazing coincidence, like Newton and Leibniz discovering calculus concurrently, because Android had started life a few years before the iPhone was introduced? Good times.

I’m going to get my paws on a copy of Dogfight and read it over the holidays. Expect a review of it in the coming weeks.



iOS Fortnightly Tutorial: A Simple Weather App, Part 2

sorry were busyI know, I know, it’s been over a fortnight since I last post a tutorial. Things have been a little bit crazy at work, but I plan to hope to use the next couple of days to get caught up, and then post a new tutorial next week.

In the last installment, I posted another installment of my iOS development tutorial series, iOS Fortnightly: SimpleWeather, a simple weather app that made use of the AFNetworking library to fetch the current weather conditions for any given city from Open Weather Map. If you’d followed the tutorial to the end, you’d have an app that looks like this when immediately after you launch it:

…and here’s what it looks like when displaying the current weather:

It’s nowhere near ready for the App Store, but in a few lines of code, it accomplishes a fair bit. If you’re new to Objective-C, it also covers some unfamiliar territory. This week’s set of articles will expand on the Simple Weather app. In this one, I’ll explain those parts of the code that might not be familiar to the novice iOS developer, namely Objective-C’s blocks and properties.

JSON Requests in AFNetworking

AFNetworking logoThe meat of the SimpleWeather app is in the Weather class’ getCurrent: method. It makes the call to Open Weather Map’s API, and it does so with this line:

AFJSONRequestOperation *operation =
[AFJSONRequestOperation JSONRequestOperationWithRequest:weatherRequest
    success:^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
        weatherServiceResponse = (NSDictionary *)JSON;
        [self parseWeatherServiceResponse];
    failure:^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON) {
        weatherServiceResponse = @{};

AFJSONRequestOperation is a class in the AFNetworking library for requesting and retrieving JSON data from a given URL. It has a single method, a class method called JSONRequestOperationWithRequest:success:failure:. Here’s what its declaration looks like:

+ (AFJSONRequestOperation *)JSONRequestOperationWithRequest:(NSURLRequest *)urlRequest 
    success:(void ( ^ ) ( NSURLRequest *request, NSURLResponse *response, id JSON ))success
    failure:(void ( ^ ) ( NSURLRequest *request, NSURLResponse *response, NSError *error , id JSON ))failure

JSONRequestOperationWithRequest:success:failure: is a method that makes a request for some JSON from a given URL and:

  • Does something if the requested JSON was successfully received
  • Does something else if the requested JSON was not successfully received

Here are the method’s parameters:

Parameter Name Description
urlRequest A NSURLRequest object representing our request for the current weather from Open Weather Map.
success A function that should be executed if the operation was a success, meaning that the requested JSON object was successfully retrieved.
failure A function that should be executed if the operation was a failure. This could mean that requested JSON object was not successfully retrieved, or that it was successfully retrieved, but couldn’t be parsed as JSON.

The urlRequest argument is pretty straightforward, but the success and failure arguments look more complicated. They’re block literals, and to talk about them, we need to talk about blocks.

A Very Quick Intro to Objective-C’s Blocks

If you’re reasonably well-versed in JavaScript, it’s quite likely that you’re familiar with anonymous functions. Here’s a quick and dirty example: an anonymous function that takes two numbers and returns their sum, stored inside a variable named doSomething:

var doSomething = function(firstNumber, secondNumber)
  return firstNumber + secondNumber;
alert(doSomething(2, 3));

In Ruby, there are a couple of types of anonymous functions: procs and blocks. Procs are the anonymous function type that you can bind to a local variable, which is close to the spirit of anonymous functions in JavaScript and Objective-C. Here’s the Ruby version of the anonymous function from the example above:

doSomething = {|firstNumber, secondNumber| firstNumber + secondNumber}
puts, 3)

And now, the Objective-C version:

int(^doSomething)(int, int) = ^(int firstNumber, int secondNumber) {
        return firstNumber + secondNumber;
NSLog(@"%d", doSomething(2, 3));

It’s not all that different from the JavaScript and Ruby versions; it’s just that Objective-C requires explicit type information. Let’s take a look at the left side of the assignment first:

int(^doSomething)(int, int)

Here’s where cdecl comes in handy. It’s a site that translates declarations and casts from “C gibberish to English” and vice versa, comes in quite handy.

Enter int(^doSomething)(int, int) into cdecl. cdecl will translate it as “declare doSomething as block (int, int) returning int“. This in turn can be interpreted as “doSomething is a variable containing an anonymous function that takes two ints and returns an int“.

Now let’s look at the right side of the assignment:

^(int firstNumber, int secondNumber) {
        return firstNumber + secondNumber;

With the exception of the ^ character in front of the parameters, it looks like a like a standard function definition.

JSONRequestOperationWithRequest‘s Block Parameters, success and failure

Let’s look at JSONRequestOperationWithRequest‘s success parameter, which expects a block that should be executed if the JSON request operation is a success. Here’s its type:

(void ( ^ ) ( NSURLRequest *request, NSURLResponse *response, id JSON ))

This means that it expects a function that expects three parameters of type NSURLRequest *, NSURLResponse *, and id, and doesn’t return anything. Here’s what we’ll pass to it:

^(NSURLRequest *request, NSHTTPURLResponse *response, id JSON) {
    weatherServiceResponse = (NSDictionary *)JSON;
    [self parseWeatherServiceResponse];

It does two things:

  • It takes the retrieved JSON, casts it to NSDictionary *, and stores it in the instance variable (or, as they like to say in Objective-C, ivar) weatherServiceResponse. Note that the block “knows” about weatherServiceResponse
  • It calls the method parseWeatherServiceResponse, which extracts the data from the JSON retrieved from Open Weather Map and puts them into the instance variables behind the class’ properties.

Let’s now look at JSONRequestOperationWithRequest‘s failure parameter, which expects a block that should be executed if the JSON request operation is a failure. Here’s its type:

(void ( ^ ) ( NSURLRequest *request, NSURLResponse *response, NSError *error , id JSON ))

This means that it expects a function that expects four parameters of type NSURLRequest *, NSURLResponse *, NSError * and id, and doesn’t return anything. Here’s what we’ll pass to it:

^(NSURLRequest *request, NSHTTPURLResponse *response, NSError *error, id JSON) {
    weatherServiceResponse = @{};

Right now, we’re not worrying about what to do in the event of a failure, so for the moment, the failure block simply sets weatherServiceResponse to be an empty dictionary.

A Quick Look at Objective-C’s Properties and the Invisible Goodies that Come with Them

Consider the first line in the parseWeatherServiceResponse method:

_cloudCover = [weatherServiceResponse[@"clouds"][@"all"] integerValue];

If you look around the class, you’ll find that the variable _cloudCover hasn’t been declared anywhere. Yet Xcode hasn’t thrown up any error messages, and it colour-codes it as it would any declared variable. What’s going on here?

It turns out that there’s a little behind-the-scenes magic that takes place whenever a @property is declared. If you look in Weather.h, you’ll see this declaration:

@property (nonatomic, readonly) NSInteger cloudCover;

Implicit in this declaration is this corresponding line in the class’ .m file:

@synthesize cloudCover = _cloudCover;

This line doesn’t actually appear in the .m file, but it’s effectively there thanks to a little compiler magic. @synthesize itself does its own magic; it creates an invisible corresponding instance variable and invisible “getter” and “setter” methods. Implicit in the line above is this instance variable declaration:

NSInteger _cloudCover;

and these methods:

- (NSInteger)cloudCover {
    return _cloudCover;

- (void)setCloudCover:(BOOL)newValue {
    _cloudCover = newValue;

Property and ivar Order

Speaking of properties and ivars, take a look at the order of the ivars in parseWeatherServiceResponse, which lives in Weather.m:

- (void)parseWeatherServiceResponse
// clouds
_cloudCover = [weatherServiceResponse[@"clouds"][@"all"] integerValue];

// coord
_latitude = [weatherServiceResponse[@"coord"][@"lat"] doubleValue];
_longitude = [weatherServiceResponse[@"coord"][@"lon"] doubleValue];

// dt
_reportTime = [NSDate dateWithTimeIntervalSince1970:[weatherServiceResponse[@"dt"] doubleValue]];

// main
_humidity = [weatherServiceResponse[@"main"][@"humidity"] integerValue];
_pressure = [weatherServiceResponse[@"main"][@"pressure"] integerValue];
_tempCurrent = [Weather kelvinToCelsius:[weatherServiceResponse[@"main"][@"temp"] doubleValue]];
_tempMin = [Weather kelvinToCelsius:[weatherServiceResponse[@"main"][@"temp_min"] doubleValue]];
_tempMax = [Weather kelvinToCelsius:[weatherServiceResponse[@"main"][@"temp_max"] doubleValue]];

// name
_city = weatherServiceResponse[@"name"];

// rain
_rain3hours = [weatherServiceResponse[@"rain"][@"3h"] integerValue];

// snow
_snow3hours = [weatherServiceResponse[@"snow"][@"3h"] integerValue];

// sys
_country = weatherServiceResponse[@"sys"][@"country"];
_sunrise = [NSDate dateWithTimeIntervalSince1970:[weatherServiceResponse[@"sys"][@"sunrise"] doubleValue]];
_sunset = [NSDate dateWithTimeIntervalSince1970:[weatherServiceResponse[@"sys"][@"sunset"] doubleValue]];

// weather
_conditions = weatherServiceResponse[@"weather"];

// wind
_windDirection = [weatherServiceResponse[@"wind"][@"dir"] integerValue];
_windSpeed = [weatherServiceResponse[@"wind"][@"speed"] doubleValue];

In this method, I’m extracting data from the JSON objects returned by Open Weather Map, so they’re ordered from that perspective: by the keys of the top-level dictionaries in alphabetical order: clouds, coord, dt, main, name, rain, snow, sys, weather, wind. Those dictionaries’ elements are also listed in alphabetical order by key. The idea is to make things easy to find when programming with Open Weather Map’s API in mind.

The order of the corresponding @properties exposed in Weather.h is different. Here, I also want things to be easy to find, but I also want to abstract away any details about the format in which Open Weather Map returns its info. Instead, I want an order that’s useful for when you just want the weather, so I’ve used comments to break the properties into three groups: place and time, qualitative, and quantitative.

// Properties
// ==========

// Place and time
@property (nonatomic, copy, readonly) NSString *city;
@property (nonatomic, copy, readonly) NSString *country;
@property (nonatomic, readonly) CGFloat latitude;
@property (nonatomic, readonly) CGFloat longitude;
@property (nonatomic, copy, readonly) NSDate *reportTime;
@property (nonatomic, copy, readonly) NSDate *sunrise;
@property (nonatomic, copy, readonly) NSDate *sunset;

// Qualitative
@property (nonatomic, copy, readonly) NSArray *conditions;

// Quantitative
@property (nonatomic, readonly) NSInteger cloudCover;
@property (nonatomic, readonly) NSInteger humidity;
@property (nonatomic, readonly) NSInteger pressure;
@property (nonatomic, readonly) NSInteger rain3hours;
@property (nonatomic, readonly) NSInteger snow3hours;
@property (nonatomic, readonly) CGFloat tempCurrent;
@property (nonatomic, readonly) CGFloat tempMin;
@property (nonatomic, readonly) CGFloat tempMax;
@property (nonatomic, readonly) NSInteger windDirection;
@property (nonatomic, readonly) CGFloat windSpeed;

As with the ordering in parseWeatherServiceResponse, the objective is to make things easy to read and find, but this time, I’m doing so not from the perspective of a programmer trying to get data from the Open Weather Map API, but a programmer trying to get data from an instance of the Weather class.

Previous Installments in the iOS Fortnightly Series

In case you missed them, here’s a list of the previous articles in this series:


Results from the LinkedIn “Information Security” Group’s 2013 BYOD/Mobile Security Survey, Part 1: The State of BYOD

A few weeks back, Holger Schulze put out the call on his Information Security group on LinkedIn for respondents to a survey on BYOD and mobile security practices. Of the group’s approximately 160,000 members, 1,650 took the survey. He’s since tallied the results and published them online:

In this article, we’ll look at those results that describe the state of BYOD at the organizations represented by the respondents.

BYOD Adoption in Organizations: Still a Long Way to Go

byod adoption stage

60% of the organizations represented in the survey have not yet adopted BYOD, but are considering it. 24% are working on the policies and practices to implement a program, and about 10% of the people who haven’t yet adopted BYOD haven’t do so because they’re forbidding it outright.

byod readiness

It’s always a tricky thing to ask people to quantify a “gut feeling” with questions like “How would you rate your readiness for full enterprise BYOD adoption, in percent, where 100% is completely ready?” What’s the difference between 20% ready and 30% ready? Or 70% ready and 80% ready? Still, the fact that most of the organizations represented in the survey say that they’re less than 50% ready to adopt BYOD says that there’s a lot of uncertainty about their ability to set up a BYOD program.

In the meantime, here’s what the organizations are doing right now:


Note that in the chart above, both “Privately-owned devices are in very limited use” and “Privately-owned devices are widely in use, but not supported by the organization” are the 3rd and 4th most popular categories, each accounting for more than 20% of the respondents. That’s a good chunk of people who are accessing corporate resources with any policies or technologies to manage them; in some cases, IT would probably be completely unaware of how widespread the practice would be. We like to call this practice SYOD — “Smuggle Your Own Device”; others like to simply put it under the larger blanket term “Shadow IT”; either way, it has the potential to cause you great trouble.

Simply put: most organizations still have a long way to go before they’re truly ready to support employees bringing their own devices for work.


BYOD Roundup: The “BYOD for You” Book, Liability, and Shadow IT

A New Book: BYOD for You

byod for you cover

Most BYOD guides we’ve seen cover BYOD from management’s or the IT department’s point of view; BYOD for You is the first we’ve seen that covers it from the rank-and-file employee’s angle. Written by Daniel Lohrmann, who blogs at Government Technology and has a site at, this Kindle ebook is a quick read that helps you determine an organizations BYOD maturity level, secure your BYOD mobile device and maximize its benefits, and how to cope with the way personal mobile devices are handled where you work.

BYOD for You is an easy lunchtime read; it’s divided into eight chapters, most of them about a half-dozen pages long, which cover these topics:

  1. Categorizing your BYOD enivronment: Gold, Silver or Bronze?
  2. Your workplace’s BYOD program, or the lack thereof
  3. Security: How to safely use your mobile device at work and home
  4. MDM
  5. Privacy and other legal considerations
  6. Maximizing the financial benefits of BYOD
  7. Ethical dilemmas and proving you deserve your mobile device
  8. Building a personalized BYOD plan that outlives your device

Each of the chapters end with a section that provides suggestions on how to handle its topic depending on the BYOD maturity level of your organization. Lohrmann’s model for BYOD maturity has three levels, which are explained below:

  • Bronze: An organization operating at the Bronze BYOD level has employees who bring their own devices to work, but doesn’t have an official BYOD policy. It’s unclear about what happens when company information security policies and personal devices collide, if employees’ personal data will remain private, or if their work-related activities on personal devices will get them in trouble. Employees also bear all costs of using the device, even for work-related purposes. MDM is practically or completely non-existent.
  • Silver: In organizations operating at the Silver BYOD level, there is a basic BYOD policy that spells out how its data can be accessed, as well as issues of security and privacy, and there is tacit permission for employees to access their work email from their devices. Employees can choose between all-expenses-paid COPE devices or BYOD devices without any reimbursement for operating costs. MDM is limited; it’s often something basic, like what’s provided by Microsoft Exchange ActiveSync.
  • Gold: At the Gold level of BYOD, there’s a full BYOD policy, and employees are fully reimbursed for all device costs. All devices are under full MDM.

Even though it’s written for end users at a workplace, it’s a useful guide for managers who are new to the idea of BYOD and want to get a grasp of the major issues that can arise when employees bring their own devices to work. I expect that we’ll be using this in our consulting work and recommending it to our customers.

There’s a special deal if you buy it today (Wednesday, April 17, 2013): it’s selling at a dollar off — a mere CAD$3.03 at, and USD$2.99 at

BYOL: Bring Your Own Liabilities


Mobile technologies bring new capabilities, but new complications as well. The CIO article BYOL: Bring Your Own Liabilities points out that the dual nature of BYOD devices — owned by the employee, but used part of the time on behalf of the company (and possibly subsidized) — present some new potential legal issues, whether or not your organization has a formal BYOD program. The article lists a number of ways you can reduce the risk of legal exposure in your BYOD program; the article goes into more detail, and we’ve summarized the main points below:

  • Policy: The article says that a policy defining your organization’s BYOD program is most important element of any BYOD strategy, and we’re inclined to agree. Such a policy should clearly define how your BYOD program will operate, specify the risks and responsibilities of the organization, employees and third parties, and define acceptable technologies and acceptable use. Most of it shouldn’t have to address legal issues, but having such a policy will help reduce your legal exposure. (By the bye, we’re pretty good about crafting mobile device policies, and we even have a guidebook to help you build your own.)
  • Liability issues: Figure out whether your organization or your employees are liable in certain cases, such as: Who’s responsible for misplaced or stolen devices? Who’s responsible in the event of a malware attack? Who pays for support?
  • Licensing: Are the apps on mobile devices — both company- and employee-owned — properly licensed?
  • Insurance: Will your organization’s insurance policy cover devices that it doesn’t directly own or lease?
  • Data security: As the article says: “Two topics generally colour the legal framework in the context of data security; these are confidential information and litigation obligations, both of which are concerns for any mobility based system.”
  • Confidentiality: We take our mobile devices (especially our smartphones) everywhere, and sooner or later, they’ll get lost or stolen. You need to consider the implications of missing mobile devices, from the loss of your organization’s sensitive information, to inadvertent breaches of confidentiality agreements with other parties, to remote wipes, to the consequences of remotely wiping an employee’s personal data. Along with the issues that come with confidential or sensitive data on the device, there’s also the issue of such data off the device, stored with third-party cloud services like Dropbox.
  • Discovery obligations: Data stored on mobile devices used for work may be subject to electronic discovery, the pre-trial phase in litigation where each party can get evidence from the opposing party. You may need to take measures to keep work and personal data separate, keeping in mind that your organization can’t object to producing some information in the discovery process simply because it has some personal employee information mixed in.
  • Privacy: One reason to try to keep work and personal data separate is to preserve employee privacy, especially when backing up information. Ideally, you want to back up only the work-related information and store no personal employee information (such as their address book or photos) on your organization’s backup system.
  • Surveillance and tracking: The ability to remotely track a device is a useful thing to have when it’s lost or misplaced, but it can be a cause for concern about its use for tracking employees. The article recommends the use of a data surveillance policy that clearly spells out how devices will be tracked, and if your organization will record information stored or transmitted by the device.

BYOD and Shadow IT

the shadow strikes

From an earlier article:

Shadow IT sounds like some kind of future slang that [William] Gibson would’ve coined, but it’s an office term referring to the set of applications and systems that are used in organizations without that organization’s approval, and especially without the approval of the IT department. It’s usually the result of one or a handful of employees discovering an application, service or system that solves a problem in a way that seems more effective, expedient, and more free of red tape than if it were solved by IT. Shadow IT usually starts off as an ad hoc solution, but if it becomes popular within an organization, its use can become standard practice, even without the approval or oversight of the IT department.

When people talk about shadow IT, they usually talk about the security issues. Mike Foremen in Huffington Post UK writes about another equally important issue: the creation of data silos, where information vital to the business lives in places where it can’t be found.


Led Down the Garden Path [Updated]

now sending your address book

Update: Path’s CEO has apologized and promised to delete any collected data. See this entry.

It’s the top story on Techmeme at this moment: the socially-networked “lifestreaming” iPhone app known as Path uploads your entire address book to its servers.

This fact was discovered by Denso developer Arun Thampi when he decided that he’d build a Mac OS X client for Path at his company’s hackathon. To do this, he decided to observe the API calls that Path made to its servers only to discover that the data for his Contacts app – names, email addresses, phone numbers – was getting HTTP POSTed to To see the the full story, be sure to read Arun’s blog entry on the matter.

Path CEO Dave Morin sent a reply to Arun, explaining that the data is used only to help users connect to their friends and family and nothing more. He also said that they “proactively rolled out an opt-in for this” on their Android client a few weeks ago and will include the same opt-in feature on the next version of the iOS client. For anyone who has the current version on their iPhone, that feature came a little too late. This is bad, and the fact that Path has recently been working on “proactive” fixes suggests that they know it.

I have Path on my phone because it’s a gorgeous app and a number of my friends and coworkers were on the network and encouraging me to take it for a spin. That means that my contact info resides on Path’s servers. A good chunk of my life is public by my own choice, so I can live with Path having my own address and phone number, but nobody else on my contacts list signed up for that. Furthermore, inclusion in my contacts list doesn’t necessarily imply that they’re someone I want in my social network graph. But Path can’t discern between my friends and family and others like my ex-wife, my local cab company or that client in Australia who just had a couple of questions. You’d think that Path would’ve learned the lessons of “Fuck You Google”, in which a woman wrote about how Gmail overshared her info with her abusive ex-husband.

It’s an even bigger problem in the case of celebrities, who presumably have other celebs’ numbers in their on-phone Rolodexes. Take a look at this tweet from Alyssa Milano:

The response, by the way:

And did it also upload my notes about people? (Yes, I’m one of those people who actually uses the “Notes” field in Contacts. For business contacts, it’s all part of the schmooze; for friends and family, it’s so I remember things like their likes, dislikes, birthdays, anniversaries and other little things.)

In the comments to Arun’s article, iOS developer Matt Gemmell suggests the following to Dave Morin:

Why are you uploading the actual address book data, rather than (say) generating hashes of the user’s email addresses locally, then uploading just those hashes? You’d be able to do friend-finding that way, and similarly if you uploaded hashes of all email addresses in the user’s address book, you’d be able to do your notifications of when a friend joins. At no point would your servers ever need to see the actual email addresses or phone numbers from our contacts.

He also points out that sending the entire Contacts database to their servers may be a violation of the App Store’s terms and conditions. In fact, section 17.1 of that T&C states:

17.1: Apps cannot transmit data about a user without obtaining the user’s prior permission and providing the user with access to information about how and where the data will be used.

Dave Morin’s been firefighting ever since the news about Path got out. He’s stayed on message with the “we’re not trying to be evil here” line, but with the faith in Google’s “Don’t be evil” mantra pretty much gone, it’s not very reassuring. On the bright side, he has made it clear that if you want your address book and even your Path account deleted from their servers, you have but to send an email to

Update (February 8, 2012): Mike Arrington has put online what I’d been thinking (but didn’t think Path would ever do without a lot of pressure): they should simply delete all the address book data they pulled. It would be an excellent goodwill gesture; let’s see if they take up his suggestion.

(Little hint, Dave: if you keep overusing “proactive” and “proactively” the way you have in your responses and tweets, it becomes a filler word, like “um” and “uh”. Especially when such “proactivity” seems limited to stating that you’re not doing anything wrong.)

There’s been some freaking out over Path in the comments for Arun’s blog entry as well as in other venues online, but it’s time to let cooler heads prevail. Let’s see what Path does in the next 48 hours – as Arun himself puts it, “I hope we can keep calm and continue to discuss this sensibly”.

If you’re developing software that makes use of people’s personal info, let this be a lesson!


Dear Microsoft: Just Update My Photo and We’ll Be Cool

If you were to go to Microsoft Canada’s blog for mobile developers as of this writing, you’d still see my photo in the banner:

canadian mobile developer banner

I really have no complaints about still having my face there, even though my last day at The Empire will be five months ago tomorrow. Being the Windows Phone guy was one of my favourite parts of my stint as a developer evangelist at Microsoft, and it’s always an honour to share a banner with Frederic Harper.

My real complaint is that the picture they’re using is from two years, and more importantly, twenty pounds ago (about the weight of a full-sized accordion).

Hey Microsoft: keep my picture up if you must, but could you at least use a newer, somewhat skinnier one? Perhaps one with me sporting my new, fashionable, I probably-paid-too-much glasses with Philippe Starck frames?

Self-portrait of Joey deVilla, taken in a mirror, showing off his new glasses

(By the bye, that’s my bathroom in the photo. I have a damn fine “re-bachelor” pad.)

If you’d much rather have a photo keeping with the mobile theme, may I suggest this one, where I’m posing with a phone and a wacky phone accessory? The pink says “Metro” – in every sense of the word!

"Moshi Moshi Metro!" Joey deVilla at Cafe Novo, holding Verna Kulish's pink iPhone connected to a pink Moshi Moshi handset.

That’s my friend and fellow ex-Microsoftie Verna Kulish’s Moshi Moshi Retro POP handset, which plugs into just about any smartphone. Feel free to Photoshop out Verna’s iPhone and replace it with an appropriate Windows Phone device – perhaps a Samsung Focus (my Windows Phone) or whatever Nokia’s releasing this fall.

Feel free to use either pic, Microsoft – as long as it’s current and skinnier, we’ll be cool.

This article also appears in The Adventures of Accordion Guy in the 21st Century.