Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Haven Android Usability & Design Audit #218
This deck walks through the production beta version of the Haven app, including onboarding, starting a new session, logs & settings. First I call out potential issues, then offer potential solutions. This work focuses on:
Wow this is a fantastic, thoughtful and helpful analysis with many, many great suggestions for improving the UI.
One thing I think maybe needs to be reconsidered/discussed further is the idea that all permissions should be combined into "one hurdle that a user needs to get over in order to jump right into the app." (p 18, p.30 etc.) with a message that says something like "We're about to ask you for a set of permissions that'll make Haven work for you"
I'm not so sure about this. Google suggests several request patterns for when the app should request certain permissions. "Critical permissions should be requested up-front. Secondary permissions may be requested in-context."
In haven's case, this is an "up front" ask because it's part of the initial wizard thing, but it's also done piecemeal in context, when the permission is actually needed, so that there's a clear correlation between the function and the permission, which makes it obvious why the permission is being requested. Putting a pile of sensitive permission requests (camera, sound, etc.) in one "hurdle" is probably not going to be too helpful for a user who is installing a security-minded app. That kind of user should be super-informed what every permission is for and if they are not planning to use one or more of the features (say, camera) they should be able to decline at the appropriate moment (say, of setting up camera sensitivity) rather than a contextless "hurdle" up front where they don't even know why they're being asked for the permission.
I kinda feel like the most transparent ask for permissions-- explaining what it's used for and why it's necessary to approve them-- is the best approach given the sensitive user demographic for this particular app. (Thanks to Haven's affiliation with Snowden, it's not hard to find people who are insisting this app will forward your deep, dark secrets to the FSB, so some additional care and explanation regarding permissions might be warranted.)
Also-- if the bulk of permissions are all asked up front and the user declines to accept one or more of them, then what? How should the rest of the flow continue? Are configurations requiring permissions simply pulled out of the sequence? Is the user offered an opportunity to re-enable them via settings? Is some carefully-worded rationale provided-- via toast? snackbar? Its own screen?
Incidentally, if these UI suggestions are accepted by @n8fr8 and others, perhaps they should be broken into sub-issues so people can work on them peicemeal? That's something maybe @glenn-sorrentino could probably do, yes? Small, bite-sized issues (change icons from play to +, add < back buttons to wizard, fix contrast colors for readability, etc.) perhaps with a reference to the page in the UI guide that describes the fix? People could then claim issues and hopefully turn them around quickly without stepping on each other's work. One of the considerations actually in triaging might be to distinguish issues that can be applied independently without conflicting with another as to avoid conflicts...
Anyway, again-- nice job!
@glenn-sorrentino Fantastic report, thank you for taking the time! At a high-level, I don't object to any of the proposed recommendations: they all feel solid to me, and many of them are well explained solutions to UX quirks that have irked me, too.
As @fat-tire suggested, it would be grand if you could slice the report up into smaller issues, scoped to action items to knock out over time.
This was referenced
Jan 18, 2018
referenced this issue
Apr 21, 2018
everything about this entire slide deck and presentation notes are so utterly wonderful that i want to buy you dinner, @glenn-sorrentino
seriously, as much as some people might consider this "soft" development (as opposed to "hard" coding of under-the-hood functionality, engine, etc)... to me this is the kind of work that makes an app look more professional (and thus more trustworthy) as well as making it more easily adopted by the masses... which is how it will have serious impact on the world.