Ability to lock insertion target

[Ash]

Apps: All
Platforms: Windows, macOS and iPad

We have now added the ability to lock all insertion targets (Behind, On Top and Inside) in all apps. This is activated by holding Alt when pressing either of those buttons in the toolbar. This is particularly useful for those who like working from top to bottom in the layer stack, meaning you can now lock Insert Behind on so all new objects you create are inserted below the current selection.

The insertion target buttons are available in the top toolbar on Windows and macOS:

And can be found in the edit menu on iPad as shown below. On iPad you can lock these either by holding Alt when you tap on the appropriate option (from command controller or attached keyboard), or alternatively by long pressing on the button.

[Affinity Info Bot]

Known Issues in this feature
A list of unresolved issues for this feature, reported by users

Released Fixes
A list of issues for this feature, available in the current beta build

• AF-1731 - Use case for locking Insert Inside [Fixed]

Upcoming Fixes
A list of issues for this feature, which will be available in a forthcoming build

[pruus]

Again a  clever solution. Yes!

[Bryan Rieger]

Oof — even more modifier keys to try to remember, with the iPad ones being even more unintutive..

[ronnyb]

2 minutes ago, Bryan Rieger said:

Oof — even more modifier keys to try to remember, with the iPad ones being even more unintutive..

Long tap would solve that problem

[garrettm30]

49 minutes ago, Bryan Rieger said:

Oof — even more modifier keys to try to remember, with the iPad ones being even more unintutive..

That’s what I was thinking: as the software becomes more capable, many of its features also become less discoverable. My suggestion would be to implement double-clicking to lock it, following the paradigm established by caps lock on mobile keyboards.

Furthermore, perhaps this is a bad idea, but my first thought is that it might be worth considering whether to implement all three alternatives: opt-click, long press, and double-click. That way, the user can achieve what he is looking for by whatever method he happens to remember or try.

For my work, this is a feature I would almost never use but really be glad for on those occasions where it would be helpful, and I would hope I could remember how to do it.

[Ash]

Actually we are looking at long press on iPad be the alternate way to activate it - that would be consistent with other alt-click operations on iPad such as either long pressing or alt-clicking "Add" creates a non-destructive compound.

[Pšenda]

23 minutes ago, garrettm30 said:

My suggestion would be to implement double-clicking to lock it,

If you are talking about clicking/double-clicking on the icon on the toolbar - then definitely yes. Currently, when an icon is clicked, the icon will change (button pressed) and thus a one-time application will occur, as the icon will then return to its original state (button not pressed). After double-clicking, the icon would change in a different way that would represent a persistent (not a one-time) state - does the icon change when pressed with Alt?

 

1 hour ago, Bryan Rieger said:

Oof — even more modifier keys to try to remember

Yes - It ceases to be memorable🙂
Since this information (difference between press with/without modifier) is not shown in Status, it could be shown in the Tooltip of the button.

[nezumi]

3 hours ago, Bryan Rieger said:

Oof — even more modifier keys to try to remember, with the iPad ones being even more unintutive..

F hell mate... I feel like I am taking crazy pills when I read this forum sometimes... What is this, kindergarten? "I need to press alt? Ow no! not possible to remember!". 😶 

Dont ever try to use some 3D software if this is too much for you to remember. Sorry to be harsh but that sort of things are taking me by surprise. So maybe they should stop adding new functionalities because you know - new things to remember... "Oof" indeed.

BTW - great option indeed.

[EricP]

this is a great feature but any reason why this is not extended to "insert inside the selection" ?

[nickbatz]

Great feature!

[StuartRc]

Brilliant.. thank you! Wanted this function for a long time.. saves lot of time having to reselect it over and over again when working with infill vectors. Used to have to select and track objects in the layers panel to try and get around it!....no need any more! A simple but huge improvement!😀

[R C-R]

1 hour ago, EricP said:

this is a great feature but any reason why this is not extended to "insert inside the selection" ?

I wondered the same thing.

[Ash]

1 hour ago, EricP said:

this is a great feature but any reason why this is not extended to "insert inside the selection" ?

Yeah happy to consider use cases for this but we were struggling to be honest. If you just insert inside once then generally what you have just created is selected within the parent. Then additional things you draw and naturally created above/below that child and naturally inserted within that original parent anyway. If insert inside was locked on then each new thing you draw will go inside the last thing created (rather than the original parent you targeted) - creating a big tree of children within children. As I say we were just struggling to think if that is really what you would ever want, but happy to hear cases when it would be useful.

[debraspicher]

5 hours ago, Bryan Rieger said:

Oof — even more modifier keys to try to remember, with the iPad ones being even more unintutive..

4 hours ago, garrettm30 said:

That’s what I was thinking: as the software becomes more capable, many of its features also become less discoverable.

So true. I have a daily notebook where I have to write things like this down and I keep it dated. Thankfully just the act of writing helps my memory, maybe not with remembering the actual keys/usage instructions, but that I wrote it down and about when, so I can remember it both exists and how it works for when I need to look it up. I've had to do this with bugs as well because it seems every time I start the program. Sad, but true. When I encounter something new or I keep a list of the smaller details (even things I like) so I can remember to post it later for when certain topics come up.

The developers are a little immune to this experience as they develop the programs and work on them everyday. So I can't blame them if they see the programs differently than us.

[Bit Disappointed]

3 hours ago, Ash said:

Yeah happy to consider use cases for this but we were struggling to be honest. If you just insert inside once then generally what you have just created is selected within the parent. Then additional things you draw and naturally created above/below that child and naturally inserted within that original parent anyway. If insert inside was locked on then each new thing you draw will go inside the last thing created (rather than the original parent you targeted) - creating a big tree of children within children. As I say we were just struggling to think if that is really what you would ever want, but happy to hear cases when it would be useful.

Dear @Ash,

Thank you for the update addressing several requested features. I have some feedback. It seems that some assumptions are based rather theoretically on the notion that your customers follow very uniform workflows, such as top-down approaches. While I utilise the entire range of insertion targets, it's not done mechanically or consistently in consecutive steps. For me, it's not a (semi)permanent setting, but more like an ad hoc setting that I need to use maybe 10-20-30 times in a row.

If I were German, I might describe my method as "An auf hinter in neben über unter vor zwischen" 🙂

Having the 'insert inside' as a permanent option for a while is not at all pointless. True, it could become a bit recursive like digging a well if one is working on the same object, but that's not necessarily the case. In my work, I would enable it because the next round of additions to an illustration involves inserting inside a variety of different objects. A permanent setting would allow me to start grouping such actions and organise my workflows into themed steps, rather than jerkily changing the insert target each time. It's quite disruptive.

So the lack of alt-clicking on insert inside is actually blocking me from working my way. When you have to actively click alt+icon to activate insert inside as a permanent setting, you can assume we know what we're doing. 🙂

This leads me to the iPad, where the insertion target is hidden away in the edit menu and not readily accessible from the toolbar, probably based on the assumption you described. I had a feeling it would end up there because the assumption is that it's seldom used. But for me, that's not the case, so its location in the edit menu is incredibly inconvenient.

Moving on to the tablet interface, it's a bit of an issue in itself to talk about keyboard shortcuts on a tablet. 🙂 In general, the Affinity tablet interface leans (too) heavily on desktop logic, especially with this horseshoe of toolbars and associated keyboard shortcuts ad libitum. It's necessary to have these, but the primary assumption should be that the customer doesn't have a keyboard on an iPad, and tablet UI logic must be smartest. The Command Controller is just a software implementation of four physical keys. The journey into a top menu with submenus is very desktop-like and quite slow. I'm really missing local and dynamic choices, where one can quickly select functions with a finger or pen, and where the dynamics mean the interface folds away and doesn't obstruct, leaving screen space for work.

There are plenty of great apps out there to draw inspiration from for methodology.

Thanks for reading this far. 🙂

[EricP]

 

13 hours ago, Ash said:

Yeah happy to consider use cases for this but we were struggling to be honest. If you just insert inside once then generally what you have just created is selected within the parent. Then additional things you draw and naturally created above/below that child and naturally inserted within that original parent anyway. If insert inside was locked on then each new thing you draw will go inside the last thing created (rather than the original parent you targeted) - creating a big tree of children within children. As I say we were just struggling to think if that is really what you would ever want, but happy to hear cases when it would be useful.

Yes, I thought you feared the risk some users may inadvertently create russian-doll layer structures, but I think there is definitely value in being able to lock this button too. As Bit Arts mentioned in his/her post, I also find myself repeating an insert into clipping mask action several times and locking this button would definitely help.

I recorded this small video as an example. Note that on last step I forgot to click insert inside and got my shortcut action sequence wrong. But you should get the point

lock insert inside use case.mov

[Pšenda]

22 hours ago, EricP said:

this is a great feature but any reason why this is not extended to "insert inside the selection" ?

Yes, enabling even this option is necessary just for the sake of consistency and uniformity of the GUI. It is very annoying and confusing for users when something works in one place and not in another - because the developer thought for the user and decided that no one would use this option.

Edited January 10 by Pšenda

[Bit Disappointed]

On 1/9/2024 at 9:31 PM, debraspicher said:

The developers are a little immune to this experience as they develop the programs and work on them everyday. So I can't blame them if they see the programs differently than us.

Programmers surely do that, but in a modern (year 2000+) development workflow, it is the specialists in user interfaces who make the decisions. If one is struggling, then such specialists are missing.

In a development team comprising a usability expert and a code developer, their roles would typically be divided as follows:

Usability Expert:

• User Experience Design: The usability expert focuses on the design of the user interface, ensuring it is intuitive, easy to use, and meets the needs of the users.
• User Research: Conducts research to understand the needs, behaviors, and motivations of the users. This can include methods like surveys, interviews, and usability testing.
• Interface Design: They create wireframes, mockups, and prototypes of the user interface, considering factors like layout, color schemes, and user flow.
• Usability Testing: Conducts tests to evaluate how easily users can navigate the product and complete tasks. They identify pain points and areas for improvement.
• Accessibility: Ensures that the product is accessible to users with disabilities, adhering to relevant guidelines and best practices.

Code Developer:

• Programming: The primary role of the code developer is to write the code that makes the software function. This includes front-end (user interface), back-end (server, database), or full-stack (both) development.
• Implementation of Design: Translates the designs and prototypes provided by the usability expert into functional code.
• Testing and Debugging: Performs technical testing to ensure the code works as intended, identifies bugs or issues, and fixes them.
• Performance Optimization: Works on optimizing the code for better performance, ensuring that the application runs smoothly and efficiently.
• Technical Problem Solving: Addresses any technical challenges or limitations that arise in the development process, finding solutions that align with the project's goals.

Both roles are crucial for the development of a user-friendly and functional product. The usability expert ensures that the product is designed with the end-user in mind, while the code developer brings these designs to life through programming. Their collaboration is key to creating a successful software product.

There are so many feedback comments about usability deficiencies here in the forum that the above tells a story in itself.

From my own career, I can reveal that if there is one thing that keeps projects going, ensures quality, steers clear of disasters, and secures satisfied customers, it's the specialists!

[ronnyb]

I can't seem to get the feature working, both buttons only place the duplicated object above the original.... on macos

[debraspicher]

13 hours ago, Bit Arts said:

Both roles are crucial for the development of a user-friendly and functional product. The usability expert ensures that the product is designed with the end-user in mind, while the code developer brings these designs to life through programming. Their collaboration is key to creating a successful software product.

There are so many feedback comments about usability deficiencies here in the forum that the above tells a story in itself.

From my own career, I can reveal that if there is one thing that keeps projects going, ensures quality, steers clear of disasters, and secures satisfied customers, it's the specialists!

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)

[Bit Disappointed]

Never ending paragrahps will stop when never ending issues stops. 🙂 In this scenario, the feedback chain is unfortunately - but as a natural consequence - circular.

[Rudantu]

I think a 'lock insertion' checkbox beside the buttons would be a lot more findable than a hidden modifier, might just be me 🤔

[Junior Jap]

On 1/10/2024 at 3:15 AM, Ash said:

Yeah happy to consider use cases for this but we were struggling to be honest. If you just insert inside once then generally what you have just created is selected within the parent. Then additional things you draw and naturally created above/below that child and naturally inserted within that original parent anyway. If insert inside was locked on then each new thing you draw will go inside the last thing created (rather than the original parent you targeted) - creating a big tree of children within children. As I say we were just struggling to think if that is really what you would ever want, but happy to hear cases when it would be useful.

Dear @Ash,

If it's possible, please extend this to "insert inside selection". It'll save a lot of time and effort especially when we went into the process of adding texture, shadow, highlight, etc. When we done with the flat colour, adding those details will be much more easier and quicker.

It's definitely a crusial part oo any illustration process.

Thank you

 

[Ash]

36 minutes ago, June Yap said:

If it's possible, please extend this to "insert inside selection".

Yes thanks all for your feedback on this, we will additionally add to Insert Inside to make it all consistent / cover the use cases you have described.