VideoPlayer

[Marco Martin]

On Friday 16 September 2011, Aaron J. Seigo wrote:
> bangarang, for instance, would be much nicer to look at and use even on the
> desktop without it's desktop-legacy-driven multiple-stacked-lists.
> 
> for some apps, yes, you need something radically different. kontact springs
> to mind for me here.
> 
> but for other things like a media player? i don't buy it :) instead, i
> suggest we need to rethink our UIs, but not in terms of "this is the touch
> UI and this is the desktop UI" but rather "this is the one UI that works
> in many situations".

I partly agree on this, let's see if i can explain better (gah, ended up in an 
overly long mail;):

some applications, like kontact you mentioned (or koffice, or other very 
feature dense, content creation oriented application) are inherently very 
complex and in that case having 100% the feature set on a touch ui is probably 
not even desiderable, moreover some particular widgets, like tree views are 
actually well suited for them, and go well in a complex workflow, so while 
even the desktop version could perhaps get some clues from a more friendly ui, 
they will stay probably significantly different for the foresable future.

other kind of applications have a dramatically simpler workflow, bangarang for 
instance all the ui it has when is not a fullscreen video player, is a media 
files browser, now there are many well known well tested patterns to make 
browsers of stuff as simple as possible, and the desktop version would gain 
for sure from a simplification as well.

here we have still probably a bit of different requirements between a version 
that would run on a desktop and one on a touch device.

for instance playlist items would have to be draggable on a desktop, while the 
whole list surface should be flickable on a touch device, as well as 
scrollbars vs scroll indicators, or click targets size.

those could be very minor behavioural/estetic differences, and since bangarang 
ui is 99% constituted by flat listviews, having them written in qml would 
probably be perfectly ok for the desktop as well, even before the official 
blessed desktop qml components are ready, since it uses custom painted 
delegates anyways.

what would change would be just 2-3 qml files over a 10 or so that could stay 
the same...

dreaming even more, would be cool this would happen at runtime as well, i 
tried the windows 8 preview, and even if they fallen in the trap of making 
overly toy uis (the metro thing) that i doubt will be adapt for really heavy 
duty apps ever, one thing that really impressed me was how well the transition 
between touch and mouse was handled: flick around a list with the finger, it 
work as any touch ui we're used does, start to move a mouse and the scroll 
indicator changes immediately in a classic scroll bar, interacting with the 
mouse doesn't flick the view but interacts with the elements (not doable in 
qml yet, since in Flickable the interaction is completely done with 
mouseevents, not touchevents)


another thing that should be considered, is that those "simple" applications 
are those that would make sense on an handheld device as well, and in that 
case having different uis will be necessary, no matter what, in this case the 
need for a base more adapt to scale, ie a set of qml files of which can be 
changed 5%, 10% or 100% would be really needed

Cheers,
Marco Martin