HIG and components API

[Thomas Pfeiffer]

On Tuesday 06 October 2015 17:09:25 Marco Martin wrote:
> 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 :)

You are right. Our original idea was to take our ideas to the kde-guidelines 
mailing list before publishing them, but
a) I admittedly forgot
b) Maybe plasma-devel is better to reach all stakeholders (or maybe cross-
posting to both lists) 

> > 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

You are right, and I am sorry. The discussion about the floating button(s) 
came up after the HIG was written, and we haven't reached a conclusion to be 
published in the HIG yet.

> 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

Since the floating buttons are more of a gimmick than something that is 
actually relevant for the interaction, we're not hell-bent on them.
The idea for them came from the  big red round button in recent Android 
applications for the main action. If you have only one button, a toolbar is a 
bit of a waste of space.

The question about the padding brings me to an idea I've een wanting to 
present to you for a while:
One of our basic assumptions is that applications should be comfortable to use 
with only the thumb while holding the phone in portrait mode.

This works well with the side drawers and with the bottom toolbar. One thing 
which would still be difficult to reach is the first item of a list, since 
it's at the top of the screen.
My idea to solve  this is to allow the user to push the list down (meaning 
scrolling up) a little further after the first item has reached the top of the 
screen, so that the first item is somehwere near the center of the screen 
where it can be reached easily. Of course when the list is displayed 
initially, the first item would be at the top of the screen, but it wouldn't 
stop there if the user scrolled further up.
Would that be possible?
And if we did that, we could (and should) do it for the last entry as well, 
and this would also solve the conflict with the floating buttons.  

> > 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.

As explained in my other mail: Consistency plus an nitial tutorial should fix 
this.

> 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?

Sailfish for example, has normal side-sliding in applications, plus the edge-
swipe for system functions. It works pretty well there. The same goes for 
Ubuntu Phone.

> 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?

Especially Sailfish makes heavy use of edge-swipes and they don't 
significantly conflict with normal swipes. The same goes for Harmattan Meego, 
where edge swipe is always there since it switches between running apps. I've 
never had any problem with it.
Still, I get your concern about the slide-to-reveal handles,  but I would like 
to test  on real users (including, but not limited to, ourselves) with some 
interaction prototypes how much of a problem it is before limiting ourselves.

Both iOS and - especially - Android are very conservative when it comes to new 
interaction paradigms on mobile, which we think doesn't do the technical 
properties of a smartphone (a multi-touch screen of a still relatively small 
size) justice. A btton at the top (or bottom) of the screen just isn't the 
most convenient way to open a drawer on a smartphone.

I hope my blog post will help to make it easier to understand why we designed 
things the way we did. That does not mean we ignore feedback, but we have 
noticed even among ourselves that it's much easier to see the benefits of a 
design decision once one knows its background.

Cheers,
Thomas