ubuntu-phone team mailing list archive
-
ubuntu-phone team
-
Mailing list archive
-
Message #01108
Re: [Design/UX/Apps] Ubuntu behaviour factors
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 13-03-16 01:46 AM, Michał Sawicz wrote:
> Case in point - notifications - default behaviour for the desktop
> is to have them non-interactive, click-through. That won't be good
> enough for a phone, where that bubble could take a significant
> portion of the screen, and there's no way to interact with what's
> behind them. It should be possible to dismiss them. On a tablet,
> however, this might be dependant on whether there's a pointer
> device.
I think this is actually a perfect case *in favor* of my argument,
though. Consider this:
The notifications as they currently exist on the desktop become
transparent when moused over, and pass clicks through them. You can
take that exact same widget, add a little bit of code that says
"dismiss myself when a finger swipes over me in a certain direction"
If you run that widget on a normal phone, the user doesn't have a
mouse, so they never see the click-through effect because they are
physically incapable of performing a mouse click -- even though the
code to pass mouse clicks through is still present. Phone users then
see the notifications and can dismiss them with a finger swipe.
On a tablet, you get the same thing -- the notification can be swiped
away with a finger, or clicked through with a mouse. If the tablet
user happens to have a bluetooth mouse, they can mouseover the
notifications to dim them, click through them, or they can put their
finger on the touchscreen to swipe it away.
You are probably right that there are going to be corner-cases, but
the larger point I'm trying to make is that there are probably many
fewer corner cases than you actually expect. Just write the widgets to
respond to different input devices in the correct way, and everything
else will fall into place.
I'll give an example of something that failed to do this currently --
if we forget about the Touch image for a second, and remember back to
when we were running the desktop images on the Nexus tablets, there
was a hilariously terrible situation in which if you tried to scroll a
window with touch gestures, what actually ended up happening was that
Ubuntu would interpret this as a mouse click+drag, and perform a text
selection rather than a scroll action. This is a case of those widgets
not being written to understand the difference between what a
touchscreen is, and what a mouse is, and was trying to map touchscreen
input onto a set of assumptions about how a mouse is supposed to be
used. Don't do that. All of the widgets in the SDK should fully
understand what a touchscreen is, and what a mouse is, and should be
able to Do What I Mean regardless of what input device I'm actually
using. That means it knows to select text on a click+drag, and it
knows to scroll on a touch-swipe. The same widget can accept both of
those inputs, and then you don't need to write any special-casing code
to figure out whether you're on a phone or a TV or anything, you
simply do the right thing in all cases.
>> Again, don't do things "only when there's a means". Provide all
>> input options simultaneously and then the user will simply choose
>> whichever one is the easiest to use given the input devices that
>> they have access to. I think this can be done in a very seamless
>> and transparent way -- eg, a button will look identical whether
>> you are expecting it to be clicked on, touch-tapped on,
>> keyboard-navigated to, or TV remote selected... and regardless of
>> which input device is used to activate the button, the button
>> activation will be identical anyway.
>
> Sure, that probably is one example where you can have that
> implemented and it simply won't be used. But the notion of focus is
> limited to text entry fields.
That's a shame, because there was a day when that wasn't true. Made it
pretty easy for keyboard-only use of a desktop, as you could simply
tab around between different widgets and activate different buttons
and things without having to know all kinds of cryptic shortcuts.
Thanks for reading my rant, apologies for the length ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/
iQIcBAEBAgAGBQJRRXksAAoJEMnVpoCaWglEVHYP/RcITdR8CWxWW6HjSKVs+IvI
NVMfIDIf7mhXMBO7R8RxGTMcR+RXemI5ND5let4GKfDjg8a+jw8UaR4wnz7HnFEt
auRzYmKwfrGWQ46Vk9ygSsvhr/sb1Z+GxYNsB7dpj6fm+c2AG+TAPokQVnQNe0PM
NaWtGfEpUr+vM6E3fryJ/wThYtASJmZSHAKj/7VCdShbhOdOi5mq71rj8UTJRt7b
n46sdIRpBA1WmQdpIqtwoh7qV8BKFj7Qj8VSn+RoKNnF9jX2kw8Me0kLLEwS5LaL
V1GYI6sGRtUm51LIQErQzEOugGSWz7WCkPk15YrRpNLLHLuIDpDnDu2BBWVqWOG5
3wk5426rCzMDnql6frjnPc2nYrc/qexQpUbGuRlUPc0yfiHibqQpyYQXeu+0kcVL
p95qMo6grNSQ5SL5xReD7xJYffolXtrEWxwMkWHk0PDw+T4HXguZ8aQsqZ7o3dWW
B6BzUKnXnKeF2bH69EDym9VqFZosq0qtxDUNFzFom8Gjq9d38KmeijMPgG4C8wvM
CG0cxkczZ0ohMUVeX3QKx5QQSL5YO0uUYgUtzP7f6xTc4Vm7ZeIy6RBF7ZHuiXiC
h+5kX58i2FZjNzRhcTFhtq9hC6MM8JvASoYRWm2Ru/tdbeHNBzqRSVZh1m+tzW0s
KFNMrbbA6S4iIZFHrpyr
=Ienv
-----END PGP SIGNATURE-----
Follow ups
References