[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: |
|
||||||||||||||||
| Issue Links: |
|
||||||||||||||||
| 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:
There are two reasons for this:
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.
|
| 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. |