> That seems like a good plan. Has anyone ever tried formalizing it and > floating it around to other vendors?
I figured I should jump into the thread since I can provide some perspective on the UI from another vendor. I'm a principal designer on Firefox and this is a feature that I'm really passionate about. > > The UA would expose some way to activate all of this functionality for > > a site in "one shot"... I totally agree that users should be able to give Web apps additional privileges in "one shot," as opposed to having to give them permission to do things like use offline storage, register to handle local files, and produce notifications individually (although we will likely allow users to revoke specific permissions). > > then a menu item in the browser might activate that > > the user could use to activate it. We are considering a menu item as well, however we haven't determined the best way to describe the action. I'm concerned that the term "install" has connotations that the Web app will actually be served locally (like how Zimbra desktop deploys with Mozilla's Prism), and a lot of users may have difficulty wrapping their head around what it literally means to install a Web app. We are also looking into granting these additional app privileges implicitly through actions that the user takes, like dragging a tab into the OS X dock or Windows quick launch bar. Additionally in Firefox 4 if the user drags a tab to the left our new Home Tab they will be able to create a small persistent tab (called an "app tab") that will be automatically granted these additional privileges. A third option that I've been thinking about is adding a new item to the Windows start menu and OS X applications folder named "Add Web Application." I think this works reasonably well conceptually since the app being created will ultimately be accessible next to the rest of the user's desktop applications. However, presenting UI outside of the browser is a little more aggressive than Firefox usually behaves. While UA interfaces are of course well outside of the scope of the standardization process for APIs, I think the Web as a whole would benefit if we coordinated to present a somewhat similar interface for this feature, at least in terms of terminology, any symbols used, etc. -Alex Faaborg On Oct 2, 4:23 pm, Jeremy Orlow <[email protected]> wrote: > That seems like a good plan. Has anyone ever tried formalizing it and > floating it around to other vendors? > > On Fri, Oct 2, 2009 at 4:11 PM, Ben Goodger (Google) <[email protected]>wrote: > > > This relates somewhat to how we'd like people to "install" web > > applications. > > > For that we figured a site would publish a manifest in some format > > (there was some talk about something like the extensions manifest) > > that specifies all kinds of appy things a site can do, like large > > icons, protocol schemes and mime types it can handle and the URLs for > > each, etc etc. > > > The UA would expose some way to activate all of this functionality for > > a site in "one shot"... e.g. if the site published the data via some > > kind of <link> tag then a menu item in the browser might activate that > > the user could use to activate it. > > > -Ben > > > On Fri, Oct 2, 2009 at 2:55 PM, Jeremy Orlow <[email protected]> wrote: > > > On Fri, Oct 2, 2009 at 2:48 PM, Peter Kasting <[email protected]> > > wrote: > > > >> On Fri, Oct 2, 2009 at 2:47 PM, Jeremy Orlow <[email protected]> > > wrote: > > > >>> Is this API even part of any standard? Maybe we should bring this up > > on > > >>> WhatWG? > > > >> The thread title is a clue that these are specced in HTML5 :) > > > > Not really. People abuse the term HTML5. Good example: WebSockets, > > > WebDatabase, LocalStorage, Workers, and many of the other APIs we > > associate > > > with HTML5 are not in that spec. > > > Anyhow, apparently this was discussed very recently and I somehow missed > > the > > > discussion: > >http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-September/02 ... > > > I'll try to take a look at the thread some time soon. Ben and/ or other > > UI > > > guys, maybe you should too. Now is the time to make noise if we think > > this > > > is a bad API. > > > J --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
