[Accepted with Revisions] SDL 0147 - Template Improvements: Color Scheme

[theresalech]

Hello SDL community,

The review of "Template Improvements: Color Scheme'" begins now and runs through March 13, 2018. The proposal is available here:

https://github.com/smartdevicelink/sdl_evolution/blob/master/proposals/0147-template-color-scheme.md

Reviews are an important part of the SDL evolution process. All reviews should be sent to the associated Github issue at:

#422

What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of SDL. When writing your review, here are some questions you might want to answer in your review:

• Is the problem being addressed significant enough to warrant a change to SDL?
• Does this proposal fit well with the feel and direction of SDL?
• If you have used competitors with a similar feature, how do you feel that this proposal compares to those?
• How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
  Please state explicitly whether you believe that the proposal should be accepted into SDL.

More information about the SDL evolution process is available at

https://github.com/smartdevicelink/sdl_evolution/blob/master/process.md

Thank you,
Theresa Lech

Program Manager - Livio
theresa@livio.io

[Jack-Byrne]

Proposal is missing changes necessary for the HMI_API.xml. When an app gets registered, the HMI is notified by onAppRegistered for a single application or by updateAppList which contains an array of all registered applications.

Both RPCs use the same type of struct to register an app on the HMI: Common.HMIApplication. The new parameters that are mentioned in this proposal also need to be added to this struct so that the HMI knows what custom colors were set for each app.

<struct name="HMIApplication">
    <description>Data type containing information about application needed by HMI.</description>
    <param name="appName" type="String" maxlength="100" mandatory="true">
      <description>The mobile application name, e.g. "Ford Drive Green".</description>
    </param>
...
+    <param name="dayColorScheme" type="Common.TemplateColorScheme" mandatory="false"></param>
+    <param name="nightColorScheme" type="Common.TemplateColorScheme" mandatory="false"></param>   
</struct>

[joeygrover]

Overall I believe this to be a good proposal and will have a really positive effect on the platform. I do have a few comments I think are worth considering:

Adding a third color

I believe most pallets are best defined by a combination of three colors and would be a simple addition if done from the start, but I believe adding it later would be problematic in terms of apps having a consistent UX from older generations to newer.

Color scheme per template

I believe we should also add the scheme params to SetDisplayLayout. This would be helpful to create truly rich experiences for apps.

Defined color adoption for elements

I completely agree with the Author that it is likely that OEMs/adopters might use the color schemes in different ways. For this reason, I believe it is incredibly important that we define how each color should be used on which UI elements. Otherwise apps are going to end up with possible poor implementations based on what an OEM does with the colors.

[joeljfischer]

@joeygrover Thanks for the review.

Adding a third color

I definitely considered a third color, but couldn't think of anything it could modify. Furthermore, I think most brands have one primary brand color, and only a few have two (where one of them isn't white / black). Perhaps soft buttons & subscription button colors could be separated.

Color scheme per template

This could be a good addition.

Defined color adoption for elements

The background color should be obvious for OEMs to implement. brandColor1 I called a "strong recommendation" to modify button background colors (e.g. soft button, subscription button, menu button). Since text is automatically white / black based on the appropriate background color, the screen background and button backgrounds are accounted for, I'm not sure what else there is to cover.

[ghost]

I like the idea and also the idea to change the style with other layouts. I think a single brand color and background color might not be sufficient. The default and highlighted button background and the font color should also be modifiable. The brand color should be used eg for the media clock bar. But that’s up to the HMI of the OEM.

I think app devs would highly appreciate to have more color params for specific cases eg. .fontColor or .highlightedColor. In addition to that a StyleSheetCapability should inform the app which of the parameters are considered by the connected head unit.

I’ve seen you want to allow different style per day or night mode. Does every possible HMI allow that? What style should be used for HMIs that don’t support day/night? I guess the answer would be the style sheet for day mode but that one might be to light for night time as app developers would expect night mode to be supported any time.

[joeljfischer]

@kshala-ford Thanks for the review. I strongly disagree that the font color should be modifiable. For driver distraction rule purposes, I believe white / black based on the color the text is presenting on is the only good solution all OEMs will be comfortable with and will reduce the OEM review process.

I agree that the brand color should change the media clock bar, but disagree that should be up to the OEM. It should be standardized.

I also disagree that devs should have too many more color params. I can see the use of highlighted color for buttons, but cannot think of any other case that a 3rd color is needed, and I don't believe font color is a good idea, for the reasons above. We could add a brandColor2 for that, or we could apply a standard darken / lighten to brandColor1. A StyleSheetCapability is not needed due to the styles being a standard / strong recommendation for all OEMs to follow in their HMI.

I’ve seen you want to allow different style per day or night mode. Does every possible HMI allow that?

Probably not.

What style should be used for HMIs that don’t support day/night? I guess the answer would be the style sheet for day mode but that one might be to light for night time as app developers would expect night mode to be supported any time.

It would be up to them, whatever would better fit with the rest of their UI.

[tpulatha]

I agree that we should keep the options controlled, especially font color is not a great idea for contrast reasons as @joeljfischer mentioned.

I would also say that we might want to only allow a primary and secondary color, and every OEM defines how to apply these colors. It will be hard to start certifying that apps don't use white for night mode colors (something you definitely don't want to do).
If we only have primary, secondary colors OEMs can use less color in the night mode and more color in the day mode (where OEMs have more freedom).

[ghost]

Regarding font and contrast the proposal includes the w3c guideline which can be used by SDL core to compare the background color and a font color and reject if they are not appropriate. Same goes for light color in night mode. If the background color for night mode is too bright it can be rejected/ignored (threshold can be specified here). Please keep in mind that font is more than only pure black and pure white. The design usually uses a dark gray e.g. #202020. In case of a night mode the font somewhat around #e6e6e6. All I want to allow apps to do is to specify their own dark gray font color with the possibility to tint the font color.

As some head units don't differentiate between day and night (except screen brightness) the two parameters should be called colorScheme and nightColorScheme. The app should be able to only specify colorScheme which should be compatible for night/dark moments.

I disagree to use the brand color for button background. Instead it should be used for highlighted buttons and for the color of the progress bar, slider, switches etc. For button backgrounds we might want to allow to specify another color e.g. in .buttonBackgroundColor.

Did you consider the color of icons on buttons? What should be done for template images? I think their coloring should follow the same direction as for font color.

[joeljfischer]

Please keep in mind that font is more than only pure black and pure white. The design usually uses a dark gray e.g. #202020. In case of a night mode the font somewhat around #e6e6e6. All I want to allow apps to do is to specify their own dark gray font color with the possibility to tint the font color.

Personally, I think that the OEM should decide their own font black / white color to match the rest of their UI.

As some head units don't differentiate between day and night (except screen brightness) the two parameters should be called colorScheme and nightColorScheme. The app should be able to only specify colorScheme which should be compatible for night/dark moments.

There may be a miscommunication, but I'm not 100% sure what the proposed change is here. The current proposal defines that apps should provide basically a light & dark scheme. If the head unit only wants to use the light scheme, they can do that, same for night. If an app only provides light, and the rest of the head unit is dark, the head unit may use their own scheme since no dark scheme was provided, and visa versa for a light schemed head unit. If the head unit supports both, then they could use their own scheme for anything the app doesn't provide.

If I'm understanding your proposed change correctly, if an app provides a colorScheme that is dark, then that may look very odd on a head unit that is light.

I disagree to use the brand color for button background. Instead it should be used for highlighted buttons and for the color of the progress bar, slider, switches etc. For button backgrounds we might want to allow to specify another color e.g. in .buttonBackgroundColor.

I can definitely see the advantages of that.

Did you consider the color of icons on buttons? What should be done for template images? I think their coloring should follow the same direction as for font color.

I think that's covered in the template images proposal. They would be dark or light based on the background of the image. e.g. if a highlighted button should have dark text / image, it will, but that may be matched with a non-highlighted button with a light text / image. Not all text and images would necessarily match across the screen.

[theresalech]

The Steering Committee has voted to defer this proposal, keeping it in review until our next meeting on 2018-03-20, to allow more time for review and discussion. This may also be discussed in greater detail during the "Enhanced Proxy Interfaces" portion of the SDLC Workshop 2018-03-19.

[theresalech]

During the workshop, it was discussed that this proposal could be accepted with the following revisions:

• Add changing color to setDisplayLayout
• Add Secondary Color
• Rename BrandColor1 to Primary Color
• If you support only one color, it must be Primary. If you support Secondary, you must also support Primary.

This implementation will be verified on the Generic HMI. Members are encouraged to verify on their own HMIs as well.

[theresalech]

The Steering Committee has voted to accept this proposal with the revisions noted in this comment.

[theresalech]

@joeljfischer please let me know when a PR has been submitted to make requested revisions to the proposal file. Thanks!

[theresalech]

Proposal has been revised to incorporate requested changes, and issues have been entered:
RPC
Core
iOS
Android
SDL HMI