HIG and components API

[Marco Martin]

On Wednesday 07 October 2015, Thomas Pfeiffer wrote:
> Yes, components are crucial both for consistency and for the adoption of
> the HIG. A HIG is supposed to make people's lives easier, not harder, and
> components that "automatically" comply with the HIG are an integral part
> of that.
> 
> > 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

> > The main points that I'm tackling now are some aspects of the
> > application: * applications should have two panels that slide from the
> > edges that overlay the app content (shown in
> > https://www.youtube.com/watch?v=4eYPTlUgdZo) * the right panel contains
> > a list of actions that are context specific to the current application
> > "page"
> 
> Ah damn, I made a mistake here: That HIG still reflects the original
> intention of using the Context Drawer only for what on desktop goes into a
> context menu. This is likely to still be true in most of the cases, but
> while thinking about concrete applications, we realised that this may be
> too limited. In Okular, for example, navigating through the currently
> opened document via TOC or bookmarks is specific to the context, but canot
> be done in a list of actions.
> 
> 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;)

> > * the left panel is some "global" actions it may include tool to invoke
> > settings or something comparable to the menubar
> > * the toolbar is at the bottom and contains at most 4 buttons
> > 
> > ----------------------
> > 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
> 
> 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

> 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

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


-- 
Marco Martin