Skip to content

Commit

Permalink
More editing
Browse files Browse the repository at this point in the history
  • Loading branch information
@peholmst
peholmst committed Dec 9, 2024
1 parent 8f62844 commit 6761c27
Showing 1 changed file with 19 additions and 11 deletions.
30 changes: 19 additions & 11 deletions articles/building-apps/presentation-layer/design/responsiveness.adoc
View file
Original file line number Diff line number Diff line change
Expand Up @@ -13,43 +13,51 @@ In the scope of UX design, responsiveness refers to the UI responding to changes

== Designing for Mobile Responsiveness

There are different approaches when optimizing an UI for a small touchscreen. The right approach depends on your application's specific needs. As a rule of thumb it's better to do a limited set of mobile functionalities well, than rush through and force everything to fit on a small screen.
You can optimize a user interface for a small touchscreen in different ways, depending on your application's specific needs. As a rule of thumb it's better to do a limited set of mobile functionalities well, than to rush through and force everything to fit on a small screen.


=== Reduce Features on Small Screens

The most lightweight option is to reduce features on smaller screens. This may work for applications that are primarily used on desktop and mobile UI is used only occasionally to access read-only data or simple workflows. Maybe the users won't really need the system administration features or heavy data entry on mobile and hiding them from the application is completely fine.
The most lightweight option is to reduce the number of features on smaller screens. This works for applications that are primarily used on the desktop, and whose mobile UI is used only from time to time to access read-only data or simple workflows. For instance, users may not need to do system administration and heavy data entry on their mobiles.

In the following example, you can see two variants of the same user interface. On the left is the desktop variant with all the features. On the right is the mobile variant with less filters.

[link=images/responsiveness1.png]
image::images/responsiveness1.png[Desktop UI on left; Mobile UI with less filters on right]
image::images/responsiveness1.png[Desktop UI on the left; Mobile UI with less filters on the right]


=== Build a Responsive System

Next approach can be to adapt all the UI's to be mobile friendly. It is easiest to achieve when the UI is based on a design system that takes responsiveness into account. UI patterns should adapt to viewport size independently to reduce need for one-off view specific overrides. CSS media query and container query are the techniques for implementing responsive UI building blocks.
The next option is to adapt the entire user interface to be mobile friendly. To make this easy, you should base the UI on a design system that takes responsiveness into account. In practice, you use CSS https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_media_queries/Using_media_queries[media queries] and https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_containment/Container_queries[container queries] to make responsive UI building blocks. To reduce the need for one-off, view specific overrides, the building blocks should adapt to the viewport size independently.

In the following example, the mobile variant of the user interface contains all the filters of the desktop variant. To adapt to the smaller viewport, the filter panel shows up as an overlay that the user can show and hide as needed.

[link=images/responsiveness2.png]
image::images/responsiveness2.png[Desktop UI on left; Mobile UI with filter panel as overlay on right]


=== Start with Mobile Size
=== Start with Small Screens

“Mobile first” means an approach where the UI definition starts with the mobile size and is adapted to larger viewport sizes. It's easier to design for experiences to be more natural on mobile when there isn't the burden of an existing desktop design. On a smaller screen a workflow is likely to consist of a series of smaller steps which may be combined on desktop. Mobile first approach fits applications which prioritize the mobile UI to be as important as the desktop UI.
If the mobile variant of your user interface is as important as the desktop variant, you should start by designing the mobile variant. This approach is called "mobile first". The user experience on mobile becomes more natural without the burden of an existing desktop design. Once the mobile UI is ready, you adapt it to larger viewport sizes for the desktop variant.

The example below shows a UI design that was first made for mobile and adapted to desktop. Note that the data is the same as in earlier examples, but the desktop UI presentation and functionality is based on the mobile version.
The following example shows a UI design that was first made for mobile, and then adapted to the desktop. The use case is the same as in the earlier examples, but the desktop variant is based on the mobile variant and not vice versa.

[link=images/responsiveness3.png]
image::images/responsiveness3.png[Mobile UI with a list of cards on left; Desktop UI with a list of cards on right]

Adapting a mobile user interface to the desktop is not only about adjusting the size of elements. For instance, a workflow may consist of a series of smaller steps on the mobile that can be combined on the desktop.


=== Separate User Interfaces

=== Separate Mobile UI
The approaches covered so far have been compromises: either the mobile UI is a variant of the desktop UI or vice versa. When the best possible user experience is required for both, you should develop the user interfaces independently from each other. However, this doubles the effort and amount of UI code. You may also need to create separate backend services for each UI, making the application more complex. This in turn makes it more expensive to add new features and make changes.

Desktop and mobile UIs should be developed separately when the best possible user experience for both are required. With this approach there is no need for compromises. Often developing separate UI:s is not desirable due to doubling the amount of UI code leading to additional challenges.
Because of this, you should aim for a responsive user interface, and only create separate versions for the parts where it is needed. For instance, QR code scanning, or a full-screen map, may benefit from having their own UI implementations for mobile and desktop.

Our recommendation is to make a separate mobile UI only for a very limited set of views or functionalities. For example QR code scanning or full screen map may benefit decoupling from the desktop UI implementation. The example below shows a mobile UI that relies on swipe gestures while the desktop version has totally different interaction patterns.
The following example shows a mobile UI that relies on swipe gestures, while the desktop version has totally different interaction patterns.

[link=images/responsiveness4.png]
image::images/responsiveness4.png[Mobile UI with touch slider on left; Desktop UI with data grid on right]
image::images/responsiveness4.png[Mobile UI with touch slider on the left; Desktop UI with data grid on the right]


=== What Screen Sizes Should I Design for?

Check warning on line 63 in articles/building-apps/presentation-layer/design/responsiveness.adoc

View workflow job for this annotation

GitHub Actions / lint 

[vale] reported by reviewdog 🐶
[Vaadin.FirstPerson] Use first person (such as ' I ') sparingly.

Raw Output:
{"message": "[Vaadin.FirstPerson] Use first person (such as ' I ') sparingly.", "location": {"path": "articles/building-apps/presentation-layer/design/responsiveness.adoc", "range": {"start": {"line": 63, "column": 29}}}, "severity": "WARNING"}
Expand Down

0 comments on commit 6761c27

Please sign in to comment.