1666076 - Overwriting an entered address no longer possible with pills

Status: RESOLVED INVALID

(Thunderbird :: Message Compose Window, defect)

Description

[Eyal Rozenberg]

Do the following:

1. Compose a new message
2. In the To line, write some of the address or name of someone in your address book
3. Allow auto-complete to occur (i.e. press Enter to accept the suggestion); a pill has materialized.
4. Select the pill (e.g. with Ctrl+A or Shift+LeftArrow)
5. Type something

Expected result:
The pill is replaced with the typed text (and autocompletion kicks in if relevant)

Actual result:
The pill remains, the typing has no effect.

Note: I'm using the BiDi Mail UI extension, although this should not have an effect on the addressee fields.

Comment 1

[Thomas D. (:thomas8)]

(In reply to Eyal Rozenberg from comment #0)

Do the following:

1. Compose a new message
2. In the To line, write some of the address or name of someone in your address book
3. Allow auto-complete to occur (i.e. press Enter to accept the suggestion); a pill has materialized.
4. Select the pill (e.g. with Ctrl+A or Shift+LeftArrow)

Please clarify - only a single pill selected, or possibly multiple pills selected (Ctrl+A)? It might matter...

5. Type something
   Actual result:
   The pill remains, the typing has no effect.
   Expected result:
   The pill is replaced with the typed text (and autocompletion kicks in if relevant)

Hi Eyal, I totally understand where you are coming from and it's a legitimate viewpoint depending on perspective.
At the heart of this is the UX concept of pills between the concept of text vs. the concept of items.

We have some reminiscences of text, e.g. with cursor in the input behind the last pill, you can press Backspace to start deleting pills as if you were deleting text (which I have implemented myself). However, note that this starts out by selecting the last pill and any subsequent pill as an item, so the text-editing notion is very rudimentary.
It took me some time to understand, but I'm now quite convinced that the notion of items is much more pronounced, definitely if you ask Alex who implemented the new UX in bug 440377.

Your RFE can only be understood from the text concept, and has plausibility within that concept.
However, if we accept that the primary concept of pills is items, it's much less plausible.

Selected items do not typically get overwritten by keyboard input.
Select a file item in Windows Explorer and start typing - it will start to navigate to the first item starting with the character you typed. It will not replace or even rename that file with what you typed. Iow, items are much more protected as UI elements, and typically require explicit deletion or explicit editing/renaming. E.g. when items are selected and you paste another set of items with Ctrl+V keyboard shortcut, they don't typically replace the selection, but just get added to the container (try it in Explorer). Maybe it's just habit formation, but to me the Windows Explorer behaviour feels like the de-facto standard when it comes to item handling, especially via keyboard.

For a single selected pill, this might feel slightly more natural, but what if there are multiple selected pills? What if other selected pills are scrolled out of view? What if there's a cross-field pills selection, some in To, some in CC (possible with Ctrl)? What if the focus is outside the selection (possible with Ctrl+cursor navigation)? I think the much cleaner and safer UX is to expect the user to explicitly delete selected pills first and then add more. In case of a single selected and focused pill, you could also press ENTER, Ctrl+A, and then start typing to replace the pill in its position (the inconvenience of that is the remainder of bug 1603051).

So after careful consideration, imo there are two main points which speak against this RFE:
1.) Pills==Items UX paradigm: According to our design, pills are primarily items after they get created. Items typically don't get overwritten by text input (details above).
2.) UX-error-prevention: It's easy to forget that you have some selected pills somewhere. Maybe they are even scrolled out of sight. It would be very easy to start typing in the wrong belief that address input or even message body has focus, and lose pills accidentally. You'll be surprised how many people think that keyboard focus is at the spot they are looking at, and expect the computer to know that, only to be surprised after typing along that it didn't come out as expected because they forgot to move focus first.

In view of 1.) - items paradigm - and, more importantly 2.) above - ux-error-prevention -, I'm inclined to recommend WONTFIX for this bug.

Alex, what do you think?

Comment 2

[Thomas D. (:thomas8)]

Given that per current UX paradigm, pills are primarily items, and not overwriting items with text input is by design, this isn't a defect.

Comment 3

[Eyal Rozenberg]

Please clarify - only a single pill selected, or possibly multiple pills selected (Ctrl+A)? It might matter...

In my example, only one pill was created, and that pill was selected. But this also happens when multiple pills are selected - regardless of how you selected them (Ctrl+A, shift+click etc.)

At the heart of this is the UX concept of pills between the concept of text vs. the concept of items.

The To box is a box which can hold both text and not-exactly-text items. If something is currently selected, it must get deleted. This is not special to Thunderbird: Think of, say, LibreOffice Writer. You can select some text and some inline objects - or even just some inline objects. When you type something, the typing replaces the selection, even if you've only selected non-text items.

Selected items do not typically get overwritten by keyboard input.

On the contrary, they do get overwritten by text in similar UI contexts, as I demonstrated above. Actually, it's the same in our message bodies as well: If you select an image or a link, and start typing - they get overwritten.

pills are primarily items, and not overwriting items with text input is by design, this isn't a defect.

No reason items shouldn't be overwritten by typing text. This is a defect. I doubt this was the explicitly decided as part of the design (citation?), but if it was, then it's a defect in the design.

Comment 4

[Alessandro Castellani [:aleca]]

Did you double click on a pill to edit the address?
We don't allow editing multiple pills at once.

Simply selecting and typing doesn't do anything because pills are standalone self-compartmentalized items.
Allowing editing or deleting multiple pills by simply "typing" would be a huge error-prone hurdle.

Also, please be respectful of the core developers and don't change the flags of the bug on your own.

Comment 5

[Eyal Rozenberg]

Did you double click on a pill to edit the address?

No, for two reasons:

1. I wasn't using the mouse at all (in one of the possible scenarios)
2. I didn't feel I wanted to edit the address, I wanted to replace it with something else. Those two things may sound about the same to some, but psychologically they aren't.

We don't allow editing multiple pills at once.

Wasn't trying to do that.

Simply selecting and typing doesn't do anything because pills are standalone self-compartmentalized items.

The first half of that sentence doesn't follow from the second half.

Allowing ... deleting multiple pills by simply "typing" would be a huge error-prone hurdle.

Alessandro, It is not a "hurdle", it is what users expect to be able to do. We should really not make pills handicap users' ability to work with the addressee boxes - they should help us, not constrict us. As for being "error prone" - I really don't understand what you mean.

Also, please be respectful of the core developers and don't change the flags of the bug on your own.

On the contrary - it is disrespectful to contributors to change what they say they're reporting. One can always open a different issue which is an enhancement request and link it to a reported defect. And you can close the issue as INVALID - but you can't put words in people's mouth.

Comment 6

[Alessandro Castellani [:aleca]]

I wasn't using the mouse at all (in one of the possible scenarios)

Then you can press "Enter" to make the pill editable.

I didn't feel I wanted to edit the address, I wanted to replace it with something else. Those two things may sound about the same to some, but psychologically they aren't.

If you want to replace a pill you can delete it with "Del" or "Backspace" and then type another address.

Simply selecting and typing doesn't do anything because pills are standalone self-compartmentalized items.

The first half of that sentence doesn't follow from the second half.

Simply selecting a pill and typing on top of it doesn't do anything because pills are standalone self-compartmentalized items.

Alessandro, It is not a "hurdle", it is what users expect to be able to do. We should really not make pills handicap users' ability to work with the addressee boxes - they should help us, not constrict us. As for being "error prone" - I really don't understand what you mean.

You're completely missing the point here of a valid user case and you're trying to create "issues" with pills that are non existent.

Let's take a little step back. What's the user case here?

• User creates a pill.
• User wants to edit the pill due to wrong address.
• User selects pill and realizes that there's no cursor and the element is entirely selectable (no input field, not prompt of typing).
• User can right click -> edit or press Enter to edit the pill.
• User can delete the pill and write a new address.

I understand this behaviour might be new to a user compared to 68, but after a single first use there's no more confusion. Also, the concept of pills is not new and many other applications, both native and web based, use it.

Now, let's analyze your personal case and proposal.

• User creates a pill.
• User wants to edit the pill due to wrong address.
• User selects pill or multiple pills and starts typing.
• All the selected elements are suddenly deleted and replaced by the new typed text.

This creates extremely dangerous scenarios where users might overwrite a pill accidentally if the selection is not correct, especially in scenarios where the user has many addresses and they're not all visible (scrolled past window height).

On the contrary - it is disrespectful to contributors to change what they say they're reporting. One can always open a different issue which is an enhancement request and link it to a reported defect. And you can close the issue as INVALID - but you can't put words in people's mouth.

A core developer has a deeper understanding of the code and the expected behaviour of an application.
When you report an "issue", we try to identify if it's an actual bug or it comes from a behaviour we intentionally implemented.

In this case, Thomas correctly identified your request as an enhancement because the pills are purposefully designed to behave this way, therefore is not a defect (an accidental issue previously introduced), but a request for an enhancement (improving the current behaviour to accommodate a specific user case).

Let's always try to remain objective and avoid turning every argument into a personal discussion over semantic.

Comment 7

[Alessandro Castellani [:aleca]]

I forgot to add that this a WONTFIX for me as introducing this "type-to-overwrite-pills" behaviour is disruptive as explained in my previous comment.

Comment 8

[Eyal Rozenberg]

Now, let's analyze your personal case and proposal.

What you described is not my use case at all. I typed an address, I didn't create a pill. A pill was created by the application. I wanted to overwrite what I'd written, like I would have been able to up to a half-second before the pill was created, like I have been able to with previous versions in TB, like I would be able to in the message body and like I would be able to in areas of similar functionality in other applications.

Also, please don't tell people to move their hands away from the keyboard to do things that can readily be done with the keyboard, and have been until now.

A core developer has a deeper understanding of ... the expected behavior of an application.

Not really. Regardless, if you disagree, mark the bug INVALID. You still can't put the words "this is not a bug, I would like an enhancement" in a reporter's mouth.

Comment 9

[Thomas D. (:thomas8)]

(In reply to Alessandro Castellani (:aleca) from comment #6)

Now, let's analyze your personal case and proposal.

• User creates a pill.
• User wants to edit the pill due to wrong address.

Well, it might be wrong address, OR maybe just trying to replace selected address(es) with another address. Eyal is applying the text paradigm, where typing will overwrite selection.

• User selects pill or multiple pills and starts typing.
• All the selected elements are suddenly deleted and replaced by the new typed text.

For text-centric users like Eyal, that might be expected behaviour. Only that pills are no longer pure text, which is Thunderbird's design decision, and rightly so.

This creates extremely dangerous scenarios where users might overwrite a pill accidentally if the selection is not correct, especially in scenarios where the user has many addresses and they're not all visible (scrolled past window height).

I'd agree with that argument, and I find it quite strong, especially for multiple selections.
Maybe it would be acceptable if a single selected pill could just be overwritten.

But even implementing that doesn't look trivial to me. You'd have to use a function which recognizes all alphanumeric characters (I think we have something like that, but it might not be cheap with alll the unicode chars out there...), or excludes all non-alphanumeric characters from handling. And you'd have to adjust some of the existing key listeners handling.

In this case, Thomas correctly identified your request as an enhancement because the pills are purposefully designed to behave this way, therefore is not a defect (an accidental issue previously introduced), but a request for an enhancement (improving the current behaviour to accommodate a specific user case).
Let's always try to remain objective and avoid turning every argument into a personal discussion over semantic.

I suggest that we bypass the defect vs. enhancement discussion, which won't lead us anywhere.
I didn't mean to be disrespectful against Eyal's opinion, but as I have laid out, there are different reasonable ways of looking at this, and in terms of bug management, it's certainly within the team's discretion to mark change requests for behaviour which works as designed as "enhancement request", if the behaviour isn't outright objectively wrong or highly obstrusive, notwithstanding the fact that the user may find it subjectively "wrong" in the sense of "inconvenient". That's not putting words into reporter's mouth, it's just bug management where someone needs to make the call. Honestly Eyal, the net result and even the classification between INVALID (reported as a bug, but not a bug according to bug managers) and WONTFIX (for enhancement = not a bug according to bug managers) is almost exactly the same...

As an example, it would be objectively wrong that if you pressed DEL on a selected attachment, and Thunderbird allows detaching attachments (a part of the message), that the entire message would get deleted (I once fought that), because that would undoubtedly violate the commonly accepted principles of keyboard focus and error prevention. This bug is different. Selected text normally gets overwritten, but selected items typically do not, AND there's good reason to err on the side of protecting user's data and prevent user errors vs. squeezing out the last inch of efficiency so that you can delete selected pills AND recreate a new one in one swipe.

Thank you for providing the Libre office example; it's good to look at the design of others and compare. Inline images are a bad example because effectively, being inline makes them part of text. It's true that image objects which are not in the text layer also get deleted when the text they are hooked into gets overwritten - which is the case of a mixed selection (not quite true here for pills, which are primarily items). However, did you notice that when you select image or text box objects/items only - overwriting will fail? For a selected textbox frame, it actually appends text inside when you start typing (which is clearly not overwriting). So if the overall design considers pills as items worth protection rather than volatile pieces of text, it's certainly a valid and reasonable design decision to not allow overwriting them, especially for multiple selection, and more so if it involves risks of inadvertent user errors.

Comment 10

[Thomas D. (:thomas8)]

(In reply to Eyal Rozenberg from comment #8)

Now, let's analyze your personal case and proposal.

What you described is not my use case at all. I typed an address, I didn't create a pill. A pill was created by the application. I wanted to overwrite what I'd written, like I would have been able to up to a half-second before the pill was created, like I have been able to with previous versions in TB, like I would be able to in the message body and like I would be able to in areas of similar functionality in other applications.

I encourage you to try similar functionality in other applications using keyboard. I have tried Postbox and handling recipients was a living nightmare, totally unpredictable, data-lossy and nowhere near the keyboard efficiency which we provide. Try to see the good sides sometimes. You can now do highly efficient keyboard handling of multiple recipients which has never been possible before with TB 68, selecting is up to 99% more efficient than before, like in the case of Ctrl+A, Ctrl+A (select all recipients in all recipient fields).

Comment 11

[Eyal Rozenberg]

or text-centric users like Eyal, that might be expected behaviour. Only that pills are no longer pure text, which is Thunderbird's design decision, and rightly so.

The fact that pills are not pure text is fine, but that doesn't mean they should not be overwritten. Try this in MS Word or LibreOffice writer for example:

1. in AutoCorrect, enable "auto-bulletification".
2. Type "foo", then Enter, then "* bar", then some more text, then Enter, then Enter again
3. You now have a bulleted paragraph with "bar". This is "no longer pure text". You're in non-bulleted mode again - similarly to how, after pillification, you're outside a pill.
4. Press down Shift; while it's pressed, press UpArrow twice; release the Shift. You've selected your bulleted paragraph
5. Type something. The paragraph and the bullet are deleted

Don't like the bulleted paragraph? Do an "Insert Picture" or "Insert Image" instead. Surely, an image is "not pure text"... now use the keyboard to select back until before the image. Typing overwrites.

This creates extremely dangerous scenarios where users might overwrite a pill accidentally if the selection is not correct

This "extremely dangerous scenario" happens when you edit any text anywhere, like in the example above - and including our own message composition body. And it's so "dangerous", that you can press Ctrl+z and undo your deletion... works with pills too.

Honestly, this statement exemplifies how you are following a paradigm of application behavior in response to keyboard input (and TBH in other cases) which is fundamentally different not just from what Thunderbird uses elsewhere, but from what essentially every similar application I know of uses, and from what users expect. It seems like your intuitions and expectations are simply based on some kind of different experience which is alien to me - and also to most of our user base. What I just don't get is why you're trying to force this paradigm on others when it's not requested and when you're getting negative feedback about it.