The Problem
While this is good from possibilities point of view, the activation approach historically sucks. Flash and it's video or microphone activation shows a dialog that asks the user to authorize media access while browsers are lazily asking via JavaScript the same. The real life scenario we all know is definitively different when a page is using a screen reader, and this article and video about twitter UX should be enough to open our eyes: something is wrong.Solutions
If we ever used an Android device, or we have download applications from whatever mobile store, we should be familiar with the installation warnings and confirmations we suppose to read and accept in order to grant application access to anything it needs to work properly.This simply means that once we accept we won't be bothered anymore and the application can easily work as expected.
It's all about privileges and in my opinion it would be nice to have similar approach in our browsers as well, also to make web application even closer to native one.
Proposal
Following the "don't break the WEB" approach, all we could do is put a meta tag, as we do for viewports, specifying all those Technologies/API we would like to use in our webpage. This is an example:
<meta name="grant" content="GeoLocation,Camera" />
<meta name="grant" content="System" />
The proposal should ask at the very beginning and only once if the webpage could access these functionalities and the user can decide before what should be available and what should not.
The "before" action is important 'cause in this Ajax era it's extremely easy to loose focus runtime with whatever activation request and this is so wrong.
The list of granted API should be reachable via userAgent via specific method such:
navigator.hasGranted("GeoLocation")
or similar, so that eventually we can decide via JavaScript if we would like to ask again runtime, as we do now, or simply provide an alternative solution or message, maybe showing an "ask again to activate" button, remembering to put back the focus in the right context.
Alternative
Web developers could implement similar concept asking with the very first script access to one or more API and put the page focus back. With GeoLocation, as example, the user will chose immediately his preferences without having surprises in the middle of a session, or later.
// As Soon As Possible
var HAS_GEO_LOCATION = false;
try {
navigator.geolocation.getCurrentPosition(function (result) {
// so that other scripts could check if already available
HAS_GEO_LOCATION = true;
// notify the event in any case
var evt = document.createEvent("Event");
evt.initEvent("geolocationready", 1, 1);
evt.data = result;
// implicit window context
dispatchEvent(evt);
});
} catch(e) {}
A usage example could be something like:
// script loaded after a while ...
if (HAS_GEO_LOCATION) {
doFreakingCoolStuffWithGeo();
} else {
addEventListener(
"geolocationready",
doFreakingCoolStuffWithGeo,
false
);
}
We can eventually specify the handleError callback as well but actually this is part of the HAS_GEO_LOCATION value, if there is an error no reason to insist, simply assume that there is no geo location and go with the fallback, if any.
What do you think?
It's indeed much like the Android installation confirmation. One thing I'd like to point out, and I can't stress this enough, let the user decide which components the app will NOT have access to.
ReplyDeleteIf I want to play a game of connect 4, I want to be able to disable access to my webcam, my geolocation, oh and the rest of my life.
This is something that annoys me in Android. Why would a game need access to my address book... Stuff like that will always prevent me from installing those games. But if I could tell Android to just disallow access to that certain resource...
I hove this idea. This is certainly a great way to improve the user experience. Also, thanks for linking to the article I did on the Twitter UX.
ReplyDeletePeter I am proposing a better way than android ... but one step per time.
ReplyDelete1. try to imagine you are playing your game and in the middle of the "battle" the application asks you to accept the usage of the camera ... is this truly what you expect?
2. I am proposing a list of APIs that require granted access but I have never said we accept all of them or nothing ( as is for Android applications )
All I am proposing is to give us a way to improve UX when the *domain* would like to take advantage of these features.
The "activation once" should be a list of "checks" where the user can *decide* what should be available and what should not and the application should be able to work accordingly, eventually reminding that some feature must be enable in order to have full application power, but never interrupting a session in the middle because latest piece of JavaScript used for the first time after a while the GeoLocation, as example.
I think this is the only way we have to make applications less annoying and let the user decide once per domain what should be available and what should not.
Do you still think this is that bad?
Regards
Some people will be anonymity freaks and that's fine. Some sites will of course ask for more than they need, even if they don't implement anything with those features that benefits the user, maybe even just for data collection and analytics.
ReplyDeleteI hope that while those checks allow things to happen, that no checks will not cripple the application, as some faux data could be provided.
Ryan agreed that any technology could be used badly ;-)
ReplyDeletestats? dunno how many sites are using Analytics so that would be eventually last thing to worry about, we are all already monitored :D
There are more and more meta-tags for desktop-like websites ( http://ajaxian.com/archives/a-call-for-pinning-menus-sanity )
ReplyDeleteI think its time to seperate this kind of data in a separate file and link it with a link-tag?
something like a http.meta file ?
ReplyDeleteI like navigator.hasGranted("GeoLocation")
ReplyDeleteBut maybe the meta name should be "request-*" instead of "grant"? The page is not granting anything, it's asking for certain features.
"Request" by itself is too vague, and "request-device" is too limited. "Request-extra"?
[meta name="api-request" content="x" /] ???
Alejandro, I am not following you ... you like the hasGranted part but you don't want to the name grant?
ReplyDeleteIf hasGranted is fine, maybe we should be semantic and use grant ... in any case, this is not the point. Whatever name as long as we can ask, when and if necessary, these authorization once and all together, rather than distract users for each bloody API we would like to use.
The W3C guys should help here with a proper draft ;)
Mozilla takes the name "capabilities" for its Application Manifest- Proposal: https://wiki.mozilla.org/Labs/Apps/Manifest
ReplyDeleteSystem.capabilities is what I sued to check back into "good old" ActionScript days and the Flash Player. I even suggested the usage of System via bridge few months ago so I would say yes, that approach makes sense and basically the concept is exactly that one: emulate local widget behaviour on web pages as well, I can't see anything bad in this!
ReplyDeleteNice article, thanks. I love the idea about meta tag and asking once the permissions needed by the application.
ReplyDeleteI think we also could add a concept of "required permission" and "optional permission". Let's take an example: a web game. The "contact permission" could be declared as optional because it's used only to share the game's result with contacts. Or a permission could be declared as optional because we have a nice callback if not allowed. Those are examples of course, but I think it could be nice.
Also, browsers should allow us to edit those permissions throw its own option, just like we can see all the cookies stored by host name and so.
What do you think ?