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.

Sign up for GitHub

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

Jump to bottom

IPFS-aware error page: improve UX when gateway is offline #806

Open
lidel opened this issue Oct 30, 2019 · 3 comments · May be fixed by #920
Open

IPFS-aware error page: improve UX when gateway is offline #806

lidel opened this issue Oct 30, 2019 · 3 comments · May be fixed by #920
Labels
effort/days Estimated to take multiple days, but less than a week effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature 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 topic/design-front-end Front-end implementation of UX/UI work topic/design-ux UX strategy, research, not solely visual design
Milestone
v2.21

Comments

@lidel
Copy link
Member

lidel commented Oct 30, 2019 •
edited
Loading

Recovery from dead public gateways was introduced in #640.

What about scenarios when local gateway goes offline?

Current UX: error page provided by the browser

Right now, opening http://docs.ipfs.io.ipns.localhost:8080 when node is offline ends up with a generic error:

2019-10-30-114745_905x465_scrot

I believe we could improve UX of errors like this.

Improvement: custom error page aware of IPFS options

We should introduce a custom error page tho, to improve UX AND to give user a final say if they choose to start local node and retry, load from original server (if DNSLink), or a public gateway instead.

Custom error page could be used in all recovery contexts (when local node is offline, but also when remote server is down, but has DNSLink).
@lidel lidel added the kind/discussion Topical discussion; usually not changes to codebase label Oct 30, 2019
@lidel lidel changed the title Should Companion recover from missing local gateway? Improve UX when local gateway is offline Jun 13, 2020
@lidel lidel added exp/wizard Extensive knowledge (implications, ramifications) required effort/days Estimated to take multiple days, but less than a week kind/enhancement A net-new feature or improvement to an existing feature need/analysis Needs further analysis before proceeding P2 Medium: Good to have, but can wait until someone steps up topic/design-content Content design, writing, information architecture topic/design-front-end Front-end implementation of UX/UI work topic/design-ux UX strategy, research, not solely visual design and removed kind/discussion Topical discussion; usually not changes to codebase labels Jun 13, 2020
@lidel lidel changed the title Improve UX when local gateway is offline IPFS-aware error page: improve UX when gateway is offline Jun 13, 2020
@lidel lidel mentioned this issue Jun 13, 2020
Closed
@jessicaschilling
Copy link
Contributor

@lidel I can certainly stub out a custom error page, but how tough would implementation of this be? I don't want to expose a rabbit hole.

@lidel
Copy link
Member Author

lidel commented Aug 31, 2020

@jessicaschilling in this case it should be relatively easy to wire it up 🤞 , in broad strokes:

we would add code in ipfs-request.js / onErrorOccured handler to check if failed request was for custom gateway defined in Preferences or a DNSLink website, and if so, open a static page, passing the failed URL after #, so the error page would read original URL via window.location.hash

If you stub the page and open a PR with it, I can block some time to wire it up.

@jessicaschilling jessicaschilling added exp/intermediate Prior experience is likely helpful effort/hours Estimated to take one or several hours good first issue Good issue for new contributors help wanted Seeking public contribution on this issue P1 High: Likely tackled by core team if no one steps up status/ready Ready to be worked and removed P2 Medium: Good to have, but can wait until someone steps up exp/wizard Extensive knowledge (implications, ramifications) required need/analysis Needs further analysis before proceeding labels Sep 1, 2020
@jessicaschilling jessicaschilling linked a pull request Sep 10, 2020 that will close this issue
Draft
3 tasks
@jessicaschilling jessicaschilling added this to the v2.15 milestone Sep 10, 2020
@jessicaschilling
Copy link
Contributor

#920 will close this once merged.

@lidel lidel modified the milestones: v2.15, v2.16 Oct 19, 2020
@lidel lidel modified the milestones: v2.16, v2.17 Nov 18, 2020
@lidel lidel modified the milestones: v2.17, v2.18 Jan 11, 2021
@lidel lidel modified the milestones: v2.18, v2.21 Nov 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
effort/days Estimated to take multiple days, but less than a week effort/hours Estimated to take one or several hours exp/intermediate Prior experience is likely helpful good first issue Good issue for new contributors help wanted Seeking public contribution on this issue kind/enhancement A net-new feature or improvement to an existing feature 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 topic/design-front-end Front-end implementation of UX/UI work topic/design-ux UX strategy, research, not solely visual design
Projects
No open projects
IPFS-GUI (PL EngRes)
Status: Needs Grooming
Milestone
v2.21
Development

Successfully merging a pull request may close this issue.

[WIP] feat: offline error page ipfs/ipfs-companion
2 participants
@lidel @jessicaschilling