-----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----- -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : ubuntu-phone@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp