HIG and components API

[Alex]

In data lunedì 5 ottobre 2015 16:50:40, Marco Martin ha scritto:
> UI wise, things that i'm still not sure/not completely agree are:
> * side panels: i have as well one slightly semantically different kind of
> panel in which you slide out the app content to uncover the panel content
> instead (like the web browser on the blackberry where the menu is an
> overlay drawer that enters from the right, the tabs are on the left, and
> the webpage slides away to show them). I like it (and is already there) but
> not so important, overlay panels on both sides are fine as well
> 
> * toolbar: I'm not sure having the side slide panels only to appear with
> edge slide, may be a good idea having two buttons at the screen edges of
> the toolbar, this leaves room for:
> two buttons for the sidebars, aligned at the edges
> 3 buttons of generic actions, aligned in the middle
> ---------------------------------
> Possible problems:
> * the two panels may be always instantiated, even if empty this may be not
> optimal memory and loading time wise
> * toolbar api still no defined
> * 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:
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.

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?

About blank content drawer: imo it should appear if it hasn't contents to 
display. Anyway we should avoid a content drawers without contents, it should 
always contains something: it's like the right mouse clic on desktop, it 
mainly has actions to display and cases in which it doesn't work cause there 
aren't options to display are very rare.