Responsivenes

Hub on different screen sizes#

Hub's experience across devices should be intentional and not accidental.

Between January and March 2019, ~30% of users logged in to Hub on a mobile or a tablet.

GA data

To date, there is no business requirement or recorded user request to have specific functionality available on tablets and mobile devices. However, this does not mean we completely ignore the experience on mobiles and tablets.

Our users have permission to see the same Hub apps on their mobile phone that they have on a desktop. If we don't intentionally decide and communicate the experience we want to provide on multiple devices, the system will provide one for us anyway.

It may be unlikely today for a user to want to bulk edit products or create a purchase order on a phone, however that doens't mean that they won't access Hub on their phone. When they do, for example, we should make sure

  • our breadcrumbs don't take 25% of prime screen real estate
  • our input fields wrap with their corresponding labels
  • the most important content on a page is seen first by the user
  • the cellphone keyboard doesn't hide the input field a user is typing into.

Desktop-first responsive design#

Responsive design is a development technique that detects the client type and dynamically adjusts the layout of a site according to the size of the screen on which it is displayed. Thus, the same content may be displayed in a three-column format on a desktop, two-column format on a tablet, and one-column format on a smartphone. NNGRoup

[Responsive Design] uses so-called breakpoints to determine how the layout of a site will appear: one design is used above a breakpoint and another design is applied below that breakpoint. NNGroup

Unless your team has very good (validated) reasons to be mobile first, we will recommend creating desktop first responsive experiences. Why? Because there isn't a business or product requirement to be better at mobile yet and because most functionality on Hub is preferred to be done on larger breakpoints. Either way, whatever breakpoint you choose to begin designing for, make sure your solution gracefully responds to the other breakpoints.

Implementation of strategy#

Because responsive design relies on shuffling elements around the page, design and development need to work closely together to ensure a usable experience across different breakpoints.

It is important that design and development teams work together not to just determine how the content should be shuffled around, but to also see what the end result of that shift looks like and how it affects the user experience. NNGroup

Responsiveness in component library and design system#

  • Simple responsive behaviour will be dealt on a global component level

    • Swapping 14px body font size to 15px on appropriate breakpoint switches
    • Collapsing vertically stacked buttons into a single dropdown button on smaller breakpoints
    • Collapsing a series of tabs into a pop-over on smaller breakpoints.
  • Design guides on responsiveness for teams to make specific use case decisions

    • Explanation of larger concepts such as layout patterns
    • Component specific guides and best practices such table column wrapping.

Responsiveness for development teams#

  • Designers and developers should think about prioritizing content and understand how elements reshuffle as the page layout changes.
  • Designers should decide and communicate component specific behaviour that they want across breakpoints based on knowledge of their users and their needs.
    • Which table column has the most important information and should respond to the breakpoint change last. The min-width of a table column, whether the column should truncate or wrap.
  • Designers should think about what experience they should hide across breakpoints.
    • Example: Should bulk editing of products be something a user should be able to do on their smartphone? If not, can it be hidden? Can it be communicated that its not optimized for mobile?

What is not part of the strategy#

Until there is a business requirement or validated end-user feedback to create mobile-optimized experiences, we will not be focusing on:

  • Using mobile/tablet specific functionality in our components or design guides.
    • Longpresses, haptic feedback, gestures etc.
  • Swapping our component functionality with native, platform-specific look and feel.
    • Using the iOs or Andriod date pickers instead of our date picker.
  • Providing notifications on locked screens and using other native device functionality
  • Providing specialized experience for complex tasks on smaller breakpoints.
    • mobile-optimized bulk table editing

Sources#

Last updated on by aslaug sollilja