Evolving Appdash

[Marco Martin]

On Tuesday 15 December 2015, Eike Hein wrote:
> I'd like to propose moving kdeplasma-addon's Appdash UI out of
> kdeplasma-addons into plasma-desktop, fleshing it out a little
> more and making it available in the following ways:
> 
> a) Global default keyboard shortcut
> b) Desktop Toolbox entry
> c) Available as hot corner action
> d) Available as a now-optional panel widget

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)

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

> * $user is using a touchscreen laptop or 2-in-1 hybrid in
>   tablet mode. They're using traditional desktop UI elements
>   most of the time (e.g. when getting work done inside classic
>   apps), but some of the time enjoy leaning back and using a
>   more generously spaced, distraction-free UI with bigger
>   touch targets. (Often e.g. as an onboarding experience to
>   a touch-driven UI like PMC/Kodi or a tablet-friendly game.)

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.

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.

The common use is the laptop is still as a laptop, but with a working 
touchscreen, here the normal use pattern is using just the touchpad ~90% of 
the time, but just occasionally here and there touching the screen to do 
stuff, either because a particular thing is easier with the touch screen or 
just because "feel like doing so".

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.
(as a side note, Appdash could just become a generic containment.. doesn't 
have to support widgets.. can even be added in the containment api that adding 
widgets is not supported)
This would even give back the use case i've seen used many times in kde4 of 
the search and launch containment used as main desktop containment)

And also for people to implement new things, ideas, alternate UI pieces that 
can fill that space.


> * $user is of the traditional mouse and keyboard variety and
>   enjoys using a small windowed launcher for activities like
>   drilling down to a specific menu category and app, but
>   prefers using a fullscreen UI for search and exploration-
>   like activity.
> 
> These user scenarios have been encountered on the issue tracker
> and in user venues before in various forms. They exist right
> now, but require some compromises from these users like adding
> a panel applet that may be unused. Competitive pressure
> (several products competing with Plasma Desktop now ship default
> UI addressing these needs) adds to it.
> 
> During the IRC meeting there was some concern about diluting the
> overall UI by having "more than one way to do it", however in the
> above user scenarios this appears desired, because:

yeah, as I said, I would prefer to having it enabled only when a touchscreen 
gets detected, because then the 2 ways to do the same thing become very 
justified.
That doesn't mean it shouldn't be possible to just enable with a click by who 
wants it anyways (and anyways I would like, if it gets in, to be able anyways 
to load different things, like "a dashboard with generic widgets", a fancy 
fullscreen activity manager, a folderview, or $newfancythinginventedbysomeone
 
> As a closing note, since we're dealing in engineering issues
> much of the day, we're sometimes very heavily habituated to
> react to proposals with a mindset of scanning for "what's wrong
> with this". This is an excellent mindset to adopt for code
> review, but it's pretty awful for product evolution. A mix of
> "what's right about this" or "what motivates this" works much
> better.

well, the thing i don't like of the "engineering mindset" is that we're too 
fast to declare that something "sucks" or "is terrible" and I'm very guilty of 
this. This is something I would like us to limit this behavior anyways.

It's always sane tough even in UI work to see and imagine the scenarios when 
something doesn't work, as useful to see the scenarion when it *will* work

seeing it now for mobile components work, I had *many* of "this pattern will 
break badly in $situation" moments that ended up being true, allowing then to 
search for a solution in that case (if the case in which the interaction 
pattern breaks is important enough).

-- 
Marco Martin