5. Mobile-first design

When designing primarily for a computer screen we tend to add a lot of content to "fill the empty spaces". And when we then move on to designing the mobile layout we have a difficult time getting everything to fit in a tighter space, especially in a practical and organized fashion. The browsing experience is negatively impacted: users have trouble finding what they need and the environmental impact is worsened from all the unnecessary content.

The “mobile-first” approach entails designing for mobile devices first. This allows designers to:

• get down to basics and reduce the number of features and the amount of extra content
• make sure that the provided service will work properly for the 55% of internet users browsing from mobile devices (Statista, 2021).

Obviously this does not mean overlooking the computer version of the site, but it is easier to go from a mobile layout to a desktop one than the other way around.

Questions to be answered

• What is actually essential?
• What is the least tech-intensive way to address the problem?
• Will it work on both mobile and desktop?
• Is the size of the buttons and fields adapted to mobile devices?

Eco-design of mobile apps

Best practices in prototyping for mobile devices are valid for "responsive" websites as well as for apps. Note: a site is said to be "responsive" when its elements (menus, fields, etc.) adapt automatically to the screen size.

Prioritizing web apps

In the context of an eco-design approach, it is recommended to prioritize web apps (website, Progressive Web Apps or PWA) over native apps for several reasons:

• Alleviate induced obsolescence of the user terminals: native apps require the latest versions of the OS (operating system) and sometimes even the latest generations of devices to run properly which leads to hardware obsolescence. Few apps can run on devices older than seven years, whereas web apps are available in pretty much all browsers and for any type of hardware. This ensures good interoperability and longevity. Read more on this topic with criterion 1.9 from the RGESN repository: "Is your digital service designed with interoperable standard technologies rather than specific and closed technologies?" (French)
• Only one version: native apps require a manifold labor increase (iOS version, Android version, web version, etc.) during development as well as during maintenance. This uses more resources in terms of work hours, design system development, storing of resources, etc.
• Controlled updates: native apps require regular updates that generate data transfer for thousands, or even millions, of users. These updates often speed up smartphone obsolescence: they can be memory sinks and can make some features unusable. In addition to this, native app updates happen through a store by replacing a single large file, while web apps allow for selective updates, file by file.
• Smaller size: web apps are on average ten times lighter than native apps. The amount of data transferred to users and memory use on terminals are therefore lessened.

Worth noting: as with many other topics of eco-design, the point is to assess what you stand to gain in the context of your service and its functional unit. For instance, in some cases, if the data transfers during use are important and draw more heavily on hardware resources because of the browser itself, developing a native app can make sense.

Differentiating quality updates from feature updates

All that being said, native apps are sometimes difficult to replace with web apps: they do not offer the same range of features. If developing a native app is necessary, the environmental impact can still be limited by allowing users to install only the updates they want.

Service updates fall into two broad categories:

• quality/compliance updates: their purpose is to fix security flaws or deal with bugs so that the system remains operational;
• feature updates: they add or expand existing features.

Informing users of the content of an update, its potential impact on their devices, and interactions with their OS version allows them to make an informed decision as to whether to install the update or not. Thus, they can opt to install only the updates they deem necessary so that, among other benefits, they may keep using their device longer (source: Software updates: the urgent need for regulation - GreenIT (French)).

Example

What not to do

WhatsApp does not give any explanation on the type of update it is conducting and does not allow users to keep using the app if the update is not installed. This can lead many users to be unable to install the update (depending on the age or performances of the phone). Therefore, this creates obsolescence and forces users to upgrade their device in order to keep using apps like this one.

With this, we are touching on the potential controversy of continuous delivery, most notably in a very flexible development industry where sprints are often short (typically two weeks). This flexibility, such as with the Scrum method, can encourage more frequent updates. In 2014, 26% of the most downloaded iOS apps had been updated within the month (source: App Store Longevity and Freshness, David Smith). Clearly, it is preferable to space out updates in order to reduce the amount of data transferred in the long term, in addition to differentiating quality updates from feature updates.

Questions to be answered

• Why do I need a native app? Could a web app be sufficient?
• What should be done to differentiate quality updates from feature updates?
• What is the ideal frequency for updates to suit the needs of my native app's users? What sprint cycle is best suited for my team?