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