Redesign Challenge (2/52):
Dropbox for Android
I love Dropbox. I use it for collaborating at work, sharing photos with friends, saving backups of files, saving screenshots, and pretty much anything else I can justify using it for. Dropbox is also one of my favourite apps for iPhone, and feels right at home by striking a good balance between the Dropbox branding and the iOS 8 look and feel. The Android app, on the other hand, is styled to match the platform’s 4.x Holo theme. My goal with this week’s redesign challenge was to re-imagine Dropbox for Android by making use of Google’s Material Design language as seen in Android 5.0 Lollipop.
Navigation Structure
The main focus of a lot of these weekly redesigns will be the navigation structure. It’s usually the biggest contributor to the overall experience, and a good navigation structure will make the app feel at home on the platform.
First, let’s take a look at the existing Dropbox Android app:
The current Dropbox for Android uses a tabs in the action bar to switch between four top-level sections: Files, Photos, Favorites, and Notifications. The overflow button in the top-right of the action bar is reserved for everything else: Help, Settings, folder actions, sorting, etc. The arrows beside files and folders also surface some of those actions that are tucked away in the overflow menu, while including file-specific actions.
Navigating through folders works as you’d expect, for the most part. However, because of the use of tabs, there’s no visual indication in the action bar that you’ve switched folders, and no animation to indicate a hierarchy, so navigating up and down through folders feels the same in both directions. The use of tabs also means that information and actions that would typically be found in the action bar have to be displayed just below the action bar instead.
With those points in mind, here’s this week’s redesign:
The biggest and most obvious change is the use of a navigation drawer. While Apple advocates against using navigation drawers, Google couldn’t disagree more. Not only have they included the pattern in their Material Design guidelines, but screens with the infamous hamburger button show up in nearly every section where there’s a pattern or component example. With the exception of a few simple apps, you’d be hard-pressed to find an Android app made by Google that doesn’t use a nav drawer as the top-level navigation.
Which brings me to those exceptions. Android and iOS take different approaches to navigation hierarchy, and specifically different approaches to the use of tabs. iOS uses them as the top-level of the navigation hierarchy, while Android usually uses them as the level just below the app bar (action bar pre-Material), to further compartmentalize a main section. As a general rule, the navigation hierarchy is as follows:
iOS
Tab Bar → Navigation Bar → Segmented Control → Content
Android
Nav Drawer → App Bar → Tabs → Content
You can see that iOS uses a segmented control where Android typically uses tabs, and a tab bar where Android typically uses a nav drawer. The exception is with simple apps, where the top-level can be removed altogether from both iOS and Android, leaving the Navigation Bar and App Bar as the new top-levels.
While exploring navigation methods for Dropbox, it became clear that it’s not a simple enough app to remove that top-level and still maintain the best experience. The Dropbox iOS app maintains the top-level through a tab bar, so while using tabs in Android may appear to be more consistent, from a hierarchical perspective, it’s a larger difference.
The change from tabs to a nav drawer also brought some other notable changes. For one, additional real estate is no longer necessary to display the current folder and Up button for navigation, which can now use the built-in app bar controls. The space freed up in the app bar also allows for commonly-used actions to be surfaced from the overflow menu, such as search and folder sharing.
Finally, the introduction of Material means the primary action — in this case, adding to Dropbox by uploading files, creating a new folder, or creating a new text file — can be contained in a floating action button for easy access.
File List
My assumption with this redesign was that most people using Dropbox for Android will spend most of their time browsing through lists of files and folders, and performing actions on them. It was important to make the list easy to read, the actions easy to find, and the overall experience as intuitive as possible.
Another goal was to keep as much consistency as possible with the existing Dropbox brand and apps, while truly fitting in with Android 5.0 Lollipop and the Material Design aesthetic. You can see the parallels with the iPhone app above, with the share icons in the app bar and navigation bar, consistent colour and font weight usage, and consistent list ordering.
The floating action button in the file list gives easy access to primary content-related actions: Upload here, New folder, and New text file. With Material in its infancy, I’ve been looking at Google’s own apps for usage examples. The overlay and labels that appear when the Add icon is tapped takes cues from Google’s Inbox Android app. However, I disagreed with covering the app bar in this case, since it gives context to where the file or folder is being added.
Bulk actions are something that are conspicuously missing from Dropbox for Android, because the long-press is currently used to bring up additional actions for an individual item. Since I removed the arrows from each list item, I thought it was necessary to add a method of performing actions on an item without leaving the list, while adding the ability to perform bulk actions.
The result is that long-pressing any file or folder in the list will switch to bulk edit mode with a contextual app bar. I’ve seen two versions of this in Google’s own apps. One with a Back arrow, as you would see by navigating through a hierarchy, and one with a Cancel icon, as you would see in a dialog. The Back button seems to be more popular, but contextually, as a state change on the same list, the Cancel icon makes more sense to me. Regardless, the contextual app bar shows how many items are selected in the title, and gives easy access to the actions of moving and deleting those files, along with additional actions in the overflow menu.
Moving Files
I chose to tackle the experience of moving files as a part of this redesign because it was a less obvious flow than simply sharing a link or renaming a file. In the existing Dropbox for Android, the user is presented with a dialog to navigate through folders. Interestingly, despite the appearance of a Back button in the top-left of the dialog, tapping it simply closes the window. Traversing through folders is identical to the main part of the app, with an added New Folder button.
I used a full-screen dialog in my redesign to allow for maximum screen real-estate. Like the contextual app bar, the dialog app bar uses the grey from Dropbox’s colour palette to differentiate itself from the main sections of the app. The Cancel icon in the top-left of the app bar closes the dialog, while the Move button in the top-right confirms the folder selection. Both the Choose destination text and the current folder location are located in the app bar title for clarity. Lastly, the New Folder action sits prominently at the top of the folder list.
As you navigate through folders, the Cancel button in the top-left of the app bar is replaced by a Back arrow. If you’re several folders deep and decide to cancel moving the file(s), this would be less convenient than a Cancel button that’s always available. However, the Back arrow makes traversing folders much more intuitive, and I would expect that once a user decides to move a file, the likeliness of them cancelling after navigating through folders is significantly less likely than cancelling after the initial dialog opening. I also made the decision to hide files entirely from the Move dialog. They served no real purpose, and because I changed the way files are ordered to stay consistent with iOS, it would have made folders more difficult to find. Finally, once the file has been moved, the user is presented with a snackbar with the option to easily Undo the move if it was accidental.
File Viewer
The last screen I had time to redesign this week was the file viewer. It is, as you’d expect, a pretty simple screen. My goal with the file viewer was to make it entirely about the content. When viewing a photo, for example, it’s already scaled to fit the entirety of the screen, and a single tap would hide the app bar, status bar, and navigation bar. Something that I wish all photo viewers would do.
The app bar is transparent, with icons remaining legible above the photo with a subtle scrim, while the status bar and navigation bar are translucent. I decided that the file name and number didn’t have enough value to be worth cluttering the app bar. Instead, I opted to bring focus to the primary actions: Favorite, Share, and Delete.
The share button is located in the same position in the app bar in both the file list and file viewer, while the delete button is located in the same position in both the bulk-edit contextual app bar and the file viewer. This helps to reinforce muscle memory and expectations of where an action will be located between screens.
While all of the app bar icons I had used in this redesign up until this point were default system icons, I used a custom icon for Favorite. Actions such as Share, Delete, Back, and Cancel are platform-specific and more related to system actions than to the app itself, so replacing them didn’t make sense without an aesthetic conflict, but Favorite is an exception. Since it’s an icon that shows up in the navigation, and appears on other platforms, it made more sense to use an icon that’s more closely related to the brand than the default system icon. This helps to mentally link the action of favoriting to the Favorites section of the app.
Conclusion
Two down, fifty to go. Despite designing more screens, and writing my thoughts in more detail, this week was not nearly as rushed as the last. Part of that can be attributed to no longer being in vacation mode, but I think even after just last week, my ability to get my thoughts down in a somewhat structured manner have improved. I had hoped to post my write-up earlier in the week, but in the end I was having fun with it and wanted to design a couple more screens. Because of that, I think the size of these posts will likely vary depending on the subject matter and how much I’m enjoying the redesign process.
Regardless, this was another fun week. I believe this is the first Material Design work I’ve shown off publicly, and it’s a design language that I already love to work with. Once again I’m happy with the results of the redesign; I think the branding was maintained, consistency with iOS was increased, and overall fit with the platform was increased with the distinct Material personality.
If you’d like to follow along, or if you’re reading this from the future and want to see what I’ve redesigned since the start of the year, I’ll be posting everything to my Weekly Redesign Challenge publication.
