Skip to content

Responsive Guidelines

Jump to bottom
Saray Cabrera Padrón edited this page Mar 20, 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 a better choice

In-inline or In-place Editing

As mentioned before, in-place editing is a nice alternative to modals.

From the user perspective it consists of the following steps:

  • In some area of the page there is some static content, probably texts, that can be edited.
  • Inside the Actions menu, there is a link to edit that content.
  • The user clicks on the link and the small area becomes a form.
  • The form's fields should correspond to the values previously displayed in the static content, as well as their order or position.
  • When the form is visible, the user can ...
    • ... do nothing and Cancel, so the form is replaced by the static content again,
    • ... change some value on any of the form fields, submit the form and, as response, the area show back the static content. This time with updated values.

We try to use Rails' Unobtrusive JavaScript (UJS) for all these actions. So, don't forget to add remote: true to the link that triggers the in-place editing, make the controller action respond to format.js and replace the area with a nice animation from the JavaScript file.

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