Affinity Designer Customer Beta (1.6 - Beta 1)

[A_B_C]

Hi steve_m,

 

wow … great to see these improvements! Your draft featuring the increased contrast is definitely better from a usability point of view. Would you mind sharing a non-Retina version of that screen shot? I would guess that a whole lot of people still have non-Retina screens on their desktops …  :)

 

But this is, once again, a proof that Serif is different from other software companies! You are listening to the users …   :)

 

Thanks, Alex

[retrograde]

 I would guess that a whole lot of people still have non-Retina screens on their desktops …  :)

 

You would be correct there. :-)

 

... and yes I'll second it. Thanks Affinity for being open to accommodating/listening to your users, what an interesting concept. ;-)

[anon1]

Amazing how they changed the color of a background after two years, great customer feedback ;) thank you for listening for such a long time and finally reacting!

 

... sorry but this fix was due for a long time, really wonder why this is such a big deal to expose one color choice to the user.

 

(If a color chooser is too much freedom for the user in your opinion, make an option to use the same color as is used for the layer highlight color, the System highlight color)

 

Anyhow let's move on to more important fixes in the next betas.

[MattP]

Hi MBd, sorry you see it that way - but as Steve has tried to suggest, it's more about the fact that we have hundreds of assets and custom controls in our application, and each one has been recreated to work properly on a light background - so it's not as simple as just exposing a colour choice... you must surely know from us by now that if something matters to our users and we can enable it quickly, we'll pop it in there - this has actually been a long process to get to where we are now, for both Steve and for our Creative team...

 

Edited to add: I think I've actually mentioned this a number of times before, but it's worth stating again... Sometimes, the things that you'd think are easy as an observer, are in fact very involved and slow to implement and sometimes the things that you might think are nightmarishly complicated are actually a few hours worth of work. Development is an unpredictable thing...

[anon1]

the tools panel is a pretty limited space so a color change of that background thing....well

 

sure development is unpredictable at times but it is not an excuse for everything

if everything depends on everything and some changes take forever it is sure enough also a result of bad code design and because I think your code is pretty new it should be less of an issue, especially for UI assets that do not depend on complex code interaction (on/off)

 

"and each one has been recreated to work properly on a light background"

well I hope you saw my screenshots one page ago and agree that this does not behave properly yet, but this should not be a big issue left over I guess

 

these are also these things like hiding studio panels is not sticky after a restart (or after light/ dark ui changes)...anyway we'll see where this 1.6 takes us, I find the communication about this update from the beginning of 1.5 till now too defensive/ not up front. and even now at the start of the beta cycle nobody knows about some sort of schedule/ expected feature map (except the one we missed for easter)

 

sure enough you can tell that I do not intend to trash this software and I also devote some time into helping others use the features that are already implemented and intend to keep it that way 

 

cheers 

[R C-R]

R C-R - glad you like it!

 

As Matt says, I'm experimenting with some code at the moment and am interested to see if people like the way it looks.

For me, it would be enough if the button & selected tool background was not even quite as dark as in your screenshot, like somewhere in the 40 to 50% black region. I don't mind if I can't pick a custom grayscale level, & I believe it would be a bad idea to allow picking custom colors that could be the same as some of the tool or button icon colors. As long as there is enough contrast between the surrounding panel or menubar background & the selected tool or enabled button that it is reasonably easy to see the difference, I would be a happy camper.

[anon1]

-

[R C-R]

... but as Steve has tried to suggest, it's more about the fact that we have hundreds of assets and custom controls in our application, and each one has been recreated to work properly on a light background - so it's not as simple as just exposing a colour choice... 

"Hundreds" is an understatement. There are around 3100 (!!!) png image files in /Applications/Affinity Designer Beta.app/Contents/Resources alone. Even ignoring the large ones for splash screens, example art, help resources, & so on, there are about 2000 or so that can appear somewhere in the UI. According to a Finder search, 882 of them have "lightui" in their filenames, suggesting each of them has been designed specifically for the new Light UI.

 

A few more statistics for those interested in such things: There are also currently 32 png files used just for the monochrome UI; & about 70 for displaying Personas (for enabled & disabled states, light & dark UI, & 1X & 2X screen resolutions) but as yet none specifically for the monochrome UI.

 

So yeah, there is nothing simple about any of this.

[anon1]

-

[R C-R]

just give them the option to highlight the box in a color they want

Consider what would happen if users had this option & the color they selected was the same or nearly the same as part or all of one or more tool or button icons. It isn't enough just to make the selection obvious; it is equally important not obscure what is selected.

 

Think about how many different icons there are that should meet this requirement. Just in the Draw Persona alone, I count 37 different Tool panel icons, & about 15 more in the other personas. I did not bother to count all the button icons that can be included if users customize the main Toolbar, the ones that appear in the Context toolbar for different tools, or those that appear in various Studio panels. Add to that all the items require three display states (enabled but not selected, selected, & disabled).

 

If you are suggesting that in effect users should be free to set the UI to make it harder for them to see everything they need to see, I do not think that would meet any reasonable standard of good UI design or be a step in the right direction.

[anon1]

-

[MattP]

"Edited to add: I think I've actually mentioned this a number of times before, but it's worth stating again... Sometimes, the things that you'd think are easy as an observer, are in fact very involved and slow to implement and sometimes the things that you might think are nightmarishly complicated are actually a few hours worth of work. Development is an unpredictable thing..."

 

 

this is sth. I do not get in any way e.g.

 

instead of experimenting and trashing it it would have been a 100% safe bet to implement a search for the layers panel e.g.

or touch that expand stroke thing

"I haven't touched expand stroke or divide yet, so there should be no difference (in theory at least!)"

or the mesh fill tool where you said "I know exactly what to type" in the first or second ezine

or a bleed preview box, just a box which you had working during the 1.4 cycle already as far as I remember 

or an arrow head line ending

....this is really weird to me 

 

this is just out of my world of understanding 

This is exactly why I said what I said. Things which seem obvious to an observer, yet if they were easy or obvious they would already be done. The problem with most of the things on your list of things there is... they all need me to do them - and I've been working pretty much all day, every single day doing other things. I have had no part in the light UI, hence why this feature has appeared before the others on that list. I also had nothing to do with the Mirror application, which again was implemented by another developer so did not interfere with whether the items on that list would've been implemented or not...

 

It's not just about what work there is to do, it's also about which developer is appropriate for each feature...

 

I do understand what you're saying, and I do appreciate that it's coming from the perspective of a keen user so I'm not taking it in the wrong way, I'm just trying to explain that we're not just making random decisions and doing them in a strange order - there's method to the apparent madness...

[retrograde]

We really appreciate everything Matt!

 

Might it help to explain or lay out some of that method? Don't know. I for one would rather you guys stay the course and forge ahead keeping things moving in a forward direction. 

 

Just don't forget all of my feature requests. ;-)

[anon1]

-

[A_B_C]

I fear people all to easily underestimate the complexities of programming work. But apart from that, there is another point to consider. Honestly, would it make sense, for instance, just to throw in a search field for the layers panel? What we would really need, in my opinion, is a more complex search engine that would allow entering properties of objects, searching for text attributes … and that would feature, particularly in the latter case, a find and replace function as well as the option of using regular expressions (think of Publisher).

 

Now imagine, we had a simple search field in the layers panel at the moment. Then people would start using it, making a habit of using it, presumably flooding the forum with complaints about its insufficiency, and later on, it would nonetheless have to be replaced by something better. Then people would again start complaing because they already had become accustomed to something that was intended to be temporary from the outset. The same goes for arrowheads and the like.

 

In short, I believe app development is not only about managing complexities, but also about strategic decisions. It does not make sense to waste time adding insufficient functionality to an application that has to be purged out later on with utmost care. To be sure, purging is no less difficult than adding. And I think the latest additions to Designer and Photo are pretty well-conceived and a huge step forward in usability. The new font selector is amazing, blurry icons notwithstanding …  ;)

 

Hope that makes sense …  :)

[anon1]

-

[steve_m]

No problem Alex, 

 

I'll upload a non-retina screenshot later on today.

 

Steve

 

Hi steve_m,

 

wow … great to see these improvements! Your draft featuring the increased contrast is definitely better from a usability point of view. Would you mind sharing a non-Retina version of that screen shot? I would guess that a whole lot of people still have non-Retina screens on their desktops …  :)

 

But this is, once again, a proof that Serif is different from other software companies! You are listening to the users …   :)

 

Thanks, Alex

[steve_m]

For me, it would be enough if the button & selected tool background was not even quite as dark as in your screenshot, like somewhere in the 40 to 50% black region. I don't mind if I can't pick a custom grayscale level, & I believe it would be a bad idea to allow picking custom colors that could be the same as some of the tool or button icon colors. As long as there is enough contrast between the surrounding panel or menubar background & the selected tool or enabled button that it is reasonably easy to see the difference, I would be a happy camper.

 

Thanks again for your feedback, R C-R.

[Oval]

a long process to get to where we are now, for both Steve and for our Creative team...

 

I'm just trying to explain that we're not just making random decisions and doing them in a strange order - there's method to the apparent madness...

 

“Experimenting with some code”?! Designing needs a concept before going public. Out of all reason why Serif that pledges perfection still uses elements that are not centered (optically).

 

 

[MattP]

To put that in context, Steve did say that he was 'experimenting' right now - because he's trying to change our design to be more like customers are asking for... We had a design of our own before going public - and Steve implemented it. There was no lack of foresight here.. The only reason this thread is still being responded to is either by people who are happy we're listening and responding to criticism, or those that are criticising because it wasn't right first time - but design is something which is personal so it's unlikely we'd hit the sweet-spot without customer response... we liked it, hence why we implemented it...

 

Those icons are poorly aligned, I'm happy to agree there - and they can (and should) be fixed, but this is a task for our Creative department, not for Steve. We'll make sure to pass it along, thanks :)

[AshTeriyaki]

 

“Experimenting with some code”?! Designing needs a concept before going public. Out of all reason why Serif that pledges perfection still uses elements that are not centered (optically).

 

 

 

Minor misalignments of icons, in a beta software release, affecting no one? I kinda see the point you're making, but c'mon, you must have something better to do with your time. 

 

Solid beta chaps, would like to see some polish and also (Mirroring comments from some others) some refinements to some of the existing tools and some wee workflow enhancements. A few nice little bugs squashed and the new font search is rather nice. Keep on keepin' on.

[VIPStephan]

Minor misalignments of icons, in a beta software release, affecting no one? I kinda see the point you're making, but c'mon, you must have something better to do with your time.

And to be fair, the artboard icon is actually centered, it’s just not symmetric. And so is the pen icon.

Yes, theoretically one could add some transparent pixels to make it appear more centered even though it would technically be off-center but looking at the actual UI of the application I wouldn’t notice these misalignments with my bare eyes, so that’s kind of nit-picking at the moment.

[steve_m]

Hi steve_m,

 

wow … great to see these improvements! Your draft featuring the increased contrast is definitely better from a usability point of view. Would you mind sharing a non-Retina version of that screen shot? I would guess that a whole lot of people still have non-Retina screens on their desktops …  :)

 

But this is, once again, a proof that Serif is different from other software companies! You are listening to the users …   :)

 

Thanks, Alex

 

Hi Alex, here's a non-retina version of the screenshot.

 

Steve

[Oval]

Sorry for reporting issues. Seems that this is not welcome. Even if the “Creative department” perhaps is more interested in art than in perfection, it is only one example of problems that still exist since years and clients are not interested in responsibilities.

 

 

Those icons are poorly aligned, I'm happy to agree there - and they can (and should) be fixed, but this is a task for our Creative department, not for Steve. We'll make sure to pass it along, thanks :)

 

I kinda see the point you're making, but c'mon, you must have something better to do with your time.

 

AshTeriyaki, seems you don’t want others to have a better and faster perceptible UI. That people don’t notice problems does not mean that they don’t have effects (on usability). 

[A_B_C]

Thank you, Steve!

 

Yes, that looks so much better. I love the increased contrast. Much in the line what R C-R said, I wonder if a little less contrast would also do, but in general, I have the impression now that a button I engaged is actually pressed and not greyed out. It makes such a difference.

 

Actually, I have no idea how these different part of the user interface are compiled from basic elements, but I assume all the background greys can be adjusted by code strings. So since we were discussing the contrast ratio of buttons and background, I wonder if it would be possible to make some tweaks elsewhere as well. I must confess, I still have problems with the text-related panels.

 

Take the Character panel, for instance. The colors of the bars where my blue arrows are pointing at are very similar, though the first one divides the panel (it opens a sub-category of Character panel), while the second one divides the sidebar. I must confess, I really have issues to see at first glance where the Character panel ends and the next ones start. The hierarchies are not particularly clear to my eyes. Would it make sense to differentiate here a little more as well? Maybe you could make the background of the title bar of the panels (lower arrow) a little darker? Would that make sense? I hope you can see what I am after …

 

Thank you again!  :)

Alex