Mobile component usage
Our mobile design approach focuses on using system defined components from Material Design and the Human Interface Guidelines when possible, while also balancing the need for custom components to accomplish specific goals for growing our mobile applications.
Here's why we use system defined components:
-
Stay updated & future-proof: Using system defined components means our designs stay in sync with the latest UI trends and OS updates. As operating systems evolve with their annual updates, our designs remain contemporary without any extra effort.
-
Benefit from ongoing improvements: These components aren’t just static elements. Over time, they receive updates that might improve their functionality or efficiency. For example: the password authentication system is a system defined component which allows the components to be updated with OS versions.
-
In-built Accessibility: system default components often meet foundational accessibility standards on the devices and work seamlessly with integrated accessibility tools.
- User understanding and recognition: By leveraging familiar patterns and UI we get two benefits; firstly, we can reduce the cognitive load for our users whether they are first time users or getting new features. Secondly, since we don’t need to teach them something new, we’ve simplified onboarding and can focus on conveying the value proposition or benefits of our features over teaching people how to use it.
However, while system defined components offer numerous advantages, we also recognize the potential benefits and needs of custom components.
Custom components demand not just initial effort to build, but continuous upkeep to remain functional and relevant, especially with frequent OS updates. Considering our mobile engineering and UX teams are constrained for resources, it's crucial to weigh the maintenance trade-offs. The reality is, without consistent upkeep, the user experience of these custom components will deteriorate over time.
We advocate for custom components when:
- System defined components fall short in meeting specific end user, business, or product objectives.
- The feature promises significant value or has the potential to significantly boost daily active users.
- There is an opportunity to provide differentiating value.
To summarize while we sometimes need to build custom components, our mobile philosophy emphasizes the long-term benefits of leveraging what's already available and optimized on mobile platforms.
Tablets & Large-Screen Devices
The tablet and large screen strategy is evolving as we get more sophisticated in our understanding of tablet usage. Currently, we are looking at how to better support external inputs, like a keyboard, and updating that across both iOS and Android.
Adaptive Layout System
Starting with Android, we have created an adaptive sizing and spacing system (documentation on Acorn to come). This size and space system is not yet optimized for all parts of the Firefox experience as of Q4 2024.
With the size and spacing tokens system, we are moving towards the ability to support a wider array of screen sizes, including tablets, and will be able to leverage this system when designing new features to also deliver more guidance on how and where the UI changes across screen sizes.
iPadOS
At the moment we consider how UI may look on iPads and provide guidance via specs, but do not create iPad optimized / centric experiences. We also try to take advantage of OS provided features such as multi-tasking.
Android Tablets
In addition to work on the adaptive layout system, we are looking to understand our tablet users more and finding other opportunities to optimize Firefox.
However, despite these improvements, we generally don’t provide tablet only experiences or target tablet specific use cases mostly due to the bandwidth of both the eng and UX teams. Rather what we are aiming for is for our designs to adapt well to the larger screen (e.g. not weirdly stretched out) and take advantage of OS tablet features like iOS multi-tasking and external inputs.