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. _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
