ubuntu-phone team mailing list archive

[Michael Zanetti <michael.zanetti@xxxxxxxxxxxxx>]

On 12.01.2016 18:36, Matthew Paul Thomas wrote:
> Michael Zanetti wrote on 12/01/16 11:19:
>> ...
> 
>> IMO the app should not switch anything (with some *very* rare 
>> exceptions I guess). It gets a surface assigned where it can render
>> to, and it will get input from different devices. Those input
>> devices are not mutually exclusive. A tablet won't lose its touch
>> capabilities just because a Bluetooth mouse is connected. If you
>> make all ui elements tiny just because a mouse is connected, you
>> break the users touch screen. The user should able to choose if 
>> he'd rather tap on something or use the mouse to click on it, not 
>> the developer. The app's ui should work just fine any of them at 
>> any point in time.
> 
>> ...
> 
> A good counterexample to this theory is the very app you used to post
> it: Thunderbird.
> 
> Thunderbird has a folder list pane and a message list pane. The rows
> in these lists are too thin to be easily touchable. But if they were
> thick enough for easy touching, there would be many fewer rows on
> screen at once.
> 
> This would have consequences. You'd have to scroll more often when
> finding messages. Or if you heightened the message list pane to
> compensate, you'd have to scroll more often when reading messages.
> You'd have to wait more often while the folder list auto-scrolled when
> dragging messages to a folder. And you'd take longer to notice when
> someone else had already replied to the mailing list message you were
> about to reply to. You would be, in short, less efficient.
> 
> And this is not a "rare exception". Similar applies to any app based
> on lists or grids: spreadsheets, newsreaders, jukeboxes, podcatchers,
> database browsers. The more touch-optimized it is, the less efficient
> it is for editing, reading, and analyzing.
> 
> You can't just make some on-screen elements bigger for touchability
> and assume that there will be no tradeoff. Other elements will get
> smaller, and that has a cost. If someone has no touchscreen, or has
> one but doesn't want to use it, it's a cost with no benefit.
> 

I do see the tradeoffs your're mentioning. However, I don't think that
is really so much of a problem, especially for the example of a mail
client. Take for instance that picture:
http://www.windowsmode.com/wp-content/uploads/2015/08/Windows-10-Outlook.jpg

I wouldn't say the fact that it is touch enabled is killing it's
usefulness to be operated with a mouse.  IMO if it would be switching
between small vs big ui elements all the time, it would be much more
confusing.

Sure, there might be some cases, say, a CAD application which really
doesn't make sense to operate by touch when drawing something, given the
level of detail is required, but it does make sense to operate by touch
just to showing things off. I still think that such an application
should not switch between 2 uis, but instead the very basic should be
usable with both, while the meat of it might have smaller ui elements
where the user will need a mouse to effectively use things. However, the
main menu bar could have a "slideshow" button which then would kick off
a fully touch enabled viewer.

What I'm trying to say is not that nothing should be ever optimized for
a single type of input, but switching between two uis, one for touch
only, one for mouse only, seems still not a good idea to me.

Attachment: signature.asc
Description: OpenPGP digital signature