As a developer new to FirefoX OS, I would like to be able to be up and running with a sample code base with the least amount of effort so that I can get going rapidly and quickly learn how to build an app on Firefox OS. Acceptance Criteria: - Developers can select a sample/template without ever leaving the App Manager and with a mouse click be up and running with the template. - Developer can choose from a list of templates directly within the App manager - (Evenutally) developers should also be able to edit their app with an editor with bare bones functionality.

While I understand the need to have an HTML page that lists the templates in a way that is accessible both by "humans and machines", I am worried that it looks like updating that page will be a manual process and that means that BUGS will happen--unless it's possible to get such page to read and render an automatically generated JSON file (which I'm already able to generate). Looks like we want the page to be in MDN, so I'm going to ask somebody who works on it about the feasibility of running custom JS code in a given page. Something else that is bothering me is having someone "malicious" editing said page and changing the links to point to somewhere that provides templates that look legit but might contain bad stuff. Unless said page can be locked. I'll ask all this to an MDN dev and will come back with data.

If we do a web based interaction, there is a need for a dedicated developer web application that would represent the template directory. It probably can't be an editable MDN Wiki page. There needs to be some sort of API callback to the App manager when the user has selected a template so that the app manager can get the coordinates for downloading the template. As an initial start, if there are no resources to build out a template directory, or we have too few templates, then a JSON file with a simple drop down in the App manager is probably enough for a first iteration.

Copying Les's email comments here for posterity: 1) We can't lock MDN pages for edits by certain users. That feature was started, but not finished in favor of other redesign work once it looked like it wouldn't actually be needed for the content zones launch. 2) We can create KumaScript to fetch that JSON, as long as the net flows exist between MDN and wherever it's hosted. That's been a problem here & there for certain data sources at Mozilla (ie. bugzilla) So, this sounds like a good project, but we've got some work to do first to support it on MDN. Axel, Can "some sort of API callback to the App Manager when the user has selected a template so that the app manager can get the coordinates for downloading the template" be a hyperlink to a template URL served with a custom Content-Type for the App Manager to handle?

AIUI, the advantages of using MDN are a faster and easier update cadence (i.e., wiki page edits vs. DevTools releases?) including faster and easier localization while keep the ability to make the interface more engaging? In addition, it may be easier to track template usage via MDN's Google Analytics? But, if these aren't immediate problems, it sounds like the drop-down is a good first step.

Personally, this feels like two separate things: 1) I would have a detailed, graphically rich page on MDN (in the App Center) that featured the layouts. 2) I would do the layout selection HTML page presented in the Developer Tools as a static resource that is generated (probably via a grunt command) by the App Engineering devs after each update to Brick and its layouts. The generated, slimmed layout selection page could then be put on a CDN that is all about serving static resources as efficiently as possible. Thoughts?

On the App Manager side, we'd prefer to deal a JSON file. There would be 2 ways to handle a HTML page, and both ways have drawbacks: 1) open the HTML page in a Firefox tab. But the user would have to unzip and import the template manually 2) open the HTML page in a App Manager window. The App Manager can handle the download and do the import automatically, but then we would have to deal with potential security issues. Option 2 might be possible, but it's more work on our side. > Can "some sort of API callback to the App Manager when the user has > selected a template so that the app manager can get the coordinates > for downloading the template" be a hyperlink to a template URL served > with a custom Content-Type for the App Manager to handle? Yes but security. It's all possible, but a JSON file would be much easier. At least for a V1.

(In reply to Paul Rouget [:paul] from comment #6) > > Can "some sort of API callback to the App Manager when the user has > > selected a template so that the app manager can get the coordinates > > for downloading the template" be a hyperlink to a template URL served > > with a custom Content-Type for the App Manager to handle? > > Yes but security. > > It's all possible, but a JSON file would be much easier. At least for a V1. Wouldn't this just amount to a window.postMessage() to the layout selection page's parent frame that sends a URL for the zip? (the App Manager could even do a quick origin check on the URL it receives to ensure it is from the correct place)

(In reply to Luke Crouch [:groovecoder] from comment #3) > Copying Les's email comments here for posterity: > > 1) We can't lock MDN pages for edits by certain users. That feature was > started, but not finished in favor of other redesign work once it looked > like it wouldn't actually be needed for the content zones launch. > > 2) We can create KumaScript to fetch that JSON, as long as the net flows > exist between MDN and wherever it's hosted. That's been a problem here & > there for certain data sources at Mozilla (ie. bugzilla) > > So, this sounds like a good project, but we've got some work to do first to > support it on MDN. > > Axel, > > Can "some sort of API callback to the App Manager when the user has selected > a template so that the app manager can get the coordinates for downloading > the template" be a hyperlink to a template URL served with a custom > Content-Type for the App Manager to handle? Lots of issues. The advantage of a custom content type for download is that you could be browsing MDN, see a template, and just click on it, which would invoke the App Manager. So developers wouldn't even have to know about the app manager, they could click on a template and it would introduce them to the App manager. I really don't see the security issue, third party bloggers should be able to create templates, publish them on their blogs and have them open up the app manager. Security could be handled the same way it's handled in modern operating systems. If it's an unverified source, then Firefox could prompt the user for extra clicks before the App manager is opened. Also, the app manager as a rule of thumb should not execute any template code anyway, so not sure what security issue exists if the app manager opens a template. If we really want broad community adoption of the App manager, we should promote the ability for third parties to create templates that will prompt the opening of the app manager when downloaded, (with security pop up if it's unverified) and have a default template directory of our own that can be opened from within the app manager.

Given the last comment by Alex, I really feel like we should split this into two bugs: 1) A bug for implementing an HTML or JSON-driven page that will be opened in the App Manager to select app layouts 2) A bug for a detailed, graphically rich documentation and exploration page on MDN - with the added possibility of opening templates from it (Alex's point) These really seem to be independent work items in my view - let's not let one block the other over issues that are unique to each.

The App Manager can implement a protocol handler: https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers

+1 to splitting these up. Axel and Daniel highlight a good point that a key advantage of leveraging MDN is to tap into the existing audience there to boost adoption of the app manager. I filed bug 966144 for the MDN enhancement.

(In reply to Paul Rouget [:paul] from comment #10) > The App Manager can implement a protocol handler: > https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers That would be beautiful. I support what Axel wrote 100%: If we enable a way for us in particular (and more generally for anyone in the community) to make a webapp template, put it somewhere to download and point a link at it, we can enable a whole new class of ecosystem activity (app creators showing off their source code to download and manipulate). I like the protocol handler over a MIME type because it won't require server changes (you can link to github /zipball URLs directly for example). Downside of this is that if only Firefox (and new Firefoxes at that) know about the protocol, this will lead to an error. Can we feature-detect if a protocol is known? If so, we could progressively enhance by replacing a normal link to the ZIP with a app-template protocol link, if and only if it is supported. Thoughts?

(In reply to Fred Wenzel [:wenzel] from comment #12) > (In reply to Paul Rouget [:paul] from comment #10) > > The App Manager can implement a protocol handler: > > https://developer.mozilla.org/en-US/docs/Web-based_protocol_handlers > > That would be beautiful. I support what Axel wrote 100%: If we enable a way > for us in particular (and more generally for anyone in the community) to > make a webapp template, put it somewhere to download and point a link at it, > we can enable a whole new class of ecosystem activity (app creators showing > off their source code to download and manipulate). > > I like the protocol handler over a MIME type because it won't require server > changes (you can link to github /zipball URLs directly for example). > > Downside of this is that if only Firefox (and new Firefoxes at that) know > about the protocol, this will lead to an error. Can we feature-detect if a > protocol is known? If so, we could progressively enhance by replacing a > normal link to the ZIP with a app-template protocol link, if and only if it > is supported. > > Thoughts? Yes, you can detect if a protocol is registered: navigator.isProtocolHandlerRegistered(). Also, web protocol handlers are also supported in Chrome as of version 11, something to keep in mind.

I think we really need two user stories. One is for the "official" template directory available from the App manager, and the other is for the ability for developers to put custom URLs in their blogs that would open the App manager with the template. I suspect one technical solution will help to implement both user stories if we use a Mozilla managed page that features the "official" templates and have that page opened in the App manager.