Proposal for a better mouse selection in text fields

[Matthew Paul Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robin Dinse wrote on 16/12/14 22:33:
> 
>> On 16 Dec 2014, at 17:38, Matthew Paul Thomas <mpt at canonical.com>
>> wrote:
> ...
>> 
>> This list is for discussion of things that help platforms 
>> interoperate. Precise behavior of text fields doesn't really
>> fall into that category.
> 
> Thanks for clearing that up.  I was referred to this list to reach 
> the maintainers of various GUIs.  Do you know a better place for 
> these sort of discussions?

I do not.

> Off-topic, but I’m curious: Were there ever considerations to add 
> usability guidelines to the concerns of fd.o?  It seems diverging
> UI behavior in open source projects is often regarded as a weak
> point of FOSS.  I think it would be great to have an open unified
> design language (think Google Material and the Apple Style
> Guide/HI Guidelines) which could possibly be created in a
> collaborative effort of various GUI maintainers and designers.

That's unlikely, partly because it's arguably unwise. When different
toolkits try to use the same visual design, you end up in an Uncanny
Valley where any differences in behavior, whether intentional or
unintentional, are much more jarring than if they looked different.
This is an example of the general principle that things that look the
same should work the same, and things that work different should look
different.

You can see this, for example, in any system that themes Firefox
and/or LibreOffice to look like GTK apps: it's more of a surprise that
their radio menus open in different directions, that list selection
behaves differently, that dialogs have buttons in different orders,
and so on. The same has happened to a lesser extent with Microsoft's
various Windows SDKs, and even in minor cases with Apple's Carbon vs.
Cocoa.

So the weak point for FOSS isn't making toolkits behave the same; that
would be a Sisyphean task. The weak point is that nobody has ever been
willing and financially+politically able to make a single toolkit the
obvious choice for third-party developers, with all other toolkits
being relegated to research experiments.

> ...
> 
> I have just tested it in LibreOffice, iOS and Android.  The
> behavior is similar but a key aspect is different.  Note that in my
> proposal the selection still gets extended all the way to one side
> if the cursor is sufficiently far away from the text field.  I do
> not know if that is the case in Windows Phone.

That is analogous to scrollbars in the classic Mac OS. While dragging
the scrollbar thumb, if you dragged a small distance away from the
scrollbar, the thumb would continue moving as normal. But if you
dragged far enough away, the thumb would do something else: snap to
its original position, on the grounds that you were probably trying to
cancel the scroll. Unfortunately newer toolkits lost this subtlety.

> I just realized, though, that there are special cases if the text 
> field is near the top or bottom of the screen.  Perhaps, the old 
> behavior could be triggered when the cursor reaches the last pixel 
> row of the screen in these cases.

Those "special cases" would be very common on small-screen touch
devices, and quite common even on PCs: for example, the address field
in a (near-)full-screen Web browser, or the Find field in any app that
uses a Find toolbar. If you'd have to diverge frequently from the
normal behavior, it wouldn't be learnable behavior.

- -- 
mpt

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlSqglgACgkQ6PUxNfU6ecrJcACdE/qREX4RBujjwR9R3GovJY82
hXkAoLdX/ajw23HNtW4OmEzRV2dP/e+0
=m9JY
-----END PGP SIGNATURE-----