Selecting Colors

[Matthias]

As much as I love Designer/Photo/Publisher I think there are a few minor UI issues where user actions don’t meet expectations. I already mentioned some of them, for example:

– Why not reveal the file path by alt-clicking on the document  title (standard macOS behavior)?

– Why not recognize the state of the alt key once dragging has started (standard Finder behavior)?

 

But my suggestion today is: I think the color handling in the color palette (or Studio) can improve with small refinements like:

– Add a command to delete all unused colors in the document/user color lists.

– Add a command to change all used colors to global.

– Make multiple color swatches selectable (and changeable, e.g. to global or for deleting) with alt-click (standard macOS behavior).

 

Cheers

Matthias

[Matthias]

Speaking of the Color Palette:

I would prefer if the predefined colors I chose kept their names in the document colors list. If I’d want to I still could rename them anytime. But a label like „Global Color 1“ doesn’t help. If it is e. g. PANTONE I sure would like to (and have to) know.

[.: NICKY G. :.]

1. It would be Good to both have the color reference of the color (RGB, CMYK, ....) Both When you see only the small square with the color the possibility of a Tooltip when you pass over the color with the color percentages indicated
When entering the Pantone be renamed with the name of the pantone.

2. It would be good to be able to insert a color created in the color palette with a Drag and drop and insert it / add it in the palette.

3. I see the color palette management palette a little too cumbersome

[fde101]

I don't much like the idea of having a global color automatically named to match the color itself.  Instead I think the actual color (pantone number or RGB/CMYK/etc. value) should be listed next to the name, or underneath it, when displaying as a list, or in a tooltip for when the display format doesn't allow that.

The reason is that global colors can be changed.  If a different color is assigned to the global color, and that color name is used as the name of the global color, then you need to change the name to keep it in sync, but if someone renamed it to something more meaningful (ex. "sidebar text") then having the program automatically change the name of the global color would wipe out the more contextually meaningful name that was given to the color.  Having it try to detect when the name should be changed is kind of dicey - if I picked pantone color 19-4150 for my sidebars and named the color as "19-4150 - sidebar text", then the auto-detection might not be smart enough to figure out how to update that...  as different people could wind up using different formats ("sidebar text (19-4150)", "sidebar text: 19-4150", etc.).

Keeping the actual color separate from the name but still making it visible would be the more ideal option.

[Matthias]

10 minutes ago, fde101 said:

The reason is that global colors can be changed.

That is a valid point.

 

10 minutes ago, fde101 said:

I think the actual color (pantone number or RGB/CMYK/etc. value) should be listed next to the name

Yeah, that would help.

What if the global color (being e.g. a Pantone color) first went with its original name (or RGB/CMYK value) like I proposed — but as soon as it is changed it would require to be given a new name or be generically named like it is now?

[fde101]

4 minutes ago, Matthias said:

but as soon as it is changed

If the software kept track of whether or not the user had renamed the color then the name could easily be one that was selected to match the color up until then, but you would still wind up with people renaming them to things like "19-4150 - sidebar text" after which they would get out of sync.  Obviously that would still be possible with what I am suggesting, but there would be less reason for the redundant inclusion of the color in the name, so if people still did things like that they could only blame themselves for the confusion.

[Dazmondo77]

I'd personally like to see a tick box or something in preferences that would enable global colours by default, so even imported artwork would import as global - so many times I've imported a logo originally done in illustrator using a different colour profile and all the colours would be in a mess especially if the print provider needs all rich blacks to be no more than 260% density and the imported blacks are 380%, I've also had similar problems with artwork setup as a single 100% black importing CMYK at around 300% - just importing in the used colours as a global palate would save potentially hours of going through layers and nested layers to convert colours to global manually, this feature is a massive time saver with indesign - I'd also love to see preference tick boxes for scale fx and strokes to be on by default 

Heres a quick screen rec detailing how easy indesign does it, although theres a slight profile mismatch so the rich black loses it's values once pasted back into designer but would take an age to sort out in designer 

[Mark Oehlschlager]

The color palette in the Affinity suite could definitely take a few cues from the Adobe suite. 

In addition to the importation of color from placed art as global color, It would be nice to create logical sub-groupings of color within a palette (e.g., primary, secondary, accents, etc.).

Beyond that, it would be nice for there to be a Select same ... menu item. Select same fill. Select same stroke. Select same stroke and fill.

[Dazmondo77]

13 hours ago, Mark Oehlschlager said:

Beyond that, it would be nice for there to be a Select same ... menu item. Select same fill. Select same stroke. Select same stroke and fill.

Yes please

[Matthias]

13 hours ago, Mark Oehlschlager said:

it would be nice for there to be a Select same ... menu item. Select same fill. Select same stroke. Select same stroke and fill.

Like — dare I say it — FreeHand had. You could even select all elements that had e.g. more than x nodes and stuff like that.

[fde101]

15 hours ago, Mark Oehlschlager said:

The color palette in the Affinity suite could definitely take a few cues from the Adobe suite. 

Adobe is not trying to maintain a consistent file format among multiple applications.

The type of behavior you are pushing for in Publisher would be a nightmare for Photo and not really all that wonderful in Designer either, at least not for some use cases.

Trying to maintain behavior like this would very likely be a source of confusion when shuttling files between the applications.

 

I'm all for coming up with ideas to improve the products, but make sure you are considering questions such as:

• Will these actually be improvements for all three programs, not just Publisher?
• Will they be flexible enough to support any other programs that might be added to the suite later on?
• Will these changes impact compatibility with importing older files from Photo and Designer as they already exist?

[Matthias]

33 minutes ago, fde101 said:

The type of behavior you are pushing for in Publisher would be a nightmare for Photo and not really all that wonderful in Designer either, at least not for some use cases.

As I am pushing, too, here are my remarks:

This type of color management would be a boon at least for me when I do corporate design work (which I do in Designer). For Photo I can’t think of a scenario where this would be a nightmare. Maybe that’s just my lack of imagination. If you see a nightmarish situation, could you please elaborate on that? Because for one situation you described (pasting in an object with an identically named global color swatch attached) I already offered a solution.

 

33 minutes ago, fde101 said:

I'm all for coming up with ideas to improve the products, but make sure you are considering questions such as:

• Will these actually be improvements for all three programs, not just Publisher?
• Will they be flexible enough to support any other programs that might be added to the suite later on?
• Will these changes impact compatibility with importing older files from Photo and Designer as they already exist?

Bullet point 1) As stated above: I can’t see the nightmare, only benefits. Because nothing would get stripped away, only some attributes would get added. So: improvement. I always think in terms of the three Affinity products which I use. Complete interchangeability is their key feature as a suite.

Bullet point 2) Of course we cannot quite consider possible Affinity products in the future we don’t know.

Bullet point 3) Maybe elements from older files with non-attached global colors must have them re-attributed in order to gain the new functionality. Maybe there is another way. But as I am not an Affinity employee I don’t think I have to come up with turnkey solutions. I see my job here as pointing to flaws and shortcomings and making resonable suggestions which might or might not be implemented.

[fde101]

23 minutes ago, Matthias said:

Because nothing would get stripped away

Apologies, I misread something and somehow associated some of this with discussion from a different thread.  I was reacting to some of the suggestions that have come up that would have tried to make all swatches into global colors - THAT would be a problem.

 

16 hours ago, Mark Oehlschlager said:

It would be nice to create logical sub-groupings of color within a palette (e.g., primary, secondary, accents, etc.)

Yes, it would, assuming you actually meant the swatches panel.

[Ashcraaft]

On 5/22/2019 at 4:56 PM, Matthias said:

– Add a command to delete all unused colors in the document/user color lists.

 

Count me in 👍