In bug 748214 there were many UX concerns brought up about the use a modal dialog box for the implementation of bug 748214, as it is interrupting to the user and forces a decision to determine if a user's location should be shared or not. This especially affects the privacy side of things as Doug mentioned, as geolocation UI needs to take into account ensuring that the user fully understands what they are doing and not just doing a click-through on the dialog prompt. Additionally, a note was made that this needs to link to more information that firefox uses (http://www.mozilla.org/en-US/firefox/geolocation/). The geolocation icon should also be used. The implementation of this bug is a follow-up implementation of the UX flow that addresses the above concerns.
Priority: -- → P1
Target Milestone: --- → Firefox 16
Nominating for k9o - This is required for followup fixes to the current implementation of geolocation in the web runtime to address UX and privacy concerns - see bug 748214 for the discussion of the concerns brought up.
blocking-kilimanjaro: --- → ?
k9o- Please renom if there is evidence that this is a significant issue for Apps in our market.
blocking-kilimanjaro: ? → -
(In reply to Lawrence Mandel [:lmandel] from comment #2) > k9o- Please renom if there is evidence that this is a significant issue for > Apps in our market. Lucas, Jonas, Doug - Want to double check you guys are alright with the - here - do you agree or disagree on this not blocking k9o? Or do you have an argument that we should block?
From a geo sec/privacy pov, the changes made in the original bug are fine and shouldn't block anything (see that bug for the details). From a usage pov, i think using modal dialogs on-use is a terrible design. I'd hope there was something better than a modal dialog. I am not sure what UX had considered. Either way, I do not think blocking on this is the right thing. blocking-kilimanjaro:-
I'd like to revisit this. The modal UI is definitely bad for security and something that I think we need to fix.
blocking-kilimanjaro: - → ?
Another reason is that I think that if we keep the dialog modal then that will affect how people design apps. I.e. the good guys will be even more hesitant to use the API since it creates a bad user experience.
Hi folks, Ian here from UX. I'm not clear on why modal dialogs are a bad user experience in this case. It seems like a case where you actually want something disruptive that people need to act on before they can continue, and it's pretty standard practice to use modal dialogs when users need to allow/disallow location sharing. Something more subtle and integrated can make for a nice looking design, but can also be easily overlooked by the user. Modal dialogs is how most mobile platforms handle geolocation sharing prompts, as well. The only other alternative I might have suggested would be to use a Firefox-style doorhanger, but I don't imagine we provide any kind of native header to which we could attach one.
k9o- While user interaction improvements are wanted we have a workable solution for k9o as is. It also doesn't seem like there is agreement that a change is needed. We will reconsider this bug with more evidence that the the case that Jonas outlined in comment 6 is causing significant pain.
blocking-kilimanjaro: ? → -
Marking for re-triage. UX does not seem to be concerned about this, and this has been k9o-.
Priority: P1 → --
The desktop runtime feature drivers discussed this today, and, in conversations with Andrew, Jonas noted that there will be a number of WebAPIs besides Geolocation whose use will be restricted, and for which we'll want users to explicitly grant access <https://wiki.mozilla.org/WebAPI/Security>. Meanwhile, our experience with Firefox suggests that modal/unretrievable dialogs are too disruptive, resulting in arbitrary user decisions that don't model users' actual preferences well, which is why Firefox has switched to non-modal and retrievable doorhangers for them. So while the current solution is ok for this one permission in the initial release of the runtime, we want something better for the various permissions in subsequent releases. Thus I am morphing this bug to be about designing and implementing that better experience. And setting its priority back to P1, as the feature drivers agree that it's very important to improve the user experience in this regard. (In reply to Ian Barlow (:ibarlow) from comment #7) > The only other alternative I might have suggested would be to use a > Firefox-style doorhanger, but I don't imagine we provide any kind of native > header to which we could attach one. The runtime does provide a native menubar (at the top of each window on Windows; integrated into the native menubar on Mac), and we could hang the doorhanger off that, perhaps more specifically off some icon/label within it that represents the runtime environment in which the app is running (similar to the way Mac OS X has the "apple" menu on the left-hand side of its menubar with items related to the operating environment, although it doesn't hang doorhangers off it). In any case, I'm not a UX designer, and that is not a UX design! I'm just noting that there are options, and we're open to the possibilities, including adding affordances that don't currently exist, in order to achieve this important goal.
Severity: normal → enhancement
Priority: -- → P1
Summary: Revisit UX for Geolocation and address UX and privacy concerns from feedback on bug 748214 → prompt users to permit access to restricted WebAPIs via non-modal/retrievable affordance
Per bug 1238079, we're going to disable the desktop web runtime and remove it from the codebase, so we won't fix these bugs in it.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WONTFIX
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.