Jump to content
You must now use your email address to sign in [click for more info] ×

New Beta


Recommended Posts

  • Staff

Just to add my voice to this, I think there must be a balance.  There is no software that is bug-free ( we are not talking about bug-ridden software here).  I believe that Serif Affinity needs to review their strategy on this and you have proven in the past that you are more that capable in this area. I don't know what necessitate the change in strategy but I am sure you have your reasons and I respect that.

 

I watched Andy and his team working tirelessly to address and fix issues in this forum that won my heart  and convinced me to pay more attention Serif Affinity.   There must certainly be a balance on releasing features that address issues that professional users are having with the current release of the software versus waiting to completely fix every possible bug before making a grand release of the software for beta testing.  The whole idea of beta testing, in my humble opinion, is for the community to help identify possible bugs for fixing and because we all don't think alike, there is bound to be a user whose workflow identifies something that may turn out to be a bug in the long run (or may be not).

 

I also believe that Affinity's strength in this area has been with engaging with the community to help fix issues.  From a software engineering perspective, we all can agree that there is no single way of achieving a particular solution (we all have developed our favoured style of coding, as an example).  By the same measure, it's well known within the software industry that how a developer/software manufacturer thinks may generally be out of sync with their users thinking.  That is to say that the workflow steps or processes that some users may employ in utilising certain feature(s) of a software product may not always match the intention of design decision of the developer or software manufacturer.  We have seen several evidence in this forum, as an example.

 

In this light, I believe that since Serif Affinity has managed so well in winning the hearts of professional users who are willing to disconnect themselves from the rule of the Adobe empire and join the Serif family, it is in the best interest (business decision) to address issues or bugs raise with the Affinity product suite not only effectively but in a timely manner so as to continue to grow and maintain their new market share.  Remember professionals designers, artists, photographers and the likes may be relying on your software to earn their daily living. 

 

So whiles generally, it makes sense to wait until every possible bug is identified and fixed before release, please use your willing users (some of whom are these professionals)  to test and identify possible bugs in these new features that you are working on to fix them, make the product rock solid.  In the process, you make your customers most happy and they may be your mouthpiece to grow your customer base through word of mouth and referrals.

 

Nana

 

Hi Nana,

 

Thanks for your comments and your support, I do just want to say that the reason we don't release until we're happy is not so we can declare 'this is the right way to do things and it's bug free' when we release a new beta with new features, but is instead to make sure that we don't anger the community by changing our minds... As an example, I'm still not completely happy with the way Symbols are working in my development branch of Designer - this is why I'm typing on a Saturday night to try to fix them. If I released the feature to you now to take a look at, and then on Monday decided I'd just implemented them the wrong way, I would break your documents on the next beta release - worse, I might break any document you happen to have touched since using the beta with my old version of Symbols that is no longer supported. I can get around it by maintaining both the old way AND the new way, but then there's a lot of bloat and dead code hanging around forever to support something that should never have been there. We typically write something at least 3 times before settling on a way to achieve everything we wanted! So this is why there hasn't been a release yet. When we say we're happy, we're really saying that architecturally we're sure that the feature is implemented in fundamentally the right way - everything about how the user uses the feature or how it is presented can be changed without impacting on these architectural decisions, so we are safe to release a beta at that point.

 

Hope that makes sense?

Matt

Link to comment
Share on other sites

And Elements has a reasonable RAW convertor. Plugins and RAW, along with a DAM are, imo, Affinity's big weaknesses at the moment but then nobody said this would be a quick and easy path to tread. Take your point re 8 bit though.

Yes.

 

I did not mention the DAM because I do not use the one at all; neither in Elements nor in my workflow tool. That makes me blind sometimes to the fact that others not only do use a DAM, but have the strong need for one.

Link to comment
Share on other sites

Hi Nana,

 

Thanks for your comments and your support, I do just want to say that the reason we don't release until we're happy is not so we can declare 'this is the right way to do things and it's bug free' when we release a new beta with new features, but is instead to make sure that we don't anger the community by changing our minds... As an example, I'm still not completely happy with the way Symbols are working in my development branch of Designer - this is why I'm typing on a Saturday night to try to fix them. If I released the feature to you now to take a look at, and then on Monday decided I'd just implemented them the wrong way, I would break your documents on the next beta release - worse, I might break any document you happen to have touched since using the beta with my old version of Symbols that is no longer supported. I can get around it by maintaining both the old way AND the new way, but then there's a lot of bloat and dead code hanging around forever to support something that should never have been there. We typically write something at least 3 times before settling on a way to achieve everything we wanted! So this is why there hasn't been a release yet. When we say we're happy, we're really saying that architecturally we're sure that the feature is implemented in fundamentally the right way - everything about how the user uses the feature or how it is presented can be changed without impacting on these architectural decisions, so we are safe to release a beta at that point.

 

Hope that makes sense?

Matt

 

Thanks Matt.  

 

You make really good and convincing points in your response and that clarifies for me the challenges that are delaying the release.    I do understand the importance of architecturally getting things right before releasing it to the public.  

 

Thank you so much for you dedication to working on this product and I hope you don't spend all weekend writing code :)   Have a good weekend.

 

Nana

Link to comment
Share on other sites

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.