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

Changing language around Redirects and Gateways #741

Closed
1 task done
lidel opened this issue Jul 26, 2019 · 5 comments
Closed
1 task done

Changing language around Redirects and Gateways #741

lidel opened this issue Jul 26, 2019 · 5 comments
Assignees
Labels
effort/days Estimated to take multiple days, but less than a week exp/intermediate Prior experience is likely helpful kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked topic/design-content Content design, writing, information architecture

Comments

@lidel
Copy link
Member

lidel commented Jul 26, 2019

Changing language around some features

We are at the stage where we need to rework language around some features provided by IPFS Companion. Current labels describe what happens at the technical level and don't tell much about the purpose unless user is already familiar with low level details of our stack.

Main menu looks like this.

Having two entries controlling "Redirect" do not help:

2019-07-26--11-21-31

On the technical level, there are different things we can "redirect":

However user does not care about the distinction.
They just want to "use local node where possible".

Current idea is to:

  • Rename Global Redirect toggle (the one that controls all redirects)
    • I believe we should stop using "gateway" here, as we will have native protocol handler at some point, and "redirecting to a gateway" won't make sense anymore
    • Initial ideas: "Prefer local node", "Use preferred node", "Try local node first"
      (would love feedback on this)
  • Replace or move Per-website redirect toggle (Enables user to disable redirect on a specific website)
    • Update: ✔️ Moved to Preferences in c7c3221
    • The main purpose for this was to give people a way to fix a website that was broken by a redirect without disabling redirects globally.
    • I think we should be more honest about this, and replace redirect toggle with one that disables all IPFS integrations on specific website.

Would love to hear some thoughts on this.

@lidel lidel added UX topic/design-ux UX strategy, research, not solely visual design labels Jul 26, 2019
@ericronne ericronne added the topic/design-content Content design, writing, information architecture label Jul 26, 2019
@ericronne
Copy link

Re labeling, Try local node first and Ignore this site strike me as lovely and clear plain-language descriptions. It would be great to run usability tests, though, to see how users interpret the various options. 🤗

@hacdias
Copy link
Member

hacdias commented Aug 14, 2019

@lidel kinda related: ipfs/ipfs-desktop#1034

@lidel
Copy link
Member Author

lidel commented Dec 6, 2019

@cwaring noted in #826 (comment):

but do you think it's widely understood what a Custom Gateway is? I would be inclined to be more specific, such as: Always load DNSLink websites via IPFS Companion's local gateway. (if that is a correct statement?)

In theory "custom gateway" could not be in local network, but I think "local gateway" is a better name as it reflects what most of users do (install ipfs-desktop, have local node).

@lidel lidel changed the title Changing language around Redirects Changing language around Redirects and Gateways Dec 6, 2019
lidel added a commit that referenced this issue Dec 6, 2019
This removes "Redirect on {fqdn}" menu item from browser action menu.
DNSLink redirect is no longer enabled by default, and this feature does
not need to be present at all times (It remains on Preferences screen if
needed).

In the future we will change it to "Disaple IPFS integrations on these
hostnames"

Part of #741
@jessicaschilling jessicaschilling removed topic/design-ux UX strategy, research, not solely visual design UX labels Mar 30, 2020
@jessicaschilling jessicaschilling added exp/intermediate Prior experience is likely helpful effort/days Estimated to take multiple days, but less than a week kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked labels Apr 7, 2020
@jessicaschilling
Copy link
Contributor

Update: Going to start noodling on some (but not all) of the remaining items in this discussion in a PR for miscellaneous UX improvements. Watch this space.

@jessicaschilling
Copy link
Contributor

I think we can close this issue based on the aggregate of improvements introduced in #907 -- if anything crops up, let's open new issues for the sake of granularity. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
effort/days Estimated to take multiple days, but less than a week exp/intermediate Prior experience is likely helpful kind/maintenance Work required to avoid breaking changes or harm to project's status quo need/analysis Needs further analysis before proceeding P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked topic/design-content Content design, writing, information architecture
Projects
None yet
Development

No branches or pull requests

4 participants