Skip to content
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

Reconsider flow-interrupting "open in native app" dark UI pattern #41

Closed
ryanprior opened this issue Jul 12, 2019 · 4 comments
Closed

Comments

@ryanprior
Copy link

ryanprior commented Jul 12, 2019

This "open in native app" modal is a dark design pattern. Simply put: as a user of https://appcenter.elementary.io/ if I click the icon for an app I expect to see the app's page in my web browser. The current design is a classic bait-and-switch antipattern: I ask to see details for the app, but the AppCenter website instead tries to redirect me to the desktop app.

It's fine to offer "Open in AppCenter" as an option on the app detail page, even prominently. But the current behavior is busted.

A few scenarios:

  • I'm a user who's not on Elementary OS but somebody linked me to an app page, or to the AppCenter homepage. In this scenario the bait-and-switch cannot possibly accomplish what it sets out to do, so it serves only to confuse me and waste my time.
  • I'm an Elementary user browsing on a secondary non-elementary device. Here too the bait-and-switch is useless at best.
  • I'm an Elementary user browsing the web on an Elementary device, and I follow a social media link to an AppCenter page. After the initial confusion of being served a modal dialog instead of the content I was expecting, I have to make a decision (do I prefer the web or native interface?) and click an extra button before getting to the content I wanted.

There's practically no scenario where the current behavior is an improvement on doing nothing. Please consider reworking this flow in light of these common user stories. Thank you for your work with AppCenter!

open in app  dialog


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@cassidyjames
Copy link
Contributor

I think a lot of your criticisms stem from the fact that it's technically impossible to know whether the user is on elementary OS or not; we don't ever want to display an "Open in AppCenter" button for folks who are not on elementary OS, and the next best thing we can tell them to do is to get elementary OS so that they can use this app.

So, for now, we throw the dialog at the beginning of the process (getting a definitive answer early on whether they're on elementary OS or not). If the user is on elementary OS, it makes sense to just direct them to the native client which is very fast, has all of the same information (and more, like other apps by the developer and more metadata down below), and provides the ability to install an app.

If a user says they're not on elementary OS, we remember that and never show this dialog again, so it's a one-time thing in your second and third scenarios.

I think in a perfect world, clicking an AppCenter link on elementary OS would just open AppCenter right off the bat, and if you're not on elementary OS, it would just show you the listing on the web. Perhaps this could be redesigned to support that case, where there's an "Open in AppCenter" button or a "View Listing on the Web" button, and then a checkbox to remember the preference.

@ryanprior
Copy link
Author

Thanks for the reply! Sounds like you're pretty confident that it's technically impossible to tell whether a visitor is using Elementary, are you 100% on that?

@cassidyjames
Copy link
Contributor

@ryanprior yes. Third-party browsers do not provide reliable/accurate user agents (often stating Linux and/or Ubuntu, making them indistinguishable from other Linux- or Ubuntu-based OSes). Originally we attempted this, but it had such a high false positive rate that it wasn't worth it. And attempting some sort of deeper fingerprinting seems too fragile to be worth the effort over an explicit user choice.

@cassidyjames
Copy link
Contributor

This has been resolved in main and won't be re-introduced due to #62

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

No branches or pull requests

2 participants