HIG and components API

[Marco Martin]

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