Evolving Appdash

[Eike Hein]

On 12/15/2015 07:45 PM, Marco Martin wrote:
> I think I still wouldn't like having it always by default for everybody, 2 
> ways to do the same thing (launching an app) by default i don't think is a 
> good pattern in general, especially since a fullscreen grid of very distanced 
> icons while looks cool, is not a good interaction model for the mouse (fits 
> law is the relation of target size *and* the distance traveled to rech it, the 
> second part is often forgotten)

Note appdash is also meant as a keyboard-driven UI - type-to-search
is a common way to use it, there's full spatial nav across all grids,
cursor col preservation moving in multi grid views, etc. I agree that
mouse interaction is the weak point of a UI like this though.


> *BUT* I think it may indeed make sense to add it by default when a touchscreen 
> is detected. why in that case suddenly it makes sense to have 2 ways to do the 
> same thing? because you have 2 input methods that work in a very different 
> way, with very different constraints *working at the same time* (giving 
> interaction pattern headaches that almost make me understand why apple is 
> insisting to not give touchscreen to macs :p), and on a touchscreen a 
> fullscreen grid of huge icons becomes instead very practical, unlike when you 
> only have a mouse or a touchpad.

I think elevating the visibility based on touchscreen presence could
make sense. How do you see this in practice?

In the a-d matrix from the original mail:

a) Shortcut always available
b) Toolbox entry conditional on touchscreen
c) Hot corner action always off by default
d) Applet never added by default

Sound OK?

My one concern here though is that we'll get "Why is it in the Tool-
box on my laptop but not on my desktop" from users though, and I can't
think of a good way to provide config for this. (Windows actually has
a "Tablet Mode" toggle in Win10 that changes the UI, but I'd like to
avoid this.)


> I think it's worth a step back and see what's behind this use case, that i 
> think it's actually valid:
> * some parts of our current shell are not much touchscreen friendly
> * on touchscreens smoe interesting things can be done, like gestures or edge 
> swipes, that we aren't really taking advantage of.

I'd like to add to this that we've previously determined that
screen-spanning UIs and touch also go well together - bigger
touch targets, and simplified window management. It's why the
Netbook shell had a screen-spanning SAL UI and maximized app
windows by default. Appdash is a continuation of that insti-
tutional knowledge buildup.


> for hybrid laptops, i think there are 2 very different use cases: when the 
> user flips and "transforms" the laptop, a very different, tablet-y shell 
> should be loaded, this is an ortogonal problem to the one described here 
> tough.

Right, but I tried to address this earlier: The above may be
the end goal, but to pull it off well we need to iterate towards
it and learn along the way. We're having a much better shot at
doing a "tablet shell" (or could find out whether it's a good or
not idea) well after doing more tablet-friendly UI. It's in part
about getting from A to B in the context of a three months release
schedule.

Now, personally: I'm not convinced dramatically changing the shell
would actually be a good idea in practice, even if the state pre-
servation is very good. The reason is that with hybrids now, hot
detach and reattach is something that's starting to be done very
casually and for short periods of time. Conversion used to require
a reboot, but on my current laptop I can detach the screen, hand
it to someone to watch a movie trailer and attach it back. For
these quick actions, changing the UI a lot is a higher cognitive
load than temporarily living with UI compromises. Knowing about
the Dash and being familiar with it pre-detach and knowing how to
get to it once detached fits this brain muscle memory thing pretty
well.

IOW: Tablet shell makes sense on a tablet-first device, desktop
shell makes sense on a desktop-first device, but being able to
open / swipe in / trigger-however a touch shell overlay on the
desktop shell also makes sense. (Once again adding that Appdash
also has happy keyboard and mouse users though.)

My thinking here is that shipping an Enhanced Appdash will make
users happy enough to use it, and then we can build on their feed-
back to see where we need to go further to meet evolving demands.


> In this case, having the possibility of having also a mobile-style launcher or 
> to have gestures like screen edge swipes can be really useful.
> Going even more generic, and looking at this problem, I would like the 
> possibility to have edge swipe (sounds like it may be a nice wayland extension 
> even :p) to make appear ui like side panels or fullscreen stuff, the launcher 
> may be even just one of the possibilities.
> Heck, this could even give back the "separated widgets dashboard" that some 
> users are asking back, so I could see the possibility of showing a generic 
> containment shown with one of such gestures.

Appdash from edge swipe sounds really cool. Sounds like this would
be combined with the hot corner KCM?


Cheers,
Eike