New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Haven Android Usability & Design Audit #218

Open
glenn-sorrentino opened this Issue Jan 13, 2018 · 5 comments

Comments

Projects
None yet
5 participants
@glenn-sorrentino

glenn-sorrentino commented Jan 13, 2018

haven deck cover

Haven Usability & Design Audit.pdf

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:

  • Usability
  • Accessibility
  • Interaction Patterns
  • Flow Efficiency
  • Information Architecture
  • UI
  • Visual Design
  • Design Systems

@glenn-sorrentino glenn-sorrentino changed the title from Haven Android Usability Audit to Haven Android Usability & Design Audit Jan 13, 2018

@fat-tire

This comment has been minimized.

Show comment
Hide comment
@fat-tire

fat-tire Jan 15, 2018

Contributor

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!

Contributor

fat-tire commented Jan 15, 2018

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!

@conorsch

This comment has been minimized.

Show comment
Hide comment
@conorsch

conorsch Jan 16, 2018

@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.

conorsch commented Jan 16, 2018

@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.

@glenn-sorrentino

This comment has been minimized.

Show comment
Hide comment
@glenn-sorrentino

glenn-sorrentino Jan 16, 2018

@conorsch @fat-tire Thanks for your feedback! I'll split these up into smaller issues this week. @fat-tire, you make some great points for the permissions - let's discuss in more depth when I break this conglomerate up!

glenn-sorrentino commented Jan 16, 2018

@conorsch @fat-tire Thanks for your feedback! I'll split these up into smaller issues this week. @fat-tire, you make some great points for the permissions - let's discuss in more depth when I break this conglomerate up!

@deviantollam

This comment has been minimized.

Show comment
Hide comment
@deviantollam

deviantollam Aug 24, 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.

great work!

deviantollam commented Aug 24, 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.

great work!

@glenn-sorrentino

This comment has been minimized.

Show comment
Hide comment
@glenn-sorrentino

glenn-sorrentino Aug 24, 2018

@deviantollam Very much appreciate your kind words! Looking forward to helping more in the future!

glenn-sorrentino commented Aug 24, 2018

@deviantollam Very much appreciate your kind words! Looking forward to helping more in the future!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment