Kilimanjaro Product Draft Feedback/Questions

[JP Rosevear]

Reading through https://wiki.mozilla.org/Kilimanjaro/ProductDraft I have
a few questions/comments, tried to break them down by section:

* B2G Phone Early Adopters

1) "The store helps her set up her phone"

Is this a practical use case? Will carriers provide training to do
this?

2) "Sofia needs help but doesn't know who to contact."

How would users be directed to the Mozilla Help Center? Who is doing
tier 1 support? Mozilla or the carriers?

* All your devices recognize you and enable access to your ID-attached
services

1) ID attached services and clients

I'm surprised that the "table stakes" for this is only contacts and
apps. I understand that we have a working sync solution for
desktop/fennec for the P2 items, but what about bookmarks, passwords,
etc on B2G?

2) DOM bindings for Sign In

Surprised this is P3, it is unclear to me how we will do Persona on B2G
in this case other than for a browser app.

* You will be able to install and use your apps across phones and PCs
where WebRT is available

1) Native install for tablets

I think its feasible to make this happen inside of Native Fennec in the
time frame discussed since.

2) Flash is available to apps (on platforms where flash is available)

Given that Adobe is not supporting flash on Android really any more, is
this a requirement there? I assume B2G is not somewhere we are
requiring flash.

3) Profile sharing

In general what elements of the profile do we want to share to
"standalone" apps?

* The Mozilla web platform will include core features for developing
games, social, productivity, and media apps.

1) H.264/AAC & mp3

I believe our target here is only B2G and Android for now, not desktop,
we should be explicit on that. We should use MPAPI.

* Developers will have comprehensive resources to enable "idea to basic
app in 5 mins"

1) Debugger

Do we really need a debugger in the minimal subset for k90? I agree its
something we need though.

2) Support

Who does tier 2/3 support? Who does tier 1?

* Mozilla will deliver a compelling device/system un-boxing experience

1) Desktop marketplace app

Does this really need to be in the minimal subset for k9o? Seems like a
nice to have with uncertain value since we have a larger browser based
audience that we plan to give nice integration with. Google Chrome just
uses the browser on the desktop.

Thanks,

-JP
--
JP Rosevear <j...@mozilla.com>
Mozilla

[Mike Connor]

On 2012-04-30, at 8:33 PM, JP Rosevear wrote:

> * All your devices recognize you and enable access to your ID-attached
> services
>
> 1) ID attached services and clients
>
> I'm surprised that the "table stakes" for this is only contacts and
> apps. I understand that we have a working sync solution for
> desktop/fennec for the P2 items, but what about bookmarks, passwords,
> etc on B2G?

We do not have a working sync solution for an "ID-attached" version of Sync, at this time. We are actively working on this, with a dependency on "Sign into the browser" (SITB). SITB was first prototyped by the Firefox team last week, and other pieces are still pending. Given the timelines for B2G, this will not be ready for v1, so it is currently not the plan to support those data types for B2G.

Shipping the current Sync code/UX in B2G is not something that makes a lot of sense, as by the time those devices hit the market we intend to have converted to the ID-attached service model for desktop and Android. It seems like a much better plan to add Sync support in the next k9o-like vehicle once SITB has been fleshed out on other platforms.

-- Mike

[Ragavan Srinivasan]

Hi JP,

Thanks for the questions - answers inline.

JP Rosevear wrote:
> Reading through https://wiki.mozilla.org/Kilimanjaro/ProductDraft I have
> a few questions/comments, tried to break them down by section:
>
> * B2G Phone Early Adopters
>
> 1) "The store helps her set up her phone"
>
> Is this a practical use case? Will carriers provide training to do
> this?

I'll let clee confirm this, but for k9o, it will be us working with the
carrier(s) to train their store employees. I think the more important
part is the second half of that sentence though: "which includes setting
up a Persona account and importing contacts from her old phone"

> 2) "Sofia needs help but doesn't know who to contact."
>
> How would users be directed to the Mozilla Help Center? Who is doing
> tier 1 support? Mozilla or the carriers?

Good questions - I don't think we have clear answers yet for the B2G use
case which is part of why we listed this.

>
> * All your devices recognize you and enable access to your ID-attached
> services
>
> 1) ID attached services and clients
>
> I'm surprised that the "table stakes" for this is only contacts and
> apps. I understand that we have a working sync solution for
> desktop/fennec for the P2 items, but what about bookmarks, passwords,
> etc on B2G?

I see Mike already answered this from an engineering standpoint, but
from a Product perspective, being able to make phone calls (contacts)
and having your current apps available (apps) are far more important
than having your bookmarks/passwords etc inside the browser app on your
phone. For example, I don't think Mobile Safari supported (limited)
browser sync on the iPhone until version 5 of iOS.

>
> 2) DOM bindings for Sign In
>
> Surprised this is P3, it is unclear to me how we will do Persona on B2G
> in this case other than for a browser app.

Thunder/Ben should answer this.

>
> * You will be able to install and use your apps across phones and PCs
> where WebRT is available
>
> 1) Native install for tablets

Tablets are a P3 for k9o and I'm not sure if there is a question here?

>
> I think its feasible to make this happen inside of Native Fennec in the
> time frame discussed since.

Installing from Native Fennec (when invoked through the "Marketplace"
mode) you mean? Apps cannot run inside Native Fennec as a tab for k9o.
They will need to run outside of the browser (just like we do on desktop
today).

> 2) Flash is available to apps (on platforms where flash is available)
>
> Given that Adobe is not supporting flash on Android really any more, is
> this a requirement there? I assume B2G is not somewhere we are
> requiring flash.

What is our Android strategy for Flash? I hear we are still planning on
supporting it. Is that not the case?

clee - what is B2G's flash support story?

>
> 3) Profile sharing
>
> In general what elements of the profile do we want to share to
> "standalone" apps?

The same set as we are sharing on desktop. Myk should have the right set
here.

>
> * The Mozilla web platform will include core features for developing
> games, social, productivity, and media apps.
>

> 1) H.264/AAC& mp3

>
> I believe our target here is only B2G and Android for now, not desktop,
> we should be explicit on that. We should use MPAPI.

Nope. Desktop is also in scope as several of the apps we are listing
(and working to get) in the marketplace work on desktop and require
H.264/AAC & mp3.

>
> * Developers will have comprehensive resources to enable "idea to basic
> app in 5 mins"
>
> 1) Debugger
>
> Do we really need a debugger in the minimal subset for k90? I agree its
> something we need though.

I'll defer to Kevin Dangoor on this one.

>
> 2) Support
>
> Who does tier 2/3 support? Who does tier 1?

For apps, the app developer is responsible for tier 1 support. For
specific cases, we have support escalation paths that entails us doing
tier 2/3. Ibai Garcia has a detailed support doc he can share if you're
interested.

I'll let clee cover the B2G support plans.

>
> * Mozilla will deliver a compelling device/system un-boxing experience
>
> 1) Desktop marketplace app
>
> Does this really need to be in the minimal subset for k9o? Seems like a
> nice to have with uncertain value since we have a larger browser based
> audience that we plan to give nice integration with. Google Chrome just
> uses the browser on the desktop.

This is actually a requirement to support installs from other browsers
as well as to maintain consistency with our model on Android. Also, we
already have a fair bit of this prototyped and working on desktop, so
not as much of a worry of not making it in time for k9o.

Regards,
Ragavan

[clee]

> JP Rosevear wrote:
> > Reading through https://wiki.mozilla.org/Kilimanjaro/ProductDraft I have
> > a few questions/comments, tried to break them down by section:
> >
> > * B2G Phone Early Adopters
> >
> > 1) "The store helps her set up her phone"
> >
> > Is this a practical use case? Will carriers provide training to do
> > this?
>
> I'll let clee confirm this, but for k9o, it will be us working with the
> carrier(s) to train their store employees. I think the more important
> part is the second half of that sentence though: "which includes setting
> up a Persona account and importing contacts from her old phone"

We are still in the process of working out the details with carriers. The basic assumption (which we need to confirm) is to offer customers 'on-boarding' help like setting up the phone and/or importing contacts from their current device.

>
> > 2) "Sofia needs help but doesn't know who to contact."
> >
> > How would users be directed to the Mozilla Help Center? Who is doing
> > tier 1 support? Mozilla or the carriers?
>
> Good questions - I don't think we have clear answers yet for the B2G use
> case which is part of why we listed this.

Agree. We are working with Dave Tenser's group to provide Mozilla support. At the same time we are connecting our team with the carrier's support team to align our efforts. This is in progress.

> > 2) Flash is available to apps (on platforms where flash is available)
> >
> > Given that Adobe is not supporting flash on Android really any more, is
> > this a requirement there? I assume B2G is not somewhere we are
> > requiring flash.
>
> What is our Android strategy for Flash? I hear we are still planning on
> supporting it. Is that not the case?
>
> clee - what is B2G's flash support story?

As far as I know, we have no intention to support Flash on B2G. I will confirm with others on the team if there is something I'm unaware of.

> > 2) Support
> >
> > Who does tier 2/3 support? Who does tier 1?
>
> For apps, the app developer is responsible for tier 1 support. For
> specific cases, we have support escalation paths that entails us doing
> tier 2/3. Ibai Garcia has a detailed support doc he can share if you're
> interested.
>
> I'll let clee cover the B2G support plans.

Tier 1 is going to likely be the carrier. Tier 2/3 is probably a combo of Mozilla and the carrier. We are in the definition stages here.

[Kevin Dangoor]

On Mon, Apr 30, 2012 at 8:33 PM, JP Rosevear <j...@mozilla.com> wrote:

> * Developers will have comprehensive resources to enable "idea to basic
> app in 5 mins"
>
> 1) Debugger
>
> Do we really need a debugger in the minimal subset for k90? I agree its
> something we need though.
>
>

The thinking here is that people building apps likely have more JavaScript
code than your typical website and will benefit that much more from a good
debugger. We were also looking at what is possible to do within the k9o
timeframe being discussed and the script debugger is on track for 15.

Kevin

--
Kevin Dangoor

work: http://mozilla.com/
email: kdan...@mozilla.com <k...@blazingthings.com>
blog: http://www.BlueSkyOnMars.com

[JP Rosevear]

On Mon, 2012-04-30 at 22:29 -0400, Mike Connor wrote:

> On 2012-04-30, at 8:33 PM, JP Rosevear wrote:
>
> > * All your devices recognize you and enable access to your ID-attached
> > services
> >
> > 1) ID attached services and clients
> >
> > I'm surprised that the "table stakes" for this is only contacts and
> > apps. I understand that we have a working sync solution for
> > desktop/fennec for the P2 items, but what about bookmarks, passwords,
> > etc on B2G?
>

> We do not have a working sync solution for an "ID-attached" version of
> Sync, at this time. We are actively working on this, with a
> dependency on "Sign into the browser" (SITB). SITB was first
> prototyped by the Firefox team last week, and other pieces are still
> pending. Given the timelines for B2G, this will not be ready for v1,
> so it is currently not the plan to support those data types for B2G.
>
> Shipping the current Sync code/UX in B2G is not something that makes a
> lot of sense, as by the time those devices hit the market we intend to
> have converted to the ID-attached service model for desktop and
> Android. It seems like a much better plan to add Sync support in the
> next k9o-like vehicle once SITB has been fleshed out on other
> platforms.

To be clear, you are saying that contacts/apps will be supported by
browser id in B2G, but that "traditional sync" (passwords, history,
bookmarks, tabs, etc) will not be?

[JP Rosevear]

On Mon, 2012-04-30 at 21:46 -0700, Ragavan Srinivasan wrote:
> Hi JP,
>
> Thanks for the questions - answers inline.
>
> JP Rosevear wrote:
> > Reading through https://wiki.mozilla.org/Kilimanjaro/ProductDraft I have
> > a few questions/comments, tried to break them down by section:

> > * All your devices recognize you and enable access to your ID-attached
> > services
> >
> > 1) ID attached services and clients
> >
> > I'm surprised that the "table stakes" for this is only contacts and
> > apps. I understand that we have a working sync solution for
> > desktop/fennec for the P2 items, but what about bookmarks, passwords,
> > etc on B2G?
>
> I see Mike already answered this from an engineering standpoint, but
> from a Product perspective, being able to make phone calls (contacts)
> and having your current apps available (apps) are far more important
> than having your bookmarks/passwords etc inside the browser app on your
> phone. For example, I don't think Mobile Safari supported (limited)
> browser sync on the iPhone until version 5 of iOS.

Ok, however Android/Google Chrome for Android support this, correct?

> > * You will be able to install and use your apps across phones and PCs
> > where WebRT is available
> >
> > 1) Native install for tablets
>
> Tablets are a P3 for k9o and I'm not sure if there is a question here?
>
> >
> > I think its feasible to make this happen inside of Native Fennec in the
> > time frame discussed since.
>
> Installing from Native Fennec (when invoked through the "Marketplace"
> mode) you mean? Apps cannot run inside Native Fennec as a tab for k9o.
> They will need to run outside of the browser (just like we do on desktop
> today).

What I'm saying is, that there is a reasonable chance Native Fennec will
support tablets in the k9o time frame, so tablets may be "free-ish" in
terms of WebRT. I am curious as to why tablets are P3 though.

>
> > 2) Flash is available to apps (on platforms where flash is available)
> >
> > Given that Adobe is not supporting flash on Android really any more, is
> > this a requirement there? I assume B2G is not somewhere we are
> > requiring flash.
>
> What is our Android strategy for Flash? I hear we are still planning on
> supporting it. Is that not the case?

It is the case, but it is currently click-to-play, its not auto loaded,
by default. There will likely be a practical limit to how good flash
can be on mobile given Adobe is deprecating it.

> > 3) Profile sharing
> >
> > In general what elements of the profile do we want to share to
> > "standalone" apps?
>
> The same set as we are sharing on desktop. Myk should have the right set
> here.

I'm not sure what "the same set as we are sharing on the desktop" means.

> > * The Mozilla web platform will include core features for developing
> > games, social, productivity, and media apps.
> >
> > 1) H.264/AAC& mp3
> >
> > I believe our target here is only B2G and Android for now, not desktop,
> > we should be explicit on that. We should use MPAPI.
>
> Nope. Desktop is also in scope as several of the apps we are listing
> (and working to get) in the marketplace work on desktop and require
> H.264/AAC & mp3.

I disagree desktop is currently in scope. Mobile and B2G via reuse of
hardware/OS provided codecs is the current engineering scope being
targeted.

> > * Developers will have comprehensive resources to enable "idea to basic
> > app in 5 mins"
> >

> > 2) Support
> >
> > Who does tier 2/3 support? Who does tier 1?
>
> For apps, the app developer is responsible for tier 1 support. For
> specific cases, we have support escalation paths that entails us doing
> tier 2/3. Ibai Garcia has a detailed support doc he can share if you're
> interested.

I think we should get that posted publicly, particularly if it implies
supporting coming from the project as a whole.

> I'll let clee cover the B2G support plans.
>
> >
> > * Mozilla will deliver a compelling device/system un-boxing experience
> >
> > 1) Desktop marketplace app
> >
> > Does this really need to be in the minimal subset for k9o? Seems like a
> > nice to have with uncertain value since we have a larger browser based
> > audience that we plan to give nice integration with. Google Chrome just
> > uses the browser on the desktop.
>
> This is actually a requirement to support installs from other browsers
> as well as to maintain consistency with our model on Android. Also, we
> already have a fair bit of this prototyped and working on desktop, so
> not as much of a worry of not making it in time for k9o.

My understanding of k9o was a minimal subset to get
convergence/unification of our own platforms/products, so I have a hard
time seeing this in the minimal subset.

[Ben Adida]

On 4/30/12 5:33 PM, JP Rosevear wrote:
> I'm surprised that the "table stakes" for this is only contacts and
> apps. I understand that we have a working sync solution for
> desktop/fennec for the P2 items, but what about bookmarks, passwords,
> etc on B2G?

Let's see if I can channel Dan for a second.

<pm impersonation>

Most initial users of B2G will use the phone as their primary computing
device and will not have another FF instance to sync with. So what
counts is a backup service for contacts (which are super annoying if
lost) and apps (which the user paid for.) The rest is, *initially*, less
important, given the expected user profile.

I'm only making a relative prioritization statement, not an absolute
one. I know there are ongoing discussions right now regarding the
absolute prioritization of contacts & apps, and I don't mean to imply
anything about that discussion.

</pm impersonation>

> 2) DOM bindings for Sign In
>
> Surprised this is P3, it is unclear to me how we will do Persona on B2G
> in this case other than for a browser app.

It's technically very possible for Persona to work using the existing
shim as long as B2G supports window.open (which it probably should
support for other reasons, e.g. Facebook Connect, OAuth dialogs, etc.)
To get an idea of what that looks like, see Persona's iOS support: it
works and looks quite nice.

In particular, signin-to-browser/device does *not* require exposing the
Persona DOM API to content.

So this is not a feasibility issue.

I know and understand that some people would prefer having the DOM API
working natively, and we are working on this actively. That said, in
terms of prioritization, it isn't a technical blocker on any required
feature.

-Ben

[Ragavan Srinivasan]

JP Rosevear wrote:

>
> Ok, however Android/Google Chrome for Android support this, correct?

Yes, that's correct. The main focus of k9o is around apps, identity and
b2g. For those pieces, browser sync is not a key requirement.

>
> What I'm saying is, that there is a reasonable chance Native Fennec will
> support tablets in the k9o time frame, so tablets may be "free-ish" in
> terms of WebRT. I am curious as to why tablets are P3 though.

Got it - but I'd explicitly not put *any* effort at all on maintaining a
tablet build at all, for k9o. While free sounds tempting, the "-ish"
piece is concerning :), especially since it means we will need dev, qa,
ux, reviews, build/rel/ etc. to spend time on this.

As for why tablets are P3, here are a few reasons:
* tablets are not a focus for b2g
* there really is not a big market for Android tablets
* If we are building something for a tablet, it should be for the iPad
(be where our users are).

> It is the case, but it is currently click-to-play, its not auto loaded,
> by default. There will likely be a practical limit to how good flash
> can be on mobile given Adobe is deprecating it.

Fair enough. I'm OK not supporting flash on Android for apps.

> I'm not sure what "the same set as we are sharing on the desktop" means.

Sorry, I misspoke. According to Myk, we mostly don't share anything. The
only exception is the webapp registry which is shared with the
installing Firefox profile. If the webapp accesses information about
itself or other webapps via the mozApps API, then it gets that info from
the shared webapp registry.

> I disagree desktop is currently in scope. Mobile and B2G via reuse of
> hardware/OS provided codecs is the current engineering scope being
> targeted.

Desktop is in scope for Product (for apps). We have several partner apps
that we've signed up that require H.264/AAC and mp3.

So, this sounds like a gap that we need to address. I know Maire has
been working on this and will have more current information.

> I think we should get that posted publicly, particularly if it implies
> supporting coming from the project as a whole.

I'll ask Ibai to share it more widely - just to be clear, this is being
driven by SUMO and not a separate operation by any means.

> My understanding of k9o was a minimal subset to get
> convergence/unification of our own platforms/products, so I have a hard
> time seeing this in the minimal subset.

I see your point, I think it is easier to talk through once we have a
few flows fleshed out to demonstrate why we think this is a requirement.
I'll ask our UX team to share this a bit more broadly once they have it
(they're swamped right now).

Regards,
Ragavan

[Asa Dotzler]

On 5/1/2012 6:26 AM, JP Rosevear wrote:
> On Mon, 2012-04-30 at 21:46 -0700, Ragavan Srinivasan wrote:

>>> 1) H.264/AAC& mp3
>>>
>>> I believe our target here is only B2G and Android for now, not desktop,
>>> we should be explicit on that. We should use MPAPI.
>>
>> Nope. Desktop is also in scope as several of the apps we are listing
>> (and working to get) in the marketplace work on desktop and require
>> H.264/AAC & mp3.
>
> I disagree desktop is currently in scope. Mobile and B2G via reuse of
> hardware/OS provided codecs is the current engineering scope being
> targeted.

mp3 for desktop is in scope for k9o. 264/aac is post-k9o because we
can't fulfill it with platform decoders (the XP problem.) also, mpapi is
being re-branded as "platform decoders" :)

- A

[Taras Glek]

On 4/30/2012 5:33 PM, JP Rosevear wrote:
> Reading through https://wiki.mozilla.org/Kilimanjaro/ProductDraft I have
> a few questions/comments, tried to break them down by section:
>

I have a one more:
* Performance and responsiveness will be sufficient to support smooth
and fluid game and media apps.

This is a non-goal because there is no clear way to tell whether it's
completed. We will still have significant content jank in September. We
will have more jank if we execute on other k9o goals at the expense of
general snappy goals.

I see this 'goal' as a polite gesture to indicate that our performance
programs are still important. However it does not help individual
teams/developers when deciding what to work on.

I think the only way to clarify how k9o fits with the regard to other
projects is to explicitly specify priorities. Can do it on meta project
granularity, eg:
MemShrink > Snappy > K9O

or project eg:
main thread sql > imagesuck > Apps in New Tab page.

Taras

[Dave Mandelin]

On Tuesday, May 1, 2012 2:10:13 PM UTC-7, Taras Glek wrote:
> On 4/30/2012 5:33 PM, JP Rosevear wrote:
> > Reading through https://wiki.mozilla.org/Kilimanjaro/ProductDraft I have
> > a few questions/comments, tried to break them down by section:
>
> I have a one more:
> * Performance and responsiveness will be sufficient to support smooth
> and fluid game and media apps.
>
> This is a non-goal because there is no clear way to tell whether it's
> completed.

I've been thinking and asking about this one because it's the main goal that affects JS. Based on responses from Asa, Sheila, and Alex this morning, I just scoped our efforts in JS, narrowly, and +'d 3 bugs. They form a coherent response that should greatly improve JS pauses, so that (plus bugs required to support Script Debugger) is our Kilimanjaro contribution.

> We will still have significant content jank in September. We
> will have more jank if we execute on other k9o goals at the expense of
> general snappy goals.
>
> I see this 'goal' as a polite gesture to indicate that our performance
> programs are still important. However it does not help individual
> teams/developers when deciding what to work on.

Are people having a hard time deciding?

> I think the only way to clarify how k9o fits with the regard to other
> projects is to explicitly specify priorities. Can do it on meta project
> granularity, eg:
> MemShrink > Snappy > K9O
>
> or project eg:
> main thread sql > imagesuck > Apps in New Tab page.

Sounds tough to make it stick.

AIUI, Kilimanjaro is an org-wide effort, takes precedence over other things, and wants a tight list of bugs that can be finished rapidly. That is why for JS I picked a few really important bugs and put a high priority on them. With that understood, I don't see conflict or competition between K9O goals and internal JS goals.

Dave

[Lawrence Mandel]

I spoke with mccr8 and benm about fixing CC and GC pauses specifically. We nomed a few bugs, which were triaged yesterday.

I tend to agree with Taras' assertion about this being a non goal but would reframe the assertion as this is not a measurable goal. We can make general improvements but there is no way to know that we have met this requirement. We can measure success and give people a clear target if we rephrase the requirement as something like:

Play a 10 minute video (default max length allowed on YouTube) without noticeable pauses.
Play game X for 10 minutes without noticeable pauses or skips (jank).

Two notes:
1. We may need to specify hardware as older phones/machines will likely have problems.
2. I don't know what to recommend for game X but I'm sure Martin Best can make some suggestions.

Lawrence

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

[Robert Kaiser]

Ragavan Srinivasan schrieb:

> * there really is not a big market for Android tablets

That tablet market surely isn't really large, that's true, but among
tablets, Android has ~40% (and growing) market share, so it's not as
negligible as you may make it sound. The iPad still has ~60% (trending
down), but it's by far not like the tablet market would be all Apple and
marginally Android.

Robert Kaiser

[Asa Dotzler]

On 5/2/2012 7:26 AM, Lawrence Mandel wrote:
> I spoke with mccr8 and benm about fixing CC and GC pauses specifically. We nomed a few bugs, which were triaged yesterday.
>
> I tend to agree with Taras' assertion about this being a non goal but would reframe the assertion as this is not a measurable goal. We can make general improvements but there is no way to know that we have met this requirement. We can measure success and give people a clear target if we rephrase the requirement as something like:
>
> Play a 10 minute video (default max length allowed on YouTube) without noticeable pauses.
> Play game X for 10 minutes without noticeable pauses or skips (jank).
>
> Two notes:
> 1. We may need to specify hardware as older phones/machines will likely have problems.
> 2. I don't know what to recommend for game X but I'm sure Martin Best can make some suggestions.
>
> Lawrence

We can also say something like "we're going to nail three top known
issues."

- A

[Gijs Kruitbosch]

Out of interest, where do those numbers come from? They do not reflect what I
see on my daily commute (but that sample may be poorly selected!).

Gijs

[Mark Finkle]

On 05/01/2012 02:50 AM, clee wrote:

>>> 2) Flash is available to apps (on platforms where flash is available)
>>>
>>> Given that Adobe is not supporting flash on Android really any more, is
>>> this a requirement there? I assume B2G is not somewhere we are
>>> requiring flash.
>>
>> What is our Android strategy for Flash? I hear we are still planning on
>> supporting it. Is that not the case?
>>
>> clee - what is B2G's flash support story?
>
> As far as I know, we have no intention to support Flash on B2G. I will confirm with others on the team if there is something I'm unaware of.

I thought we had the "shumway" project to support Flash content using
HTML5 technologies. That could be used to support Flash content on B2G.
Just because Adobe is not supporting Flash Player on mobile doesn't mean
Flash content will disappear from the web.

[Chris Peterson]

When we prioritize our dev/test time for Android tablets, Amazon's
Kindle Fire tablet should be a high priority.

The Kindle Fire is 54% of Android tablet marketshare. The runner up is
Samsung's Galaxy Tab family, which dropped from 23% to just 15%.

http://arstechnica.com/gadgets/news/2012/04/amazons-kindle-fire-now-the-1-android-tablet.ars


chris peterson

[Jet Villegas]

Yes, Shumway is our best path forward for Mobile Flash content.

-- Jet

[Dao]

On 02.05.2012 19:37, Mark Finkle wrote:
> On 05/01/2012 02:50 AM, clee wrote:
>
>>>> 2) Flash is available to apps (on platforms where flash is available)
>>>>
>>>> Given that Adobe is not supporting flash on Android really any more, is
>>>> this a requirement there? I assume B2G is not somewhere we are
>>>> requiring flash.
>>>
>>> What is our Android strategy for Flash? I hear we are still planning on
>>> supporting it. Is that not the case?
>>>
>>> clee - what is B2G's flash support story?
>>
>> As far as I know, we have no intention to support Flash on B2G. I will
>> confirm with others on the team if there is something I'm unaware of.
>
> I thought we had the "shumway" project to support Flash content using
> HTML5 technologies.

Isn't this a research project that isn't going to be ready in the
foreseeable future?

[JP Rosevear]

On Tue, 2012-05-01 at 09:27 -0700, Ben Adida wrote:
> On 4/30/12 5:33 PM, JP Rosevear wrote:
> > I'm surprised that the "table stakes" for this is only contacts and
> > apps. I understand that we have a working sync solution for
> > desktop/fennec for the P2 items, but what about bookmarks, passwords,
> > etc on B2G?
>
> Let's see if I can channel Dan for a second.
>
> <pm impersonation>
>
> Most initial users of B2G will use the phone as their primary computing
> device and will not have another FF instance to sync with. So what
> counts is a backup service for contacts (which are super annoying if
> lost) and apps (which the user paid for.) The rest is, *initially*, less
> important, given the expected user profile.
>
> I'm only making a relative prioritization statement, not an absolute
> one. I know there are ongoing discussions right now regarding the
> absolute prioritization of contacts & apps, and I don't mean to imply
> anything about that discussion.
>
> </pm impersonation>

Ok, that is a reasonable position to take for prioritization.

> > 2) DOM bindings for Sign In
> >
> > Surprised this is P3, it is unclear to me how we will do Persona on B2G
> > in this case other than for a browser app.
>
> It's technically very possible for Persona to work using the existing
> shim as long as B2G supports window.open (which it probably should
> support for other reasons, e.g. Facebook Connect, OAuth dialogs, etc.)
> To get an idea of what that looks like, see Persona's iOS support: it
> works and looks quite nice.

The B2G browser may support window.open, but what about the core OS
itself? (Think Accounts on Android) It seems weird to hit a server
there.

[JP Rosevear]

On Tue, 2012-05-01 at 11:55 -0700, Ragavan Srinivasan wrote:
> JP Rosevear wrote:
>
> >
> > Ok, however Android/Google Chrome for Android support this, correct?
>
> Yes, that's correct. The main focus of k9o is around apps, identity and
> b2g. For those pieces, browser sync is not a key requirement.

So, the original put for k9o included sync. Its ok if we evolved that,
but its a bit odd to consider it "table stakes" for Fennec (as it is for
the 1.0 relesase)

> >
> > What I'm saying is, that there is a reasonable chance Native Fennec will
> > support tablets in the k9o time frame, so tablets may be "free-ish" in
> > terms of WebRT. I am curious as to why tablets are P3 though.
>
> Got it - but I'd explicitly not put *any* effort at all on maintaining a
> tablet build at all, for k9o. While free sounds tempting, the "-ish"
> piece is concerning :), especially since it means we will need dev, qa,
> ux, reviews, build/rel/ etc. to spend time on this.
>
> As for why tablets are P3, here are a few reasons:

Note - its quite possible we get tablet's for free on the Fennec side.

> * tablets are not a focus for b2g
> * there really is not a big market for Android tablets

Irina Sandu can provide data on this.

> * If we are building something for a tablet, it should be for the iPad
> (be where our users are).

Can you define "our users" in this case? Our potential users?

> > It is the case, but it is currently click-to-play, its not auto loaded,
> > by default. There will likely be a practical limit to how good flash
> > can be on mobile given Adobe is deprecating it.
>
> Fair enough. I'm OK not supporting flash on Android for apps.

Ok. I assume we'd advocate canvas and webgl instead?

> > I'm not sure what "the same set as we are sharing on the desktop" means.
>
> Sorry, I misspoke. According to Myk, we mostly don't share anything. The
> only exception is the webapp registry which is shared with the
> installing Firefox profile. If the webapp accesses information about
> itself or other webapps via the mozApps API, then it gets that info from
> the shared webapp registry.

Ok.

> > I disagree desktop is currently in scope. Mobile and B2G via reuse of
> > hardware/OS provided codecs is the current engineering scope being
> > targeted.
>
> Desktop is in scope for Product (for apps).

This seems to contradict Asa's reply in this thread.

> We have several partner apps
> that we've signed up that require H.264/AAC and mp3.
>
> So, this sounds like a gap that we need to address. I know Maire has
> been working on this and will have more current information.

Indeed.

> > I think we should get that posted publicly, particularly if it implies
> > supporting coming from the project as a whole.
>
> I'll ask Ibai to share it more widely - just to be clear, this is being
> driven by SUMO and not a separate operation by any means.

Ok.

> > My understanding of k9o was a minimal subset to get
> > convergence/unification of our own platforms/products, so I have a hard
> > time seeing this in the minimal subset.
>
> I see your point, I think it is easier to talk through once we have a
> few flows fleshed out to demonstrate why we think this is a requirement.
> I'll ask our UX team to share this a bit more broadly once they have it
> (they're swamped right now).

Ok.

[Ben Adida]

On 5/2/12 11:29 AM, JP Rosevear wrote:
> The B2G browser may support window.open, but what about the core OS
> itself?

So does this mean that no B2G app can use Facebook Connect, or perform
an OAuth transaction? It seems to me that apps, not just the browser,
will need a solution for window.open.

> (Think Accounts on Android) It seems weird to hit a server
> there.

For identity provisioning, you're almost always going to hit a server at
least to vouch for the user.

So yes, I agree that it will be better to have the native
implementation, and I am specifically working to get some dedicated FX
hacking time to make that happen faster.

That said, when prioritizing for k9o, given that we can make it *work*
right now, I don't think we can call the native DOM API support a blocker.

-Ben

[JP Rosevear]

On Wed, 2012-05-02 at 07:26 -0700, Lawrence Mandel wrote:
> I spoke with mccr8 and benm about fixing CC and GC pauses specifically. We nomed a few bugs, which were triaged yesterday.
>
> I tend to agree with Taras' assertion about this being a non goal but would reframe the assertion as this is not a measurable goal. We can make general improvements but there is no way to know that we have met this requirement. We can measure success and give people a clear target if we rephrase the requirement as something like:
>
> Play a 10 minute video (default max length allowed on YouTube) without noticeable pauses.
> Play game X for 10 minutes without noticeable pauses or skips (jank).
>
> Two notes:
> 1. We may need to specify hardware as older phones/machines will likely have problems.
> 2. I don't know what to recommend for game X but I'm sure Martin Best can make some suggestions.

The key question question is would these block. ie would k9o not
ship/be done without these. I suspect the answer is we would ship with
out big things like the js improvements.

Thanks,

[Justin Lebar]

On Wed, May 2, 2012 at 4:55 PM, Ben Adida <bena...@mozilla.com> wrote:
> On 5/2/12 11:29 AM, JP Rosevear wrote:
>>
>> The B2G browser may support window.open, but what about the core OS
>> itself?
>
> So does this mean that no B2G app can use Facebook Connect, or perform an
> OAuth transaction? It seems to me that apps, not just the browser, will need
> a solution for window.open.

Let's be careful about how we scope this.

We agree that B2G apps need a solution for FB Connect / OAuth / similar things.

But that does not necessarily mean that B2G apps need a general
window.open function.

Looking through the FB Connect docs [1], it looks like the app gets to
create the window within which the FB Connect login operates. That
gives us lots of flexibility.

What we've been considering for apps is blocking all window.open calls
except open(url, window_name, "auth"). We'd handle these "auth"
windows with a special UI (make them modal, etc).

An alternative would be handling the login within a (special) iframe,
where we explicitly show the domain of the framed content etc.

Anyway, there's work to be done here, and I don't think anyone has dug
into this yet. But scope is important. Let's please not say that
supporting general popup windows is a requirement for B2G apps.

-Justin

[1] http://developers.facebook.com/docs/guides/web/

[Ben Adida]

On 5/2/12 2:47 PM, Justin Lebar wrote:
> What we've been considering for apps is blocking all window.open calls
> except open(url, window_name, "auth"). We'd handle these "auth"
> windows with a special UI (make them modal, etc).

That's interesting, and super cool as it uplevels the window.open into a
semantically recognizable "time to authenticate" moment. I'd be happy to
help think about that as it relates to Persona and to support this
emerging convention.

Do you have the sense that we can get other signin mechanisms to do
this? Facebook typically puts the window.open() somewhere inside their
library, not under the web site/app's control.

-Ben

[Clint Talbert]

JP,
I'm confused. Dmandelin worked through a bunch of JS bugs found the ones
he thought most pressing to give the most bang for the buck
performance-wise. If you would ship without something like that, what
*are* you shipping, quality wise?

There are certainly other metrics than performance, but that seems like
a rather unusual statement to me.

Clint

[Ragavan Srinivasan]

JP Rosevear wrote:
> Can you define "our users" in this case? Our potential users?

Yes, as well as current Firefox users who also own an iPad. At any rate,
tablets (including iPads) are P3 for k9o.

> Ok. I assume we'd advocate canvas and webgl instead?

Yes, sounds reasonable. In the k9o timeframe, I don't think shumway is
an option.

>
> This seems to contradict Asa's reply in this thread.

I'll check with him and Maire. We have apps on the desktop that will
need 264/aac, so perhaps there is a fallback for k9o.

Ragavan

[Irina Sandu]

On May 1, 2012, at 6:27 PM, Ben Adida wrote:

> On 4/30/12 5:33 PM, JP Rosevear wrote:
>> I'm surprised that the "table stakes" for this is only contacts and
>> apps. I understand that we have a working sync solution for
>> desktop/fennec for the P2 items, but what about bookmarks, passwords,
>> etc on B2G?
>
> Let's see if I can channel Dan for a second.
>
> <pm impersonation>
>
> Most initial users of B2G will use the phone as their primary computing device and will not have another FF instance to sync with.

The fact that those users don't have a personal computer and a phone is their primary device is exactly the reason why they are visiting cybercafes. Out of the people accessing the Internet in Brazil, over half of them are doing it from these sort of places, or schools and universities [1]. And for the ones who do have a computer at home, it is likely shared with the rest of the family. Correlating this with the user profile that we have been investigating for B2G - young and socially active - it makes sense that these are people in the group that is actively engaged with the Internet where they can, which are mostly environments with shared computers.

> So what counts is a backup service for contacts (which are super annoying if lost) and apps (which the user paid for.) The rest is, *initially*, less important, given the expected user profile.

I would say that the opposite is true: because people have intermittent access to the Internet on the desktop, the ability to sync their experiences across these 2 devices can be very important and the use case of being able to log in with your ID into the browser on a shared computer and when you log off have that information on your mobile devices occurs more often and is more important that when people lose their phone or reset it, etc.


Relating to the app purchase matter, do we have any stats with regards to the propensity of Brazilian users to download paid apps? I think we shouldn't prioritize app sync by that factor, which I assume to be lower, because for free apps it is also important to keep whatever information is stored locally on the device, so I would factor in the overall propensity to install apps, regardless whether they are paid for or not. My expectation is that this number is a lot higher than that of paid apps, but it is just an expectation.

Irina

[David Bruant]

Le 03/05/2012 13:58, Irina Sandu a écrit :
> On May 1, 2012, at 6:27 PM, Ben Adida wrote:
>

>> On 4/30/12 5:33 PM, JP Rosevear wrote:
>>> I'm surprised that the "table stakes" for this is only contacts and
>>> apps. I understand that we have a working sync solution for
>>> desktop/fennec for the P2 items, but what about bookmarks, passwords,
>>> etc on B2G?
>> Let's see if I can channel Dan for a second.
>>
>> <pm impersonation>
>>
>> Most initial users of B2G will use the phone as their primary computing device and will not have another FF instance to sync with.

> The fact that those users don't have a personal computer and a phone is their primary device is exactly the reason why they are visiting cybercafes. Out of the people accessing the Internet in Brazil, over half of them are doing it from these sort of places, or schools and universities [1].

Where does the "[1]" references to? It sounds like an interesting resource.

Thanks,

David

[Irina Sandu]

On May 2, 2012, at 10:11 PM, JP Rosevear wrote:
>>>
>>> What I'm saying is, that there is a reasonable chance Native Fennec will
>>> support tablets in the k9o time frame, so tablets may be "free-ish" in
>>> terms of WebRT. I am curious as to why tablets are P3 though.
>>
>> Got it - but I'd explicitly not put *any* effort at all on maintaining a
>> tablet build at all, for k9o. While free sounds tempting, the "-ish"
>> piece is concerning :), especially since it means we will need dev, qa,
>> ux, reviews, build/rel/ etc. to spend time on this.
>>
>> As for why tablets are P3, here are a few reasons:
>

> Note - its quite possible we get tablet's for free on the Fennec side.
>

>> * tablets are not a focus for b2g
>> * there really is not a big market for Android tablets
>

> Irina Sandu can provide data on this.

It is indeed that if we look only at numbers of install base for tablets that is not a high amount when compared to smartphones or desktops (the amount of tablets that will be in usage in 2015 is forecasted to be about the same as the amount of smartphones in use last year).

What is important to note here is that these numbers do not correlate with market importance and influence equally for these 3 different segments: tablets, smartphones and desktops, which means that if install base is an important criteria for prioritization in one case, say smartphones, it is not necessarily equally important for the other.

For tablets, they have an important influence on the mobile Web because they generate a lot of page views, more than a smartphone. A browsing session on a tablet is a few times longer than on a smartphone and as a matter of fact, it looks like screen size inside the tablet segment is directly proportional with the amount of time spent in a session. [1] They are also important because they are generally more powerful and they can more easily support advanced Web applications, which makes them an important segment when we talk about pushing HTML5 adoption.


So my proposal is that for tablet prioritization we look at what are the most relevant factors for what we want to achieve with Kilimanjaro - they might be different than what I mentioned above - and see where that puts them relative with the other platforms.


Irina


[1] - http://www.prnewswire.com/news-releases/tablet-competition-heats-up-kindle-fire-captures-more-than-half-of-android-tablet-market-149097995.html

[Irina Sandu]

Sorry about that. Here is the link:

http://thebrazilbusiness.com/article/internet-use-in-brazil

Irina

On May 3, 2012, at 2:13 PM, David Bruant wrote:

> Le 03/05/2012 13:58, Irina Sandu a écrit :
>> On May 1, 2012, at 6:27 PM, Ben Adida wrote:
>>

>>> On 4/30/12 5:33 PM, JP Rosevear wrote:
>>>> I'm surprised that the "table stakes" for this is only contacts and
>>>> apps. I understand that we have a working sync solution for
>>>> desktop/fennec for the P2 items, but what about bookmarks, passwords,
>>>> etc on B2G?
>>> Let's see if I can channel Dan for a second.
>>>
>>> <pm impersonation>
>>>
>>> Most initial users of B2G will use the phone as their primary computing device and will not have another FF instance to sync with.

[Irina Sandu]

Some context to this number is that it is US-only and also that the Barnes & Noble Android-based tablets were considered eReaders for the analysis, so were not included in the calculation. That is not to say that the Kindle Fire has not had an impact on the *US* tablet market, but I would not put that number high on the criteria list for how we prioritize dev time.


Irina




>
>
> chris peterson

[Ben Adida]

On 5/3/12 4:58 AM, Irina Sandu wrote:
>
> I would say that the opposite is true: because people have
> intermittent access to the Internet on the desktop, the ability to
> sync their experiences across these 2 devices can be very important
> and the use case of being able to log in with your ID into the
> browser on a shared computer and when you log off have that
> information on your mobile devices occurs more often and is more
> important that when people lose their phone or reset it, etc.

Very interesting! Have you looped this information back to the Product
team? I don't think that's fully factored into the product plan,
although signin-to-the-browser would certainly go a long way to
achieving this.

-Ben

[Benjamin Smedberg]

What we have right now. The question is not whether these aren't good
things to do (they obviously are). The question is whether they are
*necessary* for this particular project of combining the identity and
webapps and sync and B2G systems. If we would actually block shipping
something because of GC pauses, then they are blockers. Otherwise, they
are just important bugs.

--BDS

[Martin Best]

> I've been thinking and asking about this one because it's the main
> goal that affects JS. Based on responses from Asa, Sheila, and Alex
> this morning, I just scoped our efforts in JS, narrowly, and +'d 3
> bugs. They form a coherent response that should greatly improve JS
> pauses, so that (plus bugs required to support Script Debugger) is
> our Kilimanjaro contribution.

I wanted to echo David here since games represent such a massive segment of the apps story. We really need to get the pauses under control to allow developers to produce product people will pay for. Especially in light of Chromes success in this area. To put a number on this, we should target getting the "hitching" time down to 16ms per second to make things work well. This represents about 1 frame lost per second. This should be a clear target for desktop but maybe harder to achieve on mobile. The more devices that will support this level of consistent frame rate the better off we will be.

Martin

[Asa Dotzler]

The Product leads are not happy with the pauses that Apps are
experiencing as a result of JS pauses. We should do what we can to fix
that in the time we have available. Several bugs/features have been
identified that we believe are important to k9o. We're calling these
blockers.

If we get estimates back that say "we thought it was 5 weeks of work but
it turns out to be a year" or we get close to the release and fixes are
nowhere in sight, then we'll probably unblock on it because that's not a
reasonable schedule and we'd rather get the rest of the good out there
sooner than wait a year for one piece.

We've never had a release where we committed to and stuck with every
bug/feature that was at one time marked a blocker and we don't have to
start that now. We mark things blockers because we think without them we
have a significantly less good release. Then we have to balance getting
everything in to the release against slipping the and make some
decisions. Sometimes we drop blockers and sometimes we slip the release.

Today these bugs are blockers. We think they will stay blockers and that
we will get fixes in time for announcing k9o.

Also, not sure if it was an unintentional omission, but k9o also
includes Desktop and Mobile. It's not just B2G, Apps, and Identity. (And
it doesn't really include Sync, IMO.)

- A

[mar...@mysix.com]

So from a games perspective, this is a blocker. In fact it is the single most important blocker between us and product being sales worthy. How games fit in to the larger agenda is a question that is worth considering and maybe product can comment on this.

Martin

[mar...@mysix.com]

I think the only bit I would see as blocking is the pausing or "hitching" problem. I know it may not seem like it but I have seen game projects fail when they couldn't eliminate inconstant frame rates on otherwise good games. The users just have a low tolerance for this particular issue. Otherwise many of the requirements for games are already landed or very close to it, so this is really the main hot button topic left for my perspective.

If the first products out the door on the app store fail to achieve financial success, it's going to be much harder to get that second wave of developers to jump in. I would have reservations about releasing without this issue improved.

Again, always take my feedback from the stand point that it really depends on how much games matter to the over all strategy. As they seem to be a dominate force on most App stores, I'm assuming they are pretty darn important.

Martin

[mar...@mysix.com]

I agree with everything Asa mentions here. Part of the reason I propose this is to highlight the importance. Another is that, via conversations with David Mandelin it seems to be within reach via IGC and fixes to recompilation. There is no way to know for sure if the current work will be the final piece needed to reduce this issue enough to make it considered resolved. My goal is to have the needed people able to focus this issue rather than work on P1s that are considered 100% blockers. So I guess the point is that we need to do everything we can to solve it, but if we can't and it will be a year to fix, we would ship with it as is.

I agree with everything here. Part of the reason I propose this is to highlight the importance. Another is that, via conversations with David Mandelin it seems to be within reach via IGC and fixes to recompilation. There is no way to know for sure if the current work will be the final piece needed to reduce this issue enough to make it considered resolved. My goal is to have those resources able to focus this issue rather than work on P1s that are considered 100% blockers. So I guess the point is that we need to do everything we can to solve it, but if we can't and it will be a year to fix, we would ship with it as is.

[Robert Kaiser]

Gijs Kruitbosch schrieb:

> On 02/05/2012 17:18 PM, Robert Kaiser wrote:
>> Ragavan Srinivasan schrieb:
>>> * there really is not a big market for Android tablets
>>
>> That tablet market surely isn't really large, that's true, but among
>> tablets,
>> Android has ~40% (and growing) market share, so it's not as negligible
>> as you
>> may make it sound. The iPad still has ~60% (trending down), but it's
>> by far not
>> like the tablet market would be all Apple and marginally Android.
>>

> Out of interest, where do those numbers come from? They do not reflect
> what I see on my daily commute (but that sample may be poorly selected!).

http://www.technobuffalo.com/companies/apple/ipad/android-tablets-may-be-more-popular-than-ipad-in-2015-idc-says/
is one article with that information that has been going around recently.

Robert Kaiser