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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
