CM0

Not sure if anyone is doing that, but yes that would not be appropriate. As someone who has led large development teams myself and worked on very large projects. It is really impossible to know from the outside what are the internal inhibitors to greater efficiency and product reliability.
Usually such matters are result of leadership, depending on size of company, but often upper management and executives. They are ultimately responsible for the operations. You can almost be certain the devs and test teams want the issues fixed as well. But they probably don't get to set the ultimate priorities.

I think they do care. But marketing works on those who don't know about the bugs.
The irony is that the bugs tend to hurt the most dedicated users. The ones doing the most advanced work. For example, not many here use Artboards. I use exclusively artboards, so most don't encounter the unbelievable number of bugs that are unique to artboards. Almost all of the live filters are broken on artboards. I've been meaning to write something up about it, but haven't had the time and my motivations are low as so far no bugs I've ever opened have been fixed as of yet.

This is sort of where I am as well. Why keep reiterating on the same set of issues that go unfixed. I spend less time contributing as a result.
 
I agree with the view rigorous testing is must, user and internal testing. However, I think another angle is being missed:
It is possible that the testing team does their job adequately but the reports just continue to mount.
If the reports are not being dealt with in a timely manner, then any other input they may provide in terms of overall usability/completeness go ignored as well. That really handicaps their capabilities.
I suggest this because 1) The easiest assumption is testing is inadequate. It's not a bad one but it may not be true. One can write reports and provide feedback all day long, but if it is ignored, doing more testing would not resolve anything.
2) We know the testing team pays attention because testing teammembers do post on the board quite regularly and are active with feedback.
It is rather unfair to throw them under the bus for bug issues when they are only the frontlines. They can't say much beyond it is reported and we have checked that the bug is valid. For all we know, their reporting work is quite vigorous, but either nothing is done or not enough follow through to help get to a solution to actually close the issue.
3) To be frank, there are features added in that are or were left unfinished and unpolished for quite some time. That doesn't scream lack of testing to me. Especially when so many of the issues are already quite obvious between user reports and staff reports with reported workarounds discovered between both ends. That suggests to me rather their work is underutilized.
 
This is where the beta program doesn't go far enough. It gives us a sense of momentum, because we can finally see features and improvements that are much needed. This is a great thing and definitely nothing to complain over. However, when important pain points are not addressed in a timely manner, we end up with a different problem. Especially as new bugs are added and left in that degrades everyday functionality. In my case, I still have to regularly minimize the program when doing masking work with a paintbrush because the UI becomes locked. Also changing brushes doesn't always apply correctly. I get brush settings trying to anticipate this by tapping multiple times.
Downgrading is often not an option because of the haphazard way new featuresets are applied and critical/usability-related bugs are left in into the next point release.
If 2.2, as an example, was the most polished, productive and stable the suite ever was.. then I can see that as rewarding users for their patience when work on 2.3  begins as they improve their progress. They have a stable release that they can depend on and the option to hold off at least until the next point release passes a polished state. Most understand bugs happen and that the only way through that sometimes is to keep updating until they find the issue.
Imho, they should continue 2.2. Maybe make it a habit that feature updates have a refinement cycle (2 cycle, add features... major refine). That focuses solely on knocking back reports and mission critical design flaws, building upon a solid UI/UX design philosophy, etc.

I think they do care. But marketing works on those who don't know about the bugs.
The irony is that the bugs tend to hurt the most dedicated users. The ones doing the most advanced work. For example, not many here use Artboards. I use exclusively artboards, so most don't encounter the unbelievable number of bugs that are unique to artboards. Almost all of the live filters are broken on artboards. I've been meaning to write something up about it, but haven't had the time and my motivations are low as so far no bugs I've ever opened have been fixed as of yet.

I think this view significantly diminishes the value and importance of bugfixes. Bugfixing in effect is like having new features as it often means you can now do something you could not before. You can market and promote these as improvements just as well and should.
Based on the activity of the "Serif Info Bot" recently, seems there has been a lot of bug fixes. This is great! I hope there are many more.
I dream of the day I will finally see "Serif Info Bot" comment on one of my submissions :-)

I think they do care. But marketing works on those who don't know about the bugs.
The irony is that the bugs tend to hurt the most dedicated users. The ones doing the most advanced work. For example, not many here use Artboards. I use exclusively artboards, so most don't encounter the unbelievable number of bugs that are unique to artboards. Almost all of the live filters are broken on artboards. I've been meaning to write something up about it, but haven't had the time and my motivations are low as so far no bugs I've ever opened have been fixed as of yet.

I think they do care. But marketing works on those who don't know about the bugs.
The irony is that the bugs tend to hurt the most dedicated users. The ones doing the most advanced work. For example, not many here use Artboards. I use exclusively artboards, so most don't encounter the unbelievable number of bugs that are unique to artboards. Almost all of the live filters are broken on artboards. I've been meaning to write something up about it, but haven't had the time and my motivations are low as so far no bugs I've ever opened have been fixed as of yet.

I think they do care. But marketing works on those who don't know about the bugs.
The irony is that the bugs tend to hurt the most dedicated users. The ones doing the most advanced work. For example, not many here use Artboards. I use exclusively artboards, so most don't encounter the unbelievable number of bugs that are unique to artboards. Almost all of the live filters are broken on artboards. I've been meaning to write something up about it, but haven't had the time and my motivations are low as so far no bugs I've ever opened have been fixed as of yet.

True, but Affinity at least has potential opportunity here by not already having an API they have complete flexibility in design, in that they can observe what is happening in the world with AI and the use cases and ensure that such integration will be possible, highly efficient and rich in capability.

lol, yes the buzzword economy. Nothing delivered what it promised. Usually it just delivered the exact opposite, complexity that only hurt your business.
I remember turning simple FTP batch scripts that cost nothing to execute into monsters of BPEL SOAP services just because executives wanted to promote advanced tool and business process adoption. A script that took someone a few hours to write turned into half a year project for an entire team. Madness.

I think this view significantly diminishes the value and importance of bugfixes. Bugfixing in effect is like having new features as it often means you can now do something you could not before. You can market and promote these as improvements just as well and should.
Based on the activity of the "Serif Info Bot" recently, seems there has been a lot of bug fixes. This is great! I hope there are many more.
I dream of the day I will finally see "Serif Info Bot" comment on one of my submissions :-)

Adobe's edge is quickly evaporating as well. Meta is now embedding AI generation directly into their social media apps and many other standalone AI generators are adding their own generative fill. The usefulness in regards to productivity can not be ignored for the users, but the business model for sustainability is going to be very challenging as any advantage is quickly lost. Thus is the nature of rapid AI development.
Therefore, my opinion in these regards is that it would not necessarily be beneficial for Affinity to spend its limited resources in a futile effort to keep up with its own implementation. They also would have to deal with as-of-yet-unresolved legal issues.
However, their scripting API would provide the necessary integration which avoids these limitations. 3rd parties and open source communities are going to be far faster at rapid innovation and keeping up with AI.

Adobe's edge is quickly evaporating as well. Meta is now embedding AI generation directly into their social media apps and many other standalone AI generators are adding their own generative fill. The usefulness in regards to productivity can not be ignored for the users, but the business model for sustainability is going to be very challenging as any advantage is quickly lost. Thus is the nature of rapid AI development.
Therefore, my opinion in these regards is that it would not necessarily be beneficial for Affinity to spend its limited resources in a futile effort to keep up with its own implementation. They also would have to deal with as-of-yet-unresolved legal issues.
However, their scripting API would provide the necessary integration which avoids these limitations. 3rd parties and open source communities are going to be far faster at rapid innovation and keeping up with AI.

Adobe's edge is quickly evaporating as well. Meta is now embedding AI generation directly into their social media apps and many other standalone AI generators are adding their own generative fill. The usefulness in regards to productivity can not be ignored for the users, but the business model for sustainability is going to be very challenging as any advantage is quickly lost. Thus is the nature of rapid AI development.
Therefore, my opinion in these regards is that it would not necessarily be beneficial for Affinity to spend its limited resources in a futile effort to keep up with its own implementation. They also would have to deal with as-of-yet-unresolved legal issues.
However, their scripting API would provide the necessary integration which avoids these limitations. 3rd parties and open source communities are going to be far faster at rapid innovation and keeping up with AI.

The content fill is truly a revolutionary level game changer for compositing work. The difference between the tools has mostly been manageable, but AI is providing a separation in capabilities that is enormous.
However, as fast as they can be implemented, they can also be copied. As openAI recently stated, there is no longer a moat to the capabilities you build. Anyone can copy them rather easily.
IMO, the quickest path to these capabilities is for Affinity to focus on finishing their plugin/scripting capabilities. They are a small team compared to Adobe, so getting the API out there allows Affinity to leverage the community and 3rd parties to greatly expand Affinity's capabilities including integrations with AI.

I think this view significantly diminishes the value and importance of bugfixes. Bugfixing in effect is like having new features as it often means you can now do something you could not before. You can market and promote these as improvements just as well and should.
Based on the activity of the "Serif Info Bot" recently, seems there has been a lot of bug fixes. This is great! I hope there are many more.
I dream of the day I will finally see "Serif Info Bot" comment on one of my submissions :-)

I think this view significantly diminishes the value and importance of bugfixes. Bugfixing in effect is like having new features as it often means you can now do something you could not before. You can market and promote these as improvements just as well and should.
Based on the activity of the "Serif Info Bot" recently, seems there has been a lot of bug fixes. This is great! I hope there are many more.
I dream of the day I will finally see "Serif Info Bot" comment on one of my submissions :-)

Hi All,
We have just made 2.2 live across all App Stores and our website. As always, the feedback we have received from you all during this beta has been an incredible help in both shaping the new features as well as squashing many bugs!
The build we have released is the same as RC3 (build 2005), meaning for the time being whether you use the latest beta version or switch to using the release version they are the same. If you anticipate taking part in the next beta you may wish to keep your current beta version installed, as this will be updated on auto update when a new beta is available. This will either be a 2.2 patch if we feel one is needed, or moving straight onto a 2.3 beta.
It would be impossible for us to do what we do without your support, and I just wanted to say a huge thanks for everything you have contributed to this release.
All the best,
Ash

Hi All,
I have logged this with our developers to be improved in a future update
Thanks
C

I agree 100% with @CM0. This is not good implementation and I hope, that like with other features that have been added and are being worked on, that further work can and will be done to fully realize the potential of these features. I understand there are technical limitations, but it should not be the deciding factor behind any design decision where user experience is concerned.

I clearly stated above why this is not a work around. It is impossible to work on a high resolution document and have correct perspective of the output. I need to see the forest, not the trees. Furthermore, I have no idea why this position is even defended as it is undesirable in any context. If it has been stated many times, then clearly this is an important issue as it has been brought up many times. Why not advocate for the improvement of Affinity?

Zooming in 100% isn't very helpful with higher resolution projects. We can never confirm from the outside what is intended or working as designed if it is not documented.
As pointed out previously, it may be by design, but the design is flawed as other applications do not exhibit this behavior and furthermore under no circumstances is this a desirable behavior. As a developer, I know the perspective of trying to protect a flawed design and not call it a bug. As a developer am also aware of the terrible customer relationship that causes as the customer does not care as to why their use case is broken, it is simply broken and dismissing it as working as designed is being tone-deaf to the customer's needs.
Therefore, it would be in the best interest of everyone to fix this undesirable behavior.

Thank you. Let me just clarify what I would hope could happen in this case. This issue, as seen by Affinity, is not a bug; however, it is also not a "nice to have" as seen by users as it is an issue that is breaking the user experience. Behavior that is misleading in a way that some could say is displaying wrong or incorrect information. Any user who experiences this will immediately think "bug" or something is broken.
To simply categorize or place it alongside all the other new feature requests seems out of place. 
So yes, if features aren't tracked, then developers simply browse features as they have time, which I'm certain is extremely limited. This request was likely long forgotten with its importance to users. I am fine with letting the developers come up with a solution. Overhaul, new view mode or something else etc. 
Suggestion:
I suppose a suggestion for Affinity to please consider would be a new tag for some features that are in the classification of "breaking user experiences" or "unexpected behaviors". I think this might be the optimal middle ground as it allows developers to find and consider such issues and prioritize them separately from the "nice to have" new features. This way, as a user, I would at least feel that the information I have delivered has been correctly understood as to its implications whether it is ever implemented or not :-)

Also as previously explained this is not a work around. There is no reality in which the UI lies to the user that is desirable or would not be seen as a bug to users. I understand this is by design, but it is severely impactful in a negative way to our work and dismissing its importance that it is by design is extraordinary frustrating to users.
Previously you had expressed interest in solving this issue and I appreciated that interest.
Exactly how does a request ever get picked up by developers? That request has indicated it is impactful to many users. Has this been logged for development into their tracking system? Often we are told development will take a look at certain issues, is development even aware of this discussion?

I understand what you have said. All of this feedback will now be viewed once someone assigns the ticket and looks at the linked threads.
For what it's worth, I would also prefer to not have to view my project at 100% or do a merge etc. I was impressed with what I saw in Krita with its live filters and I would hope that one day we could implement something similar