On Tuesday 06 October 2015, Alex wrote: > > * could some content for the global drawer be there by default? do we > > leave a blank slate? even the hig examples are very heterogeneous > > https://techbase.kde.org/Projects/Usability/HIG/GlobalDrawer > > Hi, > thanks for you work. I discuss about the toolbar with Thomas and we agree > that we should avoid any kind of "chrome" in the UI, so avoid the toolbar > and use it only when:
It would be good if such discussions would happen in a mailinglist, so far the scant details about it i mostly got from "i talked with $foo and he thinks we want $bar". This seems a quite vague procedure that also allows very little feedback from developers, would be nice continuing on this thread instead :) > 1) the actions are really intuitive and refers to the current view; > 2) to make the interaction quicker, so only action really frequently used > in that view. > Instead of toolbar we'd like "floating buttons" that suggest better the > fact that the actions refers to the current view and they > appear/disappear/change when the view changes. The floating buttons should > be very few: mainly one in the middle bottom of the screen, 2 o 3 > centered. 4 should be used only in strong-manipulation app. buttons directly over the content? it may look cool, but it may give quite some problems as well. Would also have helped if that was stated in the hig instead of explicitly talking about a toolbar, I can't read minds :p I fear in this case it may make harder to make the bottom of the content, whatever it is to not be covered by the buttons (ie whenever you have any flicking content, it should have padding at the bottom, to be able to scroll out of the way) that makes every single application to have to workaround and assume things on an external design factor that may even change any time > About drawing buttons for drawers: IMO they will occupy too much space and > in certain cases could distract user from his task. I.e. the navigation > pattern that use views-by-column approach focus on navigation and the use > of drawers is not so frequent to justify the drawers' buttons. > Exactly, why is it important for you to have drawers' buttons? mainly two things: one concern is that if there are no other ways than side slide that is hidden, for many users simply they won't exist. second, for some types of apps, I'm finding this in okular and possibly the image viewer, where side sliding may conflict a bit with the flicking around of the document contents, in my experience is not uncommon to trigger not what you were expecting, so may even be worth to disable swiping in certain situations? in the paragraph "Slide to reveal actions" also if i uderstand correctly what would happen is that a lateral swipe would do: * show the side panel if done from the rightmost few pixels of the screen * reveal the actions if is done from the next few pixels, over an handle of the item * go "back" if done from the middle-ish area of the screen it may require a bit too much precision in movements? -- Marco Martin _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
