Created attachment 183013 [details] Proposal for palettes with named colors We introduced the new color palette for bug 87538 resp. bug 80196 and others a couple of years ago. But using such a palette with more or less random colors is probably not a user centered approach to style documents and rather suited for drawing tools. The proposal is to introduce a themed color palette similar to how competitors handle the situation [1,2]. Such a palette would provide a number of "named colors" that are used for text background and foreground along with accent colors that are use on diagrams and other colored content. Switching the palette means to change the effective colors in the document (unless a color is directly applied). The palette part consists of variations of the named colors with more or less muted variants. Introducing this means to change the way of handling color palettes. Today we allow to Add/Remove colors via a special "User" palette. The proposal however considers complete palettes with a fix number of different named colors (10 for compatibility reasons) and although the variations could be computed all named colors need to be defined. We could a) always derive/clone from a standard palette and provide just means to modify one color at time, b) allow to modify the shipped palettes, c) provide some dialog to manage palettes, d) leave it to 3rd party tools / extensions. Introducing the named color palette would also fix the document color issues from bug 107380 by resolving bug 63898, requesting to integrate color palettes into the document. Attached is an idea for some named colors. [1] https://itstraining.wichita.edu/microsoft-office-color-themes-and-custom-color-palettes/ [2] http://www.addbalance.com/usersguide/styles.htm#Themes
I've no great objection, so long as the current Standard color theme remains the base cross module. Minor concern with using sets of "Named" color themes (of 12 fixed colors-DK1, LT1, DK2, LT2, ACCENT1, ACCENT2, ACCENT3, ACCENT4, ACCENT5, ACCENT6, HLINK, FOLHLINK) is the general lack of applied color theory for the themes--no logic or functional design in the sets of color that get chosen to go into a theme--either what we'd provide as new "Named" color themes, or what gets passed in and mapped from os/DE. Current Standard, Tonal and freecolour-hlc palettes are formula generated color sets--reproducible and suitable in any part of the UI. Overall not too much of an issue as all colors are either HEX RGB, or decimal equivs of the RGB. And get recorded to ODF as hex RGB. If we extend ODF with a fixed set of color labels (assume that is going to be needed) then I guess the "Theme" can be embedded into the documents--and we'd want to handle it consistent to OOXML's encoding (if any) for better interoperability.
This J. Korchok blog has some good details on limits of OOXML color themes, whose 10 color limits originates from MS Office PowerPoint color picker GUI limitations: https://www.brandwares.com/bestpractices/2018/02/great-color-themes/
> If we extend ODF with a fixed set of color labels (assume that is going to be needed) then I guess the "Theme" can be embedded into the documents--and we'd want to handle it consistent to OOXML's encoding (if any) for better interoperability. This is already happening, we write the themed colors (those 12 ones) of a PPTX master page into ODP & read it back, see https://vmiklos.hu/blog/sd-theme-shape-text.html and https://vmiklos.hu/blog/sd-theme-shape-fill.html. I hope to work on this more in the future to use themed colors at more places in Impress (and also Writer/Calc), once I get time to do so. :-)
Removing needsUXEval since input has been given but cannot set my own ticket to NEW.
I'll set => NEW understanding that it does not affect current color picker--color palette usage. Looking forward to Miklos's work on implementation(s) in UI.
The mockup at https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-id=d9665a57-0073-80a2-8002-47af3e11cf34§ion=interactions&index=0&share-id=d5fc0283-ef1c-80fa-8002-47d90c42f7c6 starts on 1) with the current implementation. While LibreOffice (on the left) offers RGB access to set all millions of colors the theme (as implemented by MSO on the right) is kind of a style and changing „Accent 1“ affects all places it is used. The requirements are: a) pick a themed colorize 1. access different brightness/colorization steps 2. show the active theme color on the selection 3. allow special colors such as „Automatic“ (eg. for font color) and „No Fill“ (Shapes) b) pick a standard color 1. provide access to the recently used colors 2. allow to switch the way RGB colors are presented (eg. Palette filtered for HTML) c) use the themed and standard colors on gradients and other places too d) allow to switch the color theme to adjust to whole document appearance (eg. from “Rainbow” to “Beach”) e) edit and share color theme f) edit and share standard colors and palettes No doubt that MSO solves a) in a perfect way, and we could do the same giving full access to the standard colors b) in an extra dialog. But we aim to give freedom to the users and should not just copy a solution but make it more flexible. Option 2) in the mockup merges a) and b) into one picker. The standard palette is reduced to save space but that’s not necessary. In contrast to the prototype from MSO we could just present the basic theme colors denying a1 (access to the brightness level could be given in the color dialog underneath the current color per slider / num stepper). It adds a dropdown to pick a theme and the load more from the extension site. Drawback of this solution is that picking a theme when coloring a random object affect every color. Changing the color theme might be better suited at some special place, in case of MSO at the Design tab. We could do this in a special dialog or in the page style dialog (respectively Slide Properties for Impress) since the setting belongs to the whole document. Option 3) takes into account that the layout of 2) feels a bit crowded. It reduces the Theme Colors to just the colors with access to the brightness levels via dropdown menu. And while we can do this for the themed colors the same is possible for the standard colors, as shown right hand. Changing the RGB palette could be done in any Area Fill dialog. Themed colors are well suited for less colorful documents as done in Writer but less optimal when color is prime, ie. in Draw. We probably need two different approaches. Comments are welcome.
I really want to keep the Theme "style" editor separate from our functional Palette based color picker. OK to use the Theme palette from the picker as now. But keeping two distinct dialogs please--not option #2 Yes to providing the 'Standard' colors (standard.soc) for use with the Theme Colors... picker would be useful. And with the 'Standard' palette the drop list would obviously be the defined "tints" and "shades" of the standard.soc. +1 for option #3 A good start but would we stop there? For Themed colors "style" dialog--how do you make changes to the Theme? Remember the theme structure is 2-backgrounds, 2 text/foregrounds, 6 accents, hyperlink, followed-hyperlink. And the rest of the "Theme" columns are calculated values against those base colors: 80%, 60%, 40% lighter and 25%, 50% darker. They are fixed as recorded to the palette. Currently, you can change one value--but you can not pick one base color to modify and recalculate its derived values to edit the "Theme". Seems that is going to be needed. Also, should there be some cross over by including the "active" palette from the color picker for editing the base colors? Maybe just link the picker as a split button (show active color - or open picker) like done on normal toolbars? Another reason to keep two dialogs.
Created attachment 186332 [details] Solid fill and gradient fill Theme colors (MS Office "schemeClr") are different from palettes because the set of scheme colors is stored in the file and bound to the master page. As Writer has only one master page it can only have one set of scheme colors. Impress/Draw can have several master pages and thus several sets of scheme colors. If you want to change a theme, that means effectively a change of the master page. So I agree with V Stuart Foote that changing or editing the set of scheme colors should not be in the area dialog but could be located in the master page dialog in Impress. In Writer it cannot be inside the page style dialog, because there is only one set of scheme colors. [Perhaps a new dialog with all document wide settings in Writer?] For selecting a scheme color, I prefer to have it separated from the palettes. There could be a dedicated area for it, see my attachment. Lighten/darken can be a new control, consisting of a set of buttons with stepped examples and a field for numerically determine the value. MS Office allows light and darken not only for scheme colors but for all colors. Therefore I would allow lighten/darken for palette colors too. See my attachment. MS Office has no fixed steps of lighten/darken but depends the steps on the brightness of the base color. So should we do (bug 153361). It is useless to make a light background color 4 steps lighter, or a dark text color even darker. The previews of the selected colors would then need to be split in showing the base color and the selected lighten/darken variant. That is not included in my attachment.
(In reply to Regina Henschel from comment #8) > Created attachment 186332 [details] > Solid fill and gradient fill Amended my mockup at https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-id=d9665a57-0073-80a2-8002-47af3e11cf34§ion=interactions&index=0 with this idea (the preview has now two pages, see arrows left/right). I don't think we need the extensions link in the picker on the theme color. Replaced it by access to the "edit theme color" dialog shown in the mockup too. I suggest to not "bleed" the UI into the left column and adjusted the positioning a bit. Wonder if this theme color brightness control would be disabled in case of a RGB color or hidden. With this UI it might be a challenge to spot whether a themed color is chosen or something from the RGB palette. The theme color editor should be self-explanatory.
Another question is how we handle (hyper) link colors since we take it currently from the system (and allow customization per app color). I omitted the two colors in my mockups.
(In reply to Heiko Tietze from comment #9) > > Amended my mockup at > https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page- > id=d9665a57-0073-80a2-8002-47af3e11cf34§ion=interactions&index=0 That link gives an oops, but the link from comment 6 seems to work. Has the revised mockup? https://design.penpot.app/#/view/d9665a57-0073-80a2-8002-47af3e11cf33?page-id=d9665a57-0073-80a2-8002-47af3e11cf34§ion=interactions&index=0&share-id=d5fc0283-ef1c-80fa-8002-47d90c42f7c6
(In reply to V Stuart Foote from comment #11) > That link gives an oops, but the link from comment 6 seems to work. Has the > revised mockup? My bad, should copy the official link. And yes, it's the same mockup but with a second page (landing page is new). Find arrows at the left/right side to switch forward/backward.
Created attachment 186369 [details] Theme color customize dialog in MS Office (In reply to Heiko Tietze from comment #10) > Another question is how we handle (hyper) link colors since we take it > currently from the system (and allow customization per app color). I omitted > the two colors in my mockups. MS Office do not show 'hyperlink' and 'followedHyperlink' when the user selects a color for shapes, text, borders, ... But they are included in the dialog to customize theme colors, see attachment.
(In reply to Heiko Tietze from comment #9) > Wonder if this theme color brightness control would be > disabled in case of a RGB color or hidden. Setting brightness is also available for non-theme colors in gradients in MS Office. And this information is written to file. We too have already "intensity" for colors in gradients, which is actually reducing luminance and written to file. So at least for colors in gradients we need a brightness control for all kind of colors.
No need for further input from UX/design for now.