HIG and components API

[Thomas Pfeiffer]

On Wednesday 07 October 2015 10:40:46 Marco Martin wrote:
> > > Moreover, I'm feeling that the api and the usage of the components will
> > > be quite intertwined with what will be the hig in the end.
> > 
> > What exactly do you mean by that?
> 
> that is very important that things are defined and pretty much final, as a
> change in how those things should behave may in some cases change
> incompatible changes in the components api as well

I agree: The goal must be to have both HIG and components in a stable state.

The thing is: All this needs to be designed in a human-centered way, which 
means iterations. We currently write in those HIGs what we _think_ works well, 
but we cannot tell if it actually works well until we have seen - and 
interacted with - it in action and tested it with some other people.

So, here is my idea for how this should work:
1. We write a draft HIG (like we have done so far)
2. Someone (probably you ;) ) creates the first iteration of a component
3. We test it out
4. We iterate design (modifying the HIG) - build - test cycles until we have 
something that works well
5. Both the HIG and the accompanying component are declared final and API-
stable

Would that work for you? 
 
> > For the Okular case we'd even need tabs in that drawer (as we had in
> > Okular
> > Active).
> 
> yes, i'm continuing it based on that code.
> what i have so far is, by default one can just specify a list of actions and
> they will appear in the drawer, however, in the application declaration one
> can also override completely the contents of the drawer and at that point
> the contents and size are completely custom (from there, is up do the
> developer to not make a mess;)

Perfect! That is exactly what I think makes most sense.

> > I do like the "split drawers" as I called them in Plasma Active in
> > general.
> > The only downside I see is that they may be in conflict - from a mental
> > model perspective - with column-based navigation (people may be confused
> > whether sliding to the side will bring the next column or the drawer).
> 
> true, may also be enabled only when the content is scrolled al the left, to
> look as an extra column
> anyways, i have the skeleton working with two overlay drawers atm

Yes, "Menu as left-most column" is an alternative we have in the back of our 
heads as well, as an alternative if we find that the combination of side-
swiping to scroll columns and edge-swiping to open the menu leads to too many 
wrong interactions.

> > In Plasma Mobile, we have the chance to give more space to the content by
> > removing UI "Chrome" without sacrificing usability, because we can make
> > sure things like the drawers are used consistently across KDE
> > applications. That way, we can give users a quick tutorial at the first
> > start (Sailfish OS is an excellent example of how a tutorial can give
> > interaction designers more freedom for innovation without sacrificing
> > usability) and then allow them to transfer that knowledge to all
> > applications.
> 
> hmm, i don't think all applications would have them and have both

Indeed, but when users can't find a function in the main UI, they know it must 
be in a drawer.

> > This is actually one of the cases where I'd hope we could make the
> > components automatically adapt to the environment they run in. In Android,
> > applicaitons by default have a header bar, which contains both the menu
> > button for the navigation drawer and the overflow button for contextual
> > controls. What I'd like to see is that when our apps run in Android, they
> > draw such a header bar with the two buttons.
> > 
> > Within Plasma Mobile, however, I'd like to give that space back to the
> > content, since a Plasma Mobile user will learn pretty quickly to epxect
> > both drawers to be there.
> > 
> > Would that be possible?
> 
> i have some doubts about the buttons overlaying the content, while is
> technically possible i think it would be a bit hard for apps to ensure some
> important content doesn't get blocked by them...
> what about a toolbar that gets hidden or comes up similar to the one usually
> in mobile web browsers?

Sorry, I didn't express my idea clearly enough: The idea was that on Android, 
the buttons are shown in an App bar ( 
https://www.google.com/design/spec/layout/structure.html#structure-toolbars ) 
like in other apps, so they would not overlay any content.