UX Suggestions

[jnthnvctr]

(Copied per @lidel 's suggestion from: ipfs/ipfs-gui#28 (comment))

(Apologies in advance if there's been a discussion about some or all of these points already/if this is the wrong place to post these thoughts. I've been loosely tracking things with IPFS, but this was me capturing my experience going in blind just testing stuff out)

Through my work I get to work with users across the technical spectrum (from those who get confused about the difference between a browser and chrome) to full on devs who are way more technical than I am. My concern is that for engineers (who understand IPFS) the current UI may be useful, but for non technical users theres a lot of jargon that would intimidate them from using IPFS.

Current UX notes:

Home page:

• Swapping the "Home Page" with the "Files Page" in the WebUI to get users closer to their content
  Details: When I open up the WebUI, I see my Node Info and my Node Addresses. I would assume for most users this is actually meaningless, or at the very least less likely the reason they opened the WebUI. I think for most users, the primary interaction they're expecting from the UI is to upload or download files. We could make it easier for users to interact with the page, if we make the Home page the files page, and rename what is currently the home page to "Information" or something.

Files page:

• Loading or status bar between an uploading action and the completion view (minor polish)
  Details: I had my Dad play around with IPFS, and immediately he tried uploading a file in between the initial upload the "upload successful message" there was a brief pause, where he was confused as to whether the file was actually uploaded.

• Automatically triggering a refresh after an upload (so the file appears in the bottom portion of the screen)
  Details: Right after the upload was successful, there was no clear indication where the file went. It was only on triggering a refresh that the file appeared.

• Allowing for an optional naming of the hash during an upload so a user can identify which hash links to which content.
  Details: Having tried uploading a few files sequentially, it became hard to track which hash was related to which file. I found the only way to identify which was which was to click on RAW to see what the hash was. Ideally if on upload you could name the hash too. Even if these are just for local reference, it would be insanely given the ordering of uploads and the ordering on the page are not consistent (its not clear how the hashes are sorted to me).

• Clicking on "Remove" for content linked me back to the home page, without removing the item from my Files page.

• Renaming "Action" terminology to something more accessible to users.
  Details: Specifically, I don't think "RAW" or "DAG" are inherently meaningful for non-technical users. Internally I've found my self equating RAW to something like "Open" or "Preview", and I don't know if have a strong association for DAG in the context of this page.

• Something that might also make this easier for users is adding a "Share" link, which autogenerates the structure of the ipfs/hash for them to dump into the WebUI (or browser once theres broader support)

DAG Page:

• Given the primary purpose of this page is to explore content, maybe rename this to something more meaningful for non-technical users - something like "Search" or "Explore"?

• This feels a little odd to have a search page, when the top bar is also a search. If the primary purpose is to have an entry point for exploring content, maybe add this to the files page as an exploration option? Given the search bar is persistent at the top, I don't know if a separate page is necessary.

• I tried with a few file types, and I notice that many times the preview ends up being a bunch of non-sensical characters, and to get the actual view I need to click on RAW or Download. I'd also note that the download didn't trigger when I clicked on the second link.
  

• A more macro question: is there limitations with support for different file types? I tried uploading an MP4 and when I went to click "RAW" or "Download" I got a weird hash file.

Config Page:

• I probably am missing how to use this as an IPFS newbie, but this seems like a good home for some of the stuff that's currently on the Home page. Useful and easy to find for users who know they need that info, hidden away from users who have no idea what it is.

General notes:
Apologies if this is just me fundamentally misunderstanding stuff, but one thing I wasn't confident of was whether when I uploaded stuff it was actually being uploaded to IPFS or if it was just locally mounted (the equivalent of things existing on a local branch in git). In the WebUI it says I'm uploading files to a "Local Folder", but when the content is uploaded, anyone can access it right (ie anyone could see /ipfs/QmZbjw3n2WRhaE2Aueqo4kYh7SjNYWiEoXpZ6MZKfsaSUe ) if they wanted to? If there is a way of formally publishing from your local folder to the rest of IPFS I don't think the UI makes it inherently obvious that you've done so. If by default everything is being shared, I think the UI needs to make this a little more explicit (especially before someone does something silly and uploads something inherently personal)!

[lidel]

@jnthnvctr this is very good feedback, thank you! 👍

FYSA WebUI work is parked as we are working on UI style guide and shared components for IPFS apps.
When that work is done we will refresh/rewrite WebUI, and your thoughts will be included in the process 👌

Feel free to post additional thoughts and ideas here, if anything new comes up in the future.

[jnthnvctr]

Definitely! Not super proficient in React, but happy to try and pick up some of the stuff in my free time

[makew0rld]

As I said on IRC:

whyrusleeping: the webui I want is one that is focused on adding content to your node, making it easy for people to have a server of some sort. Similar to the desktop orion client for ipfs. Rn the webui greets the user with setttings, and the upload interface isn't very informative, and doesn't display what's already there.

[hacdias]

Hey @makeworld-the-better-one 😄 I think you'll find on the revamp branch a brand new file browser where you can add content very easily to your node!

[olizilla]

@jnthnvctr We've just gone through a round of redesign work on the IPFS Web UI. It'd be great to get your feedback on it if you have time. From your original feedback. It's not deployed with go-ipfs yet, but you can see a preview at https://webui.ipfs.io

Swapping the "Home Page" with the "Files Page"

This is good idea. We don't have this yet. The home page is still the status page, but I'm going to create an issue to make this change. Any empty files page is an opportunity to add an introduction / walk through, and I imagine, as you say, the first thing a new user is going to want to do here is add / share / get files from the network, so we should avoid showing them a bunch of stats and graphs at that point.

Files page:

The files page has been completely rebuilt, with upload progress feedback and showing files you just uploaded. A share action has been added and in a future release will be accompanied with a web app that's focused just on that https://share.ipfs.io

DAG Page:

The DAG page has been rebuilt and renamed "explore", and starts with some example datasets to give a clue as to what can be done with it.

Apologies if this is just me fundamentally misunderstanding stuff, but one thing I wasn't confident of was whether when I uploaded stuff it was actually being uploaded to IPFS or if it was just locally mounted

This is something we have to do a much better job of explaining and demonstrating. "Uploading" is misleading here as when you "add to IPFS" you are adding it to your local IPFS repo. Doing so means it's possible that others may fetch those files and blocks from you at some point, but until then they only exist on your machine. They are not automatically backed up to some other nodes. It does make it easy to share files with others and be sure that you got exactly the same file back if you ask them for it later. It opens up the possibilty of communally co-hosting files and websites that are important to you, but right now you have to understand enough about IPFS to encourage some friends to do the same. https://awesome.ipfs.io/categories/datasets/ has some examples of datasets that are now hosted by many IPFS users.

Also of note, added files are not private, as other nodes could request them, but they can only be retrieved if the other user knows the content address for them. They can only get that if you share it with them, or they already have the files, as the content address is uniquely generated from the raw data in the files. You can think of like "unlisted" on services like youtube, where only people you share the link with can get the data. The current recommendation for sensitive data is to encrypt it before adding it to IPFS.

[jessicaschilling]

Closing due to the fact that there have been some pretty substantial changes made in the interim, and this might be best approached with fresh eyes. Please feel free to re-open if needed. Thank you!