"Blue Ocean" Full-Colour icons refresh
Ken Vermette
vermette at gmail.com
Tue Oct 19 00:28:47 BST 2021
Howdy Andreas! (And thank you)
Noooononono! Don't stop the train over my proposition. :)
I'll get the preliminary samples and a few different variants of the
refresh up onto a new Phabricator task tomorrow evening-ish. Maybe
morning after. Feedback and tweaks are a certainty, and there's always
the possibility that the ideas/direction of a refresh may be rejected,
so let's not put existing work on hold over unapproved/unknown work.
Ideally I'd like any work on Breeze icons to continue as-is until
there's a level of certainty that a larger refresh is going to be
accepted, and even then, things outside whatever phase of the refresh
we're in should absolutely remain active; we still need working
up-to-date icons for each release, and it's better to have icons in
their most accurate "state" for reference. I mean we're well north of
700 icons being targeted by this initiative - before we commit let's
play it safe!
Merci beaucoup! ~
- Ken
On Mon, Oct 18, 2021 at 6:54 PM kainz.a <kainz.a at gmail.com> wrote:
>
> That's great Ken, I love your work.
>
> However I already work on a MR to use the highlight color for the places icon see
> https://invent.kde.org/frameworks/breeze-icons/-/merge_requests/141
>
> Let me know if I should finalize the MR or you will jump in.
>
> 5 Years after my last icon work for breeze I come back
> and 2 weeks later the awesome Ken. That's fantastic.
>
> cheers
> Andreas_K
>
> Am Mo., 18. Okt. 2021 um 21:30 Uhr schrieb Noah Davis <noahadvs at gmail.com>:
>>
>> Hi Ken, this sounds like a really cool idea and I'd be interested in
>> seeing what you have in mind.
>>
>> On Mon, Oct 18, 2021 at 12:50 PM Ken Vermette <vermette at gmail.com> wrote:
>> >
>> > Also relevant: [Breeze] [Bug 443288] New: Custom folder icons
>> >
>> > Hey all;
>> >
>> > There's been quite a bit of interest in having colour scheme
>> > responsive full-colour icons, especially with the accent-colour being
>> > much more accessible. In addition the Breeze "Blue Ocean" refresh has
>> > been coming along very nicely (congratulations to everyone behind it!)
>> >
>> > I would like to gauge any interest in allowing me to do a larger
>> > refresh on the full-colour icons in Breeze. This would include
>> > "modernization" to the current trends, adjustments to the style spec,
>> > writing up new documentation to assist future artists, and considerate
>> > future-proofing for the several hundred unique full-colour icon files.
>> > This sort of thing would probably be done over the span of 2-3 release
>> > cycles in phases without assistance. I can commit to doing the
>> > iconography required, documentation, and visual guides. Monochrome
>> > icons would be untouched by this project.
>> >
>> > If this were done, I'd imagine the rollout looking something like...
>> >
>> > Phase 1: Mimetypes, Places (5.24)
>> > Phase 2: Preferences, Categories, Devices (5.24/5.25)
>> > Phase 3: Application Icons (5.25/5.26)
>> > Phase 4: Possible second-pass for colour-science (explained below) (5.26/5.27)
>> >
>> > Since Breeze has been well thought-out and users are accustomed to it
>> > this would be a refresh - not a total redesign. An icon designed to
>> > look like a CD jacket will still look like a CD jacket, but with the
>> > following adjustments and "modernization":
>> > - Responsive colours added where appropriate / not obnoxious (e.g.
>> > folders, various prefs icons, etc), an overall move to class-driven
>> > colouring.
>> > - Removal of the 45-degree shadows, moving to softer top-down
>> > lighting, more "logical" lighting.
>> > - Rounding and smoothing of the general design, as appropriate.
>> > - A secondary style tag named "extended-color-scheme" (explained below)
>> > - Retain the "mostly flat" design, but allowing depth where appropriate.
>> > - Overall a less "angular" and more "comfortable" design language.
>> > - Roughly the same amount of detail, give-or-take.
>> >
>> > I have several sample icons illustrating...
>> > - Emblems in mimetypes and places following the text colour, with
>> > appropriate soft glows/shadows.
>> > - Folders following the accent scheme.
>> > - Icons which can very slightly adjust some individual dark/light
>> > levels to either provide contrast or subtlety for optimal visual
>> > clarity in light/dark/moderate schemes.
>> > - The "extended-color-scheme" style tag (explanation below)
>> > - A new "ColorScheme-Toggle" class (currently does nothing, explanation below)
>> >
>> > The accent colours are things that will get the community excited, but
>> > in terms of usability and comfort any new icons should subtly re-shade
>> > themselves to visually stand out just enough from the background to be
>> > usable but not overwhelming. We have many icons that might feel "too
>> > bright" or "too dark" under certain conditions. A major goal is to
>> > ensure all icons are a pleasing luminosity without "sinking in" or
>> > "popping out" of the system colour scheme.
>> >
>> > "extended-color-scheme" is a style tag with a set of CSS classes
>> > containing the 10 major colours in light/med/dark, and 3 shades.
>> > Unlike the current-color-scheme style tag where every colour can
>> > completely change, extended-color-scheme is more rigid (red is always
>> > red, dark is always darkest). With this extended scheme we can much
>> > more easily produce "vibrant" and "de-saturated" variants of the icon
>> > scheme. I'm midway finished producing a compile-time script for
>> > optimization and colour modulation, so while Plasma itself might not
>> > support this potential feature, it can be used to easily maintain both
>> > "desaturated" and "high contrast/accessibility" icon variants ~ Phase
>> > 2. In the future a pioneering developer may play with this "extended"
>> > colour support as we currently do with system colours. If users wanted
>> > a colour saturation slider or match the colours to their wallpaper
>> > this gives us that future avenue.
>> >
>> > Lastly, I'd also be adding the CSS class "ColorScheme-Toggle" to
>> > select elements. Not everyone prefers the accent colour to dominate
>> > their icons, so this class would provide a mechanism for icon authors
>> > to allow disabling select colourizing in a flexible manner. The
>> > primary example of this is folder icons where users may not want the
>> > folders to follow their highlight colours. The mechanism to make this
>> > work is to keep a copy of the current-color-scheme element during its
>> > replacement, then doing a "dumb" text replacement of ".ColorScheme" to
>> > ".ColorScheme-Toggle .ColorScheme" of its contents. In the Icons panel
>> > we'd provide a checkbox labeled "Use accents from color scheme" to
>> > manage this new behavior.
>> >
>> > If this is done and support for extended-color-scheme and the toggle
>> > rolls out, it will directly benefit community iconographers targeting
>> > KDE Plasma, as they would no longer need to maintain several
>> > variations of their sets in the future. While it theoretically means
>> > more work on a per-icon bases, it dramatically decreases the number of
>> > icons required and puts the focus of different icon packs to shape and
>> > style. In my own work on this I'll be producing complimentary scripts
>> > which will further assist the community in optimizing and deploying
>> > these slightly more dynamic icons.
>> >
>> > If a larger refresh is not needed I don't wish to push a larger design
>> > effort onto the community, especially since it changes some of the
>> > foundational style aspects of the icon theme, but this is work that
>> > I'm able and willing to do. Between the strides of Plasma getting a
>> > cleaner look/feel and competitors upping their aesthetic game, I think
>> > this is a decent opportunity to keep pace in the graphical segment
>> > while refreshing the iconography a bit. This requires effort in the
>> > high-hundreds to low-thousands of icons, it would likely spawn several
>> > phab tasks, so please let me know if you'd like me to begin this
>> > initiative before I start making tasks which might pollute
>> > Phabricator.
>> >
>> > Thank you.
>> > - Ken
More information about the Visual-design
mailing list