N9 Swipe undocumented feature; activate sane behavior

Ed Page recently blogged about his idea to improve the Swipe UI. Fortunately for him, a bunch of people and I had the same idea inside Nokia ๐Ÿ™‚

Update: apparently this is not present in the images distributed with the Nokia N950’s, it was introduced after 25-3.

If you open ~/.config/mcompositor/mcompsitor.conf, you’ll see a bunch of swipe-action-foo configs, all of them set to “away” (by default).

You can, however, change them to something like:
swipe-action-up: switcher
swipe-action-down: close
swipe-action-left: events
swipe-action-right: launcher

And voilร ! Now depending on which direction you swipe, is the action that would happen. You need to kill mcompositor for them to become active (or send SIGTERM/SIGINT, I don’t remember which one).

This was possible because I got fed up arguing about the benefits of swiping down to close applications, and decided to implement the thing by myself. While doing that, I also decided to implement an idea that was flying around, which was to do something different depending on the direction of the swipe. It took me about two days to do, including making it configurable, mostly trying to familiarize myself with the code that was split into multiple packages, and wrapping myself around C++, which I have avoided as much as possible. That was much less time than the time spent discussing before and after I implemented the patches. Fortunately, after seeing the thing in action, many people jumped into the wagon, and at least swipe down to close is available to the masses, which people seem to like. Guerrilla design ๐Ÿ˜‰

However, after a lot of though, I realized the configuration I mentioned above is ideal. And this is my rationale:

Rationale

The current design is inconsistent; when you swipe away, you never know in which desktop view you are going to end up, specially if you just unlocked the device. You might end up in ‘switcher’, or ‘launcher’, or ‘events’. Same action, different behaviour equals inconsistency.

There’s a simple solution; utilize the simple mental model required to navigate the desktop views.

Swipe mental model

In this way, it’s easy to know exactly what would happen when swiping on each direction, decreasing the amount of actions needed from the user. The same action always produces the same behavior.

It is unclear if this mode is ever going to be officially supported on the device, despite the fact that I think it’s obviously superior (and Ed Page seems to agree, as he came with the exact same idea by himself), maybe some people are worried about updating manuals and what not, but at least it’s trivial to activate, and anybody can create a 3rd party app for that ๐Ÿ˜‰

BTW. This is yet another reason why I distrust people telling me I’m a “geek”, and “designers” know better when it comes to design. In the words of Elaine Morgan; yes, they can all be wrong, history is strung with occasions when they all got it wrong.

Enjoy ๐Ÿ™‚

44 thoughts on “N9 Swipe undocumented feature; activate sane behavior

  1. Don’t forget to add that it is available only in N9 firmware versions after N950 22-6 developers firmware was published. So it is not accessible yet for people with N950 — until they’ll get SDK and firmware update, hopefully soon.

    Like

  2. Unless I’m misinterpreting due ambiguity of directions, I think I would have preferred up/down swapped. There are several reason (1) I’ve never used webOS but I immediately thought of imitating how they did it both because it is a precedence and their designers probably had reasons, (2) a down could be likened to minimize (only geeks would catch on to this one), (3) even the body language would seem to match with this pattern, up would be away from you and unwanted while down would be towards yourself to keep it.

    Oh well, either I’ll have to get used to it or just update the config file (once available)

    Like

  3. +Ed Page That’s why there’s a configuration file ๐Ÿ™‚

    Anyway, I think it’s better to swipe down to close because it’s harder than swiping up; the easiest move should trigger the most common action you want; swipe away.

    Like

  4. Pingback: Felipe Contreras: N9 Swipe undocumented feature; activate sane behavior | MeeGo

  5. +1 – And purely because FelipeC rocks so much, we have this configuration now on the device. He was insanely persistent on pushing for this and finally we all conceded. Brilliant! And let’s do a tool soon for everybody to easily change these things.

    Like

  6. This is, in a nutshell, why I’m so sad Nokia is jumping ship (or off the torched platform, I guess I should say), I can’t see something like this happening on any other platform or really from any other current big company. Kudos! This kind of care and thought put into software is very, very much appreciated by us users downstream.

    Like

  7. I think it’s great work being done by the guys who have access to the early devices. My thoughts on swipe gestures are that swipes up or down to do a preset action that relates to navigating throught the phone is really the starting point. We don’t have to agree on everything but a consensus on the basic defaults would serve to get this to move foward. From the demoes I’ve seen side swipes take you to a homescreen and minimises the app. From what FellipC pointed out the homescreen you get is a lottery if you didn’t know the privious state. In any case that maybe too much to expect of ordianary users. I propose that the side swipes remain as they are but only add regulation on left or right swipe always going to either launcher or switcher respectively. Also leaving swipe up to be used as an application options launcher for example. Swipe down with direction would exit to a specific homescreen as shown in the article.

    Like

  8. I agree the current setup is incongruous, but I have a small tweak with explanation:

    swipe-action-up: launcher

    swipe-action-down: close

    swipe-action-left: events

    swipe-action-right: switcher

    I transposed your switcher and launcher swipe directions because of logic. you already do a partial up swipe for the quick launch icons. Its almost like a mini launcher already (which would be sweet to mod to have two rows of shortcuts, 4 configurable), and connecting the up swipe to launching apps is natural in practice.

    This is crazy, because I just talked about this just today on FB with an associate! looking forward to seeing it work for the masses…

    Like

  9. Good work! It’s a shame that something so logical and obvious to many has not been considered by the designers who nonetheless have done a pretty decent job with the rest of the system.

    It would be good if the lock screen did the same if you haven’t done that already. I also hope that the sliding animations can match up with this change, i.e. if the launcher home screen is accessible by swiping up then when an app is launched from that screen it should slide in from the top.

    Taking the idea further I would like to see these swipes be the same even for the home screens themselves, i.e. swiping up on the events view would show the launcher screen and swiping right would show the .

    I would like even more power with the configuration of this, specifically each of the four swipes could be configured to switch / launch any specific application with a swipe, e.g. I think I would prefer to have the search application as swipe up from anywhere rather than the application launcher home screen. The close action could do with being expanded so you can close the app and switch to a specific home screen / app.

    It would also be useful to have a ‘last-app’ action so e.g. when you view an appointment in the calendar and tap to view the location in maps then a swipe right could take you back to the appointment saving you from having to go to the switcher home screen first. I know this would require an application stack to be maintained but I think it would be very intuitive and useful. This swipe action could also be expanded to allow a fallback action (like ‘events’) to be specified for the times when the app stack is empty.

    Finally, having application / home screen specific swipe configuration to override these global defaults might be another nice addition, e.g. swipe down on a home screen could lock the device, or swiping left / right could be disabled for certain apps like the photo browser or when the swype keyboard is active.

    My personal configuration (with these changes) would be:

    swipe-action-up: search
    swipe-action-down: close && lock
    swipe-action-left: switcher
    swipe-action-right: last-app || events

    Like

  10. Please make the swipes completely configurable, and the double tap gesture too, this would be amazing! Imagine the possibilities? Swipe down to lock, swipe up for dialer, swipe up for settings/down to close app, swipe up to lockscreen/down to close app, double tap to close app!

    Like

  11. I really like the hack (just interchanged left with right action), but still there’s room for improvement. There were some nice ideas in comments above, I have some, too. For example, when closing app by swipe from up it should be configurable what the user wants to see. Now it’s usually the switcher. I’d like to see either launcher (in most cases) or last app (especially, when closing one of multiple browser windows – I’d like to see a page I had when launched a new one with “open in new window”)

    Like

  12. Whoops, I left a sentence unfinished. Had too many thoughts distracting me! Should have been:

    “Taking the idea further I would like to see these swipes be the same even for the home screens themselves, i.e. swiping up on the events view would show the launcher screen and swiping right would show the events view. Note that the carousel behaviour of the home screens would still be there when scrolling off the left and right of the screens, this would just change the swipe from edge of screen behaviour.”

    Another thought to take swiping even further would be to allow configurable gestures after starting the swipe. We already have a swipe up then pause gesture for showing the mini launcher. That could be configurable for each direction. Another gesture could be to flick in a different direction at the end of the swipe, e.g. swipe down then flick right could close the app and switch to the previous app, swipe down then flick left could close the app and switch to the switcher home screen. Making the animations fit might be a bit tricky with that though.

    Jay: I’m not sure overriding double taps is a good idea as it is something you might want to do in an app, e.g. to select a word.

    Like

  13. Nice feature Felipe
    One guestion. Do these follow accelometer? if you rotate the phone landscape/upside down etc. , Does the swipe directions adapt to the current orientation of the phone or are these locked to the default upright position. Because I could see getting disoriented. if I’m on landscape and swiping from the current top (normally right side) of the screen, I’m expecting it to close the application, because this is what would happen, if i was on portrait and swiped from the top of the screen.

    Like

  14. @Martin Alderson: I actually demoed my idea with mockups of the lockscreen. Felipe commented the following on my post:
    “””
    However, I disabled that on the lock-screen. Maybe that should be changed…
    “””

    @variaatio: I don’t know what is implemented but not sure how much work they’d put into this seeing as landscape is not officially supported on the home screens.

    Like

  15. Whoa! Comment overload.

    +Urho Konttori Thanks! I was certainly pleasantly surprised that the swipe down to close made it to the final product in the form of a config. That’s more than I expected ๐Ÿ™‚

    +christexaport That’s a good point. I implemented that before the quilck launch bar was implemented. Anyway, the “close” action goes back to the switcher view, which makes sense because then you can see the close animation, therefore, I think it makes sense that swipe up goes to the switcher (symmetrical).

    +Martin Alderson Those suggestions might be worth exploring, but unfortunately I think they would require a lot of changes, which would probably mean that if somebody tries to explore them and they turn out to be good, it would be too late to make it into a release. Personally, while I see why some people might want those configurations, I don’t think they would benefit the bulk of the users =/

    +Jay Peterman From what I saw of the code, I think double tapping (or any special gestures) would be tricky to implement =/

    I think the “last-app”, and multiple actions is an idea worth exploring that’s probably not too difficult to implement.

    Anyway, Urho is probably the guy you should try to convince ๐Ÿ˜‰

    +variaatio It follows the orientation in the app, which is not necessarily the orientation of the phone.

    Like

  16. Pingback: N9 Swipe Undocumented Feature Activate Sane Behavior

  17. Felipe, one more thing – can this be configured (or work the same) also for the swipe gestures on the lock screen? It behaves differently than the same on active application.

    Like

  18. Honestly I think all the configurable bits are only going to benefit a small number of users unless they were made super easy to configure. By far the most important thing is that users aren’t frustrated by the interface and not knowing what screen you will end up on sounds like it would get irritating fast. Your (Felipe’s) changes sound like they will help a lot (thanks again – they really should be the default) but I’m a little worried that the consistency won’t be there with swipes on the lock screen and the home screens possibly being different to the ones when you’re in an app.

    I’m wondering which, out of the suggestions that have been made so far could be implemented by the community (without having to re-write huge chunks of code that is). The application specific swipes could probably be done assuming that the trigger to make changes to mcompositor.conf active is lightweight with no side effects. Pretty much all the other suggestions look like they won’t be possible to me…… Oh hang on! All this swipe gesture stuff is developed in the open (gitorious/meegotouch/meegotouch-compositor*) ?! That’s pretty awesome.

    How does one go about finding how all the harmattan bits link together – like how do you know that mcompositor is the bit that handles swiping?

    * Note: Struggling to post this comment so took out gitorious URL.

    Like

  19. sounds really cool. the problem is im kind of a noob. how do i manage this to work. i ssh into the phone, found the file, edit it, but cant save it. probably because the file is in use. how do i kill the process so i can save/overwrite the file? would like to puplish it (tutorial) on my website…

    thx, dominique, nokiablog.ch

    Like

  20. Truly awesome news!!!!
    The opportunities for more complicated “swipe macros” are endless, i hope this becomes extended!
    Thanks Felipe, you’re a legend!

    Like

  21. Great idea, those defaults are both consistent and easy to use.

    Regarding all the comments which expect the behaviour to be easily configurable, this would be a very bad design decision. It is important that 2 different N9s follow the same bahaviour, Just imagine that your friend changes the keyboard shortcuts on your computer and swap Ctrl-C and Ctrl-V… It would be a mess.

    Like

  22. “Just imagine that your friend changes the keyboard shortcuts on your computer and swap Ctrl-C and Ctrl-Vโ€ฆ It would be a mess.”

    So what?
    Key bindings have been configurable (to varying levels of coolness) on PC’s/Macs for decades.
    It hasn’t been a “mess” as you put it.

    Like

  23. @Felipe

    You mentioned doco being a reason for why this change may not have been included.

    Nokia so needs to use this for the N9!!
    http://arstechnica.com/gadgets/news/2011/08/dozuki-will-drag-service-manuals-kicking-and-screaming-into-21st-century.ars
    http://www.engadget.com/2011/08/18/ifixit-intros-dozuki-promises-service-manuals-that-don-t-suck/

    I’m so sick of all the poor “official” doco everywhere WRT hardware, & even software.
    And so are “many” other peeps. This would be a huge improvement.

    Like

  24. Because it is luckily not easy to change the key bindings (and I have doubts that you can really do that on Windows). As I said, I am not against configuration, but it should not be encouraged. Consistency between units is crucial.

    Like

  25. “Because it is luckily not easy to change the key bindings”

    It’s dead easy if you know what you’re looking for, & you’re the type to care.
    As are macro/productivity tools like quicksilver etc.
    http://qsapp.com/about.php
    [there are equivalents for Windows 7]

    “Consistency between units is crucial.”

    Of course it should remain uniform.
    It will be at release, no one’s suggesting otherwise.

    Like

  26. “Itโ€™s dead easy if you know what youโ€™re looking for, & youโ€™re the type to care.
    As are macro/productivity tools like quicksilver etc.”

    Hopefully, “the type to care” will not share his phone ๐Ÿ™‚

    I have no doubt that you manage to do that (I am actually the kind of guy who relayout my keyboard under linux as a workaround for defect keys…)

    But those kinds of features need to be kept hidden. People working at hotlines know what I mean ๐Ÿ™‚

    Like

  27. ^
    I understand your point. And “if” Konttori does proceed with a GUI…
    I’m sure some nice big warnings will be included in the interface. ๐Ÿ™‚

    Like

  28. How difficult is it actually to swipe up with one handed use (i.e. using your thumb)? I’m imagining that running your thumb from the bottom of the screen all the way to top might not be as natural to the hand as the left/right swipes. But then againโ€ฆ I haven’t seen the N9 irl and tried it out.

    It’s just something I was wondering since we’re talking about different kinds of swipes. If it’s more difficult to swipe up (since the gesture requires more difficult thumb movement), wouldn’t this make people use it less compared to the left/right swipes? That might be an answer as to why they didn’t choose to implement it.

    Like

  29. ^ The left/right swipes are for one-handed use.
    The other swipes bring a 2nd hand into play.
    Surely you’ve seen that in vidz?
    Doesn’t affect usability, still just a simple to use.

    Like

  30. Yes, I’ve seen people use their 2nd hand when swiping up/down. I’m just thinking that this might be a reason why they didn’t implement this feature.

    In the videos I’ve seen the Nokia people put a lot of emphasis on one-handed use. Maybe the current system is better when it comes to one-handed use.

    On a side note: I find it stupid that other swipes require a 2nd hand. Things like taking incoming phone calls is a bit more difficult (since you need to swipe up when in lock screen) compared to the iPhone. Of course this is just guesses from my part.

    Like

  31. Try re-reading the OP for a reason why they didn’t implement it…

    One-handed use isn’t necessarily the “panacea”, sometimes a 2nd had coming into play is useful.
    It just so happens that some useful aspects of the UI only need one hand.

    You clearly don’t understand why they have swipes from the edge, & smaller swipes in-app etc.
    From what I’ve seen of taking calls, it couldn’t be more straight forward.

    Like

  32. To follow up on what I said before about the relevant code being open source: mcompositor is open source but that seems to just provide a basic framework. I think the swipe gestures are handled in a closed source mcompositor extension called libnokiaswipeextension.so. This is probably where Felipe implemented the configurable swipes. I found this from looking at the mcompositor code and the Harmattan device emulator in the Qt SDK.

    That means my original thought that most of these suggestions can’t be implemented by the community without re-writing big chunks of code is likely correct ๐Ÿ˜ฆ

    I think nokia have come up with an inspiring user interface design but unfortunately it won’t be so easy for non-nokians to enhance it.

    @Phphdk: I think it would be pretty easy to swipe from the bottom of the screen with one hand though I guess it depends on how you hold the device. Also, you don’t have to drag it all the way – you can flick it the same way you scroll through a web page on a smart phone. It will keep going and snap in to place. For phone calls you just drag a big button like thing up, you don’t have to start from the bottom of the screen (note: I’m just going off what I’ve seen in videos).

    Like

  33. “I think it would be pretty easy to swipe from the bottom of the screen with one hand though I guess it depends on how you hold the device. Also, you donโ€™t have to drag it all the way โ€“ you can flick it the same way you scroll through a web page on a smart phone. It will keep going and snap in to place. For phone calls you just drag a big button like thing up, you donโ€™t have to start from the bottom of the screen (note: Iโ€™m just going off what Iโ€™ve seen in videos).”

    ^ Spot-on, I just CBF’d typing all that, thought it was pretty obvious to conscientious observers.

    Like

  34. [That means my original thought that most of these suggestions canโ€™t be implemented by the community without re-writing big chunks of code is likely correct ๐Ÿ˜ฆ
    I think nokia have come up with an inspiring user interface design but unfortunately it wonโ€™t be so easy for non-nokians to enhance it.]

    Unless of course Nokia decides to open libnokiaswipeextension.so
    Large chunks of Qt components have been shared (under strict terms) so it’s no without precedent.
    By no means inevitable though… ๐Ÿ˜ฆ

    Thanks for looking into this….
    Felipe/Nokia could you please advise, is there a chance this could be opened eventually?

    Like

  35. Actually, after trying this configuration for a while, I found one problem; when the virtual keyboard pops up, it’s not possible to swipe up. So I changed my configuration to always go to the switcher (and close when swiping down). So far I think it’s the best ๐Ÿ™‚

    Like

  36. Pingback: MeeGo na Nokia N9 » Openmobility

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.