Reference object for alignment in v 2.4 – am I getting something wrong?

[Lorox]

I just installed the updates and I was really looking forward to the new "reference object feature" for aligning several objects.

However, while this seems to work with distributing (alt-click one object of several selected ones to have this and the one to the left [if I remember correctly] of it as the reference for distributing/spacing) I cannot make that ”reference thing“ work for simple top/middle/bottom alignments (like it has been a standard in AI since quite a long time).

What I mean is: if I have – say – 5 objects distributed in random vertical positions on my artboard and I want to align all of these to the bottom of i.e. the second one, I thought/hoped that I can now alt-click that second one (which as the reference object gets that special selection outline), click the "align bottom" icon and have all of my selected objects aligned with their bottom selection bounds to the bottom of that reference object. (Accordingly, of course, as all other alignment options are concerned). (see attached screenshot)

I really did love this feature of reference objects for alignments in AI as it often came in very handy as it didn't make it necessary to manually put some objects in more suitable positions beforehand.

I am missing something here or does it really not (yet) work in v 2.4 as I actually hoped for?

[MEB]

Hi @Lorox
In the Alignment panel make sure the Align to dropdown (below align vertically icons) is set to First Selected (which aligns to you first selected object which is the key object you selected). Seems you have set it to Selection Bounds currently.

[Lorox]

34 minutes ago, MEB said:

Seems you have set it to Selection Bounds currently.

Man, thank you so much – you were absolutely right!

I actually thought I should be able to change something in that dropdown menu, but as it seems to be greyed out so you cannot change the current entry until you actually make a specific choice of alignment (e.g. top/middle/bottom) for your selection by selecting the corresponding button/icon – which I hadn't done yet – I felt a bit irritated and just left it at "Selection Bounds" and (unwillingly, though) thought it had to be that way... Always good to ask someone who knows...

That being said: the feature is great and (now) does just what I hoped it would do!

Edited March 6 by Lorox
Added final sentence...

[MEB]

Glad to know it's working as you want now Lorox.
You're welcome.
 

[Pšenda]

1 hour ago, Lorox said:

but as it seems to be greyed out so you cannot change the current entry until you actually make a specific choice of alignment

Yes, there is no point in allowing some parameters to be set, without specifying the desired operation, when some of the set parameters would make no sense at all.
Why allow the "Align to" parameter to be set when the operation performed will be "Space horizontally/vertically"? Why enable the setting of distribute parameters when the operation will be Align?

[Lorox]

@Pšenda:

Yeah, I guess you're right, when I give it a second thought. Sometimes you're just so focussed on what you want to do at a specific occasion or in a specific place that you don't really think about what another user would possibly want to do actually using basically the same part of the interface where you sort of expect just your options to display. Maybe it's human nature to be a bit shortcircuited at times... But yes, you really cannot blame the Afffinity guys here!

[bbrother]

3 hours ago, Pšenda said:

Yes, there is no point in allowing some parameters to be set, without specifying the desired operation, when some of the set parameters would make no sense at all.
Why allow the "Align to" parameter to be set when the operation performed will be "Space horizontally/vertically"? Why enable the setting of distribute parameters when the operation will be Align?

It's quite the opposite. If a parameter determines or significantly affects how an operation will be performed, it should be allowed to set it before specifying the operation.

The "Align to:" parameter determines how alignment operation will be made by seting the crucial criterion for the operation that is align either in relation to: 

• Nominated Key object,
• Selection Bounds,
• page Spread,
• page Margin,
• or the first (or last) object selected during a multi-object selection

So the "Align to:" dropdown shouldn't be greyed out at any time for vertical and horizontal alignment.
It's been requested many times by users to not greying out the "Align to:" dropdown and to revert back to the initial behavior from V1 when this wasn't the case.

 

[Lorox]

4 minutes ago, bbrother said:

So the "Align to:" dropdown shouldn't be greyed out at any time for vertical and horizontal alignment.
It's been requested many times by users to not greying out the "Align to:" dropdown and to revert back to the initial behavior from V1 when this wasn't the case.

Ah, look here! I actually didn't remember clearly that it had been different with v1 than it is with v2, but that's possibly the reason why I felt so irritated when the dropdown was greyed out as long as I din't make the actual choice of what alignment I was going to do...

Anyway, I actually do understand both lines of thought leading to greying the dropdown out or not – maybe eventually it's just the way you're "wired" personally which lets you prefer one or the other.

That being said, once you know what order of actions you have to take, it is in fact very easy to see if you’re getting what you want as the live preview immediately kicks in and you can always choose another operation or just opt out if it isn't at all what you wanted.

[Pšenda]

22 minutes ago, bbrother said:

revert back to the initial behavior from V1 when this wasn't the case.

Hmm (V1.10.5)

 

23 minutes ago, bbrother said:

So the "Align to:" dropdown shouldn't be greyed out at any time for vertical and horizontal alignment.

It's never grayed out - as far as "horizontal or vertical alignment" is selected!

[Pšenda]

13 minutes ago, Lorox said:

once you know what order of actions you have to take

I think the order of actions is clearly and logically given by the ordering of the controls (from top to bottom), so it shouldn't be that big of a problem.

The problem in the control logic results from the fact that this dialog serves not only to align the elements - where the order of Operation selection (alignment type) and the AlignTo parameter could easily be reversed, but also to distribute the elements, so it is necessary to specify the type of operation first (that's why it is listed in the first place), and only then enable the setting of the necessary parameters for the selected operation.

[bbrother]

1 hour ago, Pšenda said:

Hmm (V1.10.5)

The behaviour was changed somehere between 1.7 or 1.8 versions if i remember.

 

1 hour ago, Pšenda said:

It's never grayed out - as far as "horizontal or vertical alignment" is selected!

You didn't understood. It should be possible to set the "Align to:" parameter first before even selecting the alignment type.

The software can't to predict the intention of the user about what type of operation he will perform (Alignment, distribution) when opening the Alignment dropdown panel. So that's why the "Align to:" dropdown with crucial parameters should be always availabe to set at any time of the process of vertical/horizontal alignment, while for distribution/spacing  the changes in this parameter and dropdown should take no effect, be ignored.

@PšendaHere you have a screen recording from ADe v1.7.
It's posible to set  the "Align To:" parameter first, before selecting alignment type.

 

Edited March 6 by bbrother
Included screen recording from ADe v1.7 Alignment behaviour

[R C-R]

2 hours ago, bbrother said:

... while for distribution/spacing  the changes in this parameter and dropdown should take no effect, be ignored.

i might have this wrong but as I (vaguely) remember it, this was changed in response to several users saying they were confused because this parameter was not greyed out when it would have no effect.

So basically, either behavior will please some & displease others.

[bbrother]

1 hour ago, R C-R said:

i might have this wrong but as I (vaguely) remember it, this was changed in response to several users saying they were confused because this parameter was not greyed out when it would have no effect.

Didn't saw any post about such complaints or request and I searched thru a lot of post/comments about the alignment. 
On the other hand there is no problem with finding posts with complaints about the change and request to revert to old behaviour.

Here is one of several post where you can find many negative feedback on this change↓

So you can say with much confidence that the alignment didn't required a change because:

• it worked well and nobody asked for it,
• before the change users haved more freedoom, they could use the "Align to:" how they want. 
• they didn't need to watch in the live preview something that is aligning up to the last selected "Align to" option because they can't set up the parameters first (like it was in earlier versions) and then press the Align method.

It was a change from something that worked well to something worse without any reason.

 

[R C-R]

11 minutes ago, bbrother said:

Didn't saw any post about such complaints or request and I searched thru a lot of post/comments about the alignment. 

How far back did you look? IIRC, this behavior was changed around V 1.5 or so, & the reason given was as I mentioned that some users were reporting that it wasn't doing anything, believing it to be a bug.

[bbrother]

6 minutes ago, R C-R said:

the reason given was as I mentioned that some users were reporting that it wasn't doing anything, believing it to be a bug

Can you provide a link to posts complaining about this problem to support your theory or did you read it from the stars?

"Align to" is a parameter that determines how alignment is performed, especially how things are aligned in relation to other things.
Claiming that it wasn't doing anything and that this is a bug is nonsense and no argument for change.

[R C-R]

7 minutes ago, bbrother said:

Claiming that it wasn't doing anything and that this is a bug is nonsense and no argument for change.

Isn't the 'wasn't doing anything' comment what you meant by your " ... while for distribution/spacing  the changes in this parameter and dropdown should take no effect, be ignored"?

Also, this is not my 'theory,' just something as I said I vaguely remember being mentioned somewhere by one of the staff in response to why it was changed. I'm not going to speand any time looking for it but my guess is that it was somewhere in the V1 bugs topics.

[Alfred]

5 minutes ago, R C-R said:

Also, this is not my 'theory,' just something as I said I vaguely remember being mentioned somewhere by one of the staff in response to why it was changed.

 

 

[bbrother]

5 hours ago, R C-R said:

Also, this is not my 'theory,' just something as I said I vaguely remember being mentioned somewhere by one of the staff in response to why it was changed.

@R C-R @Alfred,

I am aware of the staff's explanation as to why this change was made. As I mentioned earlier, I have read and analyzed almost everything about this decision and user feedback on this on the forum.

This is how they explained it:

Quote

This is not actually a regression, but the intended behaviour. Selecting an "Align to" option before selecting the method would not make sense, so having it greyed out is expected. The problem is on Windows, where you can select an "Align to" before doing anything else - not sure why one would need this, as it does not do anything anyways. 

---------------------

After internal discussions it's been decided that Mac has the correct behaviour, and it's actually Windows that is incorrect

And now the facts:

On the one hand, you all have numerous specific arguments from users, which outnumber those who are confused, why this change is bad, it annoys them, it is unintuitive, illogical and that they want to go back to the way it was before.

On the other hand, we have Serif's decision to introduce the change, allegedly based on one very questionable argument, namely, not even a few users claimed that "Align to:" does nothing and is confusing for them, which clearly means that they understand what a parameter is, and how it differs from an action.

And now this questionable argument is used to defend what many users believe was a bad decision to make a change for the worse. This is just ridiculous.

If user has problem how to understand what is parameter and what is action, what's the difference and how you use a parameter dropdown with an action button in Alignment panel the staff should explained it to them and not change well-made functionality for worse one. In fact, the first implementation by the Windows development team was the best, they did a good job unlike the devs from MacOS and due to the numerous arguments given it should be reverted back to.

 

[R C-R]

7 hours ago, bbrother said:

And now the facts:

One of which is people seldom mention changes they do not find annoying or illogical while those who do are much more likely to complain about them. So there is not much anyone can conclude from these supposedly "numerous" users complaining about the change, which at best represent a tiny fraction of the user base.

Regardless, if you feel so strongly about this, all you can do is make a feature request in the appropriate forum or quit using/recommending the Affinity apps. The rest is just a waste of time.

[bbrother]

7 minutes ago, R C-R said:

So there is not much anyone can conclude from these supposedly "numerous" users complaining about the change, which at best represent a tiny fraction of the user base.

However, these supposedly "numerous" users complaining about the change, including me, were able to present concrete substantive arguments for restoring the original functionality, while those who don't care about it cannot do it.

I joined other users who asked for the previous operation to be restored. I tried to draw attention to this matter, but unfortunately there was no response.
Maybe when the user base starts to shrink, when enough stupid decisions like this accumulate, Serif will take its customers more seriously.

 

25 minutes ago, R C-R said:

Regardless, if you feel so strongly about this, all you can do is make a feature request in the appropriate forum or quit using/recommending the Affinity apps.

This advice is as stupid as changing the "Align to:" behavior and claiming that it works in a logical and intuitive way after introducing the change.
Why submit a feature request when the point is to restore the original functionality of an long existing feature.

[R C-R]

3 minutes ago, bbrother said:

However, these supposedly "numerous" users complaining about the change, including me, were able to present concrete substantive arguments for restoring the original functionality, while those who don't care about it cannot do it.

The alternative argument that the old behavior did not make sense is just as substantive as yours. 

8 minutes ago, bbrother said:

Why submit a feature request when the point is to restore the original functionality of an long existing feature.

 For the obvious reason that just complaining about it here in the Questions forum will do nothing useful to convince the developers to revert to the previous behavior. As you just said, there has been no response from them here & there likely never will be.

As an aside, I think that it is extremely unlikely that the user base will shrink because of changes like this one. Most users seem not to care enough even to comment about it.

[bbrother]

8 minutes ago, R C-R said:

For the obvious reason that just complaining about it here in the Questions forum will do nothing useful to convince the developers to revert to the previous behavior. As you just said, there has been no response from them here & there likely never will be.

I wrote about it not only here, but also in other relevant threads , including on the beta forums.

 

11 minutes ago, R C-R said:

As an aside, I think that it is extremely unlikely that the user base will shrink because of changes like this one. Most users seem not to care enough even to comment about it.

You'll be surprised at the negative impact even such subtle changes have on the number of users, especially if they accumulate more over time.
There are more stupid UI and UX changes, not just the "Align To:" we're talking about specifically in this thread.

[R C-R]

1 hour ago, bbrother said:

You'll be surprised at the negative impact even such subtle changes have on the number of users, especially if they accumulate more over time.

I would be quite surprised if small changes like this one will have any significant impact one way or another on those who are deciding if buying and/or using one or more of the Affinity apps is worth it for them.

It is obvious you are frustrated because the developers have not agreed with you & the others who think this is a change for the worse. That's understandable but ranting about it in the forums, which seems like what this is devolving into, is not going to do any good, so I have to wonder why you keep at it.

In short, can you explain what you hope to accomplish that your other posts have failed to do about this change?

[Lorox]

I had no idea what would follow when I started this topic with that little problem I had with aligning objects with the new v2.4 feature...

Guys, please don’t get that upset with this – effectively – minor issue that actually seems to be more or less subject to personal preference. What counts is that we actually can get ever more things nicely done in Affinity. And comfortably aligning objects is one of those. Now that I know how it's done I personally don't really care if I have to select that alignment icon or another first to access the dropdown for more specific control. Come on, as to this  feature it's just one button to push before getting the desired result!

But yes: there are other things in Affinity which are entirely not there yet and which I (and many others, I guess) dearly miss – like blends, image tracing, real(!) vector brushes and the ability to adjust stroke widths at specific places directly at specific points on the path and not via some abstract curve on/in a detached pallette (to name just a few). Let the devs devote their time and effort to these instead of the minor issue this thread seems to have turned to!

[Pšenda]

17 hours ago, Lorox said:

Now that I know how it's done

I am happy, if my post contributed to the understanding of the control method/logic.
Affinity simply does some things differently, and if the user tries to understand and accept this logic - like you - then he is ultimately satisfied.