Menu Search
Jump to the content X X
Smashing Conf Barcelona

You know, we use ad-blockers as well. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

C-Swipe: An Ergonomic Solution To Navigation Fragmentation On Android

There are 3,997 different Android devices1. Your navigation should work with all of them. C-Swipe can help: It is an alternative navigation pattern for tablets and mobile devices that is novel, ergonomic and localized.

This article provides a detailed walk-through of the design and code and provides a downloadable mini-app so that you can try out C-Swipe to see whether it’s right for your app.

Further Reading on SmashingMag:

Size, Complexity Increasing Link

The number of touch devices is increasing, with new devices and features being introduced daily. If we look at recent Windows OS developments, one clear trend is that touch devices are getting larger. Already, the lineup includes 12-, 15- and 21-inch touchscreens and touch-friendly applications are becoming more complex and full-featured, now including standard Microsoft Office apps optimized for touch. And if the latest 12.85-inch Chromebook Pixel6 with its 2560 × 1700 touchscreen display is any indication, Google is likewise serious about integrating touch into larger hardware for serious computing.

It’s only a matter of time before Android OS is forced to catch up; however, scaling the current Android 4.x action bar scheme may not be realistic or ergonomically desirable for all applications or device types.

I’m proposing C-Swipe as an alternative navigation pattern, based on the natural ergonomics of the human hand. C-Swipe can be used to bring up a contextual menu anywhere on the touchscreen by swiping the thumb in a natural semicircular arc along the surface. This gesture is roughly in a shape of the letter C when executed with the right hand — hence, the name of the pattern (the gesture is called a “reverse C” when executed with the left hand).

Content Is King Link

Imagine the entire surface of a mobile or tablet touch device being devoted to content. To use the functionality or navigation, the user would swipe the screen with their thumb in a natural semicircle gesture anywhere on the device. They could make this touch gesture while holding the device comfortably and securely with two hands, while the device is flat on the table, while reading in bed, or in any position and orientation they choose. That’s because all they need to do is swipe the screen with their thumb.

The swipe of the thumb causes a semicircular contextual menu to display. When the menu comes up, the most commonly used function is on top, near the final position of the thumb. Icons and text for the menu are positioned where they will not be blocked by the thumb. The user taps the item they want, and once the action is performed or the screen is tapped anywhere outside the menu, the menu would disappear.

Easy To See, Yet Hard To Reach Link

Flipboard is an elegant app that has gained legions of loyal fans through its gorgeous UI and effective use of content as navigation. Yet, on Flipboard’s detail pages, some options — “Back,” “Favorite” and “Like” — are located in the top action bar:

Flipboard app for Android 4.7
Fig. 1: The Flipboard app for Android 4 places action buttons in the top action bar. Larger view8.

The top action bar is a popular location for navigation and functionality in Android 4 and is recommended in Android 4’s design guidelines. The top bar facilitates the discovery of functions: it presents them for easy viewing at the top of the device, where they would never be covered by the user’s hands.

Yet placing the actions at the top of the screen is a double-edged sword: reaching the top bar on many devices is difficult. Even on small mobile devices, reaching the top bar requires awkward juggling. Larger devices, such as the popular Galaxy Note, require full use of the second hand to tap the buttons, making both multitasking and relaxed casual use more difficult.

The action bar also takes up important space at the top of the screen. The visible functions serve as an effective learning aid while the user is learning the app. Unfortunately, as soon as the user learns the functions, the bar’s visibility becomes a distraction, taking up precious space in the most visually active place on the screen.

What if there was a way to devote 100% of the screen to content, while allowing the user to effortlessly call up a functional menu from anywhere on the device, wherever their hand is, and provide direct access to all options without any awkward gestures or juggling? That is exactly what C-Swipe does:

Swipe-and-release gesture in Flipboard app.9
Fig. 2: In this redesign of the Flipboard app, the user makes a swipe-and-release gesture to bring up the locally accessible contextual navigation. Larger view10.

A semicircular swipe with a thumb anywhere on the screen brings up a hidden menu containing the same items as located in the top action bar. Once the menu is open, tapping the desired item with the same thumb is easy.

Two Menu Designs Link

A C-Swipe gesture can be made in two different but important ways: as a swipe and release or as a swipe only. In each case, the menu would look different. Pick the one that is right for your app. The swipe-and-release design puts the icons inside the menu tiles, as seen in figure 2 above.

The user would swipe the surface with a semi-circular gesture and then release their thumb from the surface of the device. The release is crucial here because otherwise the thumb would cover most of the menu items, making usage awkward.

The second type is swipe only, shown in figure 3 below. The system recognizes the same swipe gesture, but this time the menu is painted while the thumb is still pressed to the surface of the device. Because the thumb is covering the menu options (by design), the items must appear outside of the menu to be visible.

Swipe-only implementation of C-Swipe.11
Fig. 3: The swipe-only implementation of C-Swipe puts the icons outside of the menu. Larger view12.

Which interaction should you choose?

With swipe only, the thumb maintains contact with the device, activating the menu immediately. This makes navigation efficient: there is literally no wasted motion. However, many testers have preferred the Spartan design that positions icons inside the menu. Try both and decide for yourself, using the enclosed downloadable mini-app. The app features a mixture of the two modes: it uses the swipe-and-release gesture, but positions the icons outside of the menu bar so that you can see how it looks.

Note: Keep in mind that the swipe motion to call up the menu in the demo mini-app requires you to draw a fairly small semi-circle, probably smaller than you’d expect. I wanted this basic demo to work on all devices, small and large, in a wide variety of touchscreen form factors and resolutions (we are hoping to cover all 3,997). Another reason is the anatomy of the human hand: it is much less awkward for a person with large hands to make a small semi-circle gesture with their thumb than for a person with small hands to make a large gesture.

Complete Action Bar Replacement Link

C-Swipe is basically a complete replacement of the current action bar menu in Android, so you can use it anywhere you might currently use the action bar. As I describe in my upcoming book, Android Design Patterns: Interaction Solutions for Developers13, particularly good candidates for the C-Swipe pattern today are experiences that call for a lights-out mode, with hidden Swiss Army knife-style navigation, such as for reading and browsing a magazine.

Another important point is that C-Swipe is almost infinitely extensible: It can be used to add more menu functions than can be seen on the screen, plus two or three levels of menus on top of the existing first-level menu scheme. To access overflow menu functions, the semi-circle inside the circular menu can be enabled as a separate button. As shown in figure 4 below, tapping that button spins the circle around, bringing up the overflow functions; tapping it again returns the menu to the original view. This allows the user to comfortably access 8 to 12 top-level functions.

Accessing the C-Swipe overflow menu.14
Fig. 4: Accessing the C-Swipe overflow menu by tapping the central button. Larger view15.

To add submenus, consider exploring both swipe-and-release and swipe only:

Two ways to access the C-Swipe submenu.16
Fig. 5: Two ways to access the C-Swipe submenu. Larger view17.

The top row shows swipe-and-release; tapping the “favorite” function in the open C-Swipe menu brings up a circular selection of stars. The user has to release their thumb from the screen to see the functions available in the submenu, and then tap the option they desire.

Swipe-and-hold (shown in the bottom row) works similarly; the user swipes and keeps their thumb on the screen. Upon sliding their thumb to the desired function (for example, “favorite”), the user would release their thumb from the screen. Then, the main menu would be replaced with the submenu.

The point is that the C-Swipe theme has many variations, and the submenu does not need to be semi-circular. It could be a long list of text and/or icons or a dedicated lightbox, as long as it comes up near where the main C-Swipe menu was invoked.

Why Use C-Swipe? Link

C-swipe has a number of important benefits:

  • Facilitates immersive experiences
    This highly immersive pattern keeps functionality hidden until needed. It opens up 100% of the screen on any of Android’s 3,997 device types to immersive experiences such as shopping, reading, movie viewing and virtual reality.
  • Minimizes arm strain
    C-Swipe is particularly suitable for large touch devices, such as the upcoming 15-, 17- and 21-inch touch tablets. Reaching the top or bottom action bars in Android 4’s existing navigation scheme would require large arm gestures, quickly leading to arm fatigue. By contrast, the C-Swipe menu appears wherever the hand is positioned on the screen and does not require large arm movements.
  • Obeys Fitts’ Law
    Fitts’ Law stipulates that the speed and ease of tapping a button correlates to the size of the target and the distance to it. Thus, tapping a small button on a large tablet is painfully slow and awkward. C-Swipe is unique because it creates navigation anywhere on the screen, and the menu always shows up exactly where the hand is positioned, so the movement needed to select an item is minimal. As a result, movements are more precise and natural.
  • Triggered uniquely
    C-Swipe uses a gesture that (as of the time of writing) is not used for anything else. Thus, it is not likely to be triggered accidentally, and closing it is as easy as tapping anywhere on the screen outside of the menu.

Note that the gesture is a “reverse C” when executed with the left hand. The enclosed source code and mini-app will work with either hand doing the gesture.

Other Applications Link

C-Swipe does not need to be activated near the edge. When the user tilts a large touchscreen in order to use it comfortably while standing, the C-Swipe navigation can be opened anywhere by making a semicircular swipe with the thumb. Usually, the user would first need to touch the screen with one of the other fingers, such as the index finger, to support the compact gesture.

C-Swipe is unique because it comes with its own “natural” animated transition. The menu simply spins out in a semicircular path, following the movement of the thumb as closely as possible.

Caution Link

C-Swipe is not easily discoverable. But its discoverability can be aided with an animated watermark or another gentle tutorial pattern. Stating something like, “Swipe with your thumb anywhere on the screen,” or animating a watermark several times in different places on the screen can help users discover the gesture:

Introducing C-Swipe with an animated watermark pattern.18
Fig. 6: Introducing C-Swipe with an animated watermark pattern. Larger view19.

Upon being discovered, the watermark can be permanently removed. C-Swipe is quickly learned, because it is familiar and convenient for the hand and thumb.

Some people believe that the drawback of a C swipe is that it is ergonomically complex and does not translate into anything “real” (like a scroll or a pan). Other designers prefer the larger gestures of Windows’ modern UI, where the entire arm transverses the screen from left to right and top to bottom. Still other designers prefer an alternative for large displays: a special multitouch gesture — for example, a five-finger tap or five-finger pinch.

I disagree.

While each of these alternatives to C-Swipe holds a great deal of promise, I find C-Swipe to be the most natural, authentic and economical of touch movements. It is also natural, almost like the user is scratching or grabbing to “dig” into the content on the screen. The swipe can be performed effortlessly with one hand, with the device in almost any position, during almost any typical activity on a mobile device. Much testing with a broad range of people is needed to confirm this.

However, one thing is clear: regardless of the gesture, being able to call up a contextual menu locally on demand is the right model for all kinds of touch devices — so my biggest caution would be not to ignore this important trend.

Source Code Explained Link

As you can imagine, this function is fairly complex, so this is just a cursory overview, highlighting the main points as you explore the enclosed source code20 (ZIP).

In order to build the app, you have to first record the custom C-Swipe gesture using the GestureBuilder delivered with the Android SDK. You can read about this detailed procedure in “Creating a Simple Gesture App With Android21” by Micha Kops.

Then, in your CSwipeActivity class, you will need to load the custom C-Swipe gesture from the library:

// Load gestures library
        mGestureLib = GestureLibraries.fromRawResource(this, R.raw.gestures_cswipe);
        if (!mGestureLib.load()) {
            // Show toast if gestures library could not be loaded
            Toast.makeText(this, R.string.KMsgErrLoadingGestures, Toast.LENGTH_SHORT).show();

Next, set up a listener to monitor for when the desired gesture is performed.

// Register gestures listener
        mGestureOverlayView.addOnGesturePerformedListener(new GestureOverlayView.OnGesturePerformedListener() {
            public void onGesturePerformed(GestureOverlayView gestureOverlayView, Gesture gesture) {
                onGesture(gestureOverlayView, gesture);

When any gesture is performed, you can check whether it matches the C-Swipe gesture using the onGesture() method. We can check whether the gesture performed by the user matches C-Swipe by seeing whether its prediction score is higher than some predetermined value. In this simple demo, we’ve set a middle-of-the-road value of 3D. Experiment to find the right value. If it is too low, then simple swipes will trigger the function accidentally; if the threshold is too high, then activating the gesture will be too difficult. When the right gesture is detected, the app inflates the special circular menu and populates it with the predefined items.

if (prediction.score > 3D) {
                // Switch content from gesture overlay view to original content view
// Inflate the CSwipe control view
                final View cSwipePopupContentView = getLayoutInflater().inflate(R.layout.view_cswipe, null);
                mCSwipe = (CSwipe) cSwipePopupContentView.findViewById(;

In our demo mini-app, two kinds of C-Swipes are possible: left and right orientation. This is checked by the following code, which then sets the orientation for the menu anchor.

// Check the orientation of the CSwipe control based on the selected gesture prediction
                final String predictionName =;
                CSwipe.Anchor cSwipeAnchor = CSwipe.Anchor.RIGHT;
                if (predictionName.equals(GESTURE_CSWIPE_LEFT_MARGIN)) { cSwipeAnchor = CSwipe.Anchor.LEFT; }
                else if (predictionName.equals(GESTURE_CSWIPE_RIGHT_MARGIN)) { cSwipeAnchor = CSwipe.Anchor.RIGHT; }

                // Set the CSwipe control anchor according to the selected gesture prediction

Set the menu as close as possible to the gesture anchor in order to maintain the illusion of a seamless menu launching directly from the gesture-bounding rectangle.

// Show the CSwipe control popup window as close as possible to the gesture bounding rectangle
                final RectF gestureBoundingRect = gesture.getBoundingBox();
                mCSwipePopupWindow.showAtLocation(mContentView, Gravity.NO_GRAVITY, (int) gestureBoundingRect.left, (int);

To launch the distinctive semi-circular menu defined by the outer and inner radius, instantiate the CSwipe class. You can find the complete code in the Widget folder.

public CSwipe(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);

        final TypedArray attributes = context.obtainStyledAttributes(attrs, R.styleable.CSwipe);

        mInnerArcRadius = attributes.getDimensionPixelSize(R.styleable.CSwipe_innerArcRadius,
                (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, DEFAULT_INNER_RADIUS_DP, getResources().getDisplayMetrics()));
        mOuterArcRadius = attributes.getDimensionPixelSize(R.styleable.CSwipe_outerArcRadius,
                (int) TypedValue.applyDimension(TypedValue.COMPLEX_UNIT_DIP, DEFAULT_OUTER_RADIUS_DP, getResources().getDisplayMetrics()));

Summary Link

I will leave it to you, readers, to polish the code for various enhancements: to improve the response time; to create a slick “swing out” opening transition; to tune the gesture threshold; and even to customize the gesture-detection algorithm over time to “learn,” thus ensuring the best fit for the device type and the owner’s hand size. For now, this demo app should give a good feel for the potential of C-Swipe navigation.

Read about how to install the mini-app on your device in the “Try It Out” section of my previous article on Smashing Magazine, “A Definitive Guide to the Android Carousel Design Pattern22.”

This code is provided free of charge and distributed under the GNU General Public License v323. See the README_LICENSE file for details. Download the demo mini-app and source code24 (ZIP).

Enjoy — and be sure to let me know what you think in the comments below.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24

↑ Back to top Tweet itShare on Facebook

Greg is a UX strategist for Fortune 500 firms. His 4th book, The $1 Prototype and the new Lean Mobile UX blog can be found at

  1. 1

    Ryan O. Hicks

    March 25, 2013 6:06 am

    Interesting article.

    Certainly a great way to access new menu items while allowing more priority to the content. If someone wanted to try this kind of menu option out without downloading your example apps they could do the following. It won’t be a C-swipe action, but it’s similar.

    The stock android browser (not chrome) has something similar to this. If you go to settings in the browser and then go to labs, and enable the quick controls setting. With a quick swipe up or down on any edge of the screen and then by keeping your finger on the screen the overflow menu (action bar) appears. Then once you move to a setting within that menu, it expands to other items, and eliminates the previous menu items.

    • 2

      Greg Nudelman

      March 25, 2013 2:38 pm

      DAMN YOU GOOGLE LABS! My World Domination Plan is Ruined! :-)

      Seriously folks — given how committed Google is to the success of Android, did anyone really expect the world’s top technological super-power not to at least consider an alternative navigation? I am not surprised at all, other than by the fact that this alternative has not received more attention. I just tried it and saw that it has a few bugs to still iron out, esp. with the overflow menu. However, it’s a very nice alternative to C-Swipe, with a similar circular menu idea. Google’s implementation certainly lends further strength to the whole C-Swipe concept, and now with the code available in this article, anyone can try this out in their own app. (I just hope someone does not run out and get a patent on any of this so people will have a bit of time to play around with this stuff.)

      So… Looks like you just got another permission to experiment with your own world domination plans. What are you waiting for?


  2. 3

    Why did this remind me of ? :)

  3. 4

    so to be clear, does it work equally for left-handed people too?

    (i don’t have a touch device to play with – at least not without resorting to sordid innuendo ;) )

    • 5

      I like the idea. Similar to the hidden menu of Chrome browser when run in full-screen mode.

    • 6

      Greg Nudelman

      March 25, 2013 2:27 pm

      Absolutely! It’s even better with your left. (Pun intended) :-)

  4. 7

    I whole-heartedly agree. I hate having to let go of my tablet to reach the top of the screen to navigate. I would love to see this gesture in ALL apps. It’s SO easy and comfortable to do.

  5. 8

    mathieu hamel

    March 25, 2013 8:33 am

    Android is already lacking cohesion in its naviguation through its various applications. The reason being that naviguation Android is deficient. Thus we see different patterns appear to solve this problem.

    If you use a BlackBerry Z10 you will get the amazing gesture naviguation. I can take Android and turn an app into a great app changing naviguation system but at the end, the user will lose because he will be lost.

    • 9

      Greg Nudelman

      March 26, 2013 9:44 am

      Afraid I’m not familiar with the Z10, but classic thumb-based up-down spinning is what Apple has done with the iPhone — that’s the most popular gesture for consuming content, though on a flat touch-screen. I’m not a blind Android Fanboy, as I’ve seen many “pure” projects go south. However, I do see tremendous potential for Android 4 — that is why I spent some much time writing a book of patterns for it. I believe Android 4 has already emerged as the dominant mobile computing platform. As a mobile designer, I see my job as taking the best ideas from other OS and helping people to incorporate them into their projects. It’s all about the customer.

  6. 10

    Scary: “top action bar is a popular location for navigation” :|

  7. 11

    All this touching and swiping is really putting a strain on my hand and arm. I’m wondering if possibly there’s an app that has my device simply read my eye movements in order to decipher my desired action. I’m sure we’re a bit aways from this, but we’ve got to become a race that simply doesn’t move at all. Of course, that aim would negate the ‘reading of my eyeballs’ as well. Is there no solution that steers us toward sheer inactivity?
    I would suggest a ‘thought-reading’ app but…all this thinking exhausts me.
    I’d elaborate but I gotta grab a nap now.

  8. 13

    I definitely like the idea of maximizing screen real estate for the purpose of content, and your innovative thinking of how to solve this.

    Still, I also have some doubts. The only “natural”, or maybe I should say “intuitive” touch gestures in my mind are tapping something you can see that looks actionable, vertical scrolling and left-to-right menu navigation if clear arrows indicate it. These 3 are so intuitive that even new users will immediately understand them, including children and the elderly.

    All other touch gestures that I have seen are not intuitive and need to be learned explicitly. I know many iPad users who don’t know any of the other gestures other than those 3. They don’t know how to switch apps, enter the app search screen, get to notifications, get to brightness and orientation locks, none of it all. Because none of those interactions are intuitive and nobody teached them. They don’t even know it exists. Hence, as you already indicated, discoverability is an issue.

    Assuming you can solve that with hints, I still wonder how this pattern is superior to the slide-left pattern used in the Facebook app for example. A small menu button is permanently visible, upon sliding it, a big menu becomes available providing clear navigation, including labels. The main advantage of your method I think is in the thumb aspect of it, which is easily done with one hand. Still, I challenge the idea of icon-only navigation in complex scenarios.

    • 14

      FERDY: To quote you above “…touch gestures in my mind are tapping something you can see that looks actionable.”

  9. 15

    Super cool! I’m finding myself increasingly frustrated at guessing where my nav is these days, between phone and tablet and different apps. It’s not even the same in one App from phone to tablet!

  10. 16

    Greg Nudelman

    March 25, 2013 2:24 pm

    Thank you all for your comments.

    Ferdy — we are of one mind. You are describing “Four Corner Navigation”, another of the 58 patterns in my new book, Android Design Patterns. Four Corner Navigation is certainly more discoverable than C-Swipe, as I discuss at length in the book. With C-Swipe, it’s not a discoverability of the single button that I’m trying to solve for. It’s *reaching* that one button repeatedly on a very large tablet. When we get to the 24-36 inch tablets, reaching the button or performing these large sweeping gestures you are talking about will be very hard to do. Try standing over your desk now and swiping the entire length up and down and left to right or reaching a small button in top left corner of your desk, over and over — gets very awkward, and fatiguing very quickly. It’s much easier to access the menu right where your hands already are with a simple swipe: the C-Swipe.

    In the 4 months of demoing this mini app around the world I have never run into an issue of people not understanding what the gesture was. The reason iPad users have not discovered how to switch apps is that double click on the home button is not intuitive and there is no hint. With C-Swipe we’ll have hints built-in with watermark. That is not to say someone somewhere will not be confused by C-Swipe. Technology is inherently a foreign soil for our pre-historic minds. Otherwise why do we insist on texting while driving at over 60 Mph? :-)

    I remember reading an article that said that the only complex innate gesture is that of a baby sucking milk — that is unique to mammals. (Breathing, blinking, swallowing, moving bowels, etc. are universal in the animal kingdom). About the only thing that is “innate” for humans is imitation, e.g. learning.

    Which means, ultimately that *all gestures are learned.*

    As a designer, I don’t believe we should discard anthropomorphism when it’s handed to us, but avoiding pure digital artifacts because “someone somewhere might possibly get confused”, is denying the direction humanity has been evolving since day 0. If there was some gesture possible on a mobile that would mimic the peeling of the prehistoric banana that our ape ancestors might (or might not) have been intimately familiar with, I’d gladly use it in my navigation. In the absence of such, I’ll gladly “settle” for pure digital, yet ergonomically advantageous ambidextrous gesture like C-Swipe.

  11. 17

    This’s a good solution for navigation of things that I wanna show after some sort of trigger.
    But as it cannot be seen in first sight, it’ll be a disaster for global navigating.

  12. 18

    David Prince

    March 26, 2013 1:31 am

    The problem with any ‘alternative’ navigation devices is that they are often difficult to discover, as you acknowledge. However, I’m not sure that tutorials of the sort you describe are a good solution; I’ve lost count of the number of interface enhancements to which I’ve thought “that’s cool!” but never used again. And that includes enhanced mouse and laptop touchpad patterns as well as mobile touch.

    This is perhaps inevitable with myriad devices on the market and more importantly in our lifestyles. Hopefully some standardisation will emerge, and contributions such as this are useful contributions to their formation.

  13. 19

    I somewhat disagree with your statements. I have a Galaxy Note and medium sized hands and normal manual dexterity and spend the majority of my time (90%+) using the phone single handed. I do not notice a problem selecting any of the corners of the screen as I need to do so when for example using the gmail app.

    1. Your design pattern first needs to be taught it is not obvious like a button
    2. May conflict with other gestures (some launchers can start applications based on gestures)
    3. I believe that a combination of factors mean that it would be easier to trigger an incorrect action than fixed buttons.
    – changeable position of the of the menu
    – the small size of the inner arc angle
    – accidental gesture / especially if multitasking induces slow down
    4. Slower to use than buttons

    • 20

      Greg Nudelman

      March 26, 2013 10:01 am

      Tez, I agree with you. I’m not arguing that C-Swipe is more intuitive than buttons; nor as you pointed out is it any faster. To me it’s about efficiency and content. Unless you are on a 7-inch tablet with a 2-handed grip, reaching tiny buttons on the top action bar is awkward. That said, I understand you have special magic fingers, and I’m impressed that you can reach the top action bar with one hand. Most people I observed need two hands to operate full-sized Android phones, and especially tablet-phone hybrid like Galaxy Note.

      Tiny buttons and full screen swipes will fatigue users during 8-hour days on very large touch screens. Plus, the recent trend is to put more nav not less — I’ve recently redesigned an app for a major food retailer that had over 45% of the screen devoted to buttons! (Of course it looked very different when I was done). But this trend of adding more buttons is simply not sustainable. We need a good way to hide navigation and allow 100% of the screen to be used for content. In my book I propose several such “experimental patterns” I’ve been user-testing for the last 6 years. C-Swipe is one alternative that solves for navigation for any size of device, and esp. larger 24-36 inch tablets and allows content to shine.

  14. 21

    Great Idea!

  15. 22

    I think this is a great idea. I agree that this would feel very natural and help take navigation design patterns to the next step. Has there been much exploration around using other shapes for the menu? I can see how a ‘C’ shaped menu would allow easy reach of all the buttons but I’m still curious about interacting with other shapes (classic rectangle, rows & columns, etc.)

    • 23

      Greg Nudelman

      March 26, 2013 9:46 am

      “Has there been much exploration around using other shapes for the menu?”

      I think you are on the front lines, my friend :-)

      BTW, as a blatant comercial, if you liked the article, do checkout my Android Design Patterns book with 58 more patterns and 12 antipatterns and a free course to go with it. :

  16. 24

    This is great, but I’m not sold. I’d be concerned that the scrolling gesture (swiping on the Y axis) can be misinterpreted as the C-swipe if a user isn’t perfectly vertical. I often make this mistake as my horizontal and vertical swipes tend to be more diagonal based on where my thumb is anchored. It’s a step in the right direction though – my concerns seem solvable. This is exciting!

  17. 25

    Jussi Pasanen

    March 26, 2013 4:18 pm

    Thanks for a very interesting article Greg. This reminds of the classic ‘pie menus’ or ‘radial menus’ with a novel gesture-based invokation mechanism. One of the more prominent examples of a radial menu would be in OneNote in Office 15; the feedback on it seems quite positive in general.

    Would it be possible to post a video of the C-Swipe in action, for those who don’t have access to an Android device? Thank you.

  18. 26

    While I think it’s a great concept, I don’t think most users would ever figure out that they were supposed to do it. And with how many aps and mobile sites there are out there which don’t have good mobile design, I can absolutely see users assuming the watermarked hint shown in the article was just a design choice that didn’t suit their screen and not a suggestion to do something. To be honest, I think users would have to be taught explicitly that it was an option, and then re-taught on many sites before they decided it was something they could typically do. Even then, if they start running into too many sites that don’t offer it, they could be discouraged from trying it. I feel like you really would need to have a visual indicator that there is something there, like the three dots menu, or even a little ball stuck to the edge that expands out when clicked or when the C-Swipe is performed.

  19. 27

    Hello Greg, you have one little error in code: if you try to create an odd number of elements, and then press the center(middle), this element will not be processed. Even with the one element it is not working. I hope that the error will be corrected. Or am I missing something :) ?

  20. 28

    Looks like you re-invented Pie Menus. Congratulations, you’re the 10,000th person to do so!

    Don Hopkins invented pie menus in the late 1980s at the university of Maryland, College Park.

  21. 29

    This is a pie menu but its ok. Pie menus are more user friendly and results in fewer selection errors. The question is – for an expert user, does it still bring up the menu or is there a mode where the menu doesn’t render but does the appropriate action? there by becoming more effective.

  22. 30

    We had a pie menu integrated in our iOS and Android app. Accessable via long press. After nearly one year we ve decided to throw this out. For one app its hard to find for “not” pro users ;).
    If the OS wld support a pie menu from the scratch than users wld be expirienced enough to catch this in an app aswell.

    At the end… the menu with submenus represented in the outer circle … nice as study but cld be a problem of catching the right menu entires on small devices. The same problem with changing in the sub context of the menu. It feels like this is simply to small. … So complex menus will be hard to set off with pie menus. Thats cld be done more effective with vertcial or horizontal scroll list views.

    I wld love to see something like navigatinwith the z-axis. So with the distance to the device you cld switch from top to bottom within the menu.

  23. 31

    Nice solution but just curious to know, isn’t it confuse user as generally on mobile menu is top. And also will it be intuitive to user?

  24. 32

    how to add this on my any activity of my program…
    package com.firstsecondpage;

    import android.os.Bundle;

    public class F1Activity extends DashboardActivityf1
    protected void onCreate(Bundle savedInstanceState)

    protected void onDestroy ()
    super.onDestroy ();
    protected void onPause ()
    super.onPause ();
    protected void onRestart ()
    super.onRestart ();
    protected void onResume ()
    super.onResume ();
    protected void onStart ()
    super.onStart ();
    protected void onStop ()
    super.onStop ();

    } // end class

  25. 33

    I’ve read through several of Greg’s articles. I appreciate the desire to challenge existing patterns and improve the experience for our users. However, I share a common concern with the majority of other readers in that many of these suggestions are not intuitive and lack minimal evidence of their effectiveness. The “tap-ahead” article suggested five people participated in usability tests (not user tests). We don’t test the user, we test the usability of the interface. That is hardly enough evidence to suggest the success of a design. I’ve heard people argue that “buttons are a hack”, but honestly, evidence suggests their effectiveness compared to that of a whimsical gesture.

    Also, the c-swipe interaction lacks in the thought of scalability. How would such an interaction handle complex navigation? The design didn’t consider eye-scanning either. Look at Target’s navigation menu, sure, it may be at the top of the screen, but it scales well and provides users an affordance and reliability in expectation. Do you have any data to suggest that action bars at the top of a screen pose usability problems? As UX professionals, we must provide valid evidence that guides our ideas and decisions. I’ve only read opinions from this author so far.

  26. 34

    Interesting to see iOS8 introducing multi-touch pie menus accessible from the edge of the screen:

    Bob, et. al. are you guys thinking this too will be “undiscoverable”? Guess we’ll find out :-) Personally I still stand by C-Swipe, though “edge-pinch” now seems to emerging as a dominant gesture to call up the menu from anywhere.

    Great discussion!


↑ Back to top