ubuntu-phone team mailing list archive

[Michał Sawicz <michal.sawicz@xxxxxxxxxxxxx>]

W dniu 15.03.2013 23:31, Robert Bruce Park pisze:
> On 13-03-15 11:57 AM, Michał Sawicz wrote:
--8<--
>> * 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.

Of course - that's the ideal case, and we should strive to achieve that,
but there will be instances where we need to tweak the behaviours,
'cause the interaction is, after all, very much different.

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.

Now we come onto the "why can't I dismiss notifications on my desktop?",
or worse "why can't I dismiss notifications on my tablet after I've
docked it?". I agree those are very difficult questions to answer - and
we should avoid them at all cost - and that's on user experience design
level.

>> * 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.

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.

> 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.

Sure, agreed.

> 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.

Yes, that is best and should be that whenever possible.

Cheers,
-- 
Michał Sawicz <michal.sawicz@xxxxxxxxxxxxx>
Canonical Services Ltd.

Attachment: signature.asc
Description: OpenPGP digital signature