Skip to content

Responsive Guidelines

Jump to bottom
Lukas Krause edited this page Feb 26, 2020 · 15 revisions

Responsive Guidelines

Content

  • Good Visual Hierarchy for your content especially on smaller viewports
  • Progressively enhance your content. Spiral out i.e. start with the core of the functionality on the smallest viewport, add more for its main aspects briefly, then optionally develop some aspects fully on larger viewports
  • Optimize images for size
  • Responsive Images
  • As usual in mobile first design, we start designing for the smallest supported viewport. In our case (320x568)

Actions

  • navigation placement should be conveniently to reach on mobile
  • optimize for touch
    • Click Target Size for touch
    • no hover states for touch
  • Scrolling is hard on touch devices, help people
    • search and filter functionality

Input

  • Remove inessential form fields
  • Input Type Attributes
  • Visual Feedback (Spinner/Animation etc.) for touch

Layout

  • Size content to the viewport width
  • Responsive Typography
    • font size
    • ideal column should contain 70 to 80 characters per line

Modals

There are often better alternatives to modals. Modals, especially large ones, don't scale well on devices with a small viewport. However, it doesn't mean that modals should never be used. Refer to the list below to guide your decisions.

  • Confirming an action: Modal is a good choice since users need to act right now
  • Warning users: Modal might be a good choice, but be wary of overuse. It should be used only when a long process started to let users know that it's in motion or when a critical error happened
  • Editing data: Favor inline editing whenever possible. Otherwise, a form on its own page could also be fine
  • Creating data: A form on its own page is better, especially on workflows with multiple steps and on error-prone forms (validation in modals is usually quite bad)
  • Displaying data: A page is better choice

Breadcrumbs

Breadcrumbs are not a replacement for proper navigation elements and and a well structured UI that by design makes it easy to navigate through the application. Although, having them usually doesn't hurt. Often they can help to quickly check the current position within the application and to show the ancestors. There are a few points that should be considered when using the breadcrumbs:

  • They should be visualized in a way that is not obtrusive to other components in the UI.
  • Shouldn't break into multiple lines (makes it hard to read them in the right order).
  • The breadcrumbs shouldn't link to the current route, since it's confusing to the user and creates unnecessary reloads of the page.
  • On mobile devices there is often a lack of space. Solutions can be, only pointing one level down, collapsing them... Again they should not break into multiple lines or take to much space (obtrusive).

Resources

If all of this is new to you, here are some things to check out

Development

Subsystems

Better SCM/CI Integration

HOWTOs

Software Design Patterns

Operations

Releases

Clone this wiki locally