Space horizontal / vertical now considers key object

[Ash]

Yes it is true that Key Object is a relatively hidden feature / one you need to know about. We should probably at least add a tooltip in move tool when you have a multiple selection to call it out.

We do have a number of things which support key object within a multiple selection. Initially the main thing requested was for alignment (and yes understand the comments on needing first selected checked in the alignment drop down, but also the default behaviour of align - what you get from the Layer -> Alignment menu as well as the alignment options which become exposed in the context toolbar when you have a multiple selection - uses key object if you have one nominated). 

Additionally:

- Spacing now considers key object as per this new addition
- Set selection box considers key object to allow multiple opjects to adopt the same selection box as your key object (again added in this beta)
- Geometry Subtract will subtract any overlapping geometry from the key object if you have one selected, rather than just the object at the bottom of the selection which is the default behaviour
- Size / Rotate to same as added in this beta will use key object as the source if nominated (or the first object selected if key object isn't nominated).
- If you choose rename layer with a multiple selection this will rename the key object if you have one nominated too.

There are some other functions which would be useful to take account of a key object nomination which we plan to add over time...
 

[bbrother]

4 hours ago, Ash said:

We should probably at least add a tooltip in move tool when you have a multiple selection to call it out

No need to. There is nothing wrong with the context toolbar in the move tool. 

In fact aligment buttons listed in that toolbar act like simplified version of what you have and can do in the alignment panel.  They allow a quick align to the selection bounds or key object. It's simple and intuitive. No need to think or remember that "first selected" is required to honor key object like it is in the main alignent panel.

The way to go:

1. Add a new "Key Object" category in the drop-down menu for the "Align To" option. Then it won't be so hidden anymore.
2. Bring back the old behavior. Allow the user to select the "Align To" option before performing the alignment operation.
   This option affects how the alignment operation is performed and should not be grayed out or unavailable before the alignment is performed.
3. Move the "Size / Rotate to the same" buttons to the transform panel.
   After selecting several objects, these buttons would become active in the transform panel and you could adjust the size and rotation. More sense for the user.
4. Describe in detail in the documentation that: spacing now considers key object, set selection box considers key object,geometry Subtract will subtract any overlapping geometry from the key object, Size / Rotate to same will use key object as the source if nominated.

@Ash make changes as in the points above and we users will have intuitive, simple solutions and you will have more satisfied users.

[debraspicher]

On 1/12/2024 at 5:52 AM, Ash said:

Yes it is true that Key Object is a relatively hidden feature / one you need to know about. We should probably at least add a tooltip in move tool when you have a multiple selection to call it out.

We do have a number of things which support key object within a multiple selection. Initially the main thing requested was for alignment (and yes understand the comments on needing first selected checked in the alignment drop down, but also the default behaviour of align - what you get from the Layer -> Alignment menu as well as the alignment options which become exposed in the context toolbar when you have a multiple selection - uses key object if you have one nominated). 

Additionally:

- Spacing now considers key object as per this new addition
- Set selection box considers key object to allow multiple opjects to adopt the same selection box as your key object (again added in this beta)
- Geometry Subtract will subtract any overlapping geometry from the key object if you have one selected, rather than just the object at the bottom of the selection which is the default behaviour
- Size / Rotate to same as added in this beta will use key object as the source if nominated (or the first object selected if key object isn't nominated).
- If you choose rename layer with a multiple selection this will rename the key object if you have one nominated too.

There are some other functions which would be useful to take account of a key object nomination which we plan to add over time...
 

Could it be possible to polish the UI a bit for Key Objects? It's difficult to scan at a glance. I honestly don't notice half the time on scan whether it is nominated or not, because the highlighting is so poor, especially at a higher resolution.

It is hard to see imo compared to other programs and there's too many times I can't tell whether I've nominated the correct piece or not. It's less bad in the first example, but in the second, there's just the central line that is highlighted and it is not immediately clear at a glance whether I have the bottom fill or a curve/stroke:




I would check the Layers panel, but that also has hierarchy/seamlessness issues with the highlighting... I drew a circle at the very top of the Artboard stack to show the highlight is very close to the key highlight.. especially on dark, they look the same. Again, at a glance, on a higher resolution display with smaller UI, they look seamless.

Is there any reason the Key Object highlight on the canvas is still blue and not another color (similar to snapping candidates?)

 

[bbrother]

12 hours ago, debraspicher said:

Could it be possible to polish the UI a bit for a Key Object? It's difficult to scan at a glance.

I would suggest two possible improvements to solve this problem.

1. Thicker borders for key objects on the canvas
2. A temporary key icon in the layers panel that would indicate that an object has been selected as a "nominated key object".
   (This option is debatable)

[albertkinng]

11 hours ago, bbrother said:

A temporary key icon

Affinity should hire you.

[Bit Disappointed]

I also believe key object should be highlighted in a less subtle way. I also don't think Serif should be ashamed of actually writing key object in small font next to the object in this case. Perhaps not as visually clear as regular bounds (press . key on a rotated object), but the concept of being clearer in complex programs is sometimes welcome.

There are places in the interface where one looks too much like the other.

A key icon in the layers panel doesn't make sense. Firstly, it is very discreet and contrastless, far away from the selection, and secondly, the key object is not a property of the layer, but a property of the selection. In addition, we have a lock icon that symbolizes locked and a key that symbolizes locked, unlock the lock? 

But that aside, the key object should be highlighted in a meaningful way in the selection, exactly where you select and click.

[bbrother]

11 hours ago, Bit Arts said:

A key icon in the layers panel doesn't make sense. Firstly, it is very discreet and contrastless, far away from the selection, and secondly, the key object is not a property of the layer, but a property of the selection. In addition, we have a lock icon that symbolizes locked and a key that symbolizes locked, unlock the lock? 

I think the same and that's why I indicated that this is a debatable solution.

 

11 hours ago, Bit Arts said:

I also don't think Serif should be ashamed of actually writing key object in small font next to the object in this case

I don't like this solution either. It is enough that a small font is used in the user interface, adding unreadable text to it all, but this time on the working canvas is unnecessary.I think that increasing the thickness of the edge for the "nominated key object" is the optimal solution. Although I don't see a significant problem in how the "key object" is currently highlighted. But I'm not working on a high pixel density monitor. 

Here's what it looks like on my side. I have no problem recognizing the "key object". 
Additionally, on the Layers panel, the background color of the "key object" layer is subtly darker than the background color of the other selected objects which I like and would rather not add more. 

EDIT: The only thing I would consider is to change the highlight color of the "key object" in case the background of the object has a similar color to the highlight color. See picture bellow.

 

[debraspicher]

11 hours ago, bbrother said:

I think the same and that's why I indicated that this is a debatable solution.

 

I don't like this solution either. It is enough that a small font is used in the user interface, adding unreadable text to it all, but this time on the working canvas is unnecessary.I think that increasing the thickness of the edge for the "nominated key object" is the optimal solution. Although I don't see a significant problem in how the "key object" is currently highlighted. But I'm not working on a high pixel density monitor. 

Here's what it looks like on my side. I have no problem recognizing the "key object". 
Additionally, on the Layers panel, the background color of the "key object" layer is subtly darker than the background color of the other selected objects which I like and would rather not add more. 

EDIT: The only thing I would consider is to change the highlight color of the "key object" in case the background of the object has a similar color to the highlight color. See picture bellow.

 

It looks worse when there's overlapping paths or certain color variations, bearing in mind this line is fairly thin on larger resolution displays running at lower DPIs (something I *must* do due to an Affinity bug affecting my machine). Then the "overlapped" portion looks thicker than the rest of the highlight and thus that blue line can be misleading as to what is highlighted/not highlighted. It's harder to see the variance on a high res display. I think to accommodate different viewing conditions, system DPI settings, there needs to more delineation.

[Bit Disappointed]

I'm not a mindless fan of small helper texts around objects in programs either, because it becomes distracting when it's overdone. On the other hand, I do like them as exception assistance.

Everything must be in balance with everything, and here programs that over-communicate with graphic feedback / colours are just as bad as minimalist programs that communicate nothing. You simply can't remember it all when it's just lines and colors, and certainly not when it's just subtle hints. And if everything becomes a mess of symbolism, then text can have its right. However, we are not that far in Affinity, even though the status bar is often filled up to the right margin.

Therefore, the most important thing here is that Affinity does not introduce small unique hints in Designer in scenarios like this, but finds a fundamental method to clarify B over A across functionalities in the Affinity programs, so that one can roughly figure out which genre of feedback one is seeing in Designer or Publisher just through recognition.

So, it's about very basic feedback and user interface principles that one must think of from the start and continuously across the programs. In the end, habit and recognition are the strongest factors in us, which make us function together with tools.

That's exactly why products need a UX responsible specialist - not a developer - for all these concepts, who owns the user interface and, among other things, keeps track of these concepts, and ensures they are followed to the letter in the continuous development work across desktop and tablet versions.

[debraspicher]

I still have to say these programs still feel far more usable for my particular workflow than PS/Illustrator. PS is simply "OK", but I opened it recently and the design feels stale and rigid compared to newer programs that have come into the space and are more willing to accommodate the needs of modern designers who need a more open and flexible workflow. So I know it must really seem like people are nit-picking, but really pushing for a polished UX further reinforces the feeling of acceptance when onboarding new designers looking for a fresh workspace to create their designs in. That helps to further inform future design decisions as well to have preexisting design fully fleshed out. (Basically, this helps everyone.) All graphic programs have their learning curves and pain points relative to this, so that's not a major critique for me. I wasn't criticizing Key Object as "not being obvious" enough as a function.... at least I wasn't. It's important to show in the interface what is happening at each stage so that the designer can work quickly and critically. I suggest only two changes to address this:

1) Change the color of the path where Key Object is selected on the canvas.
2) Change the Layer background color from a color that is not darker, but lighter so it intrinsically is interpreted as a "highlight" action...

Side thought: This may or may not look right on testing (and with other preexisting design language), so this only a thought, but perhaps italicize the Layer name text for a Key Object.

[bbrother]

9 hours ago, debraspicher said:

It looks worse when there's overlapping paths or certain color variations, bearing in mind this line is fairly thin on larger resolution displays running at lower DPIs (something I *must* do due to an Affinity bug affecting my machine).

I understand your problem. Some time ago I asked a friend of mine, who has more than 10 years of experience in professional photo editing and vector graphics, for advice on what kind of kit to choose (monitor, processor... etc.). The first thing he told me was not to buy a high pixel density monitor such as 4K, and not to be like other fools who sit in front of a 40-inch 4k monitor, because due to scaling problems, that's how big the screen has to be to reach the optimal PPI for comfortable work without scaling. As for other components, he said to take what you think is right, but don't follow misguided rules like the more processor cores the better, or spending a fortune on a graphics card,because an integrated one is enough.

 

2 hours ago, debraspicher said:

1) Change the color of the path where Key Object is selected on the canvas.

I would prefer not to change the color of the path. A better idea would be a hatch pattern in the fill or over the fill, such as in the shape builder tool.

 

2 hours ago, debraspicher said:

2) Change the Layer background color from a color that is not darker, but lighter so it intrinsically is interpreted as a "highlight" action...

This proposal seems reasonable and worth considering, although the current solution does not bother me.

 

[TheSnooze]

Affinity on the innovation front! I love this little smart things you come up with like this. In my opinion that's the true USP of this suite. You guys are actual software developers other that salesmen like other big-A companies.

 

Thanks!

[Bit Disappointed]

Now my main point is emerging. We're back where we started and where the forum started. Are we nitpicking? Affinity apparently has 2 million users, and "I think" is something that neither I nor anyone else here can present as anything other than our own preference.

This is simply why I say there is a need for a specialist who, on behalf of 2 million users, is working on methods and an interface that solves as many problems as possible and enables as many people as possible to work enjoyably and efficiently. Has professionalism, has the overview and keeps the applications on track. The most important phrase I've heard in the labour market is "have respect for the professionalism of others". 

2 million users. That's 4 million fewer users than my own colleagues - and I - have to satisfy. It's just a matter of having the right people to do it. Not that we sit here and state our very, very few preferences. It's an unscientific, inadequate and unreliable knowledge base.

Best regards

[Bit Disappointed]

6 hours ago, TheSnooze said:

Affinity on the innovation front! I love this little smart things you come up with like this. In my opinion that's the true USP of this suite. You guys are actual software developers other that salesmen like other big-A companies.

Lets fact check - it's fun, challenging and enriching - and let credit go to those it should rightfully belong to:

Quote

Key objects for alignment in vector software, a feature widely used in graphic design, were not invented by a single individual but rather developed over time as part of the evolution of graphic design software.

The concept of using a key object for alignment in vector graphics software likely evolved as these programs became more sophisticated. In the early stages of computer graphics, software capabilities were limited and designers often had to rely on manual methods for alignment. As vector graphics software like Adobe Illustrator, CorelDRAW, and others advanced, they began to include more sophisticated features to aid in design, including various alignment tools.

The introduction of a 'key object' as a reference for aligning multiple objects is a natural progression of these features. It's a concept that likely emerged from user needs and software development rather than being an invention by a single person. The development and refinement of such features are typically the result of collaborative efforts among software developers, user interface designers, and feedback from the user community.

Specifically attributing the invention of key objects for alignment to a single person is difficult, as it is more of an iterative development within the field of graphic design software.

In Adobe Illustrator, a "key object" is used as a reference point for aligning other objects in relation to it. This is particularly useful when working with multiple objects and you want to ensure they are precisely aligned in relation to a specific object. Here's how it's typically used:

Selecting Objects: First, you select the objects you want to align. This can include the object you intend to use as your key object.

Designating the Key Object: After selecting the objects, you click on one of them again (usually with the Direct Selection Tool or Selection Tool) to make it the key object. This object will be highlighted with a thicker blue outline, indicating that it's the key object.

Applying Alignment: Once the key object is selected, you can apply various alignment tools (found in the Control Panel, Properties Panel, or Align Panel). The other selected objects will be aligned in relation to the position of the key object. This is particularly useful for ensuring that the distance between objects is uniform or that they are precisely aligned along a certain axis.

Using a key object ensures that you can align objects precisely without moving the reference object, which is a great advantage in complex design tasks where precision is necessary.

[debraspicher]

10 hours ago, bbrother said:

I would prefer not to change the color of the path. A better idea would be a hatch pattern in the fill or over the fill, such as in the shape builder tool.

I would otherwise say thicken the line more, but it looks reasonably thick in your example. My example looks similar to yours on my machine if the highlight is over a white background. It looks like there's some transparency to the highlight, so maybe it's that...

[bbrother]

2 hours ago, debraspicher said:

It looks like there's some transparency to the highlight, so maybe it's that...

Perhaps. It could be better, but it's not bad either. It can be improved in many ways suggested in this post and not only. However, it seems to me that we have strayed a bit from the topic, which is spacing horizontal/vertical with the key object in mind.

[Tim,c]

The align object
key object distribute spacing cannot work!

Perhaps the key objects can be attribute spaced according to the input value.

But can they feature be improved?

[bbrother]

On 1/12/2024 at 12:52 PM, Ash said:

We should probably at least add a tooltip in move tool when you have a multiple selection to call it out.

What about instead adding info in status bar while in the move tool. Like one bellow?

[debraspicher]

3 hours ago, bbrother said:

What about instead adding info in status bar while in the move tool. Like one bellow?

I personally prefer the tooltip myself, "bold" type available modifiers currently setup under the toolname and it's shortcut (if applicable) and what they do... maybe even a very very short description of the tool... But, it makes sense to repeat it in the status bar if there's plenty of room... the tooltip is out of the way and doesn't clutter the interface, but can provide a short keycard.

[Bit Disappointed]

Unfortunately, when the move tool pointer is above the selection, the status looks like this:

Actually a good idea, but key objects are very, very rarely relevant to the selections customers make, so the dilemma is that we can either show the tip too early and too often or too late in the dialogue box.

Since key objects are not exactly self-explanatory and are for experienced customers, I would personally prefer if dialogue boxes very discreetly and aesthetically provided access to context-sensitive help, i.e. a button with a link to the online help. The current assumption that customers will simply read it on their own probably means that the help is used much less. And key objects are simply something you need a few minutes of schooling to understand.

Not that I'm a consumer of online help in general - but it simply lives an isolated, unknown life alongside the programs.

[bbrother]

On 1/21/2024 at 7:23 PM, Bit Arts said:

I would personally prefer if dialogue boxes very discreetly and aesthetically provided access to context-sensitive help, i.e. a button with a link to the online help. The current assumption that customers will simply read it on their own probably means that the help is used much less.

No joke. Then the user interface would be cluttered with links to help files.
It is obvious that if you want to learn the program, you need to read the documentation. If the user doesn't do this, he gets lost not because there are no links in the UI, but because he is lazy and unprofessional.

The UI shouldn't be used as an index to help the user to find info in documentation only because the command or func is complicated or the user is lazy.

[Bit Disappointed]

5 hours ago, bbrother said:

No joke. Then the user interface would be cluttered with links to help files.
It is obvious that if you want to learn the program, you need to read the documentation. If the user doesn't do this, he gets lost not because there are no links in the UI, but because he is lazy and unprofessional.

The UI shouldn't be used as an index to help the user to find info in documentation only because the command or func is complicated or the user is lazy.

Nonsense, no clutter or aestheticians died from this small discrete icon in Windows 95 that somehow provided context-sensitive help throughout the program.

It's not my experience that customers read documentation in full, and that's the point I'm making. My experience with my stakeholders is that they typically don't read it because it's not absolutely at their fingertips, and then they see if they can't do without it anyway. It's very engineering-minded to refer to manuals at all. We need to move into more complex products before people start approaching it from that perspective. And a different type of customers than Serifs. This is not AutoCAD.

Regardless of what they should and shouldn't, I see no reason why computers of all things on earth should isolate people from easy access to digital context-sensitive help. Otherwise, online help hasn't moved a bit further since printed manuals.

And I personally find this discreet link to help more tolerable than the banal, clunky and graphical megatooltips that pop up in programs because people don't read manuals. At a fundamental level, I find the total separation of help and software, other than a menu item, quite awkward and outdated. Regardless of which program we are discussing.

[BBG3]

As a user experience designer, I'm going to point out a valuable thing to our developers.

Have you guys counted how many actions should a user take to finish a simple task, regarding this matter?

Well, 7 actions. The actions can be reduced to 3 or 2. like Adobe Illustrator and Figma.

[bbrother]

14 hours ago, Bit Arts said:

And I personally find this discreet link to help more tolerable than the banal, clunky and graphical megatooltips that pop up in programs because people don't read manuals. At a fundamental level, I find the total separation of help and software, other than a menu item, quite awkward and outdated. Regardless of which program we are discussing.

I think you greatly overestimate your experience in the matter you are talking about. Mentally, you're probably still stuck in the 90s when it comes to UI/UX. Otherwise you wouldn't propose such thing. This would also explain your tendency to post pictures of old operating systems on the forum.

It's the 21st century and now we have things like docker with hints (Corel DRAW), context toolbars (Adobe, Serif), status bars and things that help the user on the fly.
Access to the electronic version of the documentation is not limited in any way nor separated from the program. Help files are often built into the program - you don't even need to have internet access.

No need to put crap like buttons that are actuali links to documentation. People are intelligent enough to access information and extract what they need from documentation.

Key objects are not new thing in the buisness. They exist at least form 2010 (Adobe AI CS5). The problem with Affinity is that the implementation of this functionality is not very intuitive, not very visible in the UI and sparingly described in the documentation. The priority should be to fix these mistakes. Linking to the help files doesn't solve any of them.

[debraspicher]

21 hours ago, bbrother said:

The UI shouldn't be used as an index to help the user to find info in documentation only because the command or func is complicated or the user is lazy.

You're correct, obviously. Or at least I agree with you. In my case I wasn't suggesting an index. I'm happier to have relevant modifiers listed though in that little tooltip. I'd say only "root"-level modifiers, not the myriad of functions available in something like node tool by various key presses. Just some hint to let the user know that if they hold those keys, it modifies the tool in some way. Because Node is largely about selecting things prior to manipulation, then I'd always focus on the selecting portion... because the "using" part of the tool can be researched or checked through help. So not a concrete list of complete functionality akin to the Status menu. Just a tooltip that subtlety hints to the user the tool itself asks you test certain modifiers to understand that this is key to using it more wisely. I hope that is clear. It might not to be, to be honest, bbrother. Because what is evident to one person may not be for another.. However, that's what I'd like see addressed: Applying more polish to the UX so that critical information is made known to make on-boarding a bit easier so a user immediately understands what the tool in their hand is capable of and relates to them more easily. Not necessarily how to use it if that makes sense. Subtlety is actually key to making this process as intuitive as possible. If one modifier key can really open up doors for say one or two tools, then the habit is then learned by the user that this is the standard way *all* tools are "augmented" in the program(s) so that they get a clue how to work with these tools more intuitively, and more importantly, waste less time.

To your credit, the way I learned about key object was only because Illustrator explicitly mentions it with a tooltip. Then I know its a functionality available to me and I search how to get a key selection in the help menu. In summary, there are ways to intuitively lead a user down the road in a program that really doesn't have to be explicit at all but guides them to learning to use the program(s) productively. It might even be possible to trim some of these actions down, actually, once a more intuitive approach is found that works consistently across most tools... but as @BBG3 widely states above:

1 hour ago, BBG3 said:

As a user experience designer, I'm going to point out a valuable thing to our developers.

Have you guys counted how many actions should a user take to finish a simple task, regarding this matter?

Well, 7 actions. The actions can be reduced to 3 or 2. like Adobe Illustrator and Figma.

Here is one example...


This is the Align Panel in Illustrator. Note its layout is all icons short of one lonesome textfield (note the up/down key that shows this is an "adjustment" field... and can you tell what the Align To: does intuitively? Most probably can. Especially if they are accustomed to these tasks in other programs having a certain order/way of being done (in theory, not practice). See the box with the key icon? Can you guess what it says in its tooltip?

Here is Affinity's version:


Note:

1) There's a dropdown for the "Align to" options (drop downs slow down the user)... in BOTH horizontal and vertical. AI just has one place for specifying distance, which is perfect, imo.
2) There's 4 dropdowns total. Also, not only are they dropdowns, but two require auto to be unchecked (often disabled depending on what you are doing) to even access them...

Another detail worth noting: In Illustrator, there is no "Status" menu for showing tool options. Most everything is quickly indicated by a cursor change when certain modifier keys are held or "on hover". If Affinity is lagging or its interface is actually being unresponsive or glitching out, we sometimes can't tell for how long or what is even happening, because I've become accustomed to Affinity's UI/UX remaining unresponsive by design. I've gotten so used to this to some extent that I often feel I can't track what is expected or unexpected behavior. Sometimes no response is expected behavior, which is not very helpful. There's many instances where no cursor change is witnessed.

So the argument for UX is not to make it something dummy-proof (never possible... life finds a way), but rather, to save time and learn to work more efficiently and confidently.