Task managers on mobile: daydreaming about new possible approaches

With my previous post about killing the back button I got a some scepticism about it from some users, but what was common in all those feedbacks was the approach to manage different apps: yes killing the back button breaks some things, but I wrote it mainly to introduce the real idea: new approaches to task managing on mobile devices.

The following is just an idea, you can see it in this video made by Nils Urbanus (that I thanks a lot):

Or you can see the original mock-up here:

mockup-task-manager-1

The idea is to have on mobile a task manager like the one on desktop, in a thin panel. The user can swipe up the panel that will resize itself and the app icons; when the icons reach the size the user wants, he stop the swipe and tap on one of the icons; instead if he want to “close” the panel without tapping on an icon, he simply need to tap on an other point of the screen or to perform an other swipe (down) to the panel. If the panel is resized over a certain line, previews of the running apps appear.

In the mock-up I add two particular icons: the KDE logo one is intended to be the apps-drawer/kick-off, instead the Plasma logo one is the icon to show the Plasma shell (corresponding to Home button on Android and “show desktop” button on desktops).

My vision for it imply that only running apps are shown, like on desktop, resolving the issue of mobile world where you don’t know if an app is running or not. So you can be totally in control about which apps are running, exactly like on desktop. For the app that runs services in background, an other solution need to be discussed. On desktop we have the system tray, but I don’t know if it will work well on mobile, maybe it could if well implemented from a UX point of view.

This approach has great advantages:

  1. the thin panel always shows to you which apps are running;
  2. it could be there a setting to “hide” the panel: you know the panel is there and you can open it by a swipe, but you have a totally immersion experience, because all the screen is dedicated to your current app;
  3. stop running apps could be very simple and intuitive: we just need “close app” button on top of the previews, but also an horizontal swipe could work;
  4. when you have a lot of running apps, it’s very easy to switch to one of them: the focus of the zoom of the icons depends by where is your finger; alternatively you can resize the panel and scroll the icons with horizontal swipes (or vertical ones if you reach the preview mode);

Since Plasma is known as an highly configurable environment, it could be cool to provide different task manager solutions, both the classic ones (like Android one) and new ones like this.

Please keep in mind that this is just a concept and currently I’m not developing it, it’s just experimental and you could see something different at the end. As always, I like to involve the community into discussions, also into the ones about fresh ideas 😉

Thanks in particular to Andrea Del Sarto for support and feedbacks.

Ciao and see you around!

 

Comments (Markdown supported):

  1. What did you use to create that animation? I suppose rest of the images were made using Inkscape.

    1. Yes Inkscape for the images, for the animation I don’t know, I didn’t it by myself.

  2. A fairly nice idea.

    Generally, both with this and the last post, I’d say that Jolla already pretty much nailed it with Sailfish UI. There all apps that are running are always visible on the home screen (quarter of the screen for each running app, like in your last shot above). If you’re in an app, sliding from the side minimises it, sliding from the top closes it, sliding from the bottom opens the notification area. That makes managing apps really intuitive and fast. And no bloody home/back buttons.

    Your mockup here is pretty much a slight variation that saves some screen space. That does make sense, since you can have plasmoids and stuff. I take it that in the app grid view one will be able to interact with apps without maximising them, like going to the next audio track? I think that’s something that Plasma already handles, right?

    In general it makes me wonder if there would be a way to have some integration to allow running Sailfish apps. Hmm.

    1. I think it’s just a little better than Sailfish’s one, because:
      1) we can use one or two edges of the screen (top and bottom) to manage everything. So we the right and the left edges of the screen are available for the apps, our apps use right and left edges to show global and context drawers.
      2) as you already mentioned, a key feature of Plasma are plasmoids, so we need an “home screen” and put it in near the icons of the task manager seems to be a good way to give it the right visibility
      3) it’s convergence ready: if you plug the phone to monitor, mouse and keyboard the mobile task manager could already work well as on desktop
      Your suggestion about the media controls is really cool! Yes on desktop we already manage them with MPRIS protocol, and on mobile we are going to do something similar, maybe holding volume buttons send next/previous track signals through MPRIS.

  3. Johan Ouwerkerk

    The downside with your proposal, though, is that it is fiddly and worse that it is laborious. With Sailfish OS: 4 simple gestures suffice, but with this proposal there’s some indistinct “middle” ground between a “icons-only taskbar look-alike” and a “app preview grid” that serves no appreciable purpose (what exactly is the point of ‘bigger’ icons: presumably you’d configure the icons to look ‘just so’ at most once, because surely they come at a sane size and resolution OOTB?).

    Additionally, the global “swipe to close” and “swipe ‘away’/to background” gestures really have a powerful impact. It really becomes part of your muscle memory quite quickly, and it makes those two fairly common actions appreciably ‘faster’ to the point that if you move to a platform without them you keep wondering why it’s all so clumsy, laborious and generally awkward.

    I don’t think I can stress that point enough. On a phone, I really don’t care about exactly how big the icons are (beyond maybe a global preference and a choice of icon theme). In the absence of keyboard and mouse for precision input, what I do care about is that the interface works in such a way to present a sense of purpose and deliberate control.

    I feel that sense of deliberation is missing in your proposal. There’s also the minor issue that once you press the ‘back’ button (<|) the UX appears to have forgotten all about it.

    Since it's easy to criticise but harder to offer constructive thoughts, here's a counter proposal for you to rip apart/scrutinise 😉

    Working with the assumption it's only intended for switching between running apps/windows, we can optimise:

    0) Use it as an overlay. The user can dismiss the thing by pressing the (<|) back button again, which is where their finger is already located because of how the overlay was summoned so it's the easiest possible target to hit (again) ?
    1) If the number of running apps is low: just show the full preview/Alt-Tab window switcher look a like. No point in fiddling with icons, though the icons could be overlaid on top of the preview for good measure.
    2) If the number of running apps is high: then you probably want a grid of icons, or even better a carousel that allows the user to swipe for next/previous (block)
    3) For good measure you can include a row on the bottom of items which are always shown by default/pinned. This should probably be limited to a single row of icons, which probably works out to 4 icons/items.

    Based on that some refinements:
    a) You could distinguish between selecting an app/icon using a quick tap and switching to the window/app. Admittedly this is tricky, but still it could be useful because:
    b) In combination with a 'menu' icon under (3) you could use it for task manager 'jump lists' (what Windows 7 has, icons-only task manager) which are menus for common actions. These would work pretty much just the same.
    c) The items under (3) should probably feature a "close everything" button, and depending how you want to work with activities probably a button to switch to the activity equivalent of a window-switcher. (And vice versa).

    Selecting a window is implemented the easiest if the window-switcher box works like Palm Pre OS, because then by definition there's only ever one window in 'focus'. Still, if you want the 4×4 grid which is a bit more space optimised you could have a quick tap (not a long press/press-and-hold because that gets in the way of actual window switching) or drag-to-center gesture for 'focusing'/selecting that window in the context of (3).

    1. Yeap, I agree with everything you said in the first four paragraphs. I don’t see why one would want to change the size of the taskbar, aside from initial setup (after all, on Plasma Shell you do that by pressing on the taskbar settings icon and then sliding the height button; otherwise you want your elements locked in order to not have it be real messy).

      But generally having an icon taskbar is a neat idea, in my opinion. It would be natural to slide it to the sides if you have a lot of apps running, and it’s completely transferable to Plasma Shell.

      1. In my proposal the icons are really little, as the icons in notifications panel at the top on Android (to save screen space). The swipe increase the size so you are able to tap on them.

      2. Johan Ouwerkerk

        > It would be natural to slide it to the sides if you have a lot of apps running, and it’s completely transferable to Plasma Shell.

        Yeah it would be but in the article’s proposal the icons are too small for that in their ‘default’ state…

        … And if you make them big enough you have the problem that they eat up content area for the apps.

        So it would be this really neat thing that unfortunately could only work with a stylus or with sufficiently large screens.

    2. Thanks for your reply 🙂

      – “With Sailfish OS: 4 simple gestures suffice” but in Plasma Mobile only the top and the bottom edges of the screen are available for the system, because the right and left edges are managed by the apps by their-selves (we can’t change this because our apps will run also on Android, where we want to exploit the right and the left edges for global and context drawers)

      – “with this proposal there’s some indistinct “middle” ground between a “icons-only taskbar look-alike” and a “app preview grid”” probably I should have been clearer here: the “middle” is only part of the animation that brings you from icon-only to previews; I didn’t mean that you can manage so big icons, instead when with the swipe you “outmatch a certain line” the animation start (as happen for Android’s notification drawer) but that line don’t correspond to the “big two icons” but is nearer the bottom.

      – “Additionally, the global “swipe to close” and “swipe ‘away’/to background” gestures really have a powerful impact.” the swipe to come back can be managed by the apps, but the system shouldn’t manage a swipe inside an app: your proposal imply a close link between the system and the app and we can’t do it because, as I said, we are designing both Plasma Mobile and mobile apps HIG to allow Plasma Mobile to run well other platforms apps and allow our mobile apps to run well on other platforms. For your future suggestions you should keep this in mind…

      – About the back button: I already explained in my previous post why it shouldn’t exist: it’s a system provided thing that pretends to manage an aspect that belong to the app, so it’s a really big problem in making system and apps independent to realize the cross-platforms support I just mentioned

      Did you proposal imply a bottom bar with buttons? My proposal has the following aims:
      1) making the panel very thin, like the Android top one; so we gain space for the running app; we can also set it to auto-hide so the running app can have all the screen and you maintain the control since you know the panel is there and you can use it by a swipe
      2) have always the running apps icons under your eyes: the icons are little like the Android notifications one, but you will be able to distinguish them and always know which app is running
      3) be convergence-ready: we should share as many components as possible with the desktop, to keep quick the switch of the interface. This task manager could be used on desktop as a traditional one, without involving any swipe

      1. Johan Ouwerkerk

        As to your first objection: I don’t really see your point. On Android people use Android’s mechanisms for switching between apps and you shouldn’t try and second guess that design even if you think you can do better. If people want better they should use Plasma Mobile instead of Android. Specifically your apps shouldn’t try to co-opt OS/shell level features.

        Meanwhile, on Plasma Mobile (the OS) the system can provide whatever the ‘right’ UX is, without regard for ‘how it is done’ elsewhere because Plasma Mobile != elsewhere and it’s about time to do it better. 😉

        Moreover it’s not up to the app to manage such global interaction with the OS. If you do it that way you design for utter and abysmal failure because you rely on the app developer to get critical, core OS functionality (and get it right). That approach is fatally broken and it cannot be salvaged. (What if an app hangs and doesn’t respond to input? What if the app is ‘foreign’ and simply doesn’t implement the necessary features at all?)

        Instead your desktop shell/compositor should take care of it. And at that point it also means that you are not bound by in-app constraints. So in the Plasma Mobile OS you can use whatever edges or input you fancy by design.

        Also I’m not sure if you understand that in the context of Sailfish OS there is a distinction between these global gestures and in-app gestures which can also be from any direction. The distinction is simple: the global ones start at the edge/from ‘outside’ and move inwards. So these global gestures can work without interfering with in-app gestures in the same direction (or vice versa).

        All in all I simply fail to see what makes you conclude that you only have two edges of the screen to work with, but that might be besides the point. (There’s something to be said for not overloading the gesture mechanism too heavily which would introduce a learning curve, a criticism leveled at Sailfish OS initially.)

        I’ll tackle your next points in a follow up reply (this one is getting long as it is…)

        1. The important point here is:
          we are trying to untie the apps from the system (since we want to run the same apps both on Android and Plasma Mobile and we want Plasma Mobile runs both our apps and Android apps). Since we can’t know how the app (for example Android one or a game) manage the swipes, we can’t define global system-provided gestures inside the app. So we are using the edges of the screen, so the gestures inside the app are managed by the app and the gestures on the edges are managed by the system. But Android apps use the left edges of the screen to show a drawer (an some apps also at the right one). So we decided this: right and left edges of the screen are managed by the apps (our ones, Android ones etc) instead the system can manage the top and the bottom edges of the screen (no problem here with Android apps since Android itself has a status bar at the top of the screen and they don’t use the bottom edge).

          About the back action: is a thing managed by the app itself since the swipe happen inside the app’s screen space. The swipe-to-back action will work in our apps both for Plasma Mobile and other platforms, but additionally for the platform that provide a back button (Android) the user can use ALSO that button (this imply that if a Plasma Mobile user want a back button he can have it easily and both our apps and Android ones are ready for it). About Android apps on Plasma Mobile, obviously we have to provide a back button at least when an Android app is running.

          About the swipe to close/hide an app: I totally disagree since this means that the system have to know how the current app work to grab correctly the swipe-back action. Yes we could provide it for our apps, but we should force developers to implement things, and we can’t provide it for Android apps.

          1. Johan Ouwerkerk

            > Since we can’t know how the app (for example Android one or a game) manage the swipes, we can’t define global system-provided gestures inside the app.

            No, the important point is: that objection is irrelevant. You don’t need to know anything about the app. Here’s why:

            A) It doesn’t apply to apps at all. It applies to the OS/shell. Apps are a given but the difference between apps is for the purpose of this discussion ultimately only a distraction.
            B) On Plasma Mobile, the OS, you have something like kwin and something like plasmashell running. Kwin is in charge of dispatching input events to apps, meaning kwin has full control of which input the app sees and which input it doesn’t.

            That’s how you implement the distinction between global gestures and in-app gestures: global ones are simply never delivered to the app but to some other process (i.e. likely kwin’s internal logic itself). This is also how Alt+Tab works in a Wayland desktop environment.

            And it works, even when the apps use the screen edges for their own purposes. I cannot recommend enough that you check out the Sailfish UX for yourself, and play with it. I think it all becomes kind of glaringly obvious once you’ve seen it in action… and more importantly ‘felt’ it. 🙂

            > But Android apps use the left edges of the screen to show a drawer (an some apps also at the right one).

            Sure, and on Sailfish OS apps typically use the top edge for invoking a menu structure (pulley menu), some use both the top and bottom edge for that. But the OS still defines the top-to-bottom swipe as a global gesture and the two still work separately and independently and both do not interfere with each other.

            It’s simply a function of doing the thing in the right component. These system level features should be implemented in a system level component as a matter of good technical (code/systems) design anyway, and as a side effect of a good technical architecture all your objections and problems simply never materialise:

            >About the swipe to close/hide an app: I totally disagree since this means that the system have to know how the current app work

            Wrong: because the app is irrelevant. All the logic would be limited to and contained within kwin (the compositor) and plasma (the shell). That is also why it is a OS feature and not an app feature, by design.

            > to grab correctly the swipe-back action.

            Wrong: because the app only gets a gesture once the system (kwin) is sure that it isn’t a system level one. Otherwise it goes to kwin/plasma. Just like how Alt+Tab, Alt+F2, Ctrl+F1, Ctrl+F2, Ctrl+F3, Ctrl+F4, Ctrl+F8, Ctrl+F9, Ctrl+F10, Ctrl+F11, Ctrl+F12 or any other global keyboard shortcuts work on a wayland desktop KDE session.

            > Yes we could provide it for our apps, but we should force developers to implement things,

            Wrong: It’s only the developers of the system level components (kwin and plasma itself) that would need take care of it. App developers do not need to bother with it.

            > and we can’t provide it for Android apps.

            Wrong: on Plasma Mobile OS you have kwin and plasma, and because the apps are not involved themselves … all apps get it automatically, by design!

            That still leaves you with the question of whether such a design is a good idea/whether you like it. But the technical objection you raised is simply invalid (as explained above).

          2. As I just said in an other comment: you totally misunderstood what I mean, I know that your objections are correct, but you are trying to convice me that the system provide apps management features, and obviously is right. I don’t know why, you thought I was talking about HIG/KDE-apps, right? But I didn’t say it, my post was about Plasma Mobile (the system) from the beginning…

      2. Johan Ouwerkerk

        As to your second point/clarification: so you have essentially two “levels”. Level 1 is a simple overview of (tiny) icons indicating what (or at least *something*) is running, Level 2 is when you complete the gesture and it morphs into your equivalent of an Alt-Tab window-switcher box? The rest is just animation feedback to let the user know the morphing is happening.

        That seems a good deal clearer already. I’m still not sure though. I suppose it hinges on the answer to the question:

        Are you optimising for the right thing? I.e. do people use the taskbar to switch between windows/apps or do they use it to look at for status information (what is running) frequently? And do they check this so frequently that a convenience gesture becomes relevant?

        I’m not being glib: in effect the full size window switcher also offers the same status information as the little icons mode anyway, the icons mode simply compresses the information down to a smaller and simpler visual indicator (at the cost of obscuring exactly how many app windows there are and limiting/prohibiting interaction with the visual indicator itself).

        Now, if the answer is ‘switching’ then there’s still no point to bother with the status info and you can go straight to the full featured mode instead and simplify the whole UX in the process. Unless I’m still missing some interaction that applies?

        Additionally a downside is also apparent: glancing doesn’t really work. You still need a gesture to get to the row of icons either way. As a result: will a clumsy user like me see their fingers/hands obscure the little row of icons? And what once the number of open apps/documents starts to become large… ? In a vertical orientation, even with tiny status icons there’s not really that much room (a direct consequence of the physical dimensions of the screen, regardless of its resolution) …

        Actually, to reiterate: I would take the option of ‘auto-hiding’ panels and in particular ‘auto-hiding’ taskbars as an indicator that people who use that feature don’t ‘glance’ at all, but rather look deliberately for particular information. So those people might not care all that much for tiny icons as status indicators, but that’s maybe just my bias. (I’m one of those people who set their panel to auto hide in KDE.)

        Or do you mean to use the two-level approach as a way for users to ‘cancel’ out by aborting the gesture before the full size window switcher appears? Note that if you set aside your objection to using a button that many handsets happen to be equipped with you get that for free (see point 0 of my alternative proposal for sparring purposes). Also if you do your window switcher more cleverly (like the Alt-Tab switcher actually already works) the app from which you navigated to the window switcher would be in the foreground already (giving you a convenient way to go back without altering mental or system state). So it’s not *really* vital to have the explicit cancellation mechanism either, though could be nice.

        … More to follow.

        1. >As to your second point/clarification: so you have essentially two “levels”. Level 1 is a simple overview of (tiny) icons indicating what (or at least *something*) is running, Level 2 is when you complete the gesture and it morphs into your equivalent of an Alt-Tab window-switcher box? The rest is just animation feedback to let the user know the morphing is happening.

          No, there are 3 levels:
          1) thin panel (like Android top one); you can’t tap on the icons;
          2) states of the resized panel and icons; you can tap on the icons and scroll them horizontally if they are too much; clarifications: there isn’t a defined size; the user resize the panel at the size he wants > stop the swipe > tap on one of the icons
          3) if the panel is resized over a certain size (~3-4 visible icons) an animation start and bring you to the full-screen previews state;

          The 1) is for knowledge of current running apps; the 2) is to switch to an other app; 3) is to have an overview and previews of the apps.

          I hope that know it has sense for you.

      3. Johan Ouwerkerk

        The specific ‘swipe to close’ and ‘swipe away/to background’ are global gestures on the system/OS/shell level. They cannot be managed by apps, or at least they ought not to be.

        So these could apply only within the scope of Plasma Mobile as an OS and not to the in-app HIG. As I explained in a previous reply (two up) these gestures can be implemented not to interfere with in-app gestures either, regardless of whether the app also implements gestures in the same direction using the simple distinction of the screen edge.

        Still nothing says you absolutely have to use them, just that experience with the Meego (N9) and Sailfish OS (Jolla) strongly hints at these two ideas being “just that good”. Rather like sliced bread. 😉

        Getting back to your objection… These ideas only apply and can only be implemented on the system/OS/shell level feature for the same reason that the window switcher must be implemented there: you cannot rely on apps to get this right. (Again: what if the app is stuck? What if the app is ‘foreign’ and simply doesn’t acknowledge your HIG?)

        Think of swipe to close as Alt+F4 (or Ctrl+W or Ctrl+Q), and the window switcher as Alt+Tab on the desktop. These are not just nice ways to conveniently manage apps but they are also your emergency ‘ejector seat’ fall back options to recover from a broken/stuck/dead/insane app. And just like the ejector seat in a fighter plane, it has to work fully independently and autonomously from the potentially flaming deathtrap that the app might have devolved into. Hence the need for these features to be managed as part of the system/OS/shell/compositor (and hence why, to me, it makes no sense to speak of constraints imposed on apps in this context).

        The fact that you want the Plasma Mobile apps and HIG to work well on Android doesn’t really change what I wrote before. In fact I’d argue that is quite irrelevant precisely because of all that: the scope is different. So on Android those goodies are simply not available but something else which is Android specific instead. That may be Android’s loss but not really a reason for the Plasma Mobile OS to follow Android’s lead and compromise on the OS level UX either.

        Of course if you think these gestures/things are inferior to what Android or something else offers then that’s another discussion entirely.

        1. >Think of swipe to close as Alt+F4 (or Ctrl+W or Ctrl+Q), and the window switcher as Alt+Tab on the desktop.

          Yes and in fact the problem isn’t the close/hide action itself, but how it is performed: we can make the system aware if it can use the swipe to close the app or currently the app need to manage that swipe (we could find a way for our apps, but not for the Android and Ubuntu Touch ones).

          >The fact that you want the Plasma Mobile apps and HIG to work well on Android doesn’t really change what I wrote before.

          No, very important point to keep in mind: we aren’t defining HIG for apps for Plasma Mobile. We are defining HIG for KDE’s mobile apps that will run on Android, Ubuntu Touch and Plasma Mobile. Since we can’t control Android and Ubuntu, we have to adapt our apps to run well on them, and we have to define Plasma Mobile to manage in a better way our apps and other platforms’ apps.
          Think about Plasma Mobile and KDE mobile apps as separated projects: Plasma Mobile has to manage other platforms’ apps. KDE mobile apps are apps designed for all these platforms at the same time.

          1. Johan Ouwerkerk

            > No, very important point to keep in mind: we aren’t defining HIG for apps for Plasma Mobile. We are defining HIG for KDE’s mobile apps that will run on Android, Ubuntu Touch and Plasma Mobile.

            Yes but beyond that you also are defining something global in this very blog post that transcends the app and is a system/OS/shell level feature. So the fact that you claim the HIG is just for apps and not for the OS is somewhat … strange.

            Note: your design cannot work on the app level. It can only work if implemented on the compositor/shell (kwin & plasma) level which means, by definition, that it can only work on the Plasma Mobile OS. Because neither kwin nor plasma shell are available (by default) on Android or Ubuntu Touch or any other mobile platform.

            > Since we can’t control Android and Ubuntu, we have to adapt our apps to run well on them, and we have to define Plasma Mobile to manage in a better way our apps and other platforms’ apps.
            >
            > Think about Plasma Mobile and KDE mobile apps as separated projects: Plasma Mobile has to manage other platforms’ apps. KDE mobile apps are apps designed for all these platforms at the same time.

            Yes, but that is not a causal relationship. You should try to define the UX of your apps to work well, generically, based on what hardware will be commonly available to them with some exceptions. You should also try to define a UX for the concept of managing apps, and for launching them and for all the other shell level bits that a phone needs.

            But those two are only tangentially related, and when the app can simply be ignored as with global features like this there’s no reason for Plasma Mobile OS to ‘compromise’ or be held back or anything like it just because you also want to run apps that aren’t native to the platform.

            However, that aside you leave me somewhat confused. On the one hand you imagine issues which turn out not to be a problem within the required technical architecture anyway; on the other hand you seem oblivious to the fact the same applies (or rather doesn’t) to your own task manager design.

            Then on top of that you want to consider a split between “KDE Mobile apps” and “Plasma Mobile” in this discussion about task managers/window-switchers and global gestures/features when, to me, it seems that this discussion could only ever apply to “Plasma Mobile” and the exact nature of the apps are merely window dressing (in the context).

            Could you humour me, and write down how you think your proposal would work technically (i.e what component/process does what) and how you think the concept of these Sailfish global gestures work? And finally where the split between HIG for KDE Mobile apps and Plasma Mobile comes in, and how that differs according to you between the two different schemes?

            That way I can better understand where you are coming from and clear up any misunderstanding on your part as well, because right now your post is confusing me a bit.

          2. In fact this post is about Plasma Mobile, not about mobile HIG… This post is a possible way for Plasma Mobile to manage apps. Someone could say: “and the back button?” and because of that I said in a previous post that the system shouldn’t provide a thing like the back button that should be instead managed by the app.
            At this point I think that all the discussion was a big misunderstanding…

      4. Johan Ouwerkerk

        So for the last bit of your reply:

        > – About the back button: I already explained in my previous post why it shouldn’t exist: it’s a system provided thing that pretends to manage an aspect that belong to the app, so it’s a really big problem in making system and apps independent to realize the cross-platforms support I just mentioned

        And I agree. But when you kill the back button for the in-app UX, then you suddenly find yourself with some redundant button and at that point you might as well *repurpose* it. If that button is located where it usually is then it also interferes with your scheme of swiping from the bottom up. Meanwhile my scheme interferes with Android apps that don’t do proper management of the back button by themselves (though that is easily fixed, ironically enough by using a swipe gesture…).

        Again, this discussion only applies to running the full Plasma Mobile OS environment, so with that in mind let me ask a question: what if there are no Android apps involved?

        What to do with that button then when nothing else uses it? It *is* rather convenient, and if you recall my comments on your previous blog I think both it and the search button could be repurposed for global (system/OS/shell level) actions that are quite independent from the app.

        The weakness in my idea is Android apps that do use the button and expect it, though:
        a) The idea only applies to Plasma Mobile OS, in which context Android apps are going to depend on a lot of things that aren’t there anyway… Like Google’s services.
        b) It can be worked around, as the idea is just as applicable to being activated with a swipe.
        c) Or conversely: as yet another job for the compat bits for Android apps. Which isn’t all that strange when you think about it: some Android phones allow you to reprogram these buttons anyway, and furthermore it’s also exactly the same case on hardware that doesn’t have these buttons (like the Jolla).

        > Did you proposal imply a bottom bar with buttons?

        Yes but only when in Alt-Tab/window-switcher mode, where it would be visible on the bottom as row of a few standard icons (so you’d have a slightly smaller content area for window previews). Not when the app is running in the foreground. My idea is based on the assumption people don’t care all that much for the status icon aspect because they can get that just as well with a quick tap on the button/swipe to get to the window switcher and get out quickly again — rendering this information available to them about just as easily (subjectively).

        > My proposal has the following aims:
        > 1) making the panel very thin, like the Android top one; so we gain space for the running app; we can also set it to auto-hide so the running app can have all the screen and you maintain the control since you know the panel is there and you can use it by a swipe
        > 2) have always the running apps icons under your eyes: the icons are little like the Android notifications one, but you will be able to distinguish them and always know which app is running

        Okay so that’s another thing that I missed: this is meant to overlay the app in the foreground so it either is hidden because the user configured it or ‘always on’ like a true taskbar? Yeah my idea definitely doesn’t feature/consider that. I’d say that if people set it to ‘hide’ they kind of defeat the design though.

        > 3) be convergence-ready: we should share as many components as possible with the desktop, to keep quick the switch of the interface. This task manager could be used on desktop as a traditional one, without involving any swipe

        I don’t really buy this argument. As far as I am aware, in the context of KDE the convergence story has never been (publicly) about running the same UX but about providing multiple UX implementations on top of the same software stack (reusing underlying engines/data/info/concepts). The distinction is subtle but important: it’s not about re-using UI components per se (though this is quite useful), but about making sure that the UI can adapt and change from UX to UX as required.

        Keeping vestiges of the desktop UX around just to make it ‘more desktop-y’ is kind of besides the point in that version of convergence, I’d say.

        In that sense the only reason to have a little strip with app indicators/icons is if that makes sense on its own and can survive scrutiny on its own merits even without convergence being considered.

        Convergence by itself is a weak argument for UX: when you do things that way and retain ‘same-ish’ elements purely for the sake of convergence, you wind up with Windows 8 where part of the desktop behaves like a tablet just because it primes you for how things work on the Windows 8 tablet — regardless of whether it makes any sense on the desktop. Failure is the result.

        Not saying that’s what your proposal amounts to, just that I think it should be evaluated and judged on its own merits as a stand alone UX.

        1. >a) The idea only applies to Plasma Mobile OS, in which context Android apps are going to depend on a lot of things that aren’t there anyway… Like Google’s services.

          We can provide something like this to replace Google Play Services:
          http://forum.xda-developers.com/android/apps-games/app-microg-gmscore-floss-play-services-t3217616/

          >As far as I am aware, in the context of KDE the convergence story has never been (publicly) about running the same UX but about providing multiple UX implementations on top of the same software stack (reusing underlying engines/data/info/concepts).

          Yes I know it, but a component shared between UIs could be only a good thing if it offer a very good experience on both the form-factors. My task manager could be a plasmoid: it will works as the traditional task manager on desktops and it will works as I described in touch-enable devices, and the plasmoid itself is the same. This means less efforts to maintain it.

  4. Johan Ouwerkerk

    As for launching things: that’s where the search button comes in handy and should probably present a search-and-launch like UX.

    So the back button is, in essence always “back to overview of running things” and “search” button is always “activate search-and-launch interface”. (Or activate apps-drawer if you will.)

    That way your distinction between the “apps drawer” and the “desktop” is taken care of automatically also, and it doesn’t require injecting a ‘fake’ app preview thing either.

  5. STiAT

    Completely wrong approach. A mobile UI needs to be completely different to a DesktopUI. The usage patterns are completely different. That’s why the UI needs to be completely different.

    If you want to know how it could look like, look at Jolla. That is a very good solution of task management, which would pretty much be your last screenshot just with features.

    1. “A mobile UI needs to be completely different to a DesktopUI” I know it but my approach is designed to work well on smartphones. It’s just an alternative task manager, I don’t want to force anyone to use it: it’s like on desktop, were you have icon+title task manager and icon-only task manager. There are users that prefer this approach and users that prefer the Android’s one. No need to discuss which is the better, instead we should discuss how to make each approach better.

  6. Johan Ouwerkerk

    Okay, Alex: so continuing our previous discussion it seemed that we were kind of talking past each other. As for me, I think what confused me and let me to mistake your intended meaning entirely was your use of words like “inside app”. To me that sounded like you wanted the app to do something, but looking back it seems you meant the perspective of “when a user is busy inside an app”. Am I correct?

    If so, yeah that changes things. So in either case we have something that is being managed by the OS/shell but the difference is in what is immediately visible to the user.

    I have to say though that your icon strip, if it cannot be interacted with until you make it bigger has the obvious benefit of being more ‘discoverable’ because it is always visible in Plasma Mobile… but equally, it also has the downside of taking away valuable screen real estate. Especially on smaller screens (and doubly so on low resolution ones, though that’s kind of becoming a thing of the past with 1080p screens being fairly ‘standard fare’ already).

    Another issue is that with really tiny icons is that they tend to become indistinguishable.

    So how big or tiny are these ‘tiny icons’, physically?

    All in all these are kind of… things I’m not yet quite convinced by more than “real glaring problems”. So there’s that. Maybe it’s just my bias coming from the N9/Jolla… With your clarifications (about the resizing) it seems your proposal is actually better than it first appeared to me.

    Going beyond this, I’ve got a few questions:

    1) Does your design support the MPRIS style icons for play/pause/ etc.? How will that look?
    2) Related: does it also support something similar to Sailfish OS cover actions or jump lists? (I.e. a number of arbitrary actions that may be invoked directly on the app without necessarily switching to it in the foreground, with possibly a fixed limit on the number of actions that an app may provide/expose.) One could view the MPRIS things as somewhat of a special case of this mechanism.

    1. Sorry for the misunderstanding 🙂

      >So how big or tiny are these ‘tiny icons’, physically?
      I think the same as notifications/status icons in Android’s top bar, it that ones are distinguishable then mine should also be distinguishable enough… remembering that in Breeze we have very good small mono-chrome icons (mainly for actions, apps currently miss them) and we should have big problems in make small but distinguishable icons.

      >1) Does your design support the MPRIS style icons for play/pause/ etc.? How will that look?
      I think that a good solution could be to put the media controls over-layered the app preview in previews mode…

      > 2) Related: does it also support something similar to Sailfish OS cover actions or jump lists?
      Referring to jump lists (for example “new document” etc in right-mouse-click menu on app icon desktops) I don’t see it as very useful on mobile devices. A possible solution could be that, after the partial resize of the icons, you can perform a long-tap to show a menu with jump list entries…
      Instead about non-MPRIS exposed controls by the apps, I think that if in future we realize the DWD project (Dynamic Window Decorations: https://kver.wordpress.com/2014/10/25/presenting-dwd-a-candidate-for-kde-window-decorations/) we could use those controls in plasmoids that we could put both on home-screen/desktop and panels.

Leave a Reply