Uniform experience using common components

[Wilfred Mathanaraj]

Hi all

In the past we had a proposal to use web-components to bring uniformity to the UX on FxOS - we did a partial implementation of this and it has left our UX with an “unfinished” look and feel.

Moving forward we want to have a very uniform UX across all our core apps. We also want to make this uniform experience available to contributors.

Having common components to achieve this will also help with the following:

1. UX to easily manage UX changes

2. Engineering to reduce code size by using these common components

3. QA to reduce their testing 

One of the methods we identified is web-components and there have been some concerns raised with :

1. time taken to implement each component

2. possible performance impacts web-components calls may have.

We are currently trying to identify other possibilities to achieve such a uniform implementation - if any of you have any proposals please feel free to reach out to Rob, Hema, or myself.

BR

Wilfred

---
FxOS Product Management
Mozilla Corp., UK

[David Scravaglieri]

Agree with this plan.

Regardless of the technology being used, we need to understand UX / UI needs and verify if it is achievable and what could be a realistic timeframe.

Thanks,

--

David Scravaglieri

Director of Engineering
Mozilla  - Firefox OS

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

[Etienne Segonzac]

On Wed, Oct 28, 2015 at 9:33 AM, Wilfred Mathanaraj <wil...@mozilla.com> wrote:

In the past we had a proposal to use web-components to bring uniformity to the UX on FxOS - we did a partial implementation of this and it has left our UX with an “unfinished” look and feel.

Moving forward we want to have a very uniform UX across all our core apps. We also want to make this uniform experience available to contributors.

The "uniformity" part is very clear. We want to share more than just style. Components are a great way to achieve this.

Glad to see this is our top goal.

Having common components to achieve this will also help with the following:

1. UX to easily manage UX changes

Somewhat yes... But I hope we'll be "extra concrete" when discussing this part, lots of misunderstandings around this.

WebComponents are a great way to "package". They don't solve the "deployment" use cases by themselves.

If the goal is "the UX makes only one change and it propagates across Gaia (and contributors app?)" it's a build system discussion more than a frontend discussion :)

 

2. Engineering to reduce code size by using these common components

To reduce app-specific code size yes.

 

3. QA to reduce their testing 

How? Not sure how this is related.

[Andrew Overholt]

One of the methods we identified is web-components and there have been some concerns raised with :

1. time taken to implement each component

2. possible performance impacts web-components calls may have. 

To your list of concerns I would add "Custom Elements are not yet standardized or specified" nor are they implemented in Gecko (Shadow DOM is almost there but Custom Elements is up in the air at the spec. level).

[Wilfred Mathanaraj]

Having some common components it makes life easier for QA to review how drop downs the usability results are marked as gating or not. but generally email is here to keep on adding questions and concerns and ideally find a solution that works for everyone!

Wilfred

---
FxOS Product Management
Mozilla Corp., UK

[Peter Dolanjski]

This is a different use case, but could be compelling to support our customization/hackability story:

The promise of web components also includes enabling third parties/devs to change the look and feel of the whole OS and offer those changes to others, as well.  Traditionally on Android that hasn't been so easy and customizations are often limited to the homescreen only.

Ideally the solution enables this use case.

Peter

[Justin D'Arcangelo]

On Oct 28, 2015, at 4:33 AM, Wilfred Mathanaraj <wil...@mozilla.com> wrote:

Hi all

In the past we had a proposal to use web-components to bring uniformity to the UX on FxOS - we did a partial implementation of this and it has left our UX with an “unfinished” look and feel.

Moving forward we want to have a very uniform UX across all our core apps. We also want to make this uniform experience available to contributors.

Having common components to achieve this will also help with the following:

1. UX to easily manage UX changes

2. Engineering to reduce code size by using these common components

3. QA to reduce their testing 

One of the methods we identified is web-components and there have been some concerns raised with :

1. time taken to implement each component

2. possible performance impacts web-components calls may have.

FWIW, the *entire* UI in the Music NGA re-write was built using web components. We used a combination of the gaia-components as well as some app-specific custom elements. I don’t believe either of these concerns are valid anymore. We were able to throw together web components very quickly when we needed to. Also, we are not seeing any noticeable performance impact from our heavy use of web components.

I saw someone else noted a concern about the Shadow DOM API not being etched in-stone yet, which is a valid point. However, we can also make use of the excellent work Wilson has put into the base “gaia-component” class. This base class allows us to work around any gaps in the platform and also provides a thin layer of abstraction between the component and the platform. So, if things change from the API standpoint, we should (hopefully) be able to just address those changes in the base “gaia-component” class.

I am hugely in favor of continuing down the web components route. Even just from a maintainability standpoint, web components were able to encapsulate all the UI complexity in the Music NGA app which kept each view’s HTML/CSS/JS code very clear and concise.

-Justin

We are currently trying to identify other possibilities to achieve such a uniform implementation - if any of you have any proposals please feel free to reach out to Rob, Hema, or myself.

BR

Wilfred

---
FxOS Product Management
Mozilla Corp., UK

[Jim Porter]

On 10/28/2015 03:33 AM, Wilfred Mathanaraj wrote:
> We are currently trying to identify other possibilities to achieve such
> a uniform implementation - if any of you have any proposals please feel
> free to reach out to Rob, Hema, or myself.

I think a great way to help manage this would be for the visual style to
stop changing until we actually have everything using the new web
components. I recently learned that the font size had changed from
1.8rem to 1.9rem in one area, and that updating to use the web component
therefore caused the font size to change.

That's not a problem in and of itself, but the end result was that it
was inconsistent with other parts of the same app. It would be a lot
easier to achieve a consistent look if switching to web components
produced no visual changes whatsoever; many of us have spent a long time
getting the visuals pixel-perfect according to the specs at the time.
Switching to web components piecemeal actually makes our apps look
*worse*. Once *everything* uses web components, we can update them in
one go and have all the apps suddenly look new and exciting, but until
then, I don't think we should be making visual changes.

It would also be helpful for developers to have access to the overall
guidelines for visual style (e.g. font sizes to use) so that we have a
better understanding of what styles get used where. Perhaps there's
already a document like this, but I don't know where it is.

- Jim

[Patryk Adamczyk]

Hello, consistency in user experience is definitely a benefit but whatever solution we come up, it would be great if we can think of the dev and mozilla community as well. If you take a look at this example: https://www.lightningdesignsystem.com/ everything is live, the component code is visual, it can easily be downloaded and hacked by the user.

So there is also another part to this, and that would to have it sit in a live styleguide.

Imagine if the components can be in github and a single change in github would instantly update:

+ master and every FXOS app

+ style guide website

That would be amazing!

 

It would really echo the ideas of focus and dynamic efficiency. 

-P

On Oct 28, 2015, at 1:02 PM, Justin D'Arcangelo <jdarc...@mozilla.com> wrote:

On Oct 28, 2015, at 4:33 AM, Wilfred Mathanaraj <wil...@mozilla.com> wrote:

Hi all

In the past we had a proposal to use web-components to bring uniformity to the UX on FxOS - we did a partial implementation of this and it has left our UX with an “unfinished” look and feel.

Moving forward we want to have a very uniform UX across all our core apps. We also want to make this uniform experience available to contributors.

Having common components to achieve this will also help with the following:

1. UX to easily manage UX changes

2. Engineering to reduce code size by using these common components

3. QA to reduce their testing 

One of the methods we identified is web-components and there have been some concerns raised with :

1. time taken to implement each component

2. possible performance impacts web-components calls may have.

FWIW, the *entire* UI in the Music NGA re-write was built using web components. We used a combination of the gaia-components as well as some app-specific custom elements. I don’t believe either of these concerns are valid anymore. We were able to throw together web components very quickly when we needed to. Also, we are not seeing any noticeable performance impact from our heavy use of web components.

I saw someone else noted a concern about the Shadow DOM API not being etched in-stone yet, which is a valid point. However, we can also make use of the excellent work Wilson has put into the base “gaia-component” class. This base class allows us to work around any gaps in the platform and also provides a thin layer of abstraction between the component and the platform. So, if things change from the API standpoint, we should (hopefully) be able to just address those changes in the base “gaia-component” class.

I am hugely in favor of continuing down the web components route. Even just from a maintainability standpoint, web components were able to encapsulate all the UI complexity in the Music NGA app which kept each view’s HTML/CSS/JS code very clear and concise.

-Justin

We are currently trying to identify other possibilities to achieve such a uniform implementation - if any of you have any proposals please feel free to reach out to Rob, Hema, or myself.

BR

Wilfred

---
FxOS Product Management
Mozilla Corp., UK

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

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

---
Patryk Adamczyk, R.G.D.
Design Manager - Visual Design Firefox OS
Mozilla Corporation

[Justin D'Arcangelo]

I love the idea of having a live style guide page! I don’t see why we couldn’t do something like that with our gaia-components page:

http://gaia-components.github.io/gaia-components/

-Justin

[Sam Foster]

On Wed, Oct 28, 2015 at 11:52 AM, Patryk Adamczyk <pada...@mozilla.com> wrote:

So there is also another part to this, and that would to have it sit in a live styleguide.

Imagine if the components can be in github and a single change in github would instantly update:

+ master and every FXOS app

+ style guide website

That would be amazing!

 

It would really echo the ideas of focus and dynamic efficiency. 

I don't think this is either practical or desirable. To have a single change cause ripples across all FxOS apps would be really really difficult to manage. Talk about strange magic from a distance! Plus we are moving away from a monolithic "Gaia app". *I do agree we need a simple opt-in way to buy into consistent look and feel and control interactions*. And a way to pick up bug fixes or updates from shared components without simultaneously breaking unrelated stuff - see Jim's note about font-size changes. But I would like to steer us away from the notion of a one-size-fits-all UI toolkit. It always ends in tears. Apologies if I'm over simplifying or mis-characterizing here, I just want to offer the counter-argument.

/Sam

[Justin D'Arcangelo]

I agree with Sam. But it needs to be trivial for apps to pick up the latest changes too. This could be easily solved with Bower. Each app could “lock in” to particular versions of the components they’re using. Then to get latest, the apps only need to have their version numbers bumped in bower.json.

-Justin

[Wilson Page]

Instantly propagating updates can sound dreamy, but live code everywhere can lead to regressions coming from nowhere.

This approach also puts a massive burden on component reviewers and contributors. It's much safer to land changes to a component and have apps PULL in the changes. This gives the app owner a chance to spot regressions, file a bug, remain on the old version and avoid breakage.

If component updates are PUSHED into the apps, regressions will increase. It is not possible for a component owner or contributor to know every single instance whereby their component is being used. Regressions *will* be caused by new patches, our job is to catch them as early as possible and mitigate the impact these regressions have.

This problem is why the Semver standard exists and package managers like NPM have grown so successful.

Our options are:

A. We force PUSH updates into apps and speed up the update process and introduce more global regressions.

B. We land frequent risk-free incremental patches into a component's source repo and PULL stable versions into Gaia one app at a time (not to dissimilar from our train-model).

How do other people do it?

If we look at deployment strategies that have proven to work in production, they all tend look similar to Option B. Facebook doesn't push new features onto all of their users at once; they trickle the changes out to 1%, 2%, 3% of users, until it reaches 100% of users.

This gives Facebook the opportunity to catch issues early, backout and fix; without impacting very many users. It would be appealing for them to be able to ship new changes to everyone in a split second, but this can hurt their users and end up costing more time than it saves.

---

This clearly need some more discussion, but it's important to note this is not a new problem :)

W I L S O N  P A G E

Front-end Developer
Firefox OS (Gaia)
London Office

Twitter: @wilsonpage
IRC: wilsonpage

[Candice Serran]

It's great that many people are weighing in on ideas and comments on this topic!

We'll continue this discussion next week in an open meeting. Please attend if you would like to be involved in helping to come up with ideas on how to solution this problem.

Date: Wednesday, November 4, 2015

Time: 7:30am PST

Location: B2G Vidyo Room

Meeting notes and agenda: https://docs.google.com/document/d/1a4Iopu76TtyVPZkFnmiz-RNPBM_Ajr02kWx1JIyJhm8/edit#

Thanks,

Candice

--

Candice Serran

Sr Mgr - FxOS Engineering Pgm Mgmt

cse...@mozilla.com
irc: cserran

mobile: 303.588.1101

[Julien Wajsberg]

What I miss from Web Components currently:
* ability to change inside styles from the outside, but not in a hacky way, more using exposed CSS API using CSS pseudo elements. I know this is being discussed currently but I really hope we'll be able to have this soon.
* and... that's actually all ;)

We also have this issue that can bite us: https://bugzilla.mozilla.org/show_bug.cgi?id=1208113
Note sure how our colleagues in the Music app managed to avoid it :)

Le 28/10/2015 09:33, Wilfred Mathanaraj a écrit :

Hi all

In the past we had a proposal to use web-components to bring uniformity to the UX on FxOS - we did a partial implementation of this and it has left our UX with an “unfinished” look and feel.

Moving forward we want to have a very uniform UX across all our core apps. We also want to make this uniform experience available to contributors.

Having common components to achieve this will also help with the following:

1. UX to easily manage UX changes

2. Engineering to reduce code size by using these common components

3. QA to reduce their testing 

One of the methods we identified is web-components and there have been some concerns raised with :

1. time taken to implement each component

2. possible performance impacts web-components calls may have.

We are currently trying to identify other possibilities to achieve such a uniform implementation - if any of you have any proposals please feel free to reach out to Rob, Hema, or myself.

BR

Wilfred

---
FxOS Product Management
Mozilla Corp., UK

[Fabrice Desré]

It's interesting that you use Facebook as an example. There was a talk
recently from one of their release manager
(https://air.mozilla.org/release-engineering-at-facebook/) and some take
away are:
- they use a (huge) mercurial monorepo (like Google does). Everything
needs to always work on tip basically. For sure being a closed
organisation may make that easier, but FxOS/gaia could be seen as a
closed organisation with not much harm I think.
- no manual QA, everything relies on CI. They ship their sites twice a
day, their mobile apps weekly.
- all employees are forced to use the beta version. So when they stage
changes to users, it's not for quality/bug testing reasons but mostly to
test product ideas (ie. a/b testing).
- our build & CI systems are from the last glaciation compared to theirs.

Fabrice

On 10/29/2015 05:05 AM, Wilson Page wrote:
> Instantly propagating updates can sound dreamy, but live code everywhere
> can lead to regressions coming from nowhere.
>
> This approach also puts a massive burden on component reviewers and
> contributors. It's much safer to land changes to a component and have

> apps *PULL* in the changes. This gives the app owner a chance to spot

> regressions, file a bug, remain on the old version and avoid breakage.
>

> If component updates are *PUSHED *into the apps, regressions will

> increase. It is not possible for a component owner or contributor to
> know every single instance whereby their component is being used.
> Regressions *will* be caused by new patches, our job is to catch them as
> early as possible and mitigate the impact these regressions have.
>

> This problem is why the Semver <http://semver.org/> standard exists and

> package managers like NPM have grown so successful.
>

> *Our options are:
> *
> A. We force *PUSH* updates into apps and speed up the update process and

> introduce more global regressions.
> B. We land frequent risk-free incremental patches into a component's

> source repo and *PULL* stable versions into Gaia one app at a time (not

> to dissimilar from our train-model).
>

> *How do other people do it?*

>
> If we look at deployment strategies that have proven to work in
> production, they all tend look similar to Option B. Facebook doesn't
> push new features onto all of their users at once; they trickle the
> changes out to 1%, 2%, 3% of users, until it reaches 100% of users.
>
> This gives Facebook the opportunity to catch issues early, backout and
> fix; without impacting very many users. It would be appealing for them
> to be able to ship new changes to everyone in a split second, but this
> can hurt their users and end up costing more time than it saves.
>
> ---
>

> This clearly need some more discussion, but it's important to note *this
> is not a new problem* :)
>
> *W I L S O N P A G E*

>
> Front-end Developer
> Firefox OS (Gaia)
> London Office
>
> Twitter: @wilsonpage
> IRC: wilsonpage
>
> On Wed, Oct 28, 2015 at 8:56 PM, Justin D'Arcangelo
> <jdarc...@mozilla.com <mailto:jdarc...@mozilla.com>> wrote:
>
> I agree with Sam. But it needs to be trivial for apps to pick up the
> latest changes too. This could be easily solved with Bower. Each app
> could “lock in” to particular versions of the components they’re
> using. Then to get latest, the apps only need to have their version
> numbers bumped in bower.json.
>
> -Justin
>
>
>> On Oct 28, 2015, at 4:49 PM, Sam Foster <sfo...@mozilla.com

>> <mailto:sfo...@mozilla.com>> wrote:
>>
>>
>>
>> On Wed, Oct 28, 2015 at 11:52 AM, Patryk Adamczyk
>> <pada...@mozilla.com <mailto:pada...@mozilla.com>> wrote:
>>
>>
>> So there is also another part to this, and that would to have
>> it sit in a live styleguide.
>> Imagine if the components can be in github and a single change
>> in github would instantly update:
>> + master and every FXOS app
>> + style guide website
>>
>> That would be amazing!
>>
>> It would really echo the ideas of focus and dynamic efficiency.
>>
>>
>> I don't think this is either practical or desirable. To have a
>> single change cause ripples across all FxOS apps would be really
>> really difficult to manage. Talk about strange magic from a
>> distance! Plus we are moving away from a monolithic "Gaia app". *I
>> do agree we need a simple opt-in way to buy into consistent look
>> and feel and control interactions*. And a way to pick up bug fixes
>> or updates from shared components without simultaneously breaking
>> unrelated stuff - see Jim's note about font-size changes. But I
>> would like to steer us away from the notion of a one-size-fits-all
>> UI toolkit. It always ends in tears. Apologies if I'm over
>> simplifying or mis-characterizing here, I just want to offer the
>> counter-argument.
>>
>> /Sam
>
>

> _______________________________________________
> dev-fxos mailing list
> dev-...@lists.mozilla.org <mailto:dev-...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-fxos

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

--
Fabrice Desré
b2g team
Mozilla Corporation

[Naoki Hirata]

I'd like to point that their QA is their dogfooders (which we have to coerce people to do because of variety of reasons) and devs are proactive on making sure that they don't break and if they do, they end up having to fix it.

The context is a bit more different of an app versus an OS.  If you make a patch to break an app, it's not as serious as if you make a patch to brick a device.

I'm curious how many branches they have.

[Wilson Page]

I did a talk on Monday about how /why we are using Web Components in Firefox OS.

Video: https://air.mozilla.org/london-web-components-meetup-wilson-page-web-components-in-firefox-os-20151026/

Slides: http://wilsonpage.github.io/presentations/web-components-in-production/

W I L S O N  P A G E

Front-end Developer
Firefox OS (Gaia)
London Office

Twitter: @wilsonpage
IRC: wilsonpage

[Augustin Trancart]

On 29/10/2015 18:03, Fabrice Desré wrote:
> It's interesting that you use Facebook as an example. There was a talk
> recently from one of their release manager
> (https://air.mozilla.org/release-engineering-at-facebook/) and some take
> away are:
> - they use a (huge) mercurial monorepo (like Google does). Everything
> needs to always work on tip basically. For sure being a closed
> organisation may make that easier, but FxOS/gaia could be seen as a
> closed organisation with not much harm I think.

My 2 cents: I'm far from advocating a unique repo, but having too many
repos with dependencies between them is not great either.
I personally found working on gaia-icons quite painful (as a reference:
bug 1209961 [1]. The number of PR it has is ... meaningful). It's
difficult to make contributor stick around if they need to update X
repos before even considering pushing their changes to gaia.

So I would propose to have only one repo for all web components of gaia.
This way, it would be much easier to make change to a wc which other wc
depend on. And we could still tag stable versions and pull them
gaia-side. Things stay manageable, even if every app has an explicit
dependency on this shared repo.

Another drawbacks I see of having a lot of separate repos for shared is
that their discovery is made more difficult. They risk becoming
underused. gaia-icons is a good example again: I don't know the whole
story behind it, but I guess the idea was to provide a set of common
icons for FxOS. A lot of apps have actually their own svg or png that
luckily often look more or less the same (I'm speaking about back,
forward, send, edit-mode, close, attach icons, and many others).

TL;DR Basically, let's keep the dependency tree as flat and simple as
possible to avoid headache.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1209961)

Augustin Trancart
Phoxygen

[Fabrice Desré]

On 10/29/2015 10:14 AM, Naoki Hirata wrote:

> I'm curious how many branches they have.

They have no branches as far as I understood.

Fabrice

[Sam Giles]

At the Financial Times we were solving these sorts of problems with what we branded Origami components - see http://registry.origami.ft.com. 

Disclaimer: I used to work on this.

Each component was in it's own repository, releases were made on an ad-hoc basis - as and when needed, breaking and major changes would necessitate a major version change etc.  Product and component developers - and there were a lot of them - would then pull in a component at build time (we even supported at runtime with https://build.origami.ft.com!) locked to a particular major version - we used semver religiously.  Bower was used as a dependency manager - admittedly with varying degrees of success at first.

As you can see, there are a lot of individual components in different repositories - we had only minor issues with this, but we solved a lot with tooling and process: http://origami.ft.com/docs/component-spec/modules/#managing-new-releases.

Tooling when using web components, from our experience there, is so important - the 'Component Info' section and the data found there was particularly useful when managing releases and figuring out dependents and dependencies: http://registry.origami.ft.com/components/o-typo...@2.0.3#section-info for example.

Tooling also helps with the discovery problem: registry.origami.ft.com - which becomes a kind of living style guide.

This worked at scale - some background can be found here if you're interested: http://triblondon.github.io/talk-components-origami/#/1

I'm actually for a single repository of components, but only if we can make it easy for the community to pull in and use components in their apps as dependencies with minimum friction.

Sam

[Wilson Page]

Thanks for the insight Sam!

IMO minimising friction is critical to usage and contribution. For this reason I believe it's a worthwhile payoff to add a little friction on our side (versioning, installing etc), in order to lower the barrier to entry and streamline the third-party contribution pathway.

If third-parties like our components and find them familiar and easy to use; they'll use them. If they depend our components, it's in their interest to improve them and fix bugs.

As Gaia contribution continues to wane, I'm hopeful we can use gaia-components as a friendly approachable on-ramp to FirefoxOS contribution.

W I L S O N  P A G E

Front-end Developer
Firefox OS (Gaia)
London Office

Twitter: @wilsonpage
IRC: wilsonpage