(In reply to Richard Marti (:Paenglab) from comment #3) > (In reply to Alessandro Castellani (:aleca) from comment #1) > > For fields only navigation, we have the F6 shortcut. > > F6 does not jump between To:, Cc:, Bcc: etc. it jumps directly from To: to Subject. Well, we could change that if needed, but it would still be undiscoverable. > > I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched. Technical implementation of having 100 text boxes should not be prejudicial wrt logical and effective design of the tab focus ring. Nothing "native" here. > The tabbing through the pills is already faster than before because it needed two tab hits to go to the next address because the menulist was in-between a tab destination. Faster doesn't help much when the number of stops isn't known and all but unlimited. If I press tab for a little too long trying to get through my 100 recipients, I end up in body, where tab gets stuck. Tab should be a controlled and predictable movement through a mostly stable focus ring. > On the other hand we could look as the recipient fields are normal text boxes and the pills are only a different representation of the text in them. Then using the cursor keys to navigate inside the fields is like moving the cursor in normal text, it moves only address wise. Absolutely. As I explained on the other bug, it's now a mix of item list and text box UI, but the text input connotations are certainly still strong.
Bug 1602372 Comment 5 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Richard Marti (:Paenglab) from comment #3) > (In reply to Alessandro Castellani (:aleca) from comment #1) > > For fields only navigation, we have the F6 shortcut. > > F6 does not jump between To:, Cc:, Bcc: etc. it jumps directly from To: to Subject. Well, we could change that if needed, but it would still be undiscoverable. > > I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched. Technical implementation of having 100 text boxes should not be prejudicial wrt logical, effective and accessible design of the tab focus ring. Nothing "native" here. > The tabbing through the pills is already faster than before because it needed two tab hits to go to the next address because the menulist was in-between a tab destination. Faster doesn't help much when the number of stops isn't known and all but unlimited. If I press tab for a little too long trying to get through my 100 recipients, I end up in body, where tab gets stuck. Tab should be a controlled and predictable movement through a mostly stable focus ring. > On the other hand we could look as the recipient fields are normal text boxes and the pills are only a different representation of the text in them. Then using the cursor keys to navigate inside the fields is like moving the cursor in normal text, it moves only address wise. Absolutely. As I explained on the other bug, it's now a mix of item list and text box UI, but the text input connotations are certainly still strong.
(In reply to Richard Marti (:Paenglab) from comment #3) > (In reply to Alessandro Castellani (:aleca) from comment #1) > > For fields only navigation, we have the F6 shortcut. > > F6 does not jump between To:, Cc:, Bcc: etc. it jumps directly from To: to Subject. Well, we could change that if needed, but it would still be undiscoverable. > > I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched. Technical implementation of having 100 text boxes should not be prejudicial wrt logical, effective and accessible design of the tab focus ring. Nothing "native" here. Otherwise the current behaviour "hijacks" tab as it gets lost in an indefinite number of stops. > The tabbing through the pills is already faster than before because it needed two tab hits to go to the next address because the menulist was in-between a tab destination. Faster doesn't help much when the number of stops isn't known and all but unlimited. If I press tab for a little too long trying to get through my 100 recipients, I end up in body, where tab gets stuck. Tab should be a controlled and predictable movement through a mostly stable focus ring. > On the other hand we could look as the recipient fields are normal text boxes and the pills are only a different representation of the text in them. Then using the cursor keys to navigate inside the fields is like moving the cursor in normal text, it moves only address wise. Absolutely. As I explained on the other bug, it's now a mix of item list and text box UI, but the text input connotations are certainly still strong.
(In reply to Richard Marti (:Paenglab) from comment #3) > (In reply to Alessandro Castellani (:aleca) from comment #1) > > For fields only navigation, we have the F6 shortcut. > > F6 does not jump between To:, Cc:, Bcc: etc. it jumps directly from To: to Subject. Well, we could change that if needed, but it would still be undiscoverable. > > I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched. Technical implementation of having 100 text boxes should not be prejudicial wrt logical, effective and accessible design of the tab focus ring. Nothing "native" here. Otherwise the current UI/behaviour "hijacks" tab as it gets lost in an indefinite number of minor stops. > The tabbing through the pills is already faster than before because it needed two tab hits to go to the next address because the menulist was in-between a tab destination. Faster doesn't help much when the number of stops isn't known and all but unlimited. If I press tab for a little too long trying to get through my 100 recipients, I end up in body, where tab gets stuck. Tab should be a controlled and predictable movement through a mostly stable focus ring. > On the other hand we could look as the recipient fields are normal text boxes and the pills are only a different representation of the text in them. Then using the cursor keys to navigate inside the fields is like moving the cursor in normal text, it moves only address wise. Absolutely. As I explained on the other bug, it's now a mix of item list and text box UI, but the text input connotations are certainly still strong.
(In reply to Richard Marti (:Paenglab) from comment #3) > (In reply to Alessandro Castellani (:aleca) from comment #1) > > For fields only navigation, we have the F6 shortcut. > > F6 does not jump between To:, Cc:, Bcc: etc. it jumps directly from To: to Subject. Well, we could change that if needed, but it would still be undiscoverable. > > I'm not super comfortable in hijacking the TAB key and I'd prefer to leave its native behaviour untouched. Technical implementation of having 100 text boxes should not be prejudicial wrt logical, effective and accessible design of the tab focus ring. Nothing "native" here. Otherwise the *current* UI/behaviour "hijacks" tab as it gets lost in an indefinite number of minor stops. > The tabbing through the pills is already faster than before because it needed two tab hits to go to the next address because the menulist was in-between a tab destination. Faster doesn't help much when the number of stops isn't known and all but unlimited. If I press tab for a little too long trying to get through my 100 recipients, I end up in body, where tab gets stuck. Tab should be a controlled and predictable movement through a mostly stable focus ring. > On the other hand we could look as the recipient fields are normal text boxes and the pills are only a different representation of the text in them. Then using the cursor keys to navigate inside the fields is like moving the cursor in normal text, it moves only address wise. Absolutely. As I explained on the other bug, it's now a mix of item list and text box UI, but the text input connotations are certainly still strong.