debraspicher

This is quite the defensive post from a simple comment and I have decided not to get into a rundown where I should have to run my observations by you in order to get into the specifics. That's not why I post here at all and it is a bad use of time over a relatively minor criticism.

It's a shame for web images. I don't usually use outer stroke over a color that would show through. It's interesting how one can use a program for so long but never notice some things...

I personally prefer the tooltip myself, "bold" type available modifiers currently setup under the toolname and it's shortcut (if applicable) and what they do... maybe even a very very short description of the tool... But, it makes sense to repeat it in the status bar if there's plenty of room... the tooltip is out of the way and doesn't clutter the interface, but can provide a short keycard.

Yay. I'll be able to put this to the test today. Thank you for all that you guys do.

I would otherwise say thicken the line more, but it looks reasonably thick in your example. My example looks similar to yours on my machine if the highlight is over a white background. It looks like there's some transparency to the highlight, so maybe it's that...

Might be worth mentioning that I was running another View on the other top screen (Monitor 2) at 50% or so while working. The DPI scales for those displays are in my signature.

I still have to say these programs still feel far more usable for my particular workflow than PS/Illustrator. PS is simply "OK", but I opened it recently and the design feels stale and rigid compared to newer programs that have come into the space and are more willing to accommodate the needs of modern designers who need a more open and flexible workflow. So I know it must really seem like people are nit-picking, but really pushing for a polished UX further reinforces the feeling of acceptance when onboarding new designers looking for a fresh workspace to create their designs in. That helps to further inform future design decisions as well to have preexisting design fully fleshed out. (Basically, this helps everyone.) All graphic programs have their learning curves and pain points relative to this, so that's not a major critique for me. I wasn't criticizing Key Object as "not being obvious" enough as a function.... at least I wasn't. It's important to show in the interface what is happening at each stage so that the designer can work quickly and critically. I suggest only two changes to address this: 1) Change the color of the path where Key Object is selected on the canvas. 2) Change the Layer background color from a color that is not darker, but lighter so it intrinsically is interpreted as a "highlight" action... Side thought: This may or may not look right on testing (and with other preexisting design language), so this only a thought, but perhaps italicize the Layer name text for a Key Object.

It looks worse when there's overlapping paths or certain color variations, bearing in mind this line is fairly thin on larger resolution displays running at lower DPIs (something I *must* do due to an Affinity bug affecting my machine). Then the "overlapped" portion looks thicker than the rest of the highlight and thus that blue line can be misleading as to what is highlighted/not highlighted. It's harder to see the variance on a high res display. I think to accommodate different viewing conditions, system DPI settings, there needs to more delineation.

Just playing around on a Pattern layer on a throw away file testing pens. I don't know why there are 2 .DMPs near the same time, but I've attached both. The time for the log was at 11:46pm. It closed without warning. bbd8c79c-cf0b-4e3c-9799-bf9307967984.dmp 2b477624-bfac-417f-87f4-e608cb1b7e44.dmp 230114_256-pattern-layers_BETA.afphoto

Pasted the Windows log below. Was using the Rusty Nib Set - "The Wally Wood Pen" brush...

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.

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?

And Swatches also. Swatches are painful right now to rename. Right Click > Rename; Move cursor to box usually in the center of the screen. Type in value...

Could it be possible to polish the UI a bit for Key Objects? It's difficult to scan at a glance. I honestly don't notice half the time on scan whether it is nominated or not, because the highlighting is so poor, especially at a higher resolution. It is hard to see imo compared to other programs and there's too many times I can't tell whether I've nominated the correct piece or not. It's less bad in the first example, but in the second, there's just the central line that is highlighted and it is not immediately clear at a glance whether I have the bottom fill or a curve/stroke: I would check the Layers panel, but that also has hierarchy/seamlessness issues with the highlighting... I drew a circle at the very top of the Artboard stack to show the highlight is very close to the key highlight.. especially on dark, they look the same. Again, at a glance, on a higher resolution display with smaller UI, they look seamless. Is there any reason the Key Object highlight on the canvas is still blue and not another color (similar to snapping candidates?)

The feedback when objects are selected/manipulated is at least needed.

It's nuanced, but I can change the text (for example, "Sun", "sun") and it won't pick up without clicking in and out of the Panel. Ex: I set "Layer name is" to "Sun" and click select, show, hide, behaves as normal... change it to "sun"... it still only responds to the first "Sun". If I click in and out of the panel, it finally registers the change. That was just to test your case-sensitive scenario. It happens of course if I change it to a completely name. As for /i /ig, it looks like flags aren't being utilized to keep it simple.

I don't like it so much for the raster brushes either. But again, I'm not looking to change the default, but rather to be able to do a full override when needed, using Snapping settings (subjectively it is not semantic, but I think it could be an appropriate area for overrides?). For example, I use whole pixels to fill in with ink with rounds, etc, similar to a vector stroke, but hand drawn with raster. Vector brushes of an organic type (non-round) don't matter as much as I tend to view them as a painterly stroke, so when they finally make those brushes full vector and we can expand it... then we can adjust as we need after. That's labor we would expect would be necessary if we needed to hint a logo or something with a vector brush stroke in it for output.

It would be fantastic if we could have a Snapping criterion that allowed users to override how [, ] handles increments. Even allowing us to use Shift + [,] to strictly follow pixel-precise convention (regardless of document units) would also be infinitely creatively useful. I get there's some calculations going on there to achieve a desired visual increment which results to increments such as 1.593255pt, and I'm not against that behavior as a different way of doing things and I think it has its place in Affinity, as long as there's a way to achieve the desired outcome without data entry.

Amusingly enough, Regular Bounds has it correct. But like you say, it can't be set.

It sounds like you are wanting an option to Save Selections that wouldn't be trigger by a query (manual selection as you said). I think that makes sense. From your post, it was a bit confusing, like you were asking to use Select>Save Selection.. from selections in addition to having those select-able with States > [Queries]

FWIW, I set "Alt + ." for Set Bounding Box in shortcuts. Works pretty well.

True I do use this for placing dummy images into presized containers set to a grid.

Thank you for this.

I'm not an optimist per say (though I don't tend to think negatively...?), but can only hope (and that's all it is) that with the amount of feature updates/code changes being introduced, perhaps much of this "old" WIP code from when there was such a long lull in updates that they are pushing these things in now quickly to work towards that polish cycle. It ideally needs to be done before there are too many changes, imo. In the specific scenario re: my post you quoted, since we are talking about active development in the context of user feedback, I was mainly contrasting that with what we can see versus what they would see being knee-deep in the programs from a development perspective. So in that context, it's understandable this hasn't been hashed out yet (hence the need for feedback here...). The other parts of your post as to why there doesn't appear to be a bigger focus on UX remains again elusive. There certainly seems to be more of a focus on customization per user workflow, which does seem to have changed substantially from the past? But again, speculating again that maybe these things have been long sitting on the table and just now being thrown into the equation with the addition of other unreleased changes. I wish they would come out and just scream they're going to tackle UX and polish head-on and what that would look like perhaps. That would be so much easier than filling up the forum with never-ending paragraphs on the same exact topic, every time something remotely like it comes into the conversation. We're here because we like to critique. It's helpful to know where development is going so we know where to better focus our energy (as unique users) and not having to repeat the same things over and over is very helpful if we can avoid it and use our own energy more productively towards our own specific needs when giving feedback. Fully back on topic, in my usage, I have used Insert Inside for drawing/patterning inside things. It doesn't need to be "locked" on once that starts though, because it continues to draw inside that same object. So I'm assuming this is why it's not made feasible? If there's multiple shapes, it could useful to have the same sticky behavior for when we're moving object to object to draw/paint inside of them, which I'm assuming is the desired scenario by others here? I can only assume if that is allowed, then that the behavior goes away when the program is closed? I can't check atm, but if it does, that would alleviate most concerns of people getting locked into confusing/undesirable behavior as many people tend to close/reopen things when programs are behaving in a non-out-of-box manner. (So then they should add lock for that button as well, imo)

I use Lock Children a lot, so this is indeed very handy. I can enjoy the benefits of Lock Children as needed without worrying too much about the state of the checkbox since I can set it to determine default behavior, which is more ideal.