Mobile Apps & Informed Consent

Around the time the Cambridge Analytica scandal was dominating headlines, I was at a wedding, seated next to a digital marketer. Unsurprisingly, the illicit gathering of millions of people’s detailed Facebook data in order to create psychographic profiles came up in our conversation, and we both agreed that compiling personal information without consent was clearly wrong and absolutely inexcusable.

But, we sheepishly admitted, wouldn’t it be cool to see that data!?

This, of course, is the dilemma facing marketers and researchers today, even those without a shred of malicious intent. Massive amounts of personal data can be incredibly valuable, and not just in a financial sense. But ensuring that this data is collected with informed consent can be difficult. Many researchers have a defined set of participants who can be asked for their consent in person, with a human being available for questions. But in an “open” study, with a free app downloaded from the app store, the consent process is generally relegated to a pop-up dialog with a lot of text which–as a rule–is never read.

Furthermore, the definition of “informed consent” can be murky. In the case of the Cambridge Analytica scandal, Facebook’s initial non-apology apology was a PR failure, but to some extent accurate: the original users of the app were informed their data would be used for a study and they did consent to give it away. What wasn’t clear was how that data would be used (sold for use for political rather than academic purposes), nor that their entire social network would be scoured as well.

Our partners and we have struggled with this issue (or ones like it) in almost every project we’ve done. How much explanation is necessary to consider “consent” to be “informed”? If the user doesn’t or won’t read your carefully worded legalese, is that on you or them? How do you balance the user experience between one which informs completely and one which causes the user to give up and uninstall?

These are some of the subtle but important questions you’ll need to ask yourself as you design apps for research purposes.

Thanksgiving Leaves

Eat. Relax. Be with Family.

One of my strongest memories from my early work years is when I was an intern-of-sorts at IBM. It was my first day of work, and we were working on improvements in the Lempel-Ziv compression algorithm (very cool). Five o’clock rolled around and I was packing up my stuff: reading materials, notes, pads & pens, etc. Then suddenly I realized: my work day was over. I didn’t actually have to bring anything home! I could just leave, and start again tomorrow.

I’m embarrassed to admit that may have been one of the last jobs where I truly stuck to a regular work schedule like that. The jobs I’ve held since then have been mostly excellent: generally enjoyable, intellectually stimulating, and goal-oriented rather than hours-oriented. But sometimes those same attributes makes it harder to leave off work when I should.

Which, I suppose, is now. Today is Thanksgiving, and I’m about to head over to the in-laws for the big meal. Soft Crow is closed, and will be tomorrow. Here’s hoping you and yours have a good time off; we’ll see you Monday.

App Store Insanity

Back in the day, the apps I wrote were distributed very differently than they are now. Our little early-90s startup made applications for Windows (Version 3! In color!) and there was a whole department dedicated to copying the disks, adding labels, packaging, and getting them to the distributor so that, within a few weeks at least, they’d be available for purchase at your local Babbages.

Obviously, in many ways it’s much easier now to get your application to the people who need it: with a bit of luck, an app I wrote this afternoon could be on millions of people’s phones by this evening. And if you’re working directly with your users — say, if they’re participants in a study — you don’t even need to guide them through the install process. By now, pretty much everyone with a smart phone knows how to download and install apps from the app store.

As is often the case, though, the new way of doing things introduced new problems as well. In the US and much of the western world, Google and Apple are an app marketplace duopoly. And sadly, they are also a prime example of what makes lack of competition so problematic.

Apple’s App Store

When we set up app delivery schedules with our partners, we are always careful to leave a week or so between “the app is fully tested and ready to go” and “your users can install the app from Apple’s App Store”. Invariably, when we do this the long hours we’ve all worked to get the app finished with an extra week left in the schedule are moot and the app is approved and launched within 24 hours. Unless we don’t build in the extra week and attempt to launch with just a day remaining; in that case the approval process does take a week and our deadline is missed.

As you can imagine, this is deeply frustrating to everyone, but there’s no way around it: the ways of the App Store are beyond the ken of us mortal folk. Apps can be rejected for the flimsiest of reasons; more than once we’ve had apps rejected simply because the reviewer didn’t bother to read the explanatory notes we included in our submission. And the appeal process is just as arbitrary. I don’t believe we’ve ever actually gotten a response to an appeal; the app just gets approved without comment.

We make all of this as clear as possible to our partners, and over the years we’ve developed a number of little tricks that can approve our chances. But if you want your app to be publicly available on the Apple App Store, you have to accept the fact that distribution is essentially out of your control.

The Google Play Store

Historically, Google’s Play Store has been just as opaque, but at least a bit quicker to approve apps. Google’s app submission process is far more automated than Apple’s, which means the expected delay between finishing your app and getting it out to your users will generally be a matter of hours rather than days.

This may be changing though, since Google has come under fire for letting too many malicious apps slip through their submission process. In particular, apps designed for children are now being reviewed by human reviewers and may take longer to get into the Play Store. Or so we assume; again, the process itself is a black box.

Making It All Work

Despite these issues, if I were given an option, I wouldn’t return to the days of loading an app from a series of sequentially numbered floppy disks. The submission process can go smoothly and even quickly, but you must allow for the possibility that things may go slowly or flat-out wrong. And it never hurts to keep your fingers crossed…

Only the beginning…

At Soft Crow Solutions, we partner with research teams and non-profits to build websites and mobile apps to strengthen proposals, improve data collection, and enhance analysis.

As anyone who’s been on a committee to draft one knows, coming up with a “mission statement” can be an arduous process. They tell us it’s an important thing to do for your organization, but it often feels like “they” haven’t spent time arguing whether a 20-word sentence is too long or too short, or whether “synthesize” sounds too “jargon-y”.

Which is why I was pleasantly surprised to find that coming up with Soft Crow’s mission statement, as seen at the top of this post, was actually pretty easy. We went through a few drafts of course, but in the end what we do (and why we do it) was straightforward.

Still, it’s only a sentence. And a sentence can’t tell you everything you need to know about the values and principles and processes of a group of people who have worked on many projects over many years. Which is why I’m writing this blog post; in fact, it’s why we’ve got the whole blog.

Our goal for the Soft Crow blog is to bring you some of that extra information about our company: what we do, what we’ve learned, what we value. Honestly, I don’t quite know what that will look like yet. But here’s hoping it’s fun and interesting… at least more fun and interesting than a mission statement committee.