We are live, and thank you!!!

[v_kyr]

1 hour ago, anto said:

Why not make the patching process more flexible? Every 2-3 days, for example, instead of weeks, they don't need to be tested.

Adding periodically patches (...and I mean just smaller patches and not always a whole build here) might be a way to try out, especially for getting rid of some important & essiential bugs quickly. But testing before what you distribute to the world is always essential too here!

Edited September 27, 2023 by v_kyr

[Return]

4 minutes ago, v_kyr said:

But testing before what you distribute to the world is always essential too here!

But the testers are in a bubble that doesn't relate to real world usage and that's why with every beta and release version there's something wrong.
If you put it out there it would surface right away.
 

[v_kyr]

6 minutes ago, Return said:

If you put it out there it would surface right away.

Where to the public aka world? - Sure, but then you would also risk to maybe distribute patches, which might make an app completely unusable, for those who use them business wise. Though such real world test usage scenarios on the other hand, of course would very quickly show up any possible app problems then.

[Return]

23 minutes ago, v_kyr said:

for those who use them business wise.

They are also more keen on getting the bugs out of the way as it will cost them money so it may(must) be patched sooner.
 

23 minutes ago, v_kyr said:

which might make an app completely unusable

That would mean that there's something fundamentally wrong and no patch would resolve that.
 

23 minutes ago, v_kyr said:

also risk

It is a part of running a business " If you can't stand the heat, stay out of the kitchen" 

 

 

[v_kyr]

28 minutes ago, Return said:

They are also more keen on getting the bugs out of the way as it will cost them money so it may(must) be patched sooner.
 

If so, they can try this method and if the practice proves successful (i.e. well received by users), they can keep it.

[Return]

9 minutes ago, v_kyr said:

If so, they can try this method and if the practice proves successful (i.e. well received by users), they can keep it.

Unlikely, although the seemingly more open character in the beta forum, Serif is still very noncommunicative overall.
If regularly patches would occur they would need to up Q&A on the forums and Devs need to address more time on bugfixing instead of reinventing the wheel aka make their own adaptation of the common toolset in these kind of programs.
That's a business decision to make but it would also mean less marketing and promotion as why would you spend a dime on patches.
Being authentic or unique is admirable but just trying to be different in so many aspects of expected usage, isn't.

 

[anto]

30 minutes ago, Return said:

why would you spend a dime on patches

i mean patches that are minimalistic, local, that do not affect the operation of other functions.

[Return]

Just now, anto said:

i mean patches that are minimalistic,

I know what you meant.

5 minutes ago, anto said:

that do not affect the operation of other functions.

But it will always affect other functions.
You can only spend time on either one and if that means that new features are getting on hold due to bugfixing, no new features are coming out.
Therefore there's nothing to promote and you will lose interest>no sales>no income>no development>no new features.
The business model is like many in the world>create hype>get noticed>sell>fix small parts>hype again with additional options packed with some other fixes>sell>fix small parts, etc.
Serif is a business and it needs to sell for its income/profit and for its development and also needs money for marketing to keep the hype going, to make more sales.
So unlikely regular patching are going to be, unless it is really ffing all users.


 

[anto]

7 minutes ago, Return said:

that new features are getting on hold due to bugfixing, no new features are coming out

I mean small patches between big betas. That is, while there is no beta version, patches are released every 3-4 days, a week. When there is a beta version, then all the attention is directed to the beta.

[Return]

Again I would like to have that too but again it is unlikely.
But I rather be proven wrong by Serif.

[debraspicher]

7 hours ago, anto said:

I mean small patches between big betas. That is, while there is no beta version, patches are released every 3-4 days, a week. When there is a beta version, then all the attention is directed to the beta.

Something like that would be nice and arguably they already do that already when wrapping up. I don't care so much how it gets done as long as the issues get fixed.

[Petar Petrenko]

Thanks guys for all your effort building such great apps and making our jobs easier and joyful.

[CM0]

On 9/27/2023 at 7:31 AM, Return said:

if that means that new features are getting on hold due to bugfixing

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 :-)

[Intuos5]

On 9/27/2023 at 1:42 PM, anto said:

I mean small patches between big betas. That is, while there is no beta version, patches are released every 3-4 days, a week. When there is a beta version, then all the attention is directed to the beta.

In general, there should be more time to test and bug fix for release candidates, Beta testers get a week or two of production use to see if there are any breaking bugs. The release canditate to me is the real Beta, everything prior is more of an alpha version. I always feel like I need to wait for the patch after each major release before I can use the software as intended. So I am a little hesitant to use the Beta versions for production work, unless a major breaking bug in a release version was fixed in the Beta.

TL;DR: There are too many breaking bugs left when the release version hits, which then affects customers who expect everything to work fine. And that's not great marketing wise. I'm not sure whether that's due to insufficient testing or insufficient time allocated to crush bugs.

[Bryan Rieger]

While I do eagerly anticipate new features, I am finding that with each release the Affinity apps are becoming less stable, and generally more buggy. Software will always have bugs, but there comes a point where the number of bugs that impact users on a day-to-day basis becomes so great that continuing to use the tools becomes a liability for many—irregardless of cost. I keep seeing reports of corrupted files and lost work, which has really eroded my confidence in the apps. In 25+ years of using Adobe software I can count the number of times I have actually lost work on one hand (YMMV). With Affinity, it's happened half a dozen times to me in the past six months (the iPad apps are especially bad for it). What's more is that many of the bugs are difficult to reproduce consistently so you don't report them right away, but then the bugs that are reported often don't get fixed for years (if ever).

I do wish Serif would communicate to users some of the challenges they are having, and how they are actively looking to rectify them. I'd much rather have the next few releases be dedicated to fixing many of the long-standing issues than pushing out new buggy features on top of all of the existing bugs, and partially-implemented features. 

Technical debt adds up fast.

As for the beta releases. Testing from users should not replace a rigorous, in-house testing process—something that currently feels lacking within Serif. I stopped running the beta releases long ago as there is still no ability to back-save document versions (I often double-click files to open them, and something will always get opened/saved in the beta), and many of the reported issues were never addressed. Endlessly logging issues with developers that are never resolved isn't progress.

I had always hoped that v2 would have been the chance for Serif to build a modern, stable foundation on which to take the Affinity apps in amazing new directions. Instead, from my perspective, it feels as if things have gone backwards. The UI/UX in v2 is just awful compared to v1 (especially on iPad), and the day-to-day issues and constant workarounds are becoming increasingly frustrating.

[Wanesty]

9 hours ago, Bryan Rieger said:

I'd much rather have the next few releases be dedicated to fixing many of the long-standing issues than pushing out new buggy features on top of all of the existing bugs.

BUT THINK OF THE PROFIT !!

joke aside yes this is an issue that plagues most for-profit products and companies.

Adobe is no stranger to this, their whole suite, at least for the part they started developing instead of just buying them off to someone else, are victim of this, features holding together with duct tape, a frankenstein monster of code, different languages and half implemented stuff.

 

mods please do correct me if i'm wrong, but i believe Affinity 1 is simply an improved version of PhotoPlus, DrawPlus and PagePlus. And yes, it do feel like some stuff were rewritten and improved especially the UI and features but affinity's goal was to be a MacOS product, making said testing easier thanks to the more limited range of products, cpu and gpu.

porting it to iPad, with a new type of user interaction with the tools were probably the hardest due to it's (from my understanding) kind of archaic codebase.

i'm not making excuses for anything here, just trying to find an explanation as to why affinity v2 didn't get as much love as it needed

[Bryan Rieger]

50 minutes ago, Wanesty said:

…please do correct me if i'm wrong, but i believe Affinity 1 is simply an improved version of PhotoPlus, DrawPlus and PagePlus. And yes, it do feel like some stuff were rewritten and improved especially the UI and features but affinity's goal was to be a MacOS product, making said testing easier thanks to the more limited range of products, cpu and gpu.

Actually, in Serif's own words:

Quote

So, we decided to start again, turning our focus to the development of a lean, super-fast suite of apps for creative professionals using Mac, Windows and iPad. This pivot meant throwing away all the old code and creating the Affinity range from scratch. 

So the Affinity range was designed to be "a lean, super-fast suite of apps for creative professionals using Mac, Windows and iPad", and none of the old code was used in creating the Affinity range of apps. I also recall hearing that v2 was a rewrite of v1, but I can't find a source currently to verify it.

There was no archaic code based to navigate, nor were they limited by porting the old user experience to the iPad. 

[Wanesty]

9 minutes ago, Bryan Rieger said:

So the Affinity range is designed to be "a lean, super-fast suite of apps for creative professionals using Mac, Windows and iPad", and none of the old code was used in creating the Affinity range of apps.

weird that they chose to use use dx9 for the ui and old dotnet for the windows installer.. ahah... anyway...
(please mods do tell me if i'm making stuff up but i don't think i am.. :)

 

Edit:

nothing wrong with reusing working stuff.. especially since the v1 is fairly good overall and Bryan's post was about the v2 anyway

my issue however is like.. don't claim you didn't lmao

Edited October 3, 2023 by Wanesty

[PaulEC]

10 hours ago, Bryan Rieger said:

I'd much rather have the next few releases be dedicated to fixing many of the long-standing issues than pushing out new buggy features on top of all of the existing bugs.

44 minutes ago, Wanesty said:

BUT THINK OF THE PROFIT !!

joke aside yes this is an issue that plagues most for-profit products and companies.

I’m assuming that by “the next few releases” we mean releases of updates to v2, not upgrades to v3, v4 etc, which, going on the first two versions, could be years apart. Obviously very few people would want to pay to upgrade to new versions if there were only bug fixes without any new features. However, I can’t see that concentrating on bug fixes in the next few updates to v2 would be a problem. These are not paid for anyway, so the only affect on profits might be to help sales to new customers by providing a more stable product.

[Bryan Rieger]

7 minutes ago, PaulEC said:

I’m assuming that by “the next few releases” we mean releases of updates to v2, not upgrades to v3, v4 etc, which, going on the first two versions, could be years apart. 

Yeah, I was referring to the 2.x cycle.

[Wanesty]

15 minutes ago, PaulEC said:

However, I can’t see that concentrating on bug fixes in the next few updates to v2 would be a problem. These are not paid for anyway, so the only affect on profits might be to help sales to new customers by providing a more stable product.

companies want a stable product, professional individual usually want more features: a lot of people switched to an unstable, beta version of photoshop only to have access to ai features.

It comes down to who Serif value most, and as said previously adobe kinda already made up their mind on the question x)

edit:
adobe also know they'll sell regardless tho..

Edited October 3, 2023 by Wanesty

[PaulEC]

I find it hard to believe that most people, professional or not, don’t care how “buggy” the software is that they use, as long as endless new features are being constantly added! This was one of the problems with the old Plus/legacy Serif software, endless new “bells and whistles” being added in order to have new selling points, while long standing, often serious, bugs just dragged on from release to release. In the end they scrapped the whole range and developed Affinity instead. I really would not like to see Affinity going the same way: the software getting so buggy that it becomes almost unusable, while endless, new features (often with their own new bugs!) are added in the hope of a few more sales!

[Wanesty]

4 minutes ago, PaulEC said:

I find it hard to believe that most people, professional or not, don’t care how “buggy” the software is that they use,

i prefer to use my gpu to render stuff in blender even tho there's a small chance it will crash my graphics driver (bug report of it if you're curious)..

in my experience people don't mind trading some stability for features/performances, this is not a good thing, especially since for-profit software companies will abuse this.

[CM0]

18 minutes ago, PaulEC said:

professional or not, don’t care how “buggy” the software is that they use, as long as endless new features are being constantly added!

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.

[debraspicher]

3 hours ago, CM0 said:

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.