This needs to be examined by the UX design team.  Alan, can you triage?

The redlines here don't refer to any of the Harmony or GM2 guidelines, but just seem to exist in a vacuum, so it's not possible to tell what differing bits differ because they represent a new concept that Chrome's implementation needs to be able to express, and what differ because the designer was not referencing the aforementioned specs.

Ideal outcome: we get a redesigned version that stops using numeric constant padding values and instead refers back to the spec concepts for Harmony/GM2 everywhere; where we desire a difference, we link to something speccing out that new core concept and how it works.

We discussed the general issues here with the core views team and bettes@ today.  Here's a summary of what I recall.

* The Chrome design team does have a common set of guidelines that should keep us consistent across different areas -- but currently there are variances between the guidelines for native UI, web UI, and content area stuff, and there supposedly aren't plans to eliminate these variances (which is at odds with my memory).

My takeaway from this bullet is that we need to be careful about what we build in web vs. native technologies, and not mix the two arbitrarily.  Native-built UI should always feel like native, web UI should feel like web, and content area stuff should feel like content area.  We should be clear about why we expect one versus another to be used so we don't end up simulating one with another.

* There is some common design terminology (e.g. around typography) that lets designers avoid giving specifics to engineers and instead refer to concepts ("Body 1 text").  kylixrd@ will work with bettes@ to help establish more terminology, with the ultimate goal that designers can give engineers mocks/redlines that don't have any numeric value on them, but instead refer to the relevant concepts (e.g. "dialog width: large modal" instead of "dialog width: 512").

Until this is done, it would be best for the design team's guidelines to be publicly available (via a go/ link) and have designers reference the relevant guidelines manually for the values on a particular mock ("32 px (go/xyz section 2.3)").  And engineers should never find themselves having to custom-implement padding, sizing, etc.; any cases like this should trigger a request to the designer to clarify what part of the common guidelines were supposed to apply.

* On this specific set of mocks, there is some history for how we got where we are.  Alan wrote some thoughts on https://docs.google.com/document/d/1MA1M1cFkLdVKO0i9IYO5vPQNdv_BdAk528CYBiHlkYc/edit?hl=en .  The primary discussion in that doc is dialog insets.  However, I believe this leaves a variety of other cases where the mocks don't align with Harmony; commented in the doc about those.

Thanks for putting this together Peter. I'm looking forward to being able to fully communicate in terms of semantics concepts instead of px, dp, etc.

Let's start over here :). You caught me on vacation where my words aren't really reflective of reality: 

- We do have a common set of guidelines. It's located at go/chrome-ux-gm2
- The scope of those guidelines cover Core, Secondary, and Web UI. 
- The goal of those guidelines is to have a single design language across all of Chrome, minimizing (and ideally eliminating) major variances between UI areas.

There are known variances (e.g. soft focus ring vs. ripples), but major design decisions (colors, typography, controls, icons) are expected to unify to a single spec. 

>> Until this is done, it would be best for the design team's guidelines to be publicly available (via a go/ link) and have designers reference the relevant guidelines manually for the values on a particular mock ("32 px (go/xyz section 2.3)").  

That's problematic because go/chrome-ux-gm2 assumes a basic understanding of harmony and core ui specs from an engineering perspective (because the same SWEs did both projects). 

go/chrome-ux-gm2 identifies the delta between pre-GM2 Chrome and GM2 Chrome, but isn't a spec for everything under the sun. 


------


These are all growing pains for moving a spec out of production and into the hands of a broader team of contributors -- appreciate everyone's patience here.

If time permits, my suggestion would be for siyua@ and team to build their UI using strict Harmony guidelines and compare it with what rfeng@ is proposing. 

I suspect we'll find that the Harmony guidelines are too compact for the format that Paradise is in. Too compact for any of the Unity dialogs as well (which can be seen within the same flow as Paradise)

Update to my suggestions in c8 based off the current email thread: 

>> Title text is different

We should add new constants to accommodate Paradise spec: crbug.com/885271

>> Checkbox focus states

Use the soft focus ring we currently use in Harmony. https://docs.google.com/presentation/d/1EO7TOpIMJ7QHjaTVw9St-q6naKwtXX2TwzMirG5EsKY/edit#slide=id.g3232c09376_10_368 

>> Other differences (vertical padding) noted between Paradise and Harmony...
 
Most of these larger numbers exist because Rui is taking into consideration Dice/Unity, which is a separate piece of UI that can appear in sequence with Paradise. See attachment. 

I see us with two options (respective of Paradise's timeline): 

1. Approve the larger spacing for Paradise and file a bug to investigate more strict layouts for both Dice/Unity and Paradise UI and/or crbug.com/884907

2. Reformat Dice/Unity and Paradise UIs to have strict Harmony layouts 

I think we're in a hole either way because Dice/Unity and Paradise need to feel like a set. 

#1 ensures they're a set without adding additional work to the Dice/Unity dialog. #2 feels like scope creep to address a problem that already exists (larger padding in Dice/Unity).


Working doc:
https://docs.google.com/document/d/1MA1M1cFkLdVKO0i9IYO5vPQNdv_BdAk528CYBiHlkYc/edit?hl=en

Deleted: image (20).png 61.5 KB

	image (20).png 61.5 KB View Download