Trackr is a sample task management app. While mainly used to explore common UI patterns from the perspective of supporting accessibility, Trackr is also one of the samples where we showcase modern Android development best practices. We recently adapted the app for large screens, so let’s take a look at how applying Material Design and responsive patterns produced a more refined and intuitive user experience on large screen devices.
Before: From the Tasks screen, you could access Archive and Settings from the menu in the bottom app bar. On large screens, the menu control is a tiny touch target in an inconvenient place, and the bottom app bar is excessively stretched.
After: When the screen is wider, we show a navigation rail instead. We also place the floating action button (which opens the New Task screen) in the navigation rail and remove the bottom app bar entirely.
Although this change was made with larger devices in mind, it’s also beneficial for phones in landscape mode because there’s more vertical space to see the list of tasks.
Before: The Tasks screen and Archive screen took up the full display width, and tapping an item replaced the list with that item’s detail. On large screens, UI elements were either stretched out or grouped to one side, and the screen felt very unbalanced.
After: Both the Tasks screen and the Archive screen show a list/detail UI using
SlidingPaneLayout. We wrote about how to do this in a previous article on changes we made to the Google I/O app, so check that out if you’re interested in the technical details.
The Task Detail screen also had a floating action button (which opens the Edit Task screen), but if the navigation rail is visible, that would result in two floating action buttons, which isn’t ideal. Instead, we hide the second floating action button and add an edit button to the toolbar in the top right
Edit Task and New Task
Before: When you edit a task, the Edit Task UI replaced the Task Detail and occupied the entire screen. Like with Task Detail, this screen felt very unbalanced. The New Task UI also had the same problem (in fact, New Task and Edit Task are actually the same destination in our navigation graph).
After: On large screens, we use a
DialogFragment so that the Edit Task UI floats over the rest of the content.
Originally we tried showing this UI in the detail pane by replacing the Task Detail. While this was straightforward, we quickly found we were unsatisfied with that approach for a few reasons:
- It doesn’t make sense for creating a New Task, a feature which is now universally accessible in the navigation rail. We could make New Task a separate destination and give it a different behavior, but that didn’t feel like a good solution.
- Edit Task looks very similar to Task Detail, just with the fields in an editable state. In a two-pane layout, when we replace the Task Detail with the Edit Task in the detail pane, it almost looks like nothing happens — there just isn’t enough visual emphasis where it needs to be. By contrast, the
DialogFragmentengages the user and puts the focus front and center.
- We don’t want to navigate away from Edit Task (or New Task) until the user saves their changes or we confirm that the changes can be discarded. This is easy to intercept when the only way out was by using the back button, but with the new app design, we have additional cases to worry about: the user could tap on something in the navigation rail or tap a different task in the list pane. Temporarily disabling all of these elements would be cumbersome. With a
DialogFragment, all of those are behind the dialog and the user can’t interact with them, which is exactly what we want.
The takeaway here is that the most straightforward design can have gaps in functionality when you try it on a device. When that happens, take a step back to focus on the user experience, and look for a design pattern to facilitate that.
I̶n̶ ̶p̶r̶o̶g̶r̶e̶s̶s̶ Completed
With the rising popularity of tablets and foldable devices, creating a responsive UI is more important now than ever before. We showed how adding a navigation rail and using
SlidingPaneLayout not only makes the Trackr app look better, but also drastically improves usability and creates experiences that couldn’t exist on a mobile phone. We also showed how sometimes you must rethink your design around usability, not just screen space, in order to best meet your users’ needs.
We hope you like the new and improved Trackr! Check out the code on github.com/android/trackr.