Shortlog - a log of everyday things



I met with Dave Wagner early today so we could go to Adrienne Porter Felt's dissertation talk. It was a great talk - she crystallized a number of the things I've been thinking about for the past few months into an easy-to-grok talk that hit on a ton of important points in a methodical manner. It turns out we'd both determined that run-time permission grants are better than install-time permission grants. She's worked out several more details, and produced some guidelines for platform designers to make their permission systems more usable and effective. The most important take-away was the following:

When building a platform, if you want to give third-party developers access to some privilege, use these interactions in the following priority order:

  1. No interaction. If an action can be safely and easily undone, just do it, and let the user undo it if they don't like what happened. It's nice to give the user some way to find out why something happened though, so if you can, leave some sort of audit trail. (Example: setting a background on your phone - set it, and show what application last set it and when with an undo button when you view the background settings.)
  2. Trusted UI. Users know what they're trying to do already. Give developers widgets that they can put in their app that will allow the user to trigger the desired action. Key bit: make it so that these widgets are the only way by which these permissions are available to apps. (Example: a button that sends an SMS when the user presses it. There can be implementation difficulties here, and this can also restrict what can be done with the platform. I'd like to think about the implications of trusted UI a little more before deciding it's a great solution.)
  3. Runtime permission grants. Users are much better at understanding their decisions in context - you might not know at install time why your bank app needs access to your location, but if it asks right after you hit the "Locate ATMs near me" button, well, that makes sense then. (Example: accessing contacts or your current location. It's possible some of these instances could be factored into trusted UI.) This should be used if the user can be expected to be available to approve the request, but the system is responsible for initiating the flow that requires the permission.
  4. Install-time permission grants. These should be reserved for things where the user can't be expected to be available to approve an action. (Example: app that wipes the phone remotely if it's stolen. It would think that the thief would select the option to allow the app to perform this action.)

Real-world notes: Android's permission system is basically entirely install-time permission grants, which is one of the reasons that permissions on Android are a ****show from a usability perspective. iOS uses runtime permission grants for location tracking and notifications, and has no interaction for most other permissions, but doesn't really allow for as powerful a separation of privilege, since there are basically no other permissions.

After the dissertation talk, I went upstairs to see the CS160 (undergrad HCI class) poster presentations, where students were showing off a bunch of projects relating to applications of the Kinect depth camera. There were a couple neat ones - the use of the Kinect to teach ballroom dance steps and posture was probably my favorite.

I ran into Kate Harrison at the poster presentations, and we wound up sitting in the CS lounge talking for several hours about all manner of things - the design of puzzlehunts, family relations, school, the computer games we played growing up, gender in the sciences, styling and upkeep of long hair, wireless spectrum, rationality, playing devil's advocate. We played Dominion against an app with a rather weak AI, and then switched to an anagramming game. Shang joined us and we all continued anagramming, then headed down the hill so Shang and Kate could catch the bus and I could head home. I am now apparently responsible for hosting a retro computer games night at some unspecified future time, which will feature such classics as The Lost Mind of Dr. Brain and Logical Journey of the Zoombinis.

It was nice to have a comparatively deep, one-on-one conversation. I haven't had many of those since coming to California. Large gatherings can be fun, but they tend to lose the introspective, thoughtful nature that becomes possible when there are only two voices needing to be heard. With a party of two, you have more time and less pressure to quickly synthesize your thoughts into words before the topic organically shifts elsewhere. There's less contention for the channel of communication.