A ‘breakpoint’ is a specific width where your UI could differ: respond to the new additional space to better take advantage of it. It could be a small difference (slightly larger margins) or a much larger change — see the ‘what to change’ section below for plenty of examples.

A good example of this is the 600dp line: it is only at this point when you should consider having two levels of content hierarchy (say a master and detail view) on the screen at the same time. Below this point and you have a very real possibility to overwhelm the user.

Similarly, the extremely larger sizes after 1600dp is a good time to set a maximum width for your UI: either center aligning and growing the margins or left aligning your entire UI.

Note: this isn’t to say your layout is completely static and fixed width between each breakpoint. Think really hard on what elements really truly need a fixed width or which should be aligned with a more flexible grid, using a fixed percentage of the available space.

To take advantage of width-based resources, you’d use the w prefix. For example, a default layout would be a layout and a layout for width 600dp or higher would be in layout-w600dp.

Height

16:9 split screen on mobile

Height, on the other hand, is less common as a high level element in building a responsive UI, but I wouldn’t count it out entirely. In fact, cases where the height is extremely limited is one of the cases where you UI can break down quite spectacularly.

Take for instance the case of a 16:9 split-screen window on mobile: such a small height can make traditionally easy to use interfaces (such as a vertically-scrolling container) into a difficult proposition.

Take particular care when using UI patterns that have fixed elements vertically aligned; while a dialog might work great in most cases, a small height might make it impossible to tap actions and interact with the dialog. (A good example where you might transform to a full screen dialog model).

Similar to qualifying resources by width, height aptly uses the h prefix — i.e., layout-h480dp.

Smallest Width and Rotation-Insensitive UIs

There’s a natural tendency to think about ‘available space’ based on the general size of the device (this is why it is so easy to fall into the ‘let’s build a tablet UI!’ thinking). But neither width or height actually cover that overall amount of size thinking — they each measure just a single dimension. But fret not! There’s an alternative to layout-w600dp-h600dp: smallest width and layout-sw600dp.

Smallest width is calculated by taking the smaller of the width and height. For example, if your app is in portrait orientation, the smallest width is the current width. When rotated, the smallest width doesn’t change even though the width has swapped with the height.

This makes smallest width a great overall representation of how much space is available. It is also really important when building a rotation insensitive UI. This means ensuring that operations are available in every orientation and that basic usage patterns are consistent across rotation.

This is particularly important when Preparing for Multi-Window in Android N:

That’s right: even if the device is in landscape, your app might be in ‘portrait’ orientation. Turns out: “portrait” really just means the height is greater than the width and “landscape” means the width is greater than the height … your app could transition from one to the other while being resized.

If you’re relying on portrait or landscape to change your UI, you and your users will be quite surprised when they resize your app and get to that magical cross over point between portrait and landscape. Make sure they aren’t surprised.

Of course, that doesn’t mean that nothing can change between orientations (there is a big difference in width after all!), but that you should keep larger structural/navigation changes to be based on smallest width if those kinds of sweeping changes are needed at all.

Choosing what to change

The ‘when’ to change is only half of the equation though. Knowing what (and how) to change is just as important.

There’s a number of responsive UI patterns which explore how you might adapt to a change in the amount of space you have.

Reveal

The first pattern involves revealing hidden content when you gain additional space. This pattern exemplifies the balance between the needs of the small screen (there comes a point where not everything will fit!) with the needs of the large screen where reducing the number of taps or reliance on hidden information can greatly improve the user experience.

This is particularly common when it comes to layouts. On a smaller screen, specific user interaction (such as tapping a button) might be required to expand less used fields.