In January I posted a proposal for multiple launch paths. At the time the Google Groups archive was not working, so there's no archive of this message. In the interest of re-introducing this to the archive, I am forwarding the original message and the responses, crudely formatted:
------------------------------------------------------------------------------ Ian Bicking [email protected] Jan 26 to dev-webapps, bcc: apps Fabrice mentioned (and has included a little support in his new IDL) support for multiple launch points from a single application. This seems sensible to me, though exactly how it might be presented in all different context I'm not sure (multiple launch icons/apps, drop down lists, ...?) Putting aside UI, here's a quick proposal for how it might look in the manifest: { name: "MyFace", launch_path: "/", icons: {"48": "/48icon.png", "128": "/128icon.png"}, entry_points: { "account": { path: "/account", name: "MyFace Account Settings", icons: {"48": "/48account.png"} }, "messages": { path: "/messages", name: "MyFace Messages" } } locales: { "es": { entry_points: {"account": {name: "configuración de la cuenta"}} } } } So, we add a new top-level property, "entry_points" - this is a mapping of entry point names to a bunch of properties. The entry point name should not be displayed to the user. Each item in this mapping must have the property "path" and "name". It may optionally have "icons" (if not, then you should borrow the icons from the top-level). (Did we ever agree on hover_text or short_description or anything? If so, then that could also be present here) When you call app.launch("account") then it will look up that entry point. Otherwise no argument, or an argument of null, means use the top-level launch_path. Here's a bit of code for getting the icon information for a launch point (this should be applied after the localization overlay): function getLaunchData(manifest, name) { if (name !== null && ((! manifest.entry_points) || (! manifest.entry_points.hasOwnProperty(name))) { throw 'Bad entry point name: ' + name; } var result = {icons: manifest.icons}; if (name !== null) { return { name: manifest.entry_points[name].name, path: manifest.entry_points[name].path, icons: manifest.entry_points[name].icons || manifest.icons }; } else { return {name: manifest.name, path: manifest.launch_path || '/', icons: manifest.icons}; } } When considering new properties, we should also consider if they apply to entry_points. See also: http://msdn.microsoft.com/en-us/library/gg491732%28v=VS.85%29.aspx Specifically they have: name: same as our name starturl: launch_path or path tooltip: maybe short_description. Or we can use "tooltip" (that's better than hover_text) - it's not really just a short description. window: they allow height/width specifications. Weird. The IE system uses <meta> tags which are easy to create dynamically, so I guess that makes this more plausibly useful. navbutton-color: back and forward button colors... huh. And then there's Tasks (http://msdn.microsoft.com/en-us/library/gg491725%28v=vs.85%29.aspx) which I think don't really apply because I think it is mean to be a dynamic (and page-local?) list. ------------------------------------------------------------------------------ Daniel Walkowski [email protected] Jan 26 to Ian, dev-webapps What is the use case? ------------------------------------------------------------------------------ Bill Walker [email protected] Jan 27 to Fabrice, dev-webapps, Ian On the one hand, I do find this idea interesting; I guess lets app developers specify how users can jump directly into various parts of an app? Have we got any app developers asking for this? On the other hand, we're signed up for a lot of (higher priority) work to implement the revised API across our many components, and nobody committed to design a new UX for these multiple entry points. I'd rather postpone this change to the manifest until we have a clear use case for it and time to design a UI for it. ------------------------------------------------------------------------------ Fabrice Desré [email protected] Jan 27 to Bill, dev-webapps, Ian On 01/27/2012 09:06 AM, Bill Walker wrote: On the one hand, I do find this idea interesting; I guess lets app developers specify how users can jump directly into various parts of an app? Have we got any app developers asking for this? We need this for gaia, where the dialer and contact manager are the same app. On the other hand, we're signed up for a lot of (higher priority) work to implement the revised API across our many components, and nobody committed to design a new UX for these multiple entry points. I'm not sure which UX work you're referring to here. Dashborads will need to process the manifest to check for additional endpoints but it's not a big deal. I'd rather postpone this change to the manifest until we have a clear use case for it and time to design a UI for it. We'll support it in b2g for the upcoming demo. ------------------------------------------------------------------------------ Bill Walker [email protected] Jan 27 to Fabrice, dev-webapps, Ian On Jan 27, 2012, at 9:18 AM, Fabrice Desré wrote: > On 01/27/2012 09:06 AM, Bill Walker wrote: >> On the one hand, I do find this idea interesting; I guess lets app >> developers specify how users can jump directly into various parts of an >> app? Have we got any app developers asking for this? > > We need this for gaia, where the dialer and contact manager are the same app. Ah. thank you for clarifying. > >> On the other hand, we're signed up for a lot of (higher priority) work >> to implement the revised API across our many components, and nobody >> committed to design a new UX for these multiple entry points. > > I'm not sure which UX work you're referring to here. Dashborads will need to > process the manifest to check for additional endpoints but it's not a big > deal. Right, I'm referring to the details of that -- I suppose the dashboard would want to present a contextual menu or something, offering a choice of entry points for launch? Should it remember the one you picked last time? Stuff like that. > >> I'd rather postpone this change to the manifest until we have a clear >> use case for it and time to design a UI for it. > > We'll support it in b2g for the upcoming demo. OK -- if you have an immediate need for it, then we'll follow your lead here. thanks, -Bill ------------------------------------------------------------------------------ Ben Francis [email protected] via mozilla.com Jan 27 to dev-webapps On Fri, Jan 27, 2012 at 5:18 PM, Fabrice Desré <[email protected]> wrote: > On 01/27/2012 09:06 AM, Bill Walker wrote: > >> On the one hand, I do find this idea interesting; I guess lets app >> developers specify how users can jump directly into various parts of an >> app? Have we got any app developers asking for this? >> > > We need this for gaia, where the dialer and contact manager are the same > app. The UX team and cjones have suggested several use cases for this in Gaia, but I do wonder whether we can work around it with Web Intents (like you originally suggested) and hyperlinks. We can intents to "call" a number and "pick" a contact and have hyperlinks between the apps which are styled to look like they're tabs inside the same app, but they actually link to the other app? Having said that, the example given earlier of launching different views of a social networking app wouldn't really warrant having two separate apps and is a valid use case. ------------------------------------------------------------------------------ Ian Bicking [email protected] Jan 27 to Bill, dev-webapps, Fabrice 2012/1/27 Bill Walker <[email protected]> On the one hand, I do find this idea interesting; I guess lets app developers specify how users can jump directly into various parts of an app? Have we got any app developers asking for this? On the other hand, we're signed up for a lot of (higher priority) work to implement the revised API across our many components, and nobody committed to design a new UX for these multiple entry points. I'd rather postpone this change to the manifest until we have a clear use case for it and time to design a UI for it. Making this easier, we don't necessarily have to support this in all clients/dashboards. Specifically we can require that applications include sufficient internal navigation to access all parts of the app, regardless of entry points. Indeed, if that is not sensible then I don't think it's sensible that the thing be one app. Also, I'd be interested to know why Gaia needs to be one app instead of two? (On my Android phone for instance, contacts and dialer appear to be two completely different apps? Maybe that's just related to the use of Intents?) ------------------------------------------------------------------------------ Fabrice Desré [email protected] Jan 27 to Ian, Bill, dev-webapps On 01/27/2012 10:40 AM, Ian Bicking wrote: Also, I'd be interested to know why Gaia needs to be one app instead of two? (On my Android phone for instance, contacts and dialer appear to be two completely different apps? Maybe that's just related to the use of Intents?) On Android, you can bundle several activities in a single application. Each activity will appear in you app list with its own icon and name. This what we do now to bundle sync and fennec in the same application. And then yes, you can use Intents to launch different a given activity. ------------------------------------------------------------------------------ Kumar McMillan [email protected] Jan 30 to Ian, dev-webapps Minor feedback: for consistency we could call it something more like 'all_launch_paths' instead of entry_points. Other feedback: this would make more sense to me if I understood how it might work in the UI. Going on faith, it does seem like a reasonable manifest addition though. The most realistic case that comes to mind is a 'support' launch path so that every app is encouraged to always provide a way for the user to get support. ------------------------------------------------------------------------------ Ian Bicking [email protected] Jan 30 to Kumar, dev-webapps On Mon, Jan 30, 2012 at 1:48 PM, Kumar McMillan <[email protected]> wrote: Minor feedback: for consistency we could call it something more like 'all_launch_paths' instead of entry_points. Other feedback: this would make more sense to me if I understood how it might work in the UI. Going on faith, it does seem like a reasonable manifest addition though. "entry_points" seemed more natural, but "launch_path" is already there; my inclination was to rename launch_path until I thought about it more and realized that level of change isn't really necessary. Also, this felt odd, because "path" becomes redundant/incorrect: { "all_launch_paths": { "support": { "name": "Support", "path": "/support" } } } The most realistic case that comes to mind is a 'support' launch path so that every app is encouraged to always provide a way for the user to get support. And data_export, privacy_policy, etc? Seems neat... except then the use cases become mixed - that becomes a structured way to describe the site, as opposed to a set of links intended to be popular entry points into an application. Support might be a popular entry point... but not icon-on-your-desktop popular. This also points out some potential for abuse; if you actually get more real estate based on your entry points, then you could get an annoying spammy application (heck, those entry points could be ad redirectors). Though if it's more like a context menu then it's not such a big deal. There are some existing conventions for describing sites on an origin basis. One example is host-meta: http://tools.ietf.org/html/rfc6415 - put that at /.well-known/host-meta.json and you can define a bunch of links, and we have a structured way to find them. No one is using it (that I know of), but apps are a great opportunity to get developers to use some of these existing tools, if we build UI that consumes that information. ------------------------------------------------------------------------------ Ragavan Srinivasan [email protected] Feb 9 to dev-webapps Ben Francis wrote: On Fri, Jan 27, 2012 at 5:18 PM, Fabrice Desré<[email protected]> wrote: We need this for gaia, where the dialer and contact manager are the same app. The UX team and cjones have suggested several use cases for this in Gaia, Can someone point me at these other use cases besides the dialer/contact manager one? Also, I suspect it would be good to get feedback on whether existing app developers we've been talking to (like those in the developer preview) would find something like this useful. ------------------------------------------------------------------------------ Ben Francis [email protected] via mozilla.com Feb 9 to dev-webapps On Thu, Feb 9, 2012 at 9:03 AM, Ragavan Srinivasan <[email protected]>wrote: > > > Ben Francis wrote: > >> On Fri, Jan 27, 2012 at 5:18 PM, Fabrice Desré<[email protected]> >> wrote: >> >>> We need this for gaia, where the dialer and contact manager are the same >>> app. >>> >> >> >> The UX team and cjones have suggested several use cases for this in Gaia, >> > > Can someone point me at these other use cases besides the dialer/contact > manager one? Also, I suspect it would be good to get feedback on whether > existing app developers we've been talking to (like those in the developer > preview) would find something like this useful. In Gaia so far examples are Dialer/Contacts and Camera/Gallery. Still not sure if multiple entry points to one app is the right solution, but it was one idea suggested by UX and seems to make sense. ------------------------------------------------------------------------------ Ian Bicking [email protected] Feb 9 to Ben, dev-webapps A speculative use case combined with Anant's proposal: allow entry points to be filterable. Or more specifically, allow different launch points for mobile or non-mobile. One thing that kind of messes up our origin-per-app system is the common practice of using entirely alternate sites for mobile (e.g., m.facebook.com). I don't understand all the motivations for this, but one major one I presume is that you want to send the minimum number of bytes on mobile, so sending a full page and then doing detection purely in the client is not ideal. By allowing selection of launch points we can do this selection for the site before the first request. ------------------------------------------------------------------------------ Ragavan Srinivasan [email protected] Feb 9 to dev-webapps Hey guys, Ian Bicking wrote: A speculative use case combined with Anant's proposal: allow entry points to be filterable. Or more specifically, allow different launch points for mobile or non-mobile. One thing that kind of messes up our origin-per-app system is the common practice of using entirely alternate sites for mobile (e.g., m.facebook.com). I don't understand all the motivations for this, but one major one I presume is that you want to send the minimum number of bytes on mobile, so sending a full page and then doing detection purely in the client is not ideal. By allowing selection of launch points we can do this selection for the site before the first request. In the interest of keeping the manifest simple, my vote is to *not* add multiple entry points for now. If we find real world use cases that are more common than the specific system Apps use cases we have discussed so far, we should revisit. Thoughts? ------------------------------------------------------------------------------ Fabrice Desré [email protected] Feb 10 to Ragavan, dev-webapps On 02/09/2012 05:00 PM, Ragavan Srinivasan wrote: Hey guys, In the interest of keeping the manifest simple, my vote is to *not* add multiple entry points for now. If we find real world use cases that are more common than the specific system Apps use cases we have discussed so far, we should revisit. Thoughts? I'd like us to add this support for two reasons: - in the "one app" case, that does not add complexity for the app developer. - we don't have an alternative. _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
