Clicking on text frame border should trigger the move tool/mode

[huangcq]

When I click on a border of the text frame, isn't the sensible thing to do is to come out of the edit mode and enable the move mode? At the moment it just continue to assume you're editing, which is not intuitive at all. Ideally it should recognize that I'm now trying to operate on the text frame itself instead of the content, so that I can just press delete to delete it, or press shift+arrow keys to move it about.

[GarryP]

A text frame, or any other layer, can be moved by simply dragging the layer when the mouse pointer becomes a four-arrow when it is near the layer boundary – no need to change to the Move Tool.

How often, while you are editing text in a text frame, do you decide to delete the entire frame?

As for the shift+arrow-key movement, have you tried – if possible, given your hardware set-up – using the mouse wheel over the relevant Transform Panel field? (With or without keyboard modifiers.)

[huangcq]

11 hours ago, GarryP said:

A text frame, or any other layer, can be moved by simply dragging the layer when the mouse pointer becomes a four-arrow when it is near the layer boundary – no need to change to the Move Tool

You can't precision move by dragging with the mouse.

I don't often need to delete a text frame "while I'm editing text" 🙄, but I do often need to delete, or move, or copy or blanket apply a style to a text frame while I click on the border of a text frame.

Bottom line is, it's not intuitive, because clicking on the border is a purposeful action. It's not easy to aim for the middle of the text frame (to start editing) and accidentally click on the border. There's a reason why this is how this kind of objects behave in all other publishing/word processing tools. You click on the border of a "text box" in Word, you can start to operate it with your keyboard. You click on the border of a text frame in InDesign, you can start to operate it with your keyboard. I don't see there's ANY POINT debating this.

[R C-R]

2 hours ago, huangcq said:

You can't precision move by dragging with the mouse.

But you can by changing the X or Y values in the Transform panel. This can be done even when the text box is in editing mode.

[huangcq]

20 minutes ago, R C-R said:

But you can by changing the X or Y values in the Transform panel. This can be done even when the text box is in editing mode.

That's another way to do it. You need both ways, depending on the use case.

[R C-R]

18 minutes ago, huangcq said:

That's another way to do it. You need both ways, depending on the use case.

How else can you make precise moves without entering numbers (or expressions) in the Transform panel, or possibly using guides & snapping?

[huangcq]

1 minute ago, R C-R said:

How else can you make precise moves without entering numbers (or expressions) in the Transform panel, or possibly using guides & snapping?

You never moved objects around with the arrow keys???

[R C-R]

2 hours ago, huangcq said:

You never moved objects around with the arrow keys???

Sure, but there are only a few choices for how far objects move per keypress. Not the kind of thing I want to use if I want to move something a large distance to a precise location.

[huangcq]

41 minutes ago, R C-R said:

Not the kind of thing I want to use if I want to move something a large distance to a precise location.

Did I say I want to use the arrow keys to move something large distance? I'm not an idiot.

[Wosven]

On 8/29/2021 at 2:05 AM, huangcq said:

When I click on a border of the text frame, isn't the sensible thing to do is to come out of the edit mode and enable the move mode?

It would be nice, since I hate needing to click twice on a blank area (none when you zoom or there's something beneth the Text frame) or clicking on the icon to get back the Move tool. Of course, the "Esc" key would be preferable... to default to the Move tool. It would be a nice way to get out of text mode.

[GarryP]

10 hours ago, huangcq said:

I don't often need to delete a text frame "while I'm editing text"

That’s how I interpreted what you said in your original post: You are editing the text, then you want to be able to click the frame to delete the frame but you can’t because the software thinks you still want to edit the text. See next quote.

On 8/29/2021 at 1:05 AM, huangcq said:

At the moment it just continue to assume you're editing, which is not intuitive at all. Ideally it should recognize that I'm now trying to operate on the text frame itself instead of the content, so that I can just press delete to delete it,

As for clicking on the frame to select the frame – rather than staying in ‘text edit mode’ – have you thought about people using the iPad versions where an accidental press on the frame – easy to do with a finger – would mean that the user could be taken out of ‘text edit mode’ without them wanting to be?

Basically you have asked for existing functionality to be changed and all I am trying to do is suggest that you think about the people who are already used to – and rely upon – how it currently works.

[Wosven]

12 minutes ago, GarryP said:

have you thought about people using the iPad versions where an accidental press on the frame – easy to do with a finger – would mean that the user could be taken out of ‘text edit mode’ without them wanting to be?

That's a completely different app with different code and different actions/triggers. The same way they can't expect keyboard shortcuts in iPad, and use more finger gestures, we can't expect the desktop app to behave the same way or limited to the same actions.

[GarryP]

I’ve never used an iPad so I can’t judge how they work or how the Affinity applications work on them.
I mentioned it to give the OP a chance to think about how the software is used on different devices and how people use them differently.
I realise that this thread is a Desktop thread but a change to such core functionality needs to be at least considered in the light of all platforms, just in case it ‘breaks’ something unintentionally. Measure twice, cut once.

[Wosven]

3 hours ago, GarryP said:

needs to be at least considered in the light of all platforms, just in case it ‘breaks’ something unintentionally. Measure twice, cut once.

No, it need not, since the code and core are differents for the UI. It's like wanting the same buttons on a bicycle and on a car, when the first one is completely different (and when APub for iPad doesn't even exist... at least officially, perhaps it's partly coded).

[Wosven]

This make me think I hate the new and big buttons interface of the Adobe suite, certainly done this way for people putting their big fingers on a touch screen... but real/main work isn't done on such screens, but big ones with keyboard and mouse & stylus, and this just means we've got less on our screen — remind me of Affinity apps and the need to click on arrows to use some fonctions that should be on the main toolbar and visible —, and we have to scroll or click to access or view, a waste of time.

 

[GarryP]

I’m not saying that any code is shared by the Desktop and iPad versions of the software.
I’m saying that it probably needs to be checked as we, as users, don’t know if it is or not.
I don’t have any insights into how the different versions of the code were written but I would be very surprised if there was no overlap whatsoever, especially when it came down to the non-UI functionality.
For example, the selection of a text frame border, no matter how it was handled in the UI layer of the software, could well be handled – sensibly so – by the same lower layer of the software (e.g. View Model, Library, Service, etc.) across different platforms.
My point is that we users can’t see the code so any assumptions we might make about it would be just that, assumptions.

[R C-R]

On 8/28/2021 at 7:05 PM, huangcq said:

When I click on a border of the text frame, isn't the sensible thing to do is to come out of the edit mode and enable the move mode?

I can't think of any significant downside to that. It might be a bit confusing to users used to the current behavior who accidentally click without dragging on the border but it should be easy enough to adjust to the change.

[Wosven]

4 hours ago, GarryP said:

I don’t have any insights into how the different versions of the code were written but I would be very surprised if there was no overlap whatsoever, especially when it came down to the non-UI functionality.

But it's not the important point. You've got keyboard keystroke, mouse and stylus actions, finger gestures taht are coded to send specific signals, and a list of commands. You just need to link them in the best way for the users to get a good UI, a good workflow.

If at some point you just find it to much work to do the work, it's time to do something else. A lot of people think the apps have really good features, but some of us also think the UI can be improved, some panels, some shortcuts also.

If it wouldn't be a waste of time to work on the interface depending of the OS used, since each one have its own particularities, its strengths and weaknesses, I wouldn't mind is less time was spend duplicating coding different colors panels, when it would be more logical for them to share the same code. Why the opacity value is only displayed in the Colors panel? Don't we need it also when adding a color to a text frame background or a decoration? No, in this case it seems we should stay blind and use tricks to have the same value.

 

1 hour ago, R C-R said:

On 8/29/2021 at 2:05 AM, huangcq said:

When I click on a border of the text frame, isn't the sensible thing to do is to come out of the edit mode and enable the move mode?

I can't think of any significant downside to that. It might be a bit confusing to users used to the current behavior who accidentally click without dragging on the border but it should be easy enough to adjust to the change.

The difficulty is more to get out of the edit mode, or to remember, when the handle and nodes of the frame are visible, that we're in edit mode, and any keystroke will end up as a new character in the text (that's really similar to the "w" we can see in ID documents, when people want to switch the view mode... with the cursor in a text frame. Or clicking on some image frame, but forgetting the option allowing to convert to text frame when you're using the text tool, same result (an unwanted "w" somewhere).

Being able to resize or move the text frame and keeping on writing can be handy too.

[R C-R]

29 minutes ago, Wosven said:

The difficulty is more to get out of the edit mode, or to remember, when the handle and nodes of the frame are visible, that we're in edit mode ...

I am not disagreeing that it would be useful to be able to click without dragging on the frame border to get out of edit mode (IOW, to switch to the Move Tool), but as for remembering we are in edit mode, isn't the text cursor enough of a visual reminder of that?

[huangcq]

17 hours ago, GarryP said:

have you thought about people using the iPad versions where an accidental press on the frame – easy to do with a finger – would mean that the user could be taken out of ‘text edit mode’ without them wanting to be?

Wow, people use this on an iPad? Even so, it's a lot easier to press one cm away from the frame (if you did manage to accidentally press on the frame), than to move 5 inches away to press on the move tool button.

I would assume vast majority of people use this app on a desktop anyway.

Edited August 31, 2021 by huangcq

[huangcq]

17 hours ago, GarryP said:

I’ve never used an iPad so I can’t judge how they work or how the Affinity applications work on them.
I mentioned it to give the OP a chance to think about how the software is used on different devices and how people use them differently.
I realise that this thread is a Desktop thread but a change to such core functionality needs to be at least considered in the light of all platforms, just in case it ‘breaks’ something unintentionally. Measure twice, cut once.

So your philosophy is to to poo poo on a change request regardless of how much sense it makes, just because it's "tradition"? Got it.

[GarryP]

Not at all; I actually think your suggestion might be useful in some cases.
However, what I am trying to suggest is that some changes may need more consideration as they may have adverse knock-on effects on other functionalities and/or how other people use the software.
I’m not trying to “poo poo” anything; I’m just saying that some things need to be thought about more than others, nothing more than that.

[huangcq]

2 minutes ago, GarryP said:

some changes may need more consideration as they may have adverse knock-on effects on other functionalities and/or how other people use the software.

That can be said about ANY changes to ANY software. I have only 4 words: Thank you Captain Obvious.

[GarryP]

You think it’s obvious, and I think it’s obvious, but you may be surprised by the number of requests that completely ignore the fact that other people use the software and might want to keep working the way they are used to.
I’ve seen plenty of suggestions which would change the workflows of many other people just because one person doesn’t want to work the way they currently have to.
What’s right for one, or a few, may not be what’s right for many; some people don’t understand that (or they deliberately ignore it).

[huangcq]

3 minutes ago, GarryP said:

You think it’s obvious, and I think it’s obvious, but you may be surprised by the number of requests that completely ignore the fact that other people use the software and might want to keep working the way they are used to.
I’ve seen plenty of suggestions which would change the workflows of many other people just because one person doesn’t want to work the way they currently have to.
What’s right for one, or a few, may not be what’s right for many; some people don’t understand that (or they deliberately ignore it).

It's just a suggestion for change mate. I'm not forcing Serif to make the change. No need to get all philosophical. I can't help how I prefer something to work. If that's not aligned with how the development team see things, so be it.