Jump to content
You must now use your email address to sign in [click for more info] ×
Our response time is longer than usual currently. We're working to answer users as quickly as possible and thank you for your continued patience.

Layer states - usability feedback for layer name or regex interface


Recommended Posts

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:

image.png.2859a554d6a6ef75e5c804cd0b1378f6.png

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.

image.png.e678eeca88ab89501b652281738af9c2.png

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.

I simply no longer believe that there are any professional graphic designers here. Everything follows suit. Just everything.

 

Link to comment
Share on other sites

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?

-- Walt
Designer, Photo, and Publisher V1 and V2 at latest retail and beta releases
PC:
    Desktop:  Windows 11 Pro, version 23H2, 64GB memory, AMD Ryzen 9 5900 12-Core @ 3.00 GHz, NVIDIA GeForce RTX 3090 

    Laptop:  Windows 11 Pro, version 23H2, 32GB memory, Intel Core i7-10750H @ 2.60GHz, Intel UHD Graphics Comet Lake GT2 and NVIDIA GeForce RTX 3070 Laptop GPU.
iPad:  iPad Pro M1, 12.9": iPadOS 17.5, Apple Pencil 2, Magic Keyboard 
Mac:  2023 M2 MacBook Air 15", 16GB memory, macOS Sonoma 14.5

Link to comment
Share on other sites

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

I simply no longer believe that there are any professional graphic designers here. Everything follows suit. Just everything.

 

Link to comment
Share on other sites

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:

image.png.ffa369dc73708df3d326ac2be409fb0f.png

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.

Link to comment
Share on other sites

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. 

I simply no longer believe that there are any professional graphic designers here. Everything follows suit. Just everything.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • 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.