UI/UX Design: A Word of Caution on Designing PWAs

 1 year ago
source link: https://uxplanet.org/ui-ux-design-a-word-of-caution-on-designing-pwas-ef9e1606e70b
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

Responses (2)

Your statement about manually turning off the Safari features is wrong.
iPhones have and have had since the first iPhone, the ability to add a website to the homescreen.
You, as the developer, need to include META tags referencing icons, status bar…...

You have 2 free member-only stories left this month.

Image for post
Image for post
Image by Jan Vašek from Pixabay

UI/UX Design: A Word of Caution on Designing PWAs

I can almost guarantee you haven’t thought about this, but you really should.


Recently, I have seen a lot of designers charging into designing native-looking applications with impunity, and while they look really good, it’s a huge problem.

Today, we’re going over one of the main, but often overlooked reasons why.

Designing for Development

In all likelihood, you’re designing on a team, and doing UI/UX for a product that thousands if not millions of users are going to interact with.

Native applications are cool, but they are expensive and often require multiple code-bases, which make most teams turn to the creation of mobile web applications or PWAs to create their solutions.

For this reason, there are some things that you need to be aware of.

What are PWAs?

A PWA stands for Progressive Web Application and it is a way that you can develop an application that has a single code-base that lives on the web (HTML, CSS, and JavaScript) but still has many of the really nice features, functionality, and smoothness of a native application.

How are PWAs different?

PWAs are NOT native applications. They run INSIDE OF A WEB BROWSER CONTAINER and are therefore subject to those design constraints by default!

UPDATE: You can create an app manifest file and specify what UI components you want turned on or off depending upon the mode that you select, be it full-screen, standalone, or other options that can be found here.

Why should you care about them?

This becomes a problem very quickly when you think you have more screen real-estate than you actually do. I myself have fallen prey to this issue more than once, and it becomes immediately apparent when you look at the issue in context:

Image for post
Image for post
Left is the PWA running in standalone mode, right is running in Safari mode (default).

As you can see, the left has significantly more screen real-estate than the right, but the thing is that they’re the exact same application.

The difference is that one is mocked running in standalone mode, whereas the other is mocked running inside Safari. The difference is definitely noticeable.

What does this mean for you?

Always mock your designs for websites, mobile web applications, and/or PWAs inside of a browser container and with spacing applied for native browser controls.

This way, you will ensure that no matter who is using your app on any platform, it has been designed with those limitations in mind; looks, feels, and performs as such.

Nick Lawrence Design
Website | Portfolio

About Joyk

Aggregate valuable and interesting links.
Joyk means Joy of geeK