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

Better UX in GUI apps #34

Open
lidel opened this issue Jul 16, 2020 · 1 comment
Open

Better UX in GUI apps #34

lidel opened this issue Jul 16, 2020 · 1 comment
Labels
dif/expert Extensive knowledge (implications, ramifications) required effort/weeks Estimated to take multiple weeks help wanted Seeking public contribution on this issue kind/architecture Core architecture of project kind/discussion Topical discussion; usually not changes to codebase kind/enhancement A net-new feature or improvement to an existing feature need/analysis Needs further analysis before proceeding need/community-input Needs input from the wider community need/maintainers-input Needs input from the current maintainer(s) P3 Low: Not priority right now status/deferred Conscious decision to pause or backlog

Comments

@lidel
Copy link
Member

lidel commented Jul 16, 2020

Continued from #6, see also #7

Now that #14 is merged, and we got the basic minimum (support for Authorization: Bearer <key>) we could discuss ways to improve UX of adding services, namely avoid manual copying of authorization token from pinning service to GUI app interface.

To illustrate UX needs, adding pinning service to WebUI in IPFS Desktop app could look like this:

  1. User goes to Settings screen and clicks on "Add Pinning Service"
  2. List of predefined services is shown
    (there is also "Custom" option for manual config)
  3. User clicks on one of predefined providers
  4. WebUI opens authorization page at Pinning Service (PS) using well known API endpoint
    (passing any data that is required)
  5. PS provides interface for "granting pinning permissions to the app X"
    (page could also enable user to create a new pin space, or attach WebUI to existing one)
  6. Upon user approval via PS interface, WebUI is able to use configured pinning service
    (without copying anything manually)

Qs:

  • Any prior art comes to mind? We'd rather not reinvent wheel, if possible
  • Do we need to return anything back to WebUI in step 6,
    if we generate sufficiently random token on the client and pass it in step 4?
    (randomness could be augmented by drand)
@lidel lidel added P3 Low: Not priority right now dif/expert Extensive knowledge (implications, ramifications) required effort/weeks Estimated to take multiple weeks help wanted Seeking public contribution on this issue kind/architecture Core architecture of project kind/discussion Topical discussion; usually not changes to codebase kind/enhancement A net-new feature or improvement to an existing feature need/analysis Needs further analysis before proceeding need/community-input Needs input from the wider community need/maintainers-input Needs input from the current maintainer(s) status/ready Ready to be worked labels Jul 16, 2020
@jessicaschilling
Copy link
Contributor

This is pretty standard flow. One thing to note: if we go down this route, it would be good to provide guidance (not requirements, just guidance) for how pinning services may wish to present their own auth page for consistency.

My only concern here is that it would create a higher barrier to entry to creating a pinning service that integrates with Desktop/Web UI -- the creator of the service actually has to build this auth flow on their end. If I was running a micro-pinning service for small-scale needs, I might not want to bother with this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dif/expert Extensive knowledge (implications, ramifications) required effort/weeks Estimated to take multiple weeks help wanted Seeking public contribution on this issue kind/architecture Core architecture of project kind/discussion Topical discussion; usually not changes to codebase kind/enhancement A net-new feature or improvement to an existing feature need/analysis Needs further analysis before proceeding need/community-input Needs input from the wider community need/maintainers-input Needs input from the current maintainer(s) P3 Low: Not priority right now status/deferred Conscious decision to pause or backlog
Projects
None yet
Development

No branches or pull requests

2 participants