Ipfs-companion: Changing language around Redirects and Gateways

[lidel]

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:

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

• content paths (resources loaded from /ipfs/{cid}/ on any website)
• DNSLink websites (which we should stop redirecting until Origin issues are solved: https://github.com/ipfs-shipyard/ipfs-companion/issues/701)
• subdomain gateways (same situation as DNSLink)

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)
  
  
• [x] Replace or move Per-website redirect toggle (Enables user to disable redirect on a specific website)
  
  
  
  • _Update:_ ✔️ Moved to Preferences in https://github.com/ipfs-shipyard/ipfs-companion/pull/826/commits/c7c32216a98e80cace6b7aae5498658d14b0edb7
  
  
  • 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.
    
    
    
    
    
    • Ideas: _"Disable Companion on example.com", "Disable all integrations on example.com" "Ignore this site"_
    
    
    
    • Alternative idea: remove this from browser menu, but keep a list of hostnames on _Preferences_. Rationale: the need for disabling companion on a specific website should be super rare, and when we ship (#701) there won't be any need for having it in browser action menu. When DNSLink website is detected we would add something where you can "make this site available offline and re-host it" as an opt-in rather than doing an eager redirect (https://github.com/ipfs-shipyard/ipfs-companion/issues/710#issue-431551526).
    
    
    
  
  

Would love to hear some thoughts on this.

[ericronne]

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]

@lidel kinda related: https://github.com/ipfs-shipyard/ipfs-desktop/issues/1034

[lidel]

@cwaring noted in https://github.com/ipfs-shipyard/ipfs-companion/pull/826#discussion_r354783663:

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

[jessicaschilling]

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]

I think we can close this issue based on the aggregate of improvements introduced in https://github.com/ipfs-shipyard/ipfs-companion/pull/907 -- if anything crops up, let's open new issues for the sake of granularity. Thanks!