← Back to team overview

ubuntu-phone team mailing list archive

Re: [Design/UX/Apps] Ubuntu behaviour factors

 

>
> 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.
>
> Another example, any kind of list that you might want to scroll
> through, should at all times accept arrow-key navigation, and also
> touch swipe dragging, and also mouse-wheel scrolling, etc. Whichever
> one the user happens to use will work quite naturally, and the other
> options that the user might not have access too are harmlessly ignored.


I am not entirely sure what you're saying has anything to do with this
discussion.

Michal Sawicz:

>  * which stage is the app running in


How would this be a behaviour factor?

Also, I wrote an
article<http://zisuandrei.webmonsters.ro/design-in-open-source-unity-and-dash/>a
while ago, but I'm not sure how to submit it for the Unity team to
review
it (I emailed Jono Bacon about it, didn't answer yet, maybe anyone could
help me?). I am talking very much about no-touch but with keyboard
interaction improvements.

What you are proposing is very welcome, as it is becoming really difficult
to use Unity with a mouse as the buttons are getting bigger and bigger,,
and I am not sure why that is, because there is no touch enabled on my
laptop, and it's giving me a hard time moving with the trackpad around.


Zisu Andrei


On 15 March 2013 22:31, Robert Bruce Park <robert.park@xxxxxxxxxxxxx> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 13-03-15 11:57 AM, Michał Sawicz wrote:
> > In the shell we managed to stay away from "if (tablet) this; elif
> > (phone) that" in favour of differentiating based on available
> > space.
>
> Excellent.
>
> > * click-through notifications - only when there’s a pointer device
> > - *not* whether it’s a desktop or a phone
>
> Ok, but I think it's a bad idea to start writing code that looks like
> "if (mouse) allow_click; elif (touch) allow_swipe"
>
> I think ideally you should just create the widget such that it can
> reasonably sanely interact with both a mouse and a touchscreen at the
> same time (ie, it knows what to do when it gets clicked on, AND it
> knows what to do when a finger swipes over it on the touchscreen). In
> this way, you can simply render the identical widget on all possible
> form factors (convergence!) and then regardless of what input devices
> the user happens to actually have, we end up behaving The Right Way.
>
> > * directional navigation - only when there’s means of that
> > navigation - a keyboard or a remote - *not* whether it’s a phone or
> > a tv
>
> 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.
>
> Another example, any kind of list that you might want to scroll
> through, should at all times accept arrow-key navigation, and also
> touch swipe dragging, and also mouse-wheel scrolling, etc. Whichever
> one the user happens to use will work quite naturally, and the other
> options that the user might not have access too are harmlessly ignored.
>
> One thing you really have to consider is that there's going to be a
> million different unpredictable combinations here -- maybe somebody
> has a desktop PC, but it's hooked up to a data projector and they have
> an IR receiver so they can use a TV remote with their PC. So maybe
> this user has a keyboard, and a mouse, and a TV remote, but no
> touchscreen. Or maybe the user has a touchscreen laptop, but they also
> have a mouse plugged in. Or maybe they have a tablet with a bluetooth
> keyboard ;-)
>
> So what I'm trying to say is, you won't possibly be able to predict
> and special-case every combination of input devices. Best to just
> allow all input devices to work at all times, and then the user can
> just use whatever comes naturally to them.
>
> > I hate to see "tablet, phone, desktop, TV" differentiation when
> > we're trying to have a converged platform. We need, all of us, to
> > work with a more holistic approach.
>
> I agree ;-)
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with undefined - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJRQ6FNAAoJEMnVpoCaWglE9BUP/2v67IFJaoEEBy3ug2EbU9qo
> m8adS3dxkiHMKIDa/2/qoQ9gye+pX+2goY5vO7vJ9wdI0vSJ1hS9q6W6L6Y62+2R
> NEnb+lIxc8DKKaeYPctGi+NjMOKOtgTxDMWGowX0MVzYFxQrNv48QI3+AbTenAeN
> z9mNbDHWlmPcpUotFcCqJlc5Hxk2+c5dsEIG7p7ajcfh4iOxi70fxhZJirQoc0xN
> ifyMYuTkgDwEybM3pqQspPkr4xK28tQcDQ/cnrnNa/pOfSh1Bn7GIpsAtunG/ZwX
> YHzGbW10DGkJwUIY07nqKmQpr2C5SErFPp0KU9eb5TPTQLnj2U7gbRmafKfRLG77
> EFnV1dbbfFQ6cbvrPN/Ai7DlHm3MWV0OrXmKGrFmyIqc/gT0PsigwMUDWswvbRu8
> PrJRCxUGZFDeEN1MvXKGRjmVcibmeHIN/tK0qWPH5qsX5oSrksicSiJSf7BzUdKC
> Hj3KI7zT7ON0Uearnsr9JHBkrkAm8SrqkT68ZIDbMdRx1x0Z3TSSz87Wqs3Oicqp
> VcwahFEF/On/76tXK80Fjg94qr44RwB7VnNzjdblrzuFcDtYN9yWgUeq0beU761W
> u/rt17agc1KSn00M+jOe3LVNM2yZftNSj7oRhXj3tUTNAQ7FgkYmuuYMQMxroZW9
> rMQdD74Fn6NC8E5n8bSr
> =1Swp
> -----END PGP SIGNATURE-----
>
> --
> Mailing list: https://launchpad.net/~ubuntu-phone
> Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>

References