Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#4165 closed defect (fixed)

Cursor-handle-top should be flipped below selection start for touch usability

Reported by: garycmartin Owned by: garnacho
Priority: Unspecified by Maintainer Milestone:
Component: untriaged Version: Unspecified
Severity: Unspecified Keywords: 13.1.0
Cc: manuq, erikos Distribution/OS: Unspecified
Bug Status: Unconfirmed

Description

Cursor-handle-top should be flipped below a selections start for touch usability. The cursor-handle-top should be pointing to the bottom left corner of the selection start, see attached screen shot for example. An updated Cursor-handle-top.svg artwork is also attached to help testing.

Attachments (4)

text-selection-top_handle_y_flip.png (262.8 KB) - added by garycmartin 8 years ago.
cursor-handle-top.svg (487 bytes) - added by garycmartin 8 years ago.
0001-Set-both-text-handles-below-text-baseline.patch (1.5 KB) - added by garnacho 8 years ago.
GTK+ patch
abiword-set-both-handles-below-baseline.diff (1.2 KB) - added by garnacho 8 years ago.
Abiword patch

Download all attachments as: .zip

Change History (15)

Changed 8 years ago by garycmartin

Changed 8 years ago by garycmartin

comment:1 Changed 8 years ago by garycmartin

  • Cc manuq erikos added

Changed 8 years ago by garnacho

GTK+ patch

Changed 8 years ago by garnacho

Abiword patch

comment:2 follow-up: Changed 8 years ago by garnacho

As things were discussed with the GNOME design team about text handles on Guadec, the opposed-looking handles were so those never lay on top of selected text nor the other handle, so these patches deviate from what was intended upstream and are unlikely to be accepted there. There's though the non-covered case of handles close to the screen bounds, where operability prevails over visibility, that upstream might want a patch for.

comment:3 in reply to: ↑ 2 Changed 8 years ago by garycmartin

Replying to garnacho:

As things were discussed with the GNOME design team about text handles on Guadec, the opposed-looking handles were so those never lay on top of selected text nor the other handle, so these patches deviate from what was intended upstream and are unlikely to be accepted there. There's though the non-covered case of handles close to the screen bounds, where operability prevails over visibility, that upstream might want a patch for.

I agree it is very unfortunate that I was not able to be at Guadec to argue this usability case for touch, it was in Sugar sketches/mockups/designs from very early on. I consider this a significant flaw in the GNOME design team notes that I did get to see, likely stemming from a lack of actual hands on use with touch screen and tablet like devices.

I it not possible to implement this as an optional configuration option? Noting that the handles do need to support vertical flipping anyway to deal with the offscreen cases when a selection handle is at the top/bottom edge of the screen and needs to flip to allow interaction with it?

comment:4 Changed 8 years ago by godiard

The change has been included in the last gtk/abiword rpm, we need change the image in sugar-toolkit and release a new version.

comment:5 follow-up: Changed 8 years ago by erikos

Gary, can you say why your proposed design is more usable? What are the benefits to the currently implemented design?

comment:6 in reply to: ↑ 5 ; follow-up: Changed 8 years ago by garycmartin

Replying to erikos:

Gary, can you say why your proposed design is more usable? What are the benefits to the currently implemented design?

When trying to adjust cursor-handle-top (the start of the selection) you have to reach with your finger (usually right handed) right over and above the start of the text selection to reach the handle, diagonally obscuring with your finger the letters & words of the selection start. The users goal in moving the selection start handle is often in modifying the selection start by a few characters or a word, these will be hidden by your finger making adjustment difficult. While moving the selection start you can not see precicely where the selection is currently unless you release the handle and move your finger out of the way. With the original proposed Sugar design, the cursor-handle-top hangs below and to the right of the selection start, this means you do not obscure the selection start text when manipulating cursor-handle-top, as your finger is below the selection start.

comment:7 in reply to: ↑ 6 Changed 8 years ago by garycmartin

Replying to garycmartin:

Replying to erikos:

Gary, can you say why your proposed design is more usable? What are the benefits to the currently implemented design?

When trying to adjust cursor-handle-top (the start of the selection) you have to reach with your finger (usually right handed) right over and above the start of the text selection to reach the handle, diagonally obscuring with your finger the letters & words of the selection start. The users goal in moving the selection start handle is often in modifying the selection start by a few characters or a word, these will be hidden by your finger making adjustment difficult. While moving the selection start you can not see precicely where the selection is currently unless you release the handle and move your finger out of the way. With the original proposed Sugar design, the cursor-handle-top hangs below and to the right of the selection start, this means you do not obscure the selection start text when manipulating cursor-handle-top, as your finger is below the selection start.

CORRECTION "cursor-handle-top hangs below and to the LEFT" see all the mockups if you're not sure ;)

comment:8 Changed 8 years ago by erikos

old==left handle with upwards orientation

new==left handle with downwards orientation

gtk3 with the old behaviour. You should test this with the old artwork (currently installed).

gtk3 with the new behaviour. You should test this with the new artwork.

comment:9 Changed 8 years ago by garycmartin

Tested new gtk3 and artwork rpms on an XO-4 (i.e. no testing with screen rotation yet), looking good and working well!

comment:10 Changed 8 years ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

On 13.1.0 build 28 the text selection handles are below the selected text.

comment:11 Changed 8 years ago by dnarvaez

  • Milestone 0.98 deleted

Milestone 0.98 deleted

Note: See TracTickets for help on using tickets.