On 04/05/2015 23:06, Jonas Sicking wrote:
The second complexity is "pinning". I think we should allow users to
pin websites to the homescreen. This should be possible for *any*
website, whether it has a W3C manifest, a FirefoxOS manifest, the
Apple-invented <meta> tags, or none of the above.

When the user pins a website I think we should grant it some
additional permissions automatically.
So we will replacing the word "installing" with the word "pinning"?
In this case, the challenge would be to make sure the user is aware of the consequences of pinning on permissions. Indeed, a user might want to be more restrictive than the Firefox Marketplace, and might not want to give additional permissions even to signed content. In this case, he/she should at least know what pinning grants. IMO, the advantage of the word "installing" is that it makes clearer that you give some level of trust to the application/website/webapp/whatever you're installing. But I agree it is quite a strong word for just bookmarking stuff in the homescreeen.
Maybe neither of these 2 words is good and we need to find something else...





On Thu, Apr 16, 2015 at 12:27 PM, Peter Dolanjski
<[email protected]> wrote:
Hello All,

There have been a number of discussion threads around the details pertaining
to the various forms of apps that are needed as we move forward with new
architecture (based on permissions, presence of a manifest, etc.).  A few of
us (product, engineering, partner engineering, Marketplace) got together to
try to assemble a simple description of what each distinct category is for
and when they would be used.  I plan to publish this on one of the v3 wikis,
but before I do I just wanted to open it up for comments/suggestions.

You can see the breakdown here: v3 App Model
Feel free to comment right in the doc.

In addition, I'll summarize it here in case you prefer some email dialogue
on it:

Web Site
Description:
Vanilla web site with no app manifest.
Distribution Channel(s):
1. Any web server
2. Indexed by Marketplace (hosted elsewhere)
Why would a Developer choose this option?
- Just a web site that should be used inside the browser. (no point in
enumerating all reasons for building a web site)
Why would a Developer *not* choose this option?
- Want to provide a more "native" experience
- Need access to sensitive APIs
Signing Required?
No
Mozilla Review?
Yes, for Marketplace indexed content only
Impact of Changes to Existing Apps
none
Proposed User Experience on v3
Discovered through browsing (any web server), searching or via Marketplace
with "open" button. Can optionally pin a page (not "site") to the homescreen
which will open in a browser window.

Web App
Description:
Standards-based web app with W3C web app manifest.
Distribution Channel(s):
1. Any web server
2. Indexed by Marketplace (hosted elsewhere)
3. Hosted by Marketplace (TBD)
Why would a Developer choose this option?

- Want content to run standalone outside the browser on multiple platforms.

- No need to package assets

- If no sensitive APIs required, no extra signing process
Why would a Developer *not* choose this option?
- Developers coming from native consider hosting a service provided by the
Marketplace
Signing Required?
No
Mozilla Review?
Yes, for Marketplace indexed/hosted content only
Impact of Changes to Existing Apps
Existing hosted apps should use the new manifest format going forward, but
new FxOS versions should support legacy app versions.
Proposed User Experience on v3

Discovered through browsing (any web server), searching or via Marketplace
with "open" button. Can use instantly in the browser and optionally pin to
the homescreen to use as a standalone app (in an app window with fullscreen,
standalone or minimal-ui display mode). Details TBD


Firefox App
Description:
Signed web app (when privileged API access needed), at least initially
Firefox* specific. W3C web app manifest with moz-prefixed extensions, inside
a hosted streamable package.
Distribution Channel(s):
1. Any web server
2. Indexed by Marketplace (hosted elsewhere)
3. Hosted by Marketplace
Why would a Developer choose this option?

- Easier to handle offline support until ServiceWorkers lands and gains
support

- Need access to Firefox* specific privileged APIs
Why would a Developer *not* choose this option?
- Requires signing by Marketplace (for privileged apps)
Signing Required?
Yes (for privileged apps, TBD)
Mozilla Review?
Yes, for Marketplace indexed/hosted content only
Impact of Changes to Existing Apps
Existing packaged apps need to be converted to new format.  Developers need
to adhere to new format going forward.
Proposed User Experience on v3
Discovered through browsing, searching or via Marketplace via "open" button.
Can use instantly in the browser and optionally pin to the homescreen to use
as a standalone app (in an app window with fullscreen, standalone or
minimal-ui display mode). Some permissions may require app installation
(TBD).

Legacy (Open Web App)
Description:
"web", "privileged" and "certified" apps with an Open Web App Manifest.
Packaged in a signed zip file (except "web" type).
Distribution Channel(s):
1. Marketplace
2. Any web server ("web" type only)
Why would a Developer choose this option?
- Supporting an old app
Why would a Developer *not* choose this option?
- Requires review by Marketplace
Signing Required?
Yes (except web type)
Mozilla Review?
Yes, for Marketplace indexed/hosted content only
Impact of Changes to Existing Apps
none
Proposed User Experience on v3

Hosted apps should work the same as web apps in v3 adhering to the display
mode. Packaged apps likely won't be supported but we'll need to
automatically convert them to work with the new UX.


Thanks,


Peter Dolanjski

Product Manager, Firefox OS

Mozilla


_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g

Reply via email to