Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, 6 Apr 2011, Andrew de Andrade wrote: Depending on the browser and device, permission will be asked either in a bar across the top of the browser (Firefox and Chrome on the desktop) or with a modal dialog (Safari on the desktop and on the iPhone). [...] As the creator of a site that uses geolocation, these two different implementations of the permissions dialog concerns me. In my tests with users, I've noticed that with Firefox and Chrome, many users don't notice the bar across the top and thus features of the web application end up crippled because the app doesn't have access to the user's location and this degrades the user experience. As with all user interface choices browser vendors have to make, some work better than others. Different goals can result in different choices, too; for example, it might be the goal of one user agent to make it clear to the user that they should share their location, while another user agent might decide that it's better to the user have to explicitly look for a way to share their location, since then they won't do it by mistake. [Proposal:] 2) The HTML5 specification defines how browsers should implement this consistently -- either a bar across the top OR modal dialog box, but not both. It's user interface: we're not going to specify it. This is the kind of thing browsers can compete on. In any case, it's impractical: If we said it should be a non-modal graphical bar, how would a browser that doesn't have a screen but instead reads everything out using speech synthesis do it? If we said it had to be a red icon, what about browsers targeting cultures where the colour red is considered offensive? If we said that the user agent should offer the option to give the user's location or no location, what about users that want to lie about their location? There are just too many possible variables here to define the UI, even if we wanted to. 3) Each browser chooses their default interface approach (bar or modal dialog), but the Geolocation API specification allows for the webapp developer to override this default. This doesn't work because those options might not be available in the first place. What if the operating system the browser is running on doesn't have the concept of a modal dialog? What if it's a line-driven text browser, with no concept of a non-modal alert? Those apps for which location is essencial for the user experience can choose to always display a modal dialog box before the user proceeds to use the webapp. What if the user never wants a dialog? On Wed, 6 Apr 2011, Peter Kasting wrote: If users don't notice or understand the geolocation prompts in a particular browser, I think the appropriate response is to provide feedback to the browser vendor that users are not successfully navigating their UI. Indeed. On Fri, 8 Apr 2011, Rich Tibbett wrote: Biju wrote: What I want from browser vendors is make navigator.geolocation.getCurrentPosition and navigator.geolocation.watchPosition ONLY callable from a CLICK event. I thought we all learned lesson from window.open popups window.open is still entirely underspecified in standards when it comes to its behavior in trusted vs. non-trusted click event invocation. The first thing somebody would need to is document how window.open works according to different modes of invocation. Then at least we would have a model to be able to discuss for other similar scenarios. The HTML spec defines this, but in a somewhat wishy-washy way intended to allow UAs to experiment with different constraints. Is this something that needs defining more precisely? In general I haven't specified this in detail because the model of trusting user clicks doesn't work (due to clickjacking attacks). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
Biju wrote: What I want from browser vendors is make navigator.geolocation.getCurrentPosition and navigator.geolocation.watchPosition ONLY callable from a CLICK event. I thought we all learned lesson from window.open popups window.open is still entirely underspecified in standards when it comes to its behavior in trusted vs. non-trusted click event invocation. The first thing somebody would need to is document how window.open works according to different modes of invocation. Then at least we would have a model to be able to discuss for other similar scenarios. What you're then suggesting is that we allow *trusted* click events (according to the DOM Level 3 Events definition) to trigger a non-blocking dialog to enable geolocation in the same way as window.open only opens a popup window if it has been called from a trusted user-initiated click event. That seems logical to me and it's something that we attempted to define in a blue-sky proposal elsewhere: http://dev.w3.org/2009/dap/contacts/Overview.html#api-invocation-via-dom-events. The same model could potentially be applied to geolocation and other upcoming Web APIs. The ability for a user to click something and receive a response that fits their work flow, instead of an async bar that the OP suggested users are frequently missing seems like something we should look in to more. Some interaction that's a little bit like the file picker interaction, but with a non-modal output notification. - Rich
[whatwg] Geolocation - Browser usability issues with regards to asking user permission
I'm building a web-app that makes use of the Geolocation API. While building my application, I've come across an issue with how browser makers have implemented the Geolocation API. Depending on the browser and device, permission will be asked either in a bar across the top of the browser (Firefox and Chrome on the desktop) or with a modal dialog (Safari on the desktop and on the iPhone). At the moment, I don't have access to Chrome on an Android device or access to Internet Explorer on Windows, so I can't tell you how they implement the permissions dialog. As the creator of a site that uses geolocation, these two different implementations of the permissions dialog concerns me. In my tests with users, I've noticed that with Firefox and Chrome, many users don't notice the bar across the top and thus features of the web application end up crippled because the app doesn't have access to the user's location and this degrades the user experience. As a web app developer, I have to either grin and bear this or I need to spend extra development effort to create an absolutely positioned window in the top righthand corner of the screen to call the user's attention to the non-obvious geolocation permission dialog. To do this I also need to browser sniff, since this absolutely positioned element should only appear on browsers where the dialog is less-than-obvious. The way I see it there are three possible solutions forward: 1) As a web app developer, I just deal with this. 2) The HTML5 specification defines how browsers should implement this consistently -- either a bar across the top OR modal dialog box, but not both. This isn't ideal either since there are arguments both for and against both solutions. For webapps where most or all users are likely to want to give the app permission for access to the additional features, the non-obtrusive bar provides a worse user experience for the webapp. With my app for example really only has value if we know where the user is located. The user informs my app of their location via the geolocation API or keying it it or they don't use my app at all. In this latter case, I most certainly prefer the browser modal dialog box approach. 3) Each browser chooses their default interface approach (bar or modal dialog), but the Geolocation API specification allows for the webapp developer to override this default. Those apps for which location is essencial for the user experience can choose to always display a modal dialog box before the user proceeds to use the webapp. Those apps for which it is not important, can opt for the bar across the top. I'm sure there are other possible solutions, but the state of the implementation insofar as the user experience is concerned needs work. In addressing the privacy aspects of the user experience, we've created a usability issue which needs to be addressed as well. best, Andrew (P.S. I really don't know if this mailing-list was the best place to raise the issues above, but since many engineers from all the browser manufacturers watch this list, I figured it is as good a place as any to raise these points)
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, Apr 6, 2011 at 4:37 PM, Andrew de Andrade and...@deandrade.com.brwrote: 2) The HTML5 specification defines how browsers should implement this consistently -- either a bar across the top OR modal dialog box, but not both. This isn't ideal either since there are arguments both for and against both solutions. Besides the con you mention, I think this is also outside the scope of HTML5. The spec has frequently advised browser vendors on characteristics that must or should be true, e.g. w.r.t. allowing users to manage and delete local storage data in a similar fashion to cookies -- but actually dictating precise bits of UI goes too far. 3) Each browser chooses their default interface approach (bar or modal dialog), but the Geolocation API specification allows for the webapp developer to override this default. Those apps for which location is essencial for the user experience can choose to always display a modal dialog box before the user proceeds to use the webapp. Those apps for which it is not important, can opt for the bar across the top. Unfortunately, it is far more common for an author to feel that a particular permission is essential than for the user to feel so. Furthermore, modal dialogs have other usability issues that the browser vendor may wish to avoid, e.g. requiring script on many different tabs to stop. In addressing the privacy aspects of the user experience, we've created a usability issue which needs to be addressed as well. Allowing users to toggle a feature on a per-site basis is not just a privacy issue but in many cases one of general functionality. For example, Chrome includes a click to play feature under a flag that allows users to dynamically control plugin invocation, not for privacy but usability reasons. The browser vendor may have strong UI design goals or interface consistency requirements that dictate how functionality choices are portrayed to the user. As a browser UI developer, I am not willing to cede control over those aspects to the web developer. If users don't notice or understand the geolocation prompts in a particular browser, I think the appropriate response is to provide feedback to the browser vendor that users are not successfully navigating their UI. I would be very interested in the details of your testing, how you determined that users were missing the prompts, and how effective were more generalized methods (than making a floating div as a UI callout) in guiding users (e.g. simply telling users they need to give the site permission to access their location before it will work correctly, showing your UI with a big No permission to access your location; did you tell your browser to allow this?-style banner overlaid, etc.). PK
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, Apr 6, 2011 at 8:04 PM, Peter Kasting pkast...@google.com wrote: Furthermore, modal dialogs have other usability issues that the browser vendor may wish to avoid, e.g. requiring script on many different tabs to stop. Are you thinking of how the prompt, etc. require that the UA pause scripts? That's only required for those old synchronous APIs. A modal prompt for an asynchronous API like this doesn't need to do that. There's also the tendency for modal dialogs to be window-modal, locking the user from using any other tab, but the recent trend towards tab-modal prompts solves that problem. I don't think this is necessary, though. A developer that wants these requests to appear modal can simply dim out the page until the response comes back. That'll push attention to whatever the browser's doing, without his having to care too much about what it is. (If the browser itself also dims the page, as for example Firefox and Opera's prompt() dialogs do, then it'll dim it twice, but that's minor.) -- Glenn Maynard
Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission
On Wed, Apr 6, 2011 at 7:37 PM, Andrew de Andrade
and...@deandrade.com.br wrote:
2) The HTML5 specification defines how browsers should implement this
consistently -- either a bar across the top OR modal dialog box, but
not both. This isn't ideal either since there are arguments both for
Right now Firefox 4 allow user to put address bar on bottom of page.
Then the pop up will be at bottom.
(All version of Firefox and SeaMonkey also allow to hide address bar)
If address bar is hidden, Firefox 4 will position the GeoLocation popup
depending on the Tab position.
1. As Firefox USER, I dont want WHATWG to tell Mozilla to stop
allowing customization.
2. As a computer USER, I dont want any modal pop ups in applications.
or in other words, I want to be on control, not the developer
and especially absolutely no control for a web developer.
(please read about CICS programming,
you could write enterprise level on-line applications
in a platform which dont allow any modal screens)
Right now following javascript
function xyz(){
navigator.geolocation.getCurrentPosition(function(position)
{alert(position)});
}
setTimeout(xyz,2000);
will trigger geoLocation after 2 seconds.
A malicious website can use this now to create annoyances for USER.
What I want from browser vendors is make
navigator.geolocation.getCurrentPosition
and navigator.geolocation.watchPosition ONLY callable from a CLICK event.
I thought we all learned lesson from window.open popups
I also wanted browser vendors to provide easy option for user to lie
about their location.
Cheers
Biju
