Layer states - usability feedback for layer name or regex interface

[Bit Disappointed]

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.

[walt.farrell]

8 hours ago, Bit Arts said:

First of all, the inputfield here should NOT be case sensitive:

Clarification, please: The input field should not be case sensitive, or the search that is run should not be case sensitive?

[Bit Disappointed]

2 hours ago, walt.farrell said:

Clarification, please: The input field should not be case sensitive, or the search that is run should not be case sensitive?

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. 🙂 

[debraspicher]

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.

[Bit Disappointed]

I believe it's just come this far here without Serif evaluating it, simply because it hasn't been discovered or tested. But as I have written elsewhere, it is bad enough. They should be able to correct this, but in more complex functionality in a different task, they could have encountered a surprise, where the fundamental architecture would need to be adjusted as late as in the beta phase (now), and then everything becomes compromises or delays from there.

Shall we guess that regex has case sensitive as default and that everything has been done with lowercase letters until this point. 

Yes, so now that we are talking about preparation, I hope Serif performance evaluates these queries and the show/hide execution on very, very large documents, and not just smaller ones. I have generally seen ok performance, but also got the beach ball on macOS a couple of times with a combo of settings.