Bug 1603051 Comment 4 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 Thomas D. from comment #1)
> ### 2. Plain navigation with cursor left/right (*new: pills AND insertion points*) ###
> - Proposal: Cursoring *alternates* between selecting pill (!) and text cursor between pills (see illustration below)
> - Note: this is significantly *different* from Postbox navigation behaviour which stubbornly *skips* the actual recipient pills.

So this is the key aspect of my proposal P1.

## Cost/Benefit evaluation (from user's pov (1)) ##

**Cost**
- So for plain vanilla recipient navigation *inside* the recipient field, we're adding an extra stop for each recipient (the insertion point before the recipient). Two cursor key presses needed to navigate to the next recipient (only for *plain* navigation, which is thus minimally different from *selection* where 1 key press suffices most of the time). Note that these are *not* tab stops (per my proposal of bug 1602372), it's intra-field navigation with cursor keys, so the message focus ring is not affected. Also note that I presuppose cursor up/down as a shortcut for vertical navigation inside multi-row recipient fields.

**Benefits**
- Maximum flexibility for inserting and reordering recipients according to user's gusto
- with a variety of mouse and keyboard methods
- Discoverable and intuitive
- Fully controlled, predictable and transparent
- Retain maximum efficiency for selecting and deleting pills in a fully item-centric manner

**Evaluation**
Imho, cost is negligible. Benefits by far outway the cost.

I would love to test this idea in a future iteration of the prototype by Alessandro.

(1) Implementation is for others to sort out... but I'm confident it's doable with Alessandro's scalable and modular coding approach.
(In reply to Thomas D. from comment #1)
> ### 2. Plain navigation with cursor left/right (*new: pills AND insertion points*) ###
> - Proposal: Cursoring *alternates* between selecting pill (!) and text cursor between pills (see illustration below)
> - Note: this is significantly *different* from Postbox navigation behaviour which stubbornly *skips* the actual recipient pills.

So this is the key aspect of my proposal P1.

## Cost/Benefit evaluation (from user's pov (1)) ##

**Cost**
- So for plain vanilla recipient navigation *inside* the recipient field, we're adding an extra stop for each recipient (the insertion point before the recipient). Two cursor key presses needed to navigate to the next recipient (only for *plain* navigation, which is thus minimally different from *selection* where 1 key press suffices most of the time). Note that these are *not* tab stops (per my proposal of bug 1602372), it's intra-field navigation with cursor keys, so the message focus ring is not affected. Also note that I presuppose cursor up/down as a shortcut for vertical navigation inside multi-row recipient fields.

**Benefits**
- Maximum flexibility for inserting and reordering recipients according to user's gusto
- with a variety of mouse and keyboard methods
- Discoverable and intuitive
- Fully controlled, predictable and transparent
- Retain maximum efficiency for selecting and deleting pills in a fully item-centric manner

**Evaluation**
- Imho, cost is negligible. Benefits by far outway the cost.

I would love to test this idea in a future iteration of the prototype by Alessandro.

(1) Implementation is for others to sort out... but I'm confident it's doable with Alessandro's scalable and modular coding approach.
(In reply to Thomas D. from comment #1)
> ### 2. Plain navigation with cursor left/right (*new: pills AND insertion points*) ###
> - Proposal: Cursoring *alternates* between selecting pill (!) and text cursor between pills (see illustration below)
> - Note: this is significantly *different* from Postbox navigation behaviour, which stubbornly *skips* the actual recipient pills.

So this is the key aspect of my proposal P1.

## Cost/Benefit evaluation (from user's pov (1)) ##

**Cost**
- So for plain vanilla recipient navigation *inside* the recipient field, we're adding an extra stop for each recipient (the insertion point before the recipient). Two cursor key presses needed to navigate to the next recipient (only for *plain* navigation, which is thus minimally different from *selection* where 1 key press suffices most of the time). Note that these are *not* tab stops (per my proposal of bug 1602372), it's intra-field navigation with cursor keys, so the message focus ring is not affected. Also note that I presuppose cursor up/down as a shortcut for vertical navigation inside multi-row recipient fields.

**Benefits**
- Maximum flexibility for inserting and reordering recipients according to user's gusto
- with a variety of mouse and keyboard methods
- Discoverable and intuitive
- Fully controlled, predictable and transparent
- Retain maximum efficiency for selecting and deleting pills in a fully item-centric manner

**Evaluation**
- Imho, cost is negligible. Benefits by far outway the cost.

I would love to test this idea in a future iteration of the prototype by Alessandro.

(1) Implementation is for others to sort out... but I'm confident it's doable with Alessandro's scalable and modular coding approach.
(In reply to Thomas D. from comment #1)
> ### 2. Plain navigation with cursor left/right (*new: pills AND insertion points*) ###
> - Proposal: Cursoring *alternates* between selecting pill (!) and text cursor between pills (see illustration below)
> - Note: this is significantly *different* from Postbox navigation behaviour, which stubbornly *skips* the actual recipient pills.

So this is the key aspect of my proposal P1.

## UX Cost/Benefit evaluation (from user's pov (1)) ##

**Cost**
- So for plain vanilla recipient navigation *inside* the recipient field, we're adding an extra stop for each recipient (the insertion point before the recipient). Two cursor key presses needed to navigate to the next recipient (only for *plain* navigation, which is thus minimally different from *selection* where 1 key press suffices most of the time). Note that these are *not* tab stops (per my proposal of bug 1602372), it's intra-field navigation with cursor keys, so the message focus ring is not affected. Also note that I presuppose cursor up/down as a shortcut for vertical navigation inside multi-row recipient fields.

**Benefits**
- Maximum flexibility for inserting and reordering recipients according to user's gusto
- with a variety of mouse and keyboard methods
- Discoverable and intuitive
- Fully controlled, predictable and transparent
- Retain maximum efficiency for selecting and deleting pills in a fully item-centric manner

**Evaluation**
- Imho, UX cost is negligible. Benefits by far outway the cost.

I would love to test this idea in a future iteration of the prototype by Alessandro.

(1) Implementation is for others to sort out... but I'm confident it's doable with Alessandro's scalable and modular coding approach.

Back to Bug 1603051 Comment 4