Mobile-oriented HIG, the first prototypes and the mock-up kit

Hello Planet readers!
Some of you already know me (as Alex L.) for my contributions in the Visual Design Group (VDG). Now it’s time for me to blog a little about my work in KDE, but first of all I want to use this post to introduce myself to you:
I’m an Italian student (Information Engineering), a FOSS enthusiast and GNU/Linux user.
I used KDE software for years, I literally love Plasma, Dolphin and many other KDE apps/projects. I have to thank a lot the KDE Community not only for the great software it provide, but also for the big amount of things I learned, for the improvements in my work-flow (thanks of the KDE’s highly configurable features-rich software) and for kindness when helping me! A lot of thanks also to the great VDG guys, all of them are very kind!
Currently I’m working on Human Interface Guidelines (HIG) for KDE mobile apps together with Thomas, Andrea and Heiko.

I have a lot of things to say, so let’s start!
What are KDE mobile apps? Thanks to Qt & QML our devs are able to deploy apps for many mobile platform: Ubuntu Touch, Sailfish OS, obviously Plasma Mobile (all of these use QML natively) and additionally Android! We will define mobile-oriented HIG so our apps can integrate well in all of these platform and obviously we will introduce our innovations in mobile world! Thomas already blog about this (part 1 & part 2), and now I’m going to update you about recent news; the subjects of our work are mainly three:
1. views-by-columns approach for browsing contents;
2. global drawer + context drawer;
3. the KDE FAB or Floating Action Button according to KDE ๐Ÿ˜‰ (the FAB is that colored button in the right-bottom corner in Android’s apps, introduced by Material Design)

The views-by-columns approach consist into translating hierarchical contents to columns and making user able to switch between columns/pages/views by swiping horizontally (avoiding the need of a back button and I will dedicate a post about this [edit: done]). We are very proud of this approach because it’s very powerful: when you reply to an e-mail for example, you can swipe back to the previous view and then swiping forward to the editing view, without losing contents already written. More details will come to the working progress wiki page, so be quite in questions about this ;-).

The global and the context drawers are two drawers the user can show by swiping from the right and left edges of the screen (by default global by the left, as in Android and the context by the right). The global drawer will be available in any views of the app and will provide actions and options that have sense everywhere in the app. Instead the context drawer change its contents according to the current view and according to eventually selected items; you can consider it the mobile counterpart of the right mouse click.

Global drawer
Global drawer
Context drawer
Context drawer

The FAB in KDE apps will not be simply an action button: since there aren’t an hamburger menu like the Android one to show the global drawer and a button for the context drawer, the user could find two issues:

  1. In the first uses of the app, the user could don’t understand that there are two drawers โ€œhiddenโ€ in the edges of the screen. And also when he will know the could be there, he don’t know which drawers are available in each view, so he could be frustrated trying to show a drawer that isn’t available;

  2. Since we use the horizontal swipes for navigation, the user need to swipe from the edges of the screen to show a drawer, but it could be a little hard, especially if the user need to open a drawer very quickly and he isn’t patient.

So at this point a bulb literally lighted in my head and I suggested to use the FAB to resolve this: the FAB can be moved to left/right to show respectively the context and the global drawers and it can have arrow-like indicators that suggest to the user which drawers are available. You can see a draft of it in the following image:


Again, I will add details about all of this stuff in the HIG wiki page.

What about implementation of these components? Marco works a lot to make prototypes and recently he met Sebastian and together they used them in Subsurface Mobile app for Android, so you are able to test this preview of the components by installing this apk!! ๐Ÿ˜€

Wait wait, the cool stuff don’t end here: since many devs ask to me for mock-ups, I decided to put all the mock-up stuff into an SVG file, making an innovative mock-up kit (here a preview): when you will open it in Inkscape you will see a poor kit, in fact you need to open the layers panel to see a lot of other hidden layers. Play with them making them visible/hidden, edit the texts and replace the icons, so you will be able to quickly do mock-ups for your app using our components. When we will draft more components, I will update the mock-up kit, so you will be able to see news and provide feedback to us during the brainstorm process ๐Ÿ™‚

Mockup kit for phone
Mock-up kit for phone

I end the post by saying that any help in updating HIG wiki page is very welcome, the wiki platform is very useful (and in fact WikiToLearn project is gaining a lot of success).

Thanks for the attention, see you around!

Comments (Markdown supported):

  1. Matthew

    That all looks really cool! One comment I did see (not sure where to stick it):

    On the last mockup, the FAB is covering the bottom list item. On Android, where FABs are pushed to the side, this isn’t a problem. But since KDE is looking to centre them, I worry this could cover important information, as it does in the screenshot. Has this been accounted for?

    My only thought is extra margin space on the bottom, but that would be ugly I feel. Maybe allowing lots of overscroll? Not sure.

    Anyways, good work so far, I keep wanting to get Plasma mobile on my phone (just don’t have time to actually sink my teeth into it currently, so many projects, so little time), can’t wait for the finished project.

    1. admin

      Thanks, about the FAB that cover the contents: the image you see is just to show the mock-up kit, in fact you could choose to hide the FAB and use all the rows I added or to show the FAB and hide the last row. There isn’t a mock-up for this, but since the contents at the top could be hard to reach, we thought to make list more scrollable at down/up to make the contents at the top and the contents hidden by the FAB more reachable. My personal idea is to make the contents fade at the bottom, so in any case the user need to scroll and he haven’t the impression the FAB is covering contents. Currently we set the FAB to hide itself when scrolling a list (you can try by your self through the linked Subsurface Mobile apk). Anyway I don’t think that putting the FAB in the middle makes more difficulties, if it works for Material Design it works for us in the middle ๐Ÿ™‚

      1. Terracotta


        I have to say that, together with trying to get rid of the “back” button, which is too inconsistent to be usable I am impressed with the HIG improvements you guys are trying to make.

        However, as I see it, it seems like the bottom of the screen is the worst place to put the necessary information about what happens for which sliding action. The information what drawer is where, had best be put on top of the screen. It is harder to reach, leaving the screen at the bottom free for quick action items or other things that are more likely to be useful to the user. The quick action for the drawer already is the sliding mechanism, why add two quick actions and loose an opportunity?

        1. “The quick action for the drawer already is the sliding mechanism, why add two quick actions and loose an opportunity?” It isn’t so simple: I’d like to maintain the app very intuitive, and sliding without know what will happen isn’t it. For this reason I want to say to the user: “open the drawers, there you will find everything you are searching for”: all the other quicker actions are only short-cuts to the actions the drawers contain, including the Floating Action Button. The FAB is so the main action for the current app, the suggested one, the one we expect the user want using that app. But I want the user open the drawers, because there are in them icon+text actions and, depending on the drawer, it’s clear if the action refers to the app (global drawer) or to an item (context drawer). For me the drawers will let us to use innovations in interactions maintaining a legacy way to use the app, that are the drawers their selves.

  2. Pingback: Links 6/12/2015: CoreOS News, MediaTek Development Platform | Techrights

  3. When some one searches for his required thing, thus he/she
    wishes to be available that in detail, thus that thing is
    maintained over here.

    1. I can’t understand what you mean…

Leave a Reply