[MGNLUI-28] Encourage the usage of safe colors for groups on the Apps screen Created: 09/Oct/12  Updated: 10/Mar/21  Resolved: 10/Mar/21

Status: Closed
Project: Magnolia UI
Component/s: applauncher
Affects Version/s: 5.2
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Andreas Weder Assignee: Unassigned
Resolution: Obsolete Votes: 0
Labels: design, ux
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 4_10_Appslauncher_MouseOver_Click.png    
Issue Links:
duplicate
is duplicated by MGNLUI-467 Group tiles on Apps screen don't work... Closed
relation
is related to MGNLUI-1441 Fix color definitions for groups on A... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:

 Description   

Our visual design encourages to choose among a set of safe colors:

  • our groups use one out of 5 predefined colors, which is then used as background color for that group
  • new groups configured by clients always have a white background. The client may however freely choose the color used for the group name. On click or touch start, as well as on hover, that color will then be briefly used as background color as well, but usually remains only visible against a white background else.

There are two reasons for this:

  • we would like to distinguish between client groups and Magnolia groups
  • there are not many colors that work nicely against the green background the Apps screen uses

We may also want to allow a customer to pick arbitrary colors for client groups, if they want to, but the configuration should allow the use of symbolic names for safe colors.

Found in the "App framework" section of the "How to build a Magnolia 5 app" chapter in the draft of the Magnolia 5 book.



 Comments   
Comment by Andreas Weder [ 09/Oct/12 ]

Unfortunately, the current style guide still references the previous color scheme. I'm thus attaching the new scheme developed shortly before the conference.

The second row in the "second level" shows a client group named "Client apps" with the pre-defined white background. The client has configured a darker orange as the title color, which is then used as background color on mouse hover (and click/tap).

Comment by Andreas Weder [ 19/Jun/13 ]

I'm reopening this since this is actually still an open issue we have to address in 5.1.

Comment by Mikaël Geljić [ 03/Dec/13 ]

Do we still plan to do something here? Reading this issue it is not so clear what we should do. Options could be e.g.

  • "force" the inverted color scheme for all groups that are not from us?
  • blend user-defined colors programmatically so that they're not too "solid" visually?
Comment by Andreas Weder [ 03/Dec/13 ]

Yes, I'd still like to pursue this. Never thought about wrongly chosen colors, but I like the idea of forcing the inverted scheme for groups that have not chosen one of the "safe" colors.

As for blending, I actually have a note here on that topic. It seems that more and more browsers are offering CSS blending now, e.g.

http://blogs.adobe.com/webplatform/2013/11/01/canvas-blending-availability/

My idea here would be that we leave things as they are for browsers that don't support blending, but start using the "multiply" blending as originally planned for all that do. We might even be able to delegate this to Vaadin, though I doubt that support for blending is on the top of their priority list.

Comment by Mikaël Geljić [ 03/Dec/13 ]

For blending, I'd say it's still pretty hard to define what that is exactly: whether the css feature is only limited to canvas, and how it reacts when text gets such color on hover/clicked states.

We may be able to compute the resulting color on the server side, based on a middle-solid green from the gradient. Then it could be perhaps 80% of the configured color and 20% of such green...

Comment by Andreas Weder [ 10/Dec/13 ]

Sounds like a good idea. I know that blending isn't a perfect solution, but it produces good results or better results than the current solution in most cases. Nevertheless, I'd like to try your approach. If it already fixes the issue, we don't have to go for blending.

Generated at Mon Feb 12 08:32:53 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.