UX Audit: Status
The Dreaded Triple Bar – or when design is outside your control
Status.im is one of the earliest projects on the space and the first to focus on a mobile browser. It starts with a–brilliantly correct–assumption that browsers in mobile are not about being smaller versions of their desktop companions but should be all about messaging. As a messaging app is also far ahead of the competition, being a rare example of an open-source, end to end encrypted, fully anonymous message app. I would say it’s one of the best-designed Ethereum focused wallets out there right now. Still, here’s how a typical Dapp looks in Status:
Ok, this is an exaggeration, a composite of many nasty popups, tabs, and other anti-patterns I found while navigating. Here are two real-world examples, the apps Zapper.fi and Zerion. I want to highlight not the apps’ content, mostly, but the many bars on top and the bottom of the screen. Notice how on the left side, the top bar for Zerion has two similar “x” in a similar place, followed by a hamburger menu.
But the worst offender in this list is undoubtedly the triple bottom bar in the zapper.fi app. The bottom two are from Status, and the top one is from Zapper. Who designed this? Well, most likely, no one did. The old saying, “success has many parents; failure is an orphan” applies very often to design. Design failures are not usually planned, but a set of decisions that individually are not wrong but collectively become a bad idea. Zerion having a top bar suggesting you download the mobile version followed by a hamburger menu is standard practice. Zapper using a bottom bar is a good idea in its face. Status having two bottom bars always visible is… Well, no, this is a bad idea.
Why is bottom navigation bars so typical in mobile, while the same navigation often becomes a side or top menu on a desktop? The reason is quite simple: it’s the natural area in which our thumbs can easily navigate around when you hold the device one-handed. Also, because your thumb is an imprecise instrument, they’re on the bottom so that if you hit them slightly below or above them, then that’s still ok. Similarly, the top menu or all the screen sides are used on desktops because if you move the mouse cursor quickly, that’s the longest and most comfortable hit area. Suppose you configure your computer so that a second monitor is arranged above the main desktop. In that case, you’ll see how much of a burden it is to hit the menu or bottom bars on the Mac–instead of being just a quick swipe of the cursor, now you need to hit precisely the border between displays. Creating two (or three in this case!) bottom menu bars transforms the area from a lazy reach from your thumb into a complex control panel.
The reason that Status had a double row of bottom navigation seems to indicate that the main navigation and the “browser” navigation were built designed separately, with both adopting the bottom bar as the “natural” way to navigate that particular hierarchy. So it’s natural to expect that an app designer, also working from a different blank slate, would also want to use this prime spot — and therefore, we end up with the haunted triple bar. Probably not designed by any individual, still what the end-user sees. It’s also indicative of a misunderstanding of the hierarchy of functionality versus the hierarchy of usage. From a company perspective, maybe developing the wallet or critical management took a lot more resources than the browser — browser is just one feature of many. But all features follow a Pareto rule: there’s a tiny number of features that account for 80% of usage, and that’s where the browser is.
What is the purpose of these buttons? I arranged them in this diagram with a color code:
We have two different buttons that will take you to chat rooms (although in other areas) positioned on different sides of the screen. Similarly, we have two buttons that will often take you to the same place, the “home” of the browser bar, one on the top another on the bottom. Going “home” on the browser bar has an unhelpful “×,” which makes it seem you are “closing” something. On Safari, the “×” is used briefly as a symbol of “stop loading,” It’s also used as a symbol to delete the URL and write a new one. This particular “×” does neither. I found it quite hard to type a new address since you need to tap the address bar multiple times until it selects the full address and then types backspace on the virtual keyboard. In the example I’ve shown earlier, a similar “×” is used to close a top informational bar. The top right corner is quite a noble position for such an unremarkable and imprecise button.
For the 12 buttons visible on the screen, what would the user probably use the most? Of course, this would require user testing, but I would be willing to bet they would be, in order, the navigation, followed by identity, followed by chat, and finally all the rest. Using that rule, we could probably hide most of the other buttons. A lot of the navigation can be done via gestures that are already standard in iOS, swipe from the left to go back, to the right to go forward, slide everything down to close the tab. Of course, these should be offered as additional, a back button icon should be present.
The four buttons on the bottom bar represent an identity crisis in Status: what is it, a messaging app, a dapp browser, a wallet, or an account management tool for your crypto? Of course, that decision needs to be a strategic one from the team, but I would dare make a bold suggestion here: drop the wallet.
A wallet is just an app among many that you can use. Many wallet interfaces are available on the status “app store” that offer pretty much the same functionality. Don’t remove that functionality, of course; just put it in the same level as any other “favorite app” as a removable default. The second suggestion would be to hide the whole account management thing deep in some hierarchical level. A user will rarely need to use it to get back some of that real estate space back. What’s left is a browser and chat, which reveals what status should strive to be:
Status is a social app browser for crypto
It’s the easiest way to interact with crypto apps, but it’s also something you can do while interacting with friends. A universal discord chatroom for all Ethereum. Let’s look at the same page, but remove all the disabled and redundant buttons and hide some of them inside the new icon representing where × used to be.
It’s clear that there’s enough room for us to not need a double bar anymore. But I think a cleaner state like this is an opportunity to think about the app’s meaning and depth. We could have a bottom bar with just three buttons–but navigation buttons only make sense inside a browser window, and you can think of a chat as something on top of all apps, a toggle of sorts.
In this design, Status starts as the main app offering all the cool, exciting stuff Ethereum has to offer and then gradually disappears in the background until the app uses all the space on the screen. Notice even the bottom bar navigation has only two buttons, but these two can also become invisible. These buttons will reappear once the user scrolls up (a standard practice in many apps, including Safari, Google, Preview, etc.). Still, most of the same functionality can be achieved by gestures: swipe from the left to navigate back, scroll down to make the top bar appear, and finally exit the app completely.
Swipe from the right could even be used to show the chat page, again reinforcing the concept of Status as a shared social browser. Or maybe it could even be on the back of each tab, with a flip around animation.
In Conclusion:
Designers don’t always control all the experience, and sometimes that’s good. Also, an issue with UX is often an issue with a fundamental division, from within the team on what they’re building. Often we want to show on the navigation all the effort we put into making our features, but the reality is that a few features will account for most of what your users will use. Hide the other 80%, and you will get a lot of new blank space to play. Use that to rethink the hierarchy and depth, and you might come out with a brand unique experience from just moving stuff around.
Response from Status
Before publishing this post, I’ve sent the draft for the Status team to take a look and they provided me with a response, quoted below:
Introspecting, when focusing a on Browser, a challenge that absorbed our attention has been how to provide access to dapps, while being at the mercy of Play/App store policies. Hence the spin-off https://dap.ps/.
Regarding gestures: (…) We have a long standing issue for the browser address and tool/nav bar to ‘hide on scroll’. This is definitely a good reminder to get back to that. (…) Gesture interactions can pose it’s own challenges of staggered interactions, less visible but similar to the multiple tab bars or close items. E.g. horizontal scroll in the dapp, in the browser, between tabs.
The potential of moving ‘key management’ to the background is definitely there. At the same time, there’s power in considering ‘wallet’ (i.e. account management) an integrated component. For example, to facilitate sending funds over chat, register an ENS username for use in chat, moderating chats through staking mechanisms, setting up paywalls to provide services, or block unsollicitate connections, voting in chat. These types of features benefit from direct access to the associated accounts.
Generally, you’re touching on a critical topic for us with the suggestion to move wallet, as we need to deeply understand the distinction between key management, identity and wallet interactions for purpose of transactions. Food for thought for sure. Here’s a prototype of a more Browser centric (or OS -like) navigation you might enjoy:
Thanks Simona and the rest of the team for the reply and the hard work you’ve put in Status!
