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

Tracking issue: Followup UX improvements or IPFS #13125

Closed
jessicaschilling opened this issue Dec 9, 2020 · 8 comments
Closed

Tracking issue: Followup UX improvements or IPFS #13125

jessicaschilling opened this issue Dec 9, 2020 · 8 comments
Labels
closed/duplicate Issue has already been reported OS/Desktop priority/P3 The next thing for us to work on. It'll ride the trains.

Comments

@jessicaschilling
Copy link

jessicaschilling commented Dec 9, 2020

Edit from @bbondy: I'll be crossing some of the below out as I post things to different issues
Spin off issue list:

Greetings 👋 from the IPFS GUI Group, specifically @jessicaschilling and @lidel!

Below is a proposed list of improvements to the Brave Nightly implementation of IPFS as it works its way toward ordinary Brave release. These may be most useful if broken up into separate issues as needed - though for the sake of a complete view, including them all here as an initial step. Many thanks!

Onboarding/use prompt at the top

This is shown both when user tries to load IPFS resource for the first time (ipfs:// or public gateway), AND whenever Brave encounters an IPFS resource if "Ask" is enabled in prefs

  • To better fit both cases in which this prompt appears, suggest changing question to IPFS resources detected. Enable Brave to load them using a local IPFS node?
  • Suggest changing "Learn more about privacy consequences" link to Learn more about IPFS and privacy pointing at https://support.brave.com/hc/en-us/sections/360010974932-InterPlanetary-File-System-IPFS-.
    • This enables us to add more general "What is IPFS?" content at a later date, while still underscoring the privacy implications.
    • Question: What's the procedure for PR-ing some more general "What is IPFS?" content on this page?
  • No visual feedback after clicking "Enable IPFS":
    • Behind the scenes go-ipfs is downloaded (which may take time on slow network) and user will think "IPFS support is broken, because nothing happened"
    • Fix: open brave://ipfs (in a new active tab) and display "installation" state (downloading, unpacking, starting). More details on this below.

brave://ipfs diagnostic screen

2020-12-05--19-28-17

  • Is there any way this can be included in the rest of Brave's Settings UI? Having it here as an orphan means it's got zero brand continuity, it's easily lost, and just feels kind of sketchy

    • If yes, happy to help wireframe something once we know the possiblities for where it could be included
    • If no, we'll want to wireframe something better here, with a clearer information hierarchy and better conveyance of value (We'll want these in settings)
    • Either way, some additional important notes outlined below ...
  • Use Start and Stop throughout rather than "Launch" and "Shutdown", to be consistent with other IPFS tools

  • "Daemon" is probably an unnecessary term of art throughout the Brave UI

    • Seems like we really mean "IPFS node" - suggest replacing throughout, so in this setting, IPFS node status as a header
  • Launch and Shutdown are always visible

    • Fix: Display only the relevant button (either Start or Stop)
    • Add Restart button (speeds up applying config changes)
  • If installation state (see above) is to be conveyed here, need to add an affordance for this:

    • If not installed, note "IPFS not installed" and button to install and start; other items should be grayed out to indicate missing functionality
      • Additionally, display the Learn more about IPFS and privacy link described above (placement/appearance TBD once we know whether this diagnostic page can be included with the rest of Brave settings UI)
    • If mid-install, progress bar for downloading, unpacking, starting (or whatever similar design pattern already exists in Brave UI); other items should be grayed out to indicate missing functionality
    • If installed, note "IPFS installed"
    • Visual implementation of this TBD based on whether this diagnostic page can be included with the rest of Brave settings UI
  • Diagnostic page displays API address, but there is no way to open Web UI

    • Fix: when node is running, add a button that opens its Web UI (http://127.0.0.1:{api-port}/webui)
      • Display at same level of prominence as Launch/Shut Down button
      • Q: Text should be My Node to match IPFS Companion
      • Q: Button should be a different color to convey different function than Launch/Shut Down button — will be able to have better guidance on this once we know whether this diagnostic page can be included with the rest of Brave settings UI
  • Connected peers: Add (details) link after peer count, linking to Peers screen in IPFS Web UI (http://127.0.0.1:{api-port}/webui/#/peers)

  • "Addresses Config" sounds like the user can actually change this config, which isn't true

    • Fix: Replace with just Addresses
  • If the user has this diagnostic page open in one tab with their node stopped, and then starts their node from a different tab, this tab doesn't update unless it's reloaded. Can this be fixed?

  • When diagnostic page is opened on an empty profile (i.e. user has not yet been asked to enable IPFS support), there is no UI to start the node:

    2020-12-05--19-24-19

    • Fix (this behavior is already specified earlier in this document): If not installed, note “IPFS not installed” and button to install and start; other items should be grayed out but present to indicate missing functionality
    • Additionally, display the Learn more about IPFS and privacy link described above (placement/appearance TBD once we know whether this diagnostic page can be included with the rest of Brave settings UI)

Settings screen

  • Under Method to resolve IPFS locations, IF the user has not yet done so, need to add an option here to install and start IPFS. Visual design on this will depend whether diagnostic screen content can display in settings instead (see above).

  • Method to resolve IPFS locations should read Method to resolve IPFS resources, since IPFS isn't location-addressed

  • Subtitle for IPFS public gateway fallback should read Automatically fall back to public IPFS gateway if your local node cannot be reached. (note: two words for "fall back" intentional, since it's a verb)

  • Subtitle for IPFS Companion should read Use the IPFS Companion extension for enhanced IPFS support in Brave, including access to common IPFS tasks from your browser bar.

  • After user is asked and chooses to "Enable IPFS", then the droplist includes a new item named "Customised" - what is this?

Other notes

  • If the user types an IPFS resource into their browser bar (like ipfs://bafy...), is given the install prompt, and selects Enable IPFS, there's likely to be a gap before IPFS is installed and/or started. In the meantime, the user sees a "This site
    can't be reached ... ERR_CONNECTION-REFUSED" page.
    (We'll instead use the tab's loading indicator)

    • Can this be intercepted somehow so it doesn't look like a true error state - particularly if it takes a while to install IPFS?
    • If not, can we at least open diagnostic screen in a new tab and switch to it, so user can see the progress of go-ipfs installation + refresh every tab with IPFS resource when done?
  • Unless the user has public gateway fallback enabled, they will see this page from time to time:

    • Header should read Can't load IPFS resources using local node
    • Main text should read Failed to use the local IPFS node to load requested IPFS resources. Click the "Proceed" button to use the public gateway instead, and to fall back automatically to the public gateway in the future
    • Advanced text should read Brave cannot load the requested IPFS resources either because the local node did not start, or because there are no connected peers available at the moment. If you choose "Proceed", Brave will automatically fall back to the default public gateway whenever using the local node fails. You can change this behavior at any point in Brave settings.
    • OR: possible to add a second button for Use public gateway this time vs Use public gateway whenever local node can't be reached? This would be better UX overall, though text specified above would need amending to account for this.
  • At present, after the user enables IPFS support, there is no way to tell in the day-to-day when the user is actually using their node (unless the URI is ipfs://). Is it possible to visually indicate this in the URI bar in a way that doesn't require us to fundamentally solve this for all browsers for the rest of time? Are there any similar affordances existing in Brave (or browserland at large) that we can adapt/adopt -- maybe something similar to the practice of annotating when the user is on an internal (prefs etc) page?

    • Clicking on IPFS icon here could open brave://ipfs diagnostic page (or a better UI in the future)
@lidel
Copy link

lidel commented Dec 9, 2020

cc @bbondy @yrliou @autonome 🙇‍♂️

@bbondy bbondy changed the title Native IPFS in Brave: UX improvements Tracking issue: Native IPFS in Brave: UX improvements Dec 11, 2020
@bbondy bbondy changed the title Tracking issue: Native IPFS in Brave: UX improvements Tracking issue: UX improvements or IPFS Dec 11, 2020
@bbondy bbondy changed the title Tracking issue: UX improvements or IPFS Tracking issue: Followup UX improvements or IPFS Dec 11, 2020
@bbondy
Copy link
Member

bbondy commented Dec 11, 2020

That's just because when the page loaded the drop down only had 3 values. When you install a local node it has a Local option. If you refresh the settings page you'll see Local.

Screen Shot 2020-12-11 at 3 49 17 PM

@bbondy
Copy link
Member

bbondy commented Dec 11, 2020

By the way the internal page is not meant to be exposed to users. It's only or troubleshooting from developers or in cases that we want support. Usually for these pages, a developer has free rein to put whatever they want to help them make the feature successful. But a typical user would not run into them. We should expose things as you mentioned in the settings, probably in a new settings sub-page as things grow.

@bbondy
Copy link
Member

bbondy commented Dec 11, 2020

Thanks or the feedback @jessicaschilling. I split this into 5 issues as edited into your original message above.
I'm going to close this in favor of the other 5 and track them on our project board here:
https://github.com/brave/brave-browser/projects/32

@bbondy bbondy closed this as completed Dec 11, 2020
@jessicaschilling
Copy link
Author

Thank you SO much! Will follow those breakout issues - please let me know if I can clarify anything.

@jessicaschilling
Copy link
Author

@bbondy For the diagnostics page - understood that it's only really intended as "expert-level" content, but suspecting it'd still be useful to give the user access to it since it provides node start/stop, peer count, etc. Would it be consistent and not overkill to provide a link in Settings to the diagnostics page as "Manage IPFS node" in the same visual style as "Manage extensions" and a few others?

image

@bbondy
Copy link
Member

bbondy commented Dec 12, 2020

We could rename it to brave://ipfs-internals for now? I wouldn't put a link unless we presented it as a more user facing full featured page. At which point it might be better to just go into settings and have a page there.

@jessicaschilling
Copy link
Author

I don't think renaming the page will change much one way or the other UX-wise. Probably better to focus efforts on getting the items into Settings itself.

@bbondy bbondy added the closed/duplicate Issue has already been reported label Dec 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed/duplicate Issue has already been reported OS/Desktop priority/P3 The next thing for us to work on. It'll ride the trains.
Projects
None yet
Development

No branches or pull requests

4 participants
@lidel @bbondy @jessicaschilling and others