At a high level the proposals are similar in the notification model - either way we'd have a persistent indicator while the camera is being accessed.
The main difference is how permission to the camera is granted. Whether its done with: a) a combination of install-time and run-time UI "dialog" mechanism as has been discussed previously. This has the downside of potentially pestering the user into making poor decisions. b) an OS "magic button" that the app places in its UI. This negates the need for a dialog but requires the user to click that button when they want the app to capture audio or video. It also means that apps couldn't have automatic access to the camera upon startup (i.e. no "always allow"), which limits what the app can do in terms of preview. As Zack pointed out, maybe apps can use WebGL shaders to overcome some of those issues, but I'm not sure if that's equivalent. Lucas. On Apr 17, 2012, at 9:49 PM, Ragavan Srinivasan wrote: > > > Lucas Adamski wrote: >> >> Comparing mockups would help, but I think it would also be important >> to get guidance on the potential impact on app design and UI for each >> of their proposals. In other words, if they were asked to build a >> camera or teleconferencing app, how would the respective proposals >> impact their designs? Lucas. > > I've tried to catch up on this thread, but between poor threading on my NNTP > client and Google Groups, I'm afraid I'm a bit lost. > > So, I'd like some help. I'll describe the two main use cases for *still* > image capture that I believe are our immediate priorities for Kilimanjaro > (K9O). I'd appreciate it if someone (Lucas?) could describe the security > team's current proposal for how the permissions (and the UX) would work for > these use cases. > > 1. Default camera app for a B2G phone that functions like the default camera > app you have on your iphone/android phone. This app will, in all probability, > come pre-bundled on your phone. > > 2. An Instagram like app that allows you to take a picture, capture the > preview, apply some filters and save/share the picture. This class of apps > will likely want to control the entire experience (including the frame, what > the buttons look like etc). I will note that this may not be possible until > more of the getUserMedia functionality lands, but this is the platform > capability we want to enable. This app will be available via the marketplace. > > Thanks, > Ragavan > > PS: I know there are discussions about a teleconferencing app, but that is > not a P1 for K9O, so I'd like to focus on the above two for now. > > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-security mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security
