🕓 2 MIN April 30th at 3:00 …
Menu
In today’s world, it is essential for any application to be accessible across multiple platforms to reach a wider audience. However, building a multi-platform application leads to some unique design and navigation considerations. In this blog post, we will discuss the key factors developers should keep in mind while building a multi-platform application.
Before we get into the specific design and navigation considerations, it’s helpful to step back and look at the high-level challenge of building applications that work on any screen size or orientation, in other words, a multi-platform application.
The term form factor often refers to the device’s physical characteristics where the application will run. These characteristics might include its size and orientation, whether it’s a phone, tablet or desktop, and whether it’s equipped with a touch screen. While some applications will be built with a single device form factor in mind (for example, a standard tablet that an organization rolls out for a specific line of business application), most applications will have to adapt to the device the application is being run on.
As you can imagine, it’s almost impossible to define the form factor of every device an application will run on, particularly for consumer-oriented applications deployed via any of the Stores. Luckily, when developing applications, the form factors can typically be clustered based on only a few relevant characteristics. These groups are then used in the design process to define how the application will look and behave when run on any device belonging to the group.
A common way to group devices is to look at the device’s orientation, such as portrait and landscape. For example, when designing for a phone, it’s common to assume the application will be run in portrait, whereas landscape is more common for tablets. Desktop (which includes web) is more complex as the application needs to support transitioning between portrait and landscape orientations based on the size of the window. For the remainder of this post, we’ll focus on how device orientation impacts design and navigation considerations.
For the rest of this blog, I will use the open-source Uno Platform examples to pontify specific challenges regarding responsive design and navigation and their solutions.
A responsive design is an approach that allows an application to adapt to different screen sizes and resolutions, ensuring that the content and user interface look good and function well on any device or platform.
There are typically two levels of responsive design. The first can be thought of as built-in or automatic resizing, where the elements on a page resize or adapt based on some constraints or rules. For example, if you set the HorizontalAlignment to Stretch on a Button, as the application resizes, the Button will automatically resize to fill the available horizontal space.
An example of where the built-in support is used is on the product details page in the Commerce sample. As the window resizes, the width and position of the elements adapt dynamically to accommodate the different screen sizes.
Another example of using the built-in support is the choice of layout containers. For example, in the Uno Platform Template Wizard, a UniformLayoutGrid is used inside an ItemsRepeater to allow the items to wrap based on the width of the application, as shown in the following image.
In a very limited set of scenarios, relying only on the built-in support for adapting to different devices may be possible. However, it’s more likely that the design for an application needs to respond to the device and dynamically adjust the layout of the application accordingly. One way to do this is by controlling the visibility of elements in a XAML application based on the size of the application.
The eCommerce sample makes use of both a TabBar and NavigationView, depending on the orientation of the device. Controlling the visibility of the TabBar and NavigationView is done by defining different VisualStates. An AdaptiveTrigger is associated with each Visual States to automatically trigger a change to a specific Visual State based on the size of the application.
An important consideration when designing a multi-platform application is the use of navigation components such as tabs, navigation view (aka burger menu) and menus (typically used in desktop applications). For example, when an application is being run in portrait, the navigation view feels inappropriate when simply switching between areas of the application. Using a set of tabs in this scenario is a much better user experience, which is why we see it used across applications such as Facebook and Twitter.
Since multi-platform applications need to support different device orientations, it may be necessary to switch between various navigation components. We saw this earlier where VisualStates were used to switch between TabBar and NavigationView in the Commerce sample.
Another navigation consideration is how an application handles the user clicking on an item in a list to see more information about the item (often referred to as the master-details, or list-details, pattern). In portrait orientation, displaying more information typically involves a page-level navigation to a new page that will display the item’s details clicked. Alternatively, in a landscape orientation, where there’s enough space, the item’s details can be displayed adjacent to the list.
In the ToDo sample application, this technique of adapting navigation to suit the orientation is used throughout the application. When running in portrait, as the user taps on a task list, the list opens in a new page, and subsequently, when they click on a task, the task opens in a new page. Conversely, when running in landscape, selecting a task list and then a task simply opens the item in an adjacent panel.
A common consideration that’s overlooked is that in the portrait scenario, there should not be any selection retained by the list, whereas in landscape, selection is required. This is because in portrait, when the user returns to the list after looking at the details, they expect to be able to tap on the same item again; they also expect the list to be scrolled at the same place it was when they tapped on the item. As opposed to landscape, where the details are presented in a pane adjacent to the list, it’s important that the selected item is identified in the list.
A few other points should be considered when building a responsive application.
A dialogue can be used when prompting the user for a response or just notifying them. However, depending on the content of the dialog and the form–factor of the device, the dialog can be presented as either a modal dialog with a dismissible background; or in full–screen mode.
It’s also important to consider whether a press of a hardware back button if one exists for the device, will dismiss the dialog or not.
As the user navigates within the application, it’s important for the application to provide a mechanism for the user to return to where they were previously. This concept is often referred to as a back-stack, where the user can go back to previous pages in the stack.
While a back stack is conceptually quite simple, it gets more complex when you break up an application into different sections, for example, with a TabBar. In this case, the application should maintain a back stack for each tab in the TabBar. This gives the user the ability to switch tabs without the fear of losing whatever context they had for specific tabs.
A topic often overlooked by mobile and desktop application developers but commonplace amongst web developers is the ability to deep link into specific sections and/or content. This can be used to make it possible to share links into the application without being concerned about which platform the application is running on.
Initially, the deep linking strategy could be as simple as the list of pages that are in the back-stack at the point where the link is shared. However, as the complexity of the application grows, the deep linking strategy may need to evolve. For example, if you have a responsive design for the list-details pattern that makes use of navigation in portrait and displays details adjacent in landscape, you’ll end up with two different deep links for the details page (/list/details in portrait and /details in landscape). This is made more complex because you can’t control the ’device’s orientation where the user clicks on the deep link, so it’s important that the application has a routing strategy that can translate a deep link into navigation within the application.
In this post, we’ve covered a number of challenges that developers face when building multi-platform applications that need to adapt and respond to the different sizes and shapes of devices that the application is running on. This post is by no means an exhaustive list of the approaches to solving these challenges. Still, it hopefully provides you with enough examples to come up with your own application–specific approaches that leverage the Uno Platform. To set up your environment for working with the open source Uno Platform and to use examples above, please refer to this documentation.
I hope this blog post helped shed some light on the complexities of navigation and responsiveness in multi-platform applications.
To upgrade to the latest release of Uno Platform, please update your packages to 4.8 via your Visual Studio NuGet package manager! If you are new to Uno Platform, following our official getting started guide is the best way to get started. (5 min to complete)
Tags:
🕓 2 MIN April 30th at 3:00 …
🕓 5 MIN From simplified UI design …
Uno Platform 5.2 LIVE Webinar – Today at 3 PM EST – Watch
