Bit Dissapointed

An issue raised in this thread ("Layer states Select and Options icons are hard to see due to small size") has now been reported to the developers by the testing team (Ref: AF-1758). Thank you very much for reporting this issue to us.

I also believe key object should be highlighted in a less subtle way. I also don't think Serif should be ashamed of actually writing key object in small font next to the object in this case. Perhaps not as visually clear as regular bounds (press . key on a rotated object), but the concept of being clearer in complex programs is sometimes welcome.
There are places in the interface where one looks too much like the other.
A key icon in the layers panel doesn't make sense. Firstly, it is very discreet and contrastless, far away from the selection, and secondly, the key object is not a property of the layer, but a property of the selection. In addition, we have a lock icon that symbolizes locked and a key that symbolizes locked, unlock the lock? 
But that aside, the key object should be highlighted in a meaningful way in the selection, exactly where you select and click.

Yes, that was what I was getting at in my first response, but I didn't want to give the forum a lecture on excellence and aesthetics in algorithms if you could do with less. Thank you for your detailed response, I completely agree with you.
Smart Mode is the layman's aid for tracing, but it is certainly not the tool for aesthetes or professionals. I prefer to draw curves myself, as I am trained now, and thus also know that the fewer nodes, the better. Actually, creating perfect aesthetic curves quickly and effortlessly is not straightforward, and that is precisely what the curvature tool assists with.
Smart Mode is for one specific need, I hope Serif does not think it also covers the other(s).
Smart Nodes in Affinity Designer: The use of Smart Nodes tends to create curves that are smooth and require less tweaking, which can be particularly useful for designers who prefer a more streamlined workflow. The automatic adjustments of curves can lead to a more efficient design process but might sometimes offer less control for intricate curve manipulation. Affinity Designer uses an algorithm for its Smart Nodes, which are designed to simplify the process of creating and editing curves. When you manipulate a Smart Node, the software automatically adjusts the adjoining curves to maintain a smooth and natural transition. The algorithm prioritizes ease of use and efficiency, aiming to reduce the need for manual adjustments of Bezier handles.
Curvature Tool in Illustrator: With the Curvature Tool, the aesthetic outcome is often characterized by very smooth and flowing lines. This tool is particularly adept at creating organic shapes and smooth transitions in paths. The Curvature Tool provides a balance between simplicity and control, allowing for the creation of complex curves with fewer adjustments. Adobe Illustrator's Curvature Tool algorithm is centered around intuitively creating and adjusting curves with minimal control points. It automatically generates and adjusts Bezier curves as you add points to a path, focusing on creating smooth, flowing curves that naturally progress through each point. The tool is designed to predict and implement the most aesthetically pleasing curve through the points you define, reducing the complexity of traditional Bezier curve manipulation.

I also believe key object should be highlighted in a less subtle way. I also don't think Serif should be ashamed of actually writing key object in small font next to the object in this case. Perhaps not as visually clear as regular bounds (press . key on a rotated object), but the concept of being clearer in complex programs is sometimes welcome.
There are places in the interface where one looks too much like the other.
A key icon in the layers panel doesn't make sense. Firstly, it is very discreet and contrastless, far away from the selection, and secondly, the key object is not a property of the layer, but a property of the selection. In addition, we have a lock icon that symbolizes locked and a key that symbolizes locked, unlock the lock? 
But that aside, the key object should be highlighted in a meaningful way in the selection, exactly where you select and click.

I also believe key object should be highlighted in a less subtle way. I also don't think Serif should be ashamed of actually writing key object in small font next to the object in this case. Perhaps not as visually clear as regular bounds (press . key on a rotated object), but the concept of being clearer in complex programs is sometimes welcome.
There are places in the interface where one looks too much like the other.
A key icon in the layers panel doesn't make sense. Firstly, it is very discreet and contrastless, far away from the selection, and secondly, the key object is not a property of the layer, but a property of the selection. In addition, we have a lock icon that symbolizes locked and a key that symbolizes locked, unlock the lock? 
But that aside, the key object should be highlighted in a meaningful way in the selection, exactly where you select and click.

Well said. This is quite a bit of UI regression, IMHO.

I also believe key object should be highlighted in a less subtle way. I also don't think Serif should be ashamed of actually writing key object in small font next to the object in this case. Perhaps not as visually clear as regular bounds (press . key on a rotated object), but the concept of being clearer in complex programs is sometimes welcome.
There are places in the interface where one looks too much like the other.
A key icon in the layers panel doesn't make sense. Firstly, it is very discreet and contrastless, far away from the selection, and secondly, the key object is not a property of the layer, but a property of the selection. In addition, we have a lock icon that symbolizes locked and a key that symbolizes locked, unlock the lock? 
But that aside, the key object should be highlighted in a meaningful way in the selection, exactly where you select and click.

I would think the usecase which would be the most common are searches where one needs to find all "instances of" a word being used, etc. That would not require a case-sensitive search. It could be in any part of a string and there may be a habit where the user is capitalizing the very beginning of a Layer. For whatever reason, readability (relative to them how they scan/seek Layers panel) or maybe there is some practical reasoning relative to Export Persona, Artboards, etc that requires certain naming conventions. Say they are exporting those assets for a website, program, or some other instance. But they still want to find all "instances of" a generic term...

I can think of my reason in my own usage where I will occasionally make 12"x12"s, but I export per Layer:



I utilize the Layer name to output a /folder with the various formats organized within into their own /folder. So, in a way, it gets in the way of my workflow to have to remember... oh I capitalized a word here, but not here maybe... when I may be exporting a graphic that has a quote, for instance. I would be just capitalizing the first letter just because it's not a title per say. Or, maybe, I'm required to follow a naming convention outside of the program itself when exporting, so it needs to be case-sensitive for that purpose, but only in that instance and I wouldn't need to write it out that way globally across the document since I'm just naming individual design elements.

The other issue, is its forcing the user to work within a certain naming convention from the get-go to make the most use of this functionality. In my opinion, it's the least user friendly option. If it has to be disabled with a flag notation, etc, it's certainly not user friendly. A toggle option is fine, I guess. Though I still recommend case-sensitivity should never be the default. It's just an additional snafu to introduce to the user when they're utilizing the functionality frequently. Options should be there to help make a functionality more useful, not more tedious. Making case-sensitive an option is making it more utilitarian... whereas, forcing it and requiring the user to turn it off is more like here's another curve ball you have to remember every single time you make global searches on a term, which is often.

Anyway, just my thoughts.

Thank you for the kind and thoughtful responses. I would still like to push back that the smart mode (or smart nodes) are not the same thing—the curvature tool in Illustrator produces curves that have perfect curvature continuity. You can see this if you analyze the continuity of the curves that are created with the curvature tool. There is only one solvable position of handles for a given position of path points on a given curve. The smart nodes does not work in this fashion—I'm not entirely sure how it determines where to place handles for a given set of path points, but the result ends up being less aesthetically pleasing and requires more manual positioning, IMO. Thank you for the discussion and consideration. 

Designer 2.4.0 (2222), macOS
There is a lack of consistency in the use of colours for actions in the states panel, which I have commented on in another post.
Here, Apply appears white, and thus the other two options appear inactive. But all three can be activated, so it is quite misleading and incorrect colour usage.

Thanks for this one - it's a REAL treat for those of us working with hierarchies of objects.
But there doesn't seem to be a way to do this on the iPad? 😞

The Serif bot is still a significant improvement over how it was done before. At least now a clutter of threads will get updated with new information when a fix is finally made. There would be a chance with a forum search to find the bot information for it.

As to bugs you are most concerned with, I recommend to bookmark them and to keep bumping them to check status. That's all you really can do. I have a significant list of some I've reported and a good number of high traffic members here also seem to know most reported bugs that are yet fixed.


Keeping an exhaustive list is probably unintuitive if they're using an official bug tracker. It's better to expose that to the public in some way (with some filtering and necessary design decisions made, I guess) than for poor Patrick/etc to have to retype/C&P that laboriously every week or so one by one. I would not take that job, personally. It's better to have a real time updating system anyway than a slowly updated list. The bot is actually more useful compared to that because it will go into the threads of users and report directly the change in status, whereas only some of us will check for a main list. Unless they put something official in the forum header... then everyone can check that?

Reading @Ash's comments in the initial thread about the addition of Layer States to Designer and Publisher I get the impression Serif have numerous additional features they plan to introduce to enhance its functionality and I'm pretty sure the feedback they receive during Beta testing goes a long way to inform the feature set that is eventually added so hopefully, whatever those additional features turn out to be, they will go a long way towards giving you the feature set you'd ideally like, though, as you mention, it sounds as though Custom States perhaps already give you around 90% of what you need...
Thanks for the image, yes, I can imagine that would involve one complex layer panel...

The low contrast ratio between the panel's background and other elements such as buttons, drop-down lists, icons, input fields is already a serious problem occurring generally throughout the application especially after the interface changes in V2. In V1, thanks to the shaded edges that gave the effect of embossing, the contrast was not the best, but it was not as much of a problem as after the changes in V2.
 
I don't particularly see anything wrong with the icons being gray. This is a common practice with dark interface themes. This is again a contrast issue between normal, disabled, active, hover state.
 
You've probably already noticed that in Affinity the background of some icons also changes when you hover. But not sure why this is not applied to all icons only selectively without consistency.  When it comes to font size, font line height in input fields, padding, margins, alignment of elements, there are also many shortcomings. But I think you know all this because I noticed from your comments that you have experience in the topic of UI design. I also have a couple of years of experience in this matter myself, and I catch all these mistakes right away.
 

Designer 2.4.0 (2222), macOS

The low contrast ratio plus the unfathomably small size of these three small icons makes them inaccessible, i.e. not visible enough for the elderly or people with visual impairments. They must appear to be dot-sized on high-resolution screens. The Select icon is particularly small.
It is also unhelpful and wrong that icons/buttons that can be used are so grey that they appear as functions that cannot currently be used because Serif wants them to appear white when clicked. See here from Photoshop how the default is for usable and non-usable functions:

When you hover these buttons in Photoshop they are highligthed with a darker background instead:
 
I assume that the varying and incorrect font sizes and the problems with parts of the letters being cut off at the bottom are on the Serif to do list.
 

Designer 2.4.0 (2222) macOS
Thumbnails are only updated when I fold Captured states in and out. Since thumbnails are important feedback, they need to be updated after clicking 'Update'.

I can only answer based on my own needs. My biggest concern with layer states is that these functionalities are made based on theoretical assumptions by employees, not user testing and lots of input. The few here from the forum are not enough. We saw it with insertion target, where Serif was "struggling" to imagine a scenario, but in 5 seconds in here alone got "Are you kidding? We need it!". It's way too late to get this input in a beta phase, contrary to what many people think, and it's too little input you get in here. Anyway, it looks half-baked as it appears and works, but let's see how far Serif can get it before release.
No, it's too crazy and extensive to name a huge number of layers based on regex needs. Not a great activity in the creative process either 🙂 But as I said, I think my exact needs can be handled with captured layers that can even be updated, which must be exactly the scenario they are intended for. A query could simply be created so that it doesn't need to be updated when I create new content. Not a disaster in my work - but I cannot answer for other types of customers.
If one day you can assign a shortcut to a query or captured state, then I'm really content.
So I think my feedback on this should give Serif something to think about for the other usage scenarios and what creates business value, which I hope they have an overview of and thought about since layer states came on the agenda for the first "lets code this thing" meetings.
But thanks for the feedback. 🙂 To give you a conceptual idea of how extensive the layer structure I'm using and how tedious a job naming to regex will be, imagine drawing this in an extensive vector version where I need a number of root layers that each have a lot of layers, objects and groups underneath. 
Psssst the image is extreme - but you get the general idea:

I must add that for my purpose, captured states is perhaps an obvious method, at least applicable here and now, although it is a somewhat static method and just a snapshot of the document here and now, so I still think that what I have described above is extremely relevant for queries.

Designer 2.4.0 (2222), macOS
I'm trying to use layer states to show or hide layers with sublayers or groups. In other words, complex content.
When I select 'Show hide others', which I am trying to use to create a query that shows one layer and hides others, all sublayers, groups and objects under the layer I actually want to show are deselected.
Are we missing an option like "Include subelements" or whatever it should be labeled.

The search executed. As in Visual Studio Code, I should by default search case-insensitive, so if I search for MADness it also matches MADNESS or madness. Case sensitive search should be an active choice; it's a rare scenario that someone would want to use case sensitive search.
No one expects case sensitive search, that's my guess. And imagine how many have named layers "Square" and "square" without thinking about it, and end up getting results they don't understand.
To really drive my point home, it's generally one of the biggest battlegrounds for carelessness I know, people's use of upper and lowercase whether they're filling out fields or sending emails, job applications, and the like, so I can only imagine that case insensitive search as the default is the 100% correct choice for this field. 🙂 

Designer 2.4.0 (2222), macOS
The interface for using regex - or not - need a hand.
First of all, the inputfield here should NOT be case sensitive:

Here's some loose UI inspiration from Visual Studio Code, which I personally use from time to time to tidy up CSS. But VS Code has gone on to become a successful editor, so it's got a lot going for it.
Here I have enabled regex, but unlike regex' default, Microsoft has turned the default upside down, so you have to ENABLE case sensitive search (Aa), which I have mentioned is probably an exception requirement.
The icons mean
(Aa) Search case sensitive (ab underlined) Match whole word (.*) Use regular expressions Notice how compact and easy to use Microsoft has made a search bar and easy access to regex built into an incredibly small space, including red feedback.

As I understand it, /i-like parameters for the entire expression are suitable for buttons like the ones above next to the search string. Advantages: users do not need to know or remember the specific syntax of regex. They can simply check a checkbox to activate or deactivate a particular search function. It makes the function accessible to a broader audience, including those who may not be technically proficient. It should also reduce the risk of errors in entering regex expressions, which can be complex and error-prone for inexperienced users.

Hello Nikkwong and welcome to the forum!
For those who aren’t familiar with the tool we’re talking about, here’s a video demonstrating how to use the curvature tool in Adobe Illustrator. I recommend watching this video to understand how it works and what it can do [Subtitles are available in several languages].
Don’t hesitate to share your experiences or questions about this tool or its equivalent in other graphic design software such as Affinity Designer.

Hi @Nikkwong
Affinity has the interesting and actually quite useful smart nodes. The difference between them and the curvature tool in Illustrator is probably that the Adobe algorithm tries to draw very simple yet beautiful curves, and that you preview them as you draw, where smart nodes give a slightly less aesthetic result if you are bezier savvy, but still good. Unfortunately, I find that I have to correct a number of them afterwards and don't always save time and achieve what I want. So for this kind of thing, a curvature tool would probably suit me just fine. I'm so experienced that I prefer to draw curves myself when using Affinity. 
But try it yourself with smart nodes in Affinity - better than the traditional never ending debates in here. Configure the pen tool like this:

And try on this:

 

Designer 2.4.0 (2222), macOS
The interface for using regex - or not - need a hand.
First of all, the inputfield here should NOT be case sensitive:

Here's some loose UI inspiration from Visual Studio Code, which I personally use from time to time to tidy up CSS. But VS Code has gone on to become a successful editor, so it's got a lot going for it.
Here I have enabled regex, but unlike regex' default, Microsoft has turned the default upside down, so you have to ENABLE case sensitive search (Aa), which I have mentioned is probably an exception requirement.
The icons mean
(Aa) Search case sensitive (ab underlined) Match whole word (.*) Use regular expressions Notice how compact and easy to use Microsoft has made a search bar and easy access to regex built into an incredibly small space, including red feedback.

As I understand it, /i-like parameters for the entire expression are suitable for buttons like the ones above next to the search string. Advantages: users do not need to know or remember the specific syntax of regex. They can simply check a checkbox to activate or deactivate a particular search function. It makes the function accessible to a broader audience, including those who may not be technically proficient. It should also reduce the risk of errors in entering regex expressions, which can be complex and error-prone for inexperienced users.

Designer 2.4.0 (2222), macOS

The low contrast ratio plus the unfathomably small size of these three small icons makes them inaccessible, i.e. not visible enough for the elderly or people with visual impairments. They must appear to be dot-sized on high-resolution screens. The Select icon is particularly small.
It is also unhelpful and wrong that icons/buttons that can be used are so grey that they appear as functions that cannot currently be used because Serif wants them to appear white when clicked. See here from Photoshop how the default is for usable and non-usable functions:

When you hover these buttons in Photoshop they are highligthed with a darker background instead:
 
I assume that the varying and incorrect font sizes and the problems with parts of the letters being cut off at the bottom are on the Serif to do list.