Media/MediaCapture/CameraAPI2-UXmeeting-20120427

Meeting Notes from April 27, 2012:

We combined the Camera API UX meeting with a Security Models coordination meeting.

• The meeting began with a discussion of Notification and Permission models for apps with the focus on mobile (B2G and Android).
• Camera API (camera apps) was the primary use case model. So most of the discussion revolved around it.
• At the last Camera API meeting, we thought the following decisions made the most sense:

1. Permission requested on Install (not Launch)
2. Persisted runtime permission after 1st response
3. Clear notification of the current permission settings (to be shown in the mock up) and the ability to access previous decisions (also to be shown in the mockup.

• At the end of the last meeting we asked Bryan to show us these decisions as a mock up with #2 and #3 being most important to see in a mock up. We were most concerned with "How would the user know the current permission settings, and how would he change his decision after having granted it?"
• We reviewed and discussed Bryan’s mock up - http://cl.ly/0t3s1P1K3g390M2r0C39 and discussed what the flow associated with the mock up would be like:
  • the App store on install would present the user with a list of permissions needed for the app.
    • Recommended permissions would be checked by default, but the user can change (check/uncheck) any permission at that time.
    • There would also be a brief explanation of why each permission is being asked for; permissions must be in the manifest.
    • The user would then press continue when permissions were set as he wanted them.
  • At 1st runtime, the user would be prompted for any permission not granted at install time.
  • After 1st runtime, the user would no longer be prompted for permission, but the user would be notified of the decision and know where to go to change it.
• Bryan’s mock up showed symbols representing the current permission state (like notification on/off, camera on/off, microphone on/off) in some sort of chrome area if one existed. If there is no chrome (like for B2G or for a full screen app), then there would be some sort of overlay to show permissions.
• Bryan thought we should rethink whether we want to have permissions at Install or Launch. We later decided that the UX team would think through both approaches, create mock ups as needed, and make a recommendation for permissions at Install or Launch.
• Lucas reviewed the four types of Apps:

1. WebContent (browser) -> all permissions are done at runtime
2. Installed version of web content (likely chromeless, same security risk as #1)
3. Trusted app – will go through a review process and be served by the App store
4. Certified app – baked in - Implicit permissions are given, this is an integral part of the OS

• We are prioritizing solving #3 and #4 at this time. There was backchannel discussion about allowing implicit permissions (#4) to be overridden by the user, even if it's a mildly inconvenient way to get to them.
• Anant told us that the Media Task Force (who is defining getUserMedia) is dividing apps into two categories:

1. Untrusted apps – which only get video/audio permissions (Lucas’ #1 and #2 App types above)
2. Trusted apps – which have the ability to choose # of cameras (front/back) (Lucas’ #3 and #4 types above)

• We agreed that Bryan’s mock ups would work for non-full screen app, but it was unclear how full-screen apps would be handled.

Action Items:

1. The UX team is going to look at granting permissions at Install vs Launch. Create some mock ups as needed and come back with a recommendation.
2. The UX team is going to look at how to display notifications and how to show the user where to change permissions after Install/Launch. They will look at the UX for full screen and non-full screen apps.
3. We need to see an example of an apps’ manifest on Installation and in particular how it would explain why a permission was needed. Originally, we asked Lucas to look at creating this, but then UX team said they would take a crack at this. It may make sense for Lucas and the UX team to coordinate further on this action item.
4. We need to see what the role of Marketplace would be in this experience (how would the Marketplace present apps). This is closely tied to the "manifest" action item immediately above. The UX team said they would take a shot at that too.
5. Maire promised to send meeting notes this weekend (before Monday). These are those notes. Attendees should feel free to modify these if details from the meeting were missed or are unclear.

NOTE: No follow up date/time was set. Maire will reach out to the UX team (in particular Bryan and Josh) to find out when they would ready for the next meeting. Maire will then find a time in Zimbra and send out a meeting invite.