An Emerging UI Pattern - Quick Return

DZone 's Guide to

An Emerging UI Pattern - Quick Return

· Java Zone ·
Free Resource
Quick Return UI design pattern (named by Roman Nurik on G+) is a screen real estate saving design pattern that still allows users to access important off screen controls by easily moving them back to the screen.

This design pattern has been in use in the Google Now app from its launch as well as on various other apps mostly on other platfoms.

If you don't have access to the Google Now app check out the screenshots below. The Google Search box is initially on the top part of the screen but it scrolls out of the screen with the UI. No matter how far the users scrolls down the search box always reappears when user starts to scroll up.

The latest Google+ app update brought the same design pattern to the G+ app and into a very central role. The new post controls were moved out from the action bar to a quick return container.

When to use this design pattern?

Screen real estate is very valuable on small screens. Apps should dedicate as much as possible of it to the actual content instead of controls. Often an app has much more controls, even frequently used controls, that can be placed on the action bar. Adding a second permanent action bar will use much more screen space.

I'm not saying that gmail app should use the quick return pattern. I'm only using gmail as example of space used by controls.

Of course, the quick return pattern only works with a scrolling container like a list or a website. In fact, I would very much like to see this approach being adopted by the Google Chrome browser for Android with the URL bar.

Quick Return on large screens

Google+ app is an interesting example of this design pattern as the app adapts very nicely to multiple screen sizes. The app also changes scroll direction when on landscape mode.

Google+ landscape on Galaxy Nexus

What is striking to me on when using the quick return in Google+ in landscape mode is that it seems to be wasting space instead of saving it. Wouldn't the three actions now fit to the action bar instead?

On Nexus 7

The same thing is apparent on a larger screen like the Nexus 7.

On a 10" tablet

On a 10" tablet screen the quick return really starts to feel cumbersome and somewhat awkward looking.

Relation to the Action Bar

While I'm aware that it would not work in every case I would like to see this component as an extension to the Action Bar instead of a fully separate idea when applicable. Especially in case of the Google+ app the quick return part contains actions that would very well be on the action bar as well. I would like the quick return bar merge into the action bar when there's room.


Hiding controls from users is generally a bad idea. Users won't spend time looking for hidden controls and will probably miss them. What makes the quick return pattern work is the correct use of scrolling as well as making the controls visible by default before user interacts with the UI. When users see the controls and see them scrolling of the screen they mentally map their location to be on the top of the scrollable component. When they feel that they need to access the component again they will intuitively look for them by scrolling up. The fact they don't have to scroll all the way up is just a happy surprise to them.


Roman Nurik and Nick Butcher posted a code example for implementing this design pattern to Google+. You can download the example code from the Google Code site. They also posted an example video of the example app in action.


The quick return design pattern can be very useful for saving screen space without making it much more difficult for users to access extra controls on screens with scrolling content. The use cases for this pattern are fairly limited but it can be a life saver in situations where action bar alone cannot hold everything users need or if the app doesn't use action bar at all.

Published at DZone with permission of Juhani Lehtimaki , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}