Swap the Before/After view in Develop?

[SoCalDave]

Hi there,

Trying to swap the before/after view so that the after view is on the right and the before is on the left.

I read that there was a swap setting in 'syncing', but I sure as heck can't find it.

Thanks,

David

[Ron P.]

There should be 3 buttons in a group about in the top-center. The one on the right is Swap.

[SoCalDave]

Maybe it's a 2.0 bug; it's not working for me unless I'm incorrect on what the swap icon does. 

Shouldn't that be moving "Before" to the left and "After" to the right?

[Ron P.]

It does swap the display, just not the labels. I think that could be a bug, unknown what the Developers intended.

[SoCalDave]

Thanks for verifying Ron, thought I was doing something wrong!

David

[Dan C]

Hi @SoCalDave,

Thanks for your report and our sincerest apologies for the delayed response here. We are exceptionally busy following the release of V2 and we thank you for your continued patience and understanding here.

I can confirm this behaviour is 'ByDesign' according to our developers:

Quote

You're not swapping the views, but literally swapping what is "before" with what is "after" then continuing from there, hence the labels do not change.
You are only ever editing the "after" view and sometimes you want to swap that over (so you can compare further changes with the changes you have made so far).

I hope this clears things up!

[Phillustrator]

I'd still like to have the option of 'Before' before and 'After' after, rather than 'Before' after 'After' and before 'Before', 'After'; after all, before must come before after and after can only come after before. I hope that clears things up!

It may be by design, but for whom is it designed? The explanation given in the quote only makes both 'Swap' (and Sync tools) more confusing to use

[R C-R]

4 hours ago, Phillustrator said:

I'd still like to have the option of 'Before' before and 'After' after, rather than 'Before' after 'After' and before 'Before', 'After'; after all, before must come before after and after can only come after before. I hope that clears things up!

Sorry but I could not follow that at all. Are you talking about the split view display order or something else?

[Phillustrator]

Yes, as per the original post, there is no option in Develop to order the split view as Before > After (the default is After > Before and is fixed). That, apparently, is by design, but the point I was making was that it would be nice to have the option and design is the issue, not the explanation.

The sentence you quoted was slightly facetious in that the sentence makes sense, by design, but is difficult to understand. Sorry about that.

The explanation provided to the original post:

"You're not swapping the views, but literally swapping what is "before" with what is "after" then continuing from there, hence the labels do not change.
You are only ever editing the "after" view and sometimes you want to swap that over (so you can compare further changes with the changes you have made so far). "

 

 

[Ambivalent100]

I would like to bump this post up again. 
It would be incredible helpful for the sake of accessibility to habe an option to "swap the views". For many users its natural to have the original on the left and see the edits on the right.

A simple toggle switch would not hurt anyone 👍

[GarryP]

32 minutes ago, Ambivalent100 said:

I would like to bump this post up again.

Welcome to the forums @Ambivalent100

‘Bumping’ a post in a Questions section of the forum isn’t likely to do anything other than bring it to the attention of some forum members.

As has been mentioned above, the current situation is “ByDesign” so, if you would like it to change, then you can ‘add your voice’ to an existing thread in the Feedback and Suggestions section regarding this, if one exists, or create your own if one doesn’t exist.

[Alfred]

2 hours ago, Ambivalent100 said:

For many users its natural to have the original on the left and see the edits on the right.

I’ve never known before-and-after monitoring to be known as anything other than ‘A/B monitoring’, but the ‘before’ obviously comes first! The user should be able to choose between two different display configurations.

[PaulEC]

2 hours ago, GarryP said:

the current situation is “By Design”

I do wish Serif would not use this as an excuse for bad design!

A lot of people would prefer before and after images to be the other way around, I can't believe it would be a major problem to provide a toggle to change it. As with many things in Affinity, it would be so much better to let the user choose the option that they prefer, rather than being forced to accept whatever option a "developer" decided should be "by design"!

[Pšenda]

49 minutes ago, PaulEC said:

I do wish Serif would not use this as an excuse for bad design!

I think anyone who has seen a timeline graph at least once in their life must be amazed at the ingenuity of this design.

 

[Alfred]

1 hour ago, PaulEC said:

I do wish Serif would not use this as an excuse for bad design!

When used correctly, the “By Design” issue resolution should only ever be applied to a bug report, indicating that the observed behaviour is intended (rather than being the result of a bug). For an improvement suggestion, it’s completely spurious to write it off as “By Design” since the user is acknowledging that it’s meant (from the developers’ point of view) to be the way it is but they’re suggesting that the behaviour could be improved. A rejected improvement suggestion should be resolved as “Postponed” or (if the developers are being obstinate) “Won’t Fix”.

[Pšenda]

5 hours ago, Alfred said:

“Won’t Fix”.

Academically only - the term "Fix" is used when it is a correction of a bug, which as you yourself admitted, is not this case. In case of rejection of requests, it should be "Don't accepted", or several years of silence 🙂

[R C-R]

I think to the developers "by design" just means "not a bug," as in 'this is not due to a bug in the code.' It doesn't say anything about if it is a good or bad design choice, or even if it will be changed or improved in some future update.

Basically, a non-committal, intentionally vague answer.

[Alfred]

3 hours ago, Pšenda said:

Academically only - the term "Fix" is used when it is a correction of a bug

In a bug-tracking context, “Won’t Fix” means a reported bug won’t be fixed (perhaps because the only possible fixes would break something else). In a wider context where non-bug issues are being tracked, “Won’t Fix” could mean “We could improve the behaviour here, but we can’t afford to commit the necessary resources to this issue.”

[R C-R]

1 minute ago, Alfred said:

In a bug-tracking context, “Won’t Fix” means a reported bug won’t be fixed (perhaps because the only possible fixes would break something else).

But they never say that about reported & confirmed bugs.

[Alfred]

3 hours ago, R C-R said:

I think to the developers "by design" just means "not a bug," as in 'this is not due to a bug in the code.'

That’s what I understand it to mean. As I observed earlier, it doesn’t apply to improvement issues (where no one is saying the code is buggy).

[Alfred]

2 minutes ago, R C-R said:

But they never say that about reported & confirmed bugs.

I don’t think it would look good if they were to say such things in public!

[Pšenda]

18 minutes ago, Alfred said:

I don’t think it would look good if they were to say such things in public!

And what is the "Bug forum" about?

[R C-R]

23 minutes ago, Alfred said:

I don’t think it would look good if they were to say such things in public!

That does not mean it is something that won't be fixed if & when they can get to it.

[Meliora spero]

Remember: a decision made by an unqualified non-UX person is by design, which really means it’s not by design at all, but by guesswork — or maybe even by accident.

In a responsible company, the debate isn’t “bug or feature,” but rather: what’s the impact on the customer? And then they prioritize a fix accordingly — and in time. It’s all about impact and prioritization. You know, in real companies.

Serif has its own style: implement something wrong, rushed, poorly, or confusing — and then let it fossilize over ten years at the customers’ expense. In the meantime, they can spend their time debating it in forums. That’s double the cost — and not very creative. It’s expensive for you to be a customer of Serif and Canva.

[jmwellborn]

Parkinson’s Law of triviality:  at a corporate board meeting the members spend the most time arguing about the size of the wastebaskets.