Strong recommendations to help developers make better apps

[Fred Wenzel]

Hello everyone!

For developers, building apps on the Web platform can pose a
fragmentation problem: For every development concern, there are often a
dozen or more possible options to consider, without clear pros or cons.
Web developers can feel intimidated not simply by their choices, but by
how _similar_ their choices are.

While this openness and community is a virtue, it leads to "choice
paralysis" and the wrong impression that the Web is a harder platform to
develop for than more restrictive alternatives.

However, by making strong, informed recommendations to developers, we
can help turn the variety of development tools available on the Web from
a daunting proposition into an empowering one.

A great example of this is the significant attention[1] tofumatt's
localForage[2] project has received. It provides a cross-platform,
asynchronous storage library that "just works". With its straightforward
API, it _removes_ an entire monotonous development choice for
developers. The community honored this drastic simplification with
almost 2000(!) "stars" on github in just a few days.

Furthermore, we have a responsibility to our developers to ensure that
certain frameworks, libraries, etc., have been tested and work well with
our own and (eventually) other target platforms.

Our developer-facing groups (Apps Engineering, Developer Relations and
Developer Tools in particular) are collaborating to expand this effort
systematically across the various parts of the development experience.


Some projects that are already in flight include:

- web-components-based (featuring Brick) app templates that work out of
the box
- additional such components for hard, yet common problems such as
scrolling of large lists
- Mozilla-endorsed framework and tool chain for apps
- using the Firefox App Manager to start a new project from a template
and allow developing on it right then and there, no other tools needed
- submitting an app straight to the Marketplace from the App Manager
- an updated "MDN Apps Zone" experience focusing on developer concerns
and our materials and recommendations for each case


If this whetted your appetite, great! 2014 is an exciting year to be an
apps developer! All this and more is coming--step by step--to a
developer experience near you.

If you have any question or comments, speak up, or step by #apps on IRC!

Thanks,
Fred Wenzel


[1] https://hacks.mozilla.org/2014/02/localforage-offline-storage-improved/
[2] https://github.com/mozilla/localForage

[Josh Carpenter]

Sounds awesome, Fred! Having been through a javascript libraries choice paralysis situation last fall, I’m totally in the market for this. Can you say a bit more yet about the output, yet? eg: Do you foresee this being a dedicated URL I can hit for the latest and greatest recommendations across categories? Or is it more of a loose cluster of parallel initiatives? Most importantly, what’s the code name for it?

—
Josh Carpenter
UX Lead, Firefox OS
Mozilla

> _______________________________________________
> dev-gaia mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-gaia

[Frederic Wenzel]

Hi Josh!

The key entry point for this on the Web is likely going to be the MDN
Apps Zone:
<https://developer.mozilla.org/en-US/Apps>

It currently does cover a variety of topics (and gets better every day
due to the tireless work of the apps docs team and community), but
there are some discoverability / IA issues, and it also does not cover
all the interesting output our ecosystem has so far produced. There are
github repos, blog posts, third-party people's projects etc etc.

That said, it is a cluster of initiatives. I don't have the illusion we
can (or should) literally pull in everything into one central place.
Code rightly lives on github, our central developer tool for apps is
the app manager (+ Fx OS Simulator), etc. Luckily, hyperlinks exist, so
I am not too worried about that :)

Code name right now is "dev recommendations" which is a) long b)
boring, so I am more than open for input!

~F

On Tue Feb 18 16:05:04 2014, Josh Carpenter wrote:
> Sounds awesome, Fred! Having been through a javascript libraries
> choice paralysis situation last fall, I’m totally in the market for
> this. Can you say a bit more yet about the output, yet? eg: Do you
> foresee this being a dedicated URL I can hit for the latest and
> greatest recommendations across categories? Or is it more of a loose
> cluster of parallel initiatives? Most importantly, what’s the code
> name for it?
>
> —
> Josh Carpenter
> UX Lead, Firefox OS
> Mozilla
>
> On Feb 19, 2014, at 12:52 AM, Fred Wenzel <fwe...@mozilla.com

>> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
>> https://lists.mozilla.org/listinfo/dev-gaia
>

[Daniel Buchner]

Another section of recommendations (which Fred may or may not have
inferred) are vetted services developers utilize in creating and managing
their apps. This area of recommendations includes the nobackend solution
space and targeted services developers consume/integrate to accomplish
specific tasks (think: YQL, Komodo Labs, social login, comment systems, etc)

We look forward to creating a robust, end-to-end, recommendation playground
that provides developers with a friendly, trusted place to explore and
select solutions that work for them.

- Daniel

[Luke Crouch]

tofumatt - great work! Fred - great vision!

Back in "my day" with the ohloh team, they let developers create their
"OSS stack" - i.e., the OSS they used from OS layer, to server software,
to apps.

So, what if we call these developer recommendations "App stacks"? I.e.,
stacks of web libraries, tools, and services that work well together to
deliver great developer and end-user experiences.

-L

On 2/18/14 6:46 PM, Daniel Buchner wrote:
> Another section of recommendations (which Fred may or may not have
> inferred) are vetted services developers utilize in creating and managing
> their apps. This area of recommendations includes the nobackend solution
> space and targeted services developers consume/integrate to accomplish
> specific tasks (think: YQL, Komodo Labs, social login, comment systems, etc)
>
> We look forward to creating a robust, end-to-end, recommendation playground
> that provides developers with a friendly, trusted place to explore and
> select solutions that work for them.
>
> - Daniel
>
> On Tue, Feb 18, 2014 at 3:52 PM, Fred Wenzel<fwe...@mozilla.com> wrote:
>
>> >Hello everyone!
>> >
>> >For developers, building apps on the Web platform can pose a
>> >fragmentation problem: For every development concern, there are often a
>> >dozen or more possible options to consider, without clear pros or cons.
>> >Web developers can feel intimidated not simply by their choices, but by

>> >how_similar_ their choices are.

>> >
>> >While this openness and community is a virtue, it leads to "choice
>> >paralysis" and the wrong impression that the Web is a harder platform to
>> >develop for than more restrictive alternatives.
>> >
>> >However, by making strong, informed recommendations to developers, we
>> >can help turn the variety of development tools available on the Web from
>> >a daunting proposition into an empowering one.
>> >
>> >A great example of this is the significant attention[1] tofumatt's
>> >localForage[2] project has received. It provides a cross-platform,
>> >asynchronous storage library that "just works". With its straightforward

>> >API, it_removes_ an entire monotonous development choice for

> _______________________________________________
> engagement-developers mailing list
> engagement...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/engagement-developers

--
Q: Why is this email five sentences or less?
A: http://five.sentenc.es

[Fred Lin]

It's great to address the burden of develop webapp.
Though gaia developer may not recognize this issue, it's quite different between gaia and webapp development at this stage.
I'd like to share some of my investigation so we can have more information to improve webapp development experience.


1. The marketplace that web user will front with:

Marketplace can't filter the unsupported app to user.

User have limit knowledge about what Firefox OS cross-platform compatibility means, and confused when they can see the app but can't use it in desktop(if develop does not select to support that platform) (It might because we didn't communicate to community about Firefox Runtime yet?)
.
http://stackoverflow.com/questions/21473666/example-of-firefox-os-cross-platform-compatibility


2. The Marketplace that webapp developer front with:

My friend has good knowledge about gaia development, and tried to use requireJS(alameda) and gUM audio for packaged app but encounter CSP issue while submitting to the marketplace (solution: precompile by r.js to pass the policy), and then he encounter the issue that the reviewer can't test gUM audio in certain devices (which is a device specific bug). The poor experience lead him cancel the app submission to marketplace. As a new mobile platform, we can see how we lose this kind of capable developer, which is eager to develop cutting edge webapp that help us differentiate from other competitors.


3. Marketplace app with cutting edge or platform specific features:

As a platform developer, we also encounter issues that we can't submit homescreen or keyboard IME webapp to marketplace for people who can use nightly version of FirefoxOS device, and find out the problem early.


4. The MDN gUM document confuse the webapp developer:

For webRTC support, most developer will reference to
https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getUserMedia

but they'll neglect the need of add permissions `"audio-capture": {}` in manifest.webapp for FirefoxOS device
https://developer.mozilla.org/en-US/Apps/Reference

It does not provide information by version (FxOS 1.2+ for gUM audio, 1.4+ for video) as well.
Maybe we should come out a rule to keep these info up-to-date.



regards
--
Fred Lin



----- 原始郵件 -----
寄件人: "Daniel Buchner" <dan...@mozilla.com>
收件人: dev-w...@lists.mozilla.org
副本: dev-...@lists.mozilla.org, "apps" <ap...@mozilla.com>, "engagement-developers" <engagement...@lists.mozilla.org>
寄件箱: 2014年2 月19日, 星期三 上午 8:46:23
標題: Re: Strong recommendations to help developers make better apps

Another section of recommendations (which Fred may or may not have
inferred) are vetted services developers utilize in creating and managing
their apps. This area of recommendations includes the nobackend solution
space and targeted services developers consume/integrate to accomplish
specific tasks (think: YQL, Komodo Labs, social login, comment systems, etc)

We look forward to creating a robust, end-to-end, recommendation playground
that provides developers with a friendly, trusted place to explore and
select solutions that work for them.

- Daniel

On Tue, Feb 18, 2014 at 3:52 PM, Fred Wenzel <fwe...@mozilla.com> wrote:

> Hello everyone!
>
> For developers, building apps on the Web platform can pose a
> fragmentation problem: For every development concern, there are often a
> dozen or more possible options to consider, without clear pros or cons.
> Web developers can feel intimidated not simply by their choices, but by

> how _similar_ their choices are.

>
> While this openness and community is a virtue, it leads to "choice
> paralysis" and the wrong impression that the Web is a harder platform to
> develop for than more restrictive alternatives.
>
> However, by making strong, informed recommendations to developers, we
> can help turn the variety of development tools available on the Web from
> a daunting proposition into an empowering one.
>
> A great example of this is the significant attention[1] tofumatt's
> localForage[2] project has received. It provides a cross-platform,
> asynchronous storage library that "just works". With its straightforward

> API, it _removes_ an entire monotonous development choice for

dev-webapps mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

[Andrew Williamson]

On 19/02/2014 03:44, Fred Lin wrote:
> It's great to address the burden of develop webapp.
> Though gaia developer may not recognize this issue, it's quite different between gaia and webapp development at this stage.
> I'd like to share some of my investigation so we can have more information to improve webapp development experience.
>
>
> 1. The marketplace that web user will front with:
>
> Marketplace can't filter the unsupported app to user.
>
> User have limit knowledge about what Firefox OS cross-platform compatibility means, and confused when they can see the app but can't use it in desktop(if develop does not select to support that platform) (It might because we didn't communicate to community about Firefox Runtime yet?)
> .
> http://stackoverflow.com/questions/21473666/example-of-firefox-os-cross-platform-compatibility

Where do you think the problem lies here? That developers don't
understand the platform selection? Or that users don't understand why
apps are shown on Desktop they can't install?

> 2. The Marketplace that webapp developer front with:
>
> My friend has good knowledge about gaia development, and tried to use requireJS(alameda) and gUM audio for packaged app but encounter CSP issue while submitting to the marketplace (solution: precompile by r.js to pass the policy),

I agree its a problem, but what can we do about CSP errors?

> and then he encounter the issue that the reviewer can't test gUM audio in certain devices (which is a device specific bug). The poor experience lead him cancel the app submission to marketplace. As a new mobile platform, we can see how we lose this kind of capable developer, which is eager to develop cutting edge webapp that help us differentiate from other competitors.

Is it a known bug? What part of the poor experience can we improve?
(zero bugs in every 3rd party manufactured device being an impossibility)

> 3. Marketplace app with cutting edge or platform specific features:
>
> As a platform developer, we also encounter issues that we can't submit homescreen or keyboard IME webapp to marketplace for people who can use nightly version of FirefoxOS device, and find out the problem early.

Marketplace can support apps like keyboards, as long as there is a
feature-bucket to filter out the app from the other 99% of users who
aren't on Nightly FxOS builds, and of course those features are
detectable on the client side. With a consumer orientated Marketplace,
there are always going to be issues for platform developers trying to
use it.

> 4. The MDN gUM document confuse the webapp developer:
>
> For webRTC support, most developer will reference to
> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getUserMedia
>
> but they'll neglect the need of add permissions `"audio-capture": {}` in manifest.webapp for FirefoxOS device
> https://developer.mozilla.org/en-US/Apps/Reference
>
> It does not provide information by version (FxOS 1.2+ for gUM audio, 1.4+ for video) as well.
> Maybe we should come out a rule to keep these info up-to-date.

agree 100% here.

[Andrew Williamson]

On 19/02/2014 03:44, Fred Lin wrote:

> It's great to address the burden of develop webapp.
> Though gaia developer may not recognize this issue, it's quite different between gaia and webapp development at this stage.
> I'd like to share some of my investigation so we can have more information to improve webapp development experience.
>
>
> 1. The marketplace that web user will front with:
>
> Marketplace can't filter the unsupported app to user.
>
> User have limit knowledge about what Firefox OS cross-platform compatibility means, and confused when they can see the app but can't use it in desktop(if develop does not select to support that platform) (It might because we didn't communicate to community about Firefox Runtime yet?)
> .
> http://stackoverflow.com/questions/21473666/example-of-firefox-os-cross-platform-compatibility

Where do you think the problem lies here? That developers don't
understand the platform selection? Or that users don't understand why
apps are shown on Desktop they can't install?

> 2. The Marketplace that webapp developer front with:
>
> My friend has good knowledge about gaia development, and tried to use requireJS(alameda) and gUM audio for packaged app but encounter CSP issue while submitting to the marketplace (solution: precompile by r.js to pass the policy),

I agree its a problem, but what can we do about CSP errors?

> and then he encounter the issue that the reviewer can't test gUM audio in certain devices (which is a device specific bug). The poor experience lead him cancel the app submission to marketplace. As a new mobile platform, we can see how we lose this kind of capable developer, which is eager to develop cutting edge webapp that help us differentiate from other competitors.

Is it a known bug? What part of the poor experience can we improve?
(zero bugs in every 3rd party manufactured device being an impossibility)

> 3. Marketplace app with cutting edge or platform specific features:
>
> As a platform developer, we also encounter issues that we can't submit homescreen or keyboard IME webapp to marketplace for people who can use nightly version of FirefoxOS device, and find out the problem early.

Marketplace can support apps like keyboards, as long as there is a
feature-bucket to filter out the app from the other 99% of users who
aren't on Nightly FxOS builds, and of course those features are
detectable on the client side. With a consumer orientated Marketplace,
there are always going to be issues for platform developers trying to
use it.

> 4. The MDN gUM document confuse the webapp developer:
>
> For webRTC support, most developer will reference to
> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getUserMedia
>
> but they'll neglect the need of add permissions `"audio-capture": {}` in manifest.webapp for FirefoxOS device
> https://developer.mozilla.org/en-US/Apps/Reference
>
> It does not provide information by version (FxOS 1.2+ for gUM audio, 1.4+ for video) as well.
> Maybe we should come out a rule to keep these info up-to-date.

agree 100% here.

[Kumar McMillan]

Sounds like a fantastic idea!

> - Mozilla-endorsed framework and tool chain for apps

Instead of Mozilla-endorsed might we consider community-endorsed? i.e. endorsed by a community of experts. If we want to make Mozilla the central authority we just need to plan for what to do when our ratings go stale. For example, should we revisit each endorsement periodically? The state of tech changes so fast; this makes me think crowd sourcing it might be more effective.

[Fabrice Desré]

On 02/18/2014 07:44 PM, Fred Lin wrote:

> 4. The MDN gUM document confuse the webapp developer:
>
> For webRTC support, most developer will reference to
> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getUserMedia
>
> but they'll neglect the need of add permissions `"audio-capture": {}` in manifest.webapp for FirefoxOS device
> https://developer.mozilla.org/en-US/Apps/Reference
>
> It does not provide information by version (FxOS 1.2+ for gUM audio, 1.4+ for video) as well.
> Maybe we should come out a rule to keep these info up-to-date.

There are rules already. Developers should set the dev-doc-needed
keyword on their bugs when they land such changes. And of course, they
can edit MDN themselves, it's a wiki ;)

Fabrice
--
Fabrice Desré
b2g team
Mozilla Corporation

[Bill Maggs]

Adding to Kumar's voice here, we can be more opinionated, but can't just say it's MoCo that is doing the recommendations. I think Mozilla has a good track record of the community being clearly identified as the source, and we can do that here, too. Especially since in the framework-crazy world of today, we are sure to piss some developers off with any choice, however well thought through.

And:

If we can just come up with a innovative solution for list scrolling that combines components with platform changes that will be easy for the other browsers to adopt, then we will get a ton of good will. I have been talking about this one for some time. Some progress now? Maybe we should document on MDN all the approaches taken by potch, Arron, and others, the good and the bad? It's a worthy effort.

[Matthew R. MacPherson]

Community can (should!) be involved too, but my observation at hack days or whatnot is that we tell developers to use a framework (but don't tell them which) or tell them to use the wrong one (I've suggested Backbone before but people have ditched it).

It would certainly be an on-going thing, but we need to keep up with said changes in tech to stay relevant to (and empathize with) the needs of web app developers anyway, so it's inescapable work in my eyes. And I think developers react well when we put our name on the tools we suggest they use.

Matthew Riley MacPherson (Sent from mobile)

[Stormy Peters]

On Wed, Feb 19, 2014 at 9:20 AM, Bill Maggs <bi...@mozilla.com> wrote:

> Adding to Kumar's voice here, we can be more opinionated, but can't just
> say it's MoCo that is doing the recommendations. I think Mozilla has a good
> track record of the community being clearly identified as the source, and
> we can do that here, too. Especially since in the framework-crazy world of
> today, we are sure to piss some developers off with any choice, however
> well thought through.
>

I think we can make recommendations in a non-exclusive way. We can say
"Hey, you need an offline solution, here's one we tried that works well."
If people have suggestions or recommendations to make, we have writers that
can help frame it appropriately.

Stormy

>
> And:
>
> If we can just come up with a innovative solution for list scrolling that
> combines components with platform changes that will be easy for the other
> browsers to adopt, then we will get a ton of good will. I have been talking
> about this one for some time. Some progress now? Maybe we should document
> on MDN all the approaches taken by potch, Arron, and others, the good and
> the bad? It's a worthy effort.
>
> ----- Original Message -----
> From: "Kumar McMillan" <kmcm...@mozilla.com>
> To: dev-w...@lists.mozilla.org
> Cc: "apps" <ap...@mozilla.com>, dev-...@lists.mozilla.org,
> engagement...@lists.mozilla.org
> Sent: Wednesday, February 19, 2014 8:03:18 AM
> Subject: Re: Strong recommendations to help developers make better apps
>
>

[Janet Swisher]

I can see this being done simply as a category of posts on Hacks. That
way, it's individual developers, who may or may not be staff, endorsing
a collection of tools for a particular purpose. If their views change,
they can make an update or a new post. Readers could view the whole
collection of recommendations, with the implicit understanding (since
it's a blog) that older posts are staler than new ones.

--
Janet Swisher <mailto:jREMOVE...@mozilla.com>
Mozilla Developer Network <https://developer.mozilla.org>
Developer Engagement Community Organizer

[Janet Swisher]

If those options fail, you can file a Dev Doc bug so the MDN writing
team will be aware of the problem:
https://bugzilla.mozilla.org/enter_bug.cgi?product=Developer+Documentation

[tofumatt]

But how is that different from the status quo? A serious of hacks posts without a common voice would not be what convinced me to use a particular set of tools. That’s what Hacks, or A List Apart, or whatever is for—and they’re great resources. But when I, as a developer, go to “How do I make web apps for Mozilla?” page I want not only guidance, but brief and instructive guidance. I don’t want to read twelve blog posts in twelve voices from twelve points in time on six frameworks or pieces. I want a README like this: https://github.com/gcollazo/brunch-with-ember-reloaded

I recently used this skeleton for a personal app, and found it AMAZING. It’s a no-nonsense, get-started approach that had me at a functioning app in no time. Plus: although it made choices FOR ME, it allowed me to change things I felt opinionated on.

Part of our messaging has always been “it’s the web and you can do what you want”. Developers who don’t like our choices can try to convince us of better ones and will either change our minds (great!) or won’t (that’s fine), but they are the ones who already have opinions. There are lots of devs who don’t care whether it’s stylus or SCSS or SASS or Less or CSS—I’m one of them. We should have solutions that cover a LOT of ground at once and are no-assembly-required, but I’m cool if we build in ways advanced people can make select choices.

I don’t want readers taking any of our recommendations as “stale”.
- tofumatt

On February 19, 2014 at 18:26:08, Janet Swisher (jswi...@mozilla.com) wrote:

I can see this being done simply as a category of posts on Hacks. That way, it's individual developers, who may or may not be staff, endorsing a collection of tools for a particular purpose. If their views change, they can make an update or a new post. Readers could view the whole collection of recommendations, with the implicit understanding (since it's a blog) that older posts are staler than new ones.

On 2/19/14 3:51 PM, Stormy Peters wrote:

On Wed, Feb 19, 2014 at 9:20 AM, Bill Maggs <bi...@mozilla.com> wrote:
Adding to Kumar's voice here, we can be more opinionated, but can't just say it's MoCo that is doing the recommendations. I think Mozilla has a good track record of the community being clearly identified as the source, and we can do that here, too. Especially since in the framework-crazy world of today, we are sure to piss some developers off with any choice, however well thought through.

I think we can make recommendations in a non-exclusive way. We can say "Hey, you need an offline solution, here's one we tried that works well." If people have suggestions or recommendations to make, we have writers that can help frame it appropriately.

Stormy

 

And:

If we can just come up with a innovative solution for list scrolling that combines components with platform changes that will be easy for the other browsers to adopt, then we will get a ton of good will. I have been talking about this one for some time. Some progress now? Maybe we should document on MDN all the approaches taken by potch, Arron, and others, the good and the bad? It's a worthy effort.

----- Original Message -----
From: "Kumar McMillan" <kmcm...@mozilla.com>

To: dev-w...@lists.mozilla.org
Cc: "apps" <ap...@mozilla.com>, dev-...@lists.mozilla.org, engagement...@lists.mozilla.org
Sent: Wednesday, February 19, 2014 8:03:18 AM
Subject: Re: Strong recommendations to help developers make better apps

Mozilla Developer Network
Developer Engagement Community Organizer

[Fred Lin]

> 1. The marketplace that web user will front with:
>
> Marketplace can't filter the unsupported app to user.
>
> User have limit knowledge about what Firefox OS cross-platform compatibility means, and confused when they can see the app but can't use it in desktop(if develop does not select to support that platform) (It might because we didn't communicate to community about Firefox Runtime yet?)
> .
> http://stackoverflow.com/questions/21473666/example-of-firefox-os-cross-platform-compatibility

> Where do you think the problem lies here? That developers don't
> understand the platform selection? Or that users don't understand why
> apps are shown on Desktop they can't install?

I think its more about the usage flow design. Once we have Firefox Account and able to install app to device from desktop just like apple or google, the problem might be mitigated. But current flow confuse the desktop user (and tablet and more..).

> 2. The Marketplace that webapp developer front with:
>
> My friend has good knowledge about gaia development, and tried to use requireJS(alameda) and gUM audio for packaged app but encounter CSP issue while submitting to the marketplace (solution: precompile by r.js to pass the policy),

> I agree its a problem, but what can we do about CSP errors?

We should follow CSP rules, but also need to address howto use these popular libraries for FirefoxOS pacakaged app in MDN. Which could align to the `Strong recommendations` section.

> and then he encounter the issue that the reviewer can't test gUM audio in certain devices (which is a device specific bug). The poor experience lead him cancel the app submission to marketplace. As a new mobile platform, we can see how we lose this kind of capable developer, which is eager to develop cutting edge webapp that help us differentiate from other competitors.

> Is it a known bug? What part of the poor experience can we improve?
(zero bugs in every 3rd party manufactured device being an impossibility)

As a platform, it's our responsibility to make sure the device should fit some compliance rule, or the feature detection is collapsed, which make the impression to user that web is not reliable.

> 3. Marketplace app with cutting edge or platform specific features:
>
> As a platform developer, we also encounter issues that we can't submit homescreen or keyboard IME webapp to marketplace for people who can use nightly version of FirefoxOS device, and find out the problem early.

> Marketplace can support apps like keyboards, as long as there is a
> feature-bucket to filter out the app from the other 99% of users who
> aren't on Nightly FxOS builds, and of course those features are
> detectable on the client side. With a consumer orientated Marketplace,
> there are always going to be issues for platform developers trying to
> use it.

We could have a staging marketplace that developer can test their app with more loose rules. Maybe just for devices that enabled the developer settings, so it create the fense to avoid consumers trapping there occasionally.

[Robert Nyman]

On February 19, 2014 at 18:26:08, Janet Swisher (jswi...@mozilla.com) wrote:

> I can see this being done simply as a category of posts on Hacks. That way, it's individual developers, who may or may not be staff, endorsing a collection of tools for a particular purpose. If their views change, they can make an update or a new post. Readers could view the whole collection of recommendations, with the implicit understanding (since it's a blog) that older posts are staler than new ones.

On 20 Feb 2014, at 00:43, tofumatt <tofu...@mozilla.com> wrote:

> But how is that different from the status quo? A serious of hacks posts without a common voice would not be what convinced me to use a particular set of tools. That’s what Hacks, or A List Apart, or whatever is for—and they’re great resources. But when I, as a developer, go to “How do I make web apps for Mozilla?” page I want not only guidance, but brief and instructive guidance. I don’t want to read twelve blog posts in twelve voices from twelve points in time on six frameworks or pieces. I want a README like this: https://github.com/gcollazo/brunch-with-ember-reloaded

Yeah, my gut feeling is that Hacks wouldn’t be optimal for this. It could help to lead attention to it on a regular basis, but for me I’d rather see it as a section on MDN. And I completely agree that it should be run by Mozillians and the greater web community alike, for credibility and, to be honest, for staying relevant.

I believe this could be a good part of the Developer Program, helping developers to make choices suiting their specific needs. I e-mailed Fred Wenzel directly when he sent the first e-mail in this thread, but I might as well share what I said here:

> This is great! The immediate thing that sprung into my mind - and an idea I’ve toyed with before - is to have a section of the Developer Program to help developers make those choices. I.e. a section for “Finding the best tool for the job”, with key questions and decisions, taking the developer step by step closer to a good list of options matching their needs.


I think we need something akin to http://www.javascriptoo.com/ (although that’s a bit simplified from the greater need, but still more in the right direction).


- Robert

[L. David Baron]

On Tuesday 2014-02-18 15:52 -0800, Fred Wenzel wrote:
> For developers, building apps on the Web platform can pose a
> fragmentation problem: For every development concern, there are often a
> dozen or more possible options to consider, without clear pros or cons.

I'd encourage talking to Gecko developers who have implemented Web
platform features, so you can incorporate their knowledge about what
is faster or smaller, what's likely to be optimized more in the
future, etc., into strong recommendations that you make.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Jonas Sicking]

On Feb 19, 2014 1:52 PM, "Stormy Peters" <spe...@mozilla.com> wrote:
>
> On Wed, Feb 19, 2014 at 9:20 AM, Bill Maggs <bi...@mozilla.com> wrote:
>
> > Adding to Kumar's voice here, we can be more opinionated, but can't just
> > say it's MoCo that is doing the recommendations. I think Mozilla has a
good
> > track record of the community being clearly identified as the source,
and
> > we can do that here, too. Especially since in the framework-crazy world
of
> > today, we are sure to piss some developers off with any choice, however
> > well thought through.
> >
>
> I think we can make recommendations in a non-exclusive way. We can say
> "Hey, you need an offline solution, here's one we tried that works well."
> If people have suggestions or recommendations to make, we have writers
that
> can help frame it appropriately.

Yes, I want to be very careful not to have developers get the impression
that we are saying "developing for FirefoxOS, then you should use one of
these libraries".

We should make it clear that our app platform is the web. Anything that
works on the web works here too. But here are some libraries that we've
found works well to solve problem X.

/ Jonas

[Daniel Buchner]

We'll also be feeding into Platform the web tech/API areas that need to be
faster, more performant, or more ergonomic, based on observed developer
need and what we discover throughout the recommendation process. We intend
to create a bi-directional feedback loop between Apps Engineering and
Platform that should net developers an even better web platform.

- Daniel

[Chris Mills]

On 19 Feb 2014, at 03:44, Fred Lin <fl...@mozilla.com> wrote:

> It's great to address the burden of develop webapp.
> Though gaia developer may not recognize this issue, it's quite different between gaia and webapp development at this stage.
> I'd like to share some of my investigation so we can have more information to improve webapp development experience.
>
>

> 1. The marketplace that web user will front with:
>
> Marketplace can't filter the unsupported app to user.
>
> User have limit knowledge about what Firefox OS cross-platform compatibility means, and confused when they can see the app but can't use it in desktop(if develop does not select to support that platform) (It might because we didn't communicate to community about Firefox Runtime yet?)
> .
> http://stackoverflow.com/questions/21473666/example-of-firefox-os-cross-platform-compatibility
>
>

> 2. The Marketplace that webapp developer front with:
>

> My friend has good knowledge about gaia development, and tried to use requireJS(alameda) and gUM audio for packaged app but encounter CSP issue while submitting to the marketplace (solution: precompile by r.js to pass the policy), and then he encounter the issue that the reviewer can't test gUM audio in certain devices (which is a device specific bug). The poor experience lead him cancel the app submission to marketplace. As a new mobile platform, we can see how we lose this kind of capable developer, which is eager to develop cutting edge webapp that help us differentiate from other competitors.

>
>
> 3. Marketplace app with cutting edge or platform specific features:
>
> As a platform developer, we also encounter issues that we can't submit homescreen or keyboard IME webapp to marketplace for people who can use nightly version of FirefoxOS device, and find out the problem early.
>

thanks for the notes. I’ve added these to my plans.

>
> 4. The MDN gUM document confuse the webapp developer:
>
> For webRTC support, most developer will reference to
> https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getUserMedia
>
> but they'll neglect the need of add permissions `"audio-capture": {}` in manifest.webapp for FirefoxOS device
> https://developer.mozilla.org/en-US/Apps/Reference
>
> It does not provide information by version (FxOS 1.2+ for gUM audio, 1.4+ for video) as well.
> Maybe we should come out a rule to keep these info up-to-date.

I’ve updated these locations with the information. For example, see

https://developer.mozilla.org/en-US/docs/Web/API/Navigator.getUserMedia#Permissions

It is a hard problem to keep all this information up to date, but we are working on it. Your input is appreciated.

One thing - shouldn’t “audio-capture” be “media-capture”, given that it handles audio and video?

[Chris Mills]

On 19 Feb 2014, at 11:41, Andrew Williamson <awill...@mozilla.com> wrote:

> On 19/02/2014 03:44, Fred Lin wrote:
>> It's great to address the burden of develop webapp.
>> Though gaia developer may not recognize this issue, it's quite different between gaia and webapp development at this stage.
>> I'd like to share some of my investigation so we can have more information to improve webapp development experience.
>>
>>
>> 1. The marketplace that web user will front with:
>>
>> Marketplace can't filter the unsupported app to user.
>>
>> User have limit knowledge about what Firefox OS cross-platform compatibility means, and confused when they can see the app but can't use it in desktop(if develop does not select to support that platform) (It might because we didn't communicate to community about Firefox Runtime yet?)
>> .
>> http://stackoverflow.com/questions/21473666/example-of-firefox-os-cross-platform-compatibility
>
> Where do you think the problem lies here? That developers don't understand the platform selection? Or that users don't understand why apps are shown on Desktop they can't install?

I am intending to add better documentation covering web runtime very soon, with more information to hopefully clear this up a bit. I agree it’s a problem, form both the web dev and mobile dev side.

>
>> 2. The Marketplace that webapp developer front with:
>>
>> My friend has good knowledge about gaia development, and tried to use requireJS(alameda) and gUM audio for packaged app but encounter CSP issue while submitting to the marketplace (solution: precompile by r.js to pass the policy),
>
> I agree its a problem, but what can we do about CSP errors?

We can’t tone down CSP errors/warnings, but we can educate people on what they mean, and how to work around them. Better CSP docs is also on my to do list.

[Chris Mills]

On 19 Feb 2014, at 16:03, Kumar McMillan <kmcm...@mozilla.com> wrote:

> Sounds like a fantastic idea!
>

>> - Mozilla-endorsed framework and tool chain for apps
>

> Instead of Mozilla-endorsed might we consider community-endorsed? i.e. endorsed by a community of experts. If we want to make Mozilla the central authority we just need to plan for what to do when our ratings go stale. For example, should we revisit each endorsement periodically? The state of tech changes so fast; this makes me think crowd sourcing it might be more effective.

+1 to community-endorsed. Great idea.

[Chris Mills]

On 19 Feb 2014, at 21:51, Stormy Peters <spe...@mozilla.com> wrote:

>
>
>
> On Wed, Feb 19, 2014 at 9:20 AM, Bill Maggs <bi...@mozilla.com> wrote:
> Adding to Kumar's voice here, we can be more opinionated, but can't just say it's MoCo that is doing the recommendations. I think Mozilla has a good track record of the community being clearly identified as the source, and we can do that here, too. Especially since in the framework-crazy world of today, we are sure to piss some developers off with any choice, however well thought through.
>
> I think we can make recommendations in a non-exclusive way. We can say "Hey, you need an offline solution, here's one we tried that works well." If people have suggestions or recommendations to make, we have writers that can help frame it appropriately.

amen to that. It needs to be recommended, not endorsed or insisted upon. People will always have their own loves and hates. Part of the app center restructure will be to include a “Recommended tools" top level menu item to cover Mozilla tools and app development workflow, but also “how to build an app with framework x, y and z”, including common gotchas and recommended frameworks for those who want a recommendation.

[Gasolin]

How about add an optional column or a regular feedback form for marketplace webapp developers if they like to share what library they use to build their app? 

Then we can have a recommend list by enthusiastic developers with true usage data.

Fred

  原始訊息  
寄件者： Chris Mills
已傳送： 2014年2月24日星期一 下午8:18
收件者： Stormy Peters
副本： dev-w...@lists.mozilla.org; engagement-developers Engagement; Kumar McMillan; apps; Bill Maggs; dev-...@lists.mozilla.org
主旨： Re: Strong recommendations to help developers make better apps

_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org

https://lists.mozilla.org/listinfo/dev-gaia

[Stefan Arentz]

I think one of the bigger problem is the lack of really good solid non-hackish and up-to-date examples.

Examples that can be used as both good tutorials and starting points for new web apps.

Other platforms usually ship with template projects. For example when I want to create a list based (master/detail) app on iOS I select that template and 5 seconds later I have something decent running. Of course there are lots of blanks to fill in but it is a real blessing to not have to start with a completely empty project directory.

How about this: Digital Ocean, a large VPS provider, recently started a program where they give people in their community $50 (or Digital Ocean credit) when they write a good tutorial. This was hugely successful ... there are now dozens and dozens of tutorials like 'how to setup a mail server' or 'how to host a ruby app on your VPS'. Maybe we should do something similar. Tell people, we want solid examples (article + code) of how to write (Firefox OS) web apps, how to use our Web APIs, how to use interesting frameworks on Firefox OS. We could even steer it in the right direction by making a list of preferred articles and putting a bounty on those.

:-)

S.

> - Mozilla-endorsed framework and tool chain for apps

> - using the Firefox App Manager to start a new project from a template
> and allow developing on it right then and there, no other tools needed
> - submitting an app straight to the Marketplace from the App Manager
> - an updated "MDN Apps Zone" experience focusing on developer concerns
> and our materials and recommendations for each case
>
>
> If this whetted your appetite, great! 2014 is an exciting year to be an
> apps developer! All this and more is coming--step by step--to a
> developer experience near you.
>
> If you have any question or comments, speak up, or step by #apps on IRC!
>
> Thanks,
> Fred Wenzel
>
>
> [1] https://hacks.mozilla.org/2014/02/localforage-offline-storage-improved/
> [2] https://github.com/mozilla/localForage

[Matthew R. MacPherson]

This is a project we're working on with mortar templates, but I don't random mini bounties are in the spirit of Mozilla.

Matthew Riley MacPherson (Sent from mobile)

[Stefan Arentz]

Those mortar templates are great.

Btw we do have a successful bounty program in place for security related issues. We pay a lot of money each year to people who contribute to that program. So I don't think it is that crazy or not in the spirit of Mozilla to also do something similar for documentation contributors.

And the submissions would not be completely random of course. They would have to be on topic to be useful. We can have a list of things we would like to see written. And coordinate so that people don't work on duplicate things. This is also what Digital Ocean does. You first submit a proposal. (Which is really 'i want to write XYZ. Ok?')

[Yvan Boily]

I think that badges make more sense; paying a content bounty is an interesting idea, but it could also yield super low quality work, not to mention an enormous amount of work to review and test user submissions

[Luke Crouch]

FWIW, the MDN demo studio "dev derby" competitions have turned out some
pretty great demos.

https://developer.mozilla.org/en-US/demos/devderby

Prizes are:

#1 Android Mobile Device
#2 Rickshaw Laptop Bag
#3 MDN t-shirt

-L

> _______________________________________________
> engagement-developers mailing list
> engagement...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/engagement-developers

--
Q: Why is this email five sentences or less?
A: http://five.sentenc.es