Make file-adding experience consistent across our tools

[olizilla]

All three apps provide drag'n'drop and and a file picker dialog to add a file, but there are problems with each one. What is the ideal UI/UX for adding files to your IPFS repo.

This is closely related to the next step Share Files via IPFS discussed in #34

The current state of things is described here: https://github.com/ipfs-shipyard/pm-ipfs-gui/blob/master/research/README.md#add-files

[olizilla]

The fundamentals... regardless of app, file-drop and open a native file picker dialog should be supported. The user should be able to add any file type or directory from the same action.

Once the file is selected we need to show a progress bar to indicate that it we're working on it. The progress bar should be deterministic, showing what percentage of the file has been processed. The progress bar could be skipped if it will take less than 1s to add.

Once completed, the filename and CID should be shown (see #9), along with a buttons to share the file (See: #34).

[hacdias]

And those files should be added to MFS, right?

[akrych]

It should also be one button for adding new files or folders.

[hacdias]

@akrych unfortunately that's something I just can't do due to Operating System restrictions.

Note: On Windows and Linux an open dialog can not be both a file selector and a directory selector, so if you set properties to ['openFile', 'openDirectory'] on these platforms, a directory selector will be shown.

Source: https://github.com/electron/electron/blob/master/docs/api/dialog.md

[hacdias]

Although, we could have one button that after clicking on it we could choose if we wanted to pick a file or a folder.

[lidel]

I believe we have three ways of adding content to ipfs.files (which implicitly pins it) right now:

• add a file
• add a directory (could be entire tree)
• add by NURI IPFS Path
  • this effectively replaces current pinning UI (based on ipfs.pin) with much simpler abstraction of MFS (ipfs.files) – I elaborated on value added by this approach in [META] Solidify mental model/language for MFS add vs IPFS pin #10 (comment)
  • would be fantastic if pinning progress bar looked the same as for other options

[akrych]

@hacdias AAa ok :D Did't know that. Ok so we will do one button and after click choose if we wanted to pick a file or a folder.

@lidel After consideration I like the simplicity of solution with add NURI as pinning - I just afraid about non-technical user - how we say them what "NURI" is. Still thinking about it

[olizilla]

Of note: NURI is dead. Long live Path

NURI (Nested URI) is just a path. This is a deprecated term, but you'll see it around.

https://gateway.ipfs.io/ipns/ipfs-docs-research.robbrackett.com/html/Interviews/2018-02-02-Lars.html

[akrych]

@olizilla So you suggest to call it "Add path" ? In my opinion still not so clear for non-technical user.
In word "pin" we had some more explenation already. Just thinking thinking out loud :)

[olizilla]

@akrych keep those out loud thoughts coming. I agree that Path just on it's own might not be enough. We should call it Path, or IPFS Path, to keep the terminology consistent with core, but we could use placeholder text or tooltips to show an example /ipfs/QmHash.

More generally, there are going to be a few concepts that will just have to be explained to every new user, so we should plan for an integrated help system from the start, along with a glossary of terms. @Mr0grog's research calls for a concepts dictionary too: ipfs-inactive/docs#56

[akrych]

Ok;D So another issue. We will have this button call "Add by IPFS Path" (or sth like that - to agreed) and when I do this, the file will be downloaded from IPFS nodes.

(According to my conversation with @lidel) The first:

1. We need to make some progress bar, icon or other info that: "resource is not ready yet -- being fetched from IPFS". It will take some time, so due to this the file should visible as none active.

2. In general added file by "Add by IPFS Path" it will look the same as other files added by "Add a file", so to improve the searching of we need to highlight it somehow. Ideas:

• Special folder: default folder “Added by Path” where all will be uploaded. But it seems that the default intention of the user is that the file upload to the current directory and if we change this behavior, we need to give the target directory, unless we give info that the file upload in "/ Recently added".

• Filters. Finally we will have to provide user filtering to help him searching for files, so beside “Recently added”, we will have also “Added by Path”. It seems to me, be a simpler way.

BTW. if only we have the technical possibility to distinguish one from the other…(?)

[olizilla]

I think we can fetch IPLD info about the data before fetching the whole file. I think we can make all this smarter by just fetching the metadata first, so that we can then offer the user more info like how big the file might be, and a chance to change their mind, along with a finite progress bar, that knows how many bytes to expect, and if it is a directory or a file or raw data.

[olizilla]

we have to deal with the fact that we might not be able to find the Path that the user gives us if there are no copies currently being offered up.

[olizilla]

What is someone trying to do when they add files to an IPFS gui? Right now, I'm probably about to share a public gateway link to those files with someone.

Adding things to an IPFS gui today leaves with a duplicate of the file, in a repo that I can't easily see in my filesystem explorer, so it's like I'm adding a share-able copy of a file to a magic box. A bit like adding a file to your Public folder in OSX, and turning on local sharing, though I have no idea how successful that is as an idea. I once used that for LAN sharing but gave up.) As the repo structure is separate from the host file system, I can't easily incorporate IPFS into my personal filing system. I can't see a strong motive yet for people to add files to IPFS as part of their daily habits.

It's possible, that I'd add them to an IPFS GUI because I want to back them up, but there is no obvious way (to me) to tell a IPFS node to auto-pin anything that is announced from a specific Peer ID.

This is not a why add files to ipfs in general question. This is, in the context of a desktop / casual user, what is most likely to be my goal. What goals are possible and should we be optimising the flow for?

[lidel]

Right now I see two paths that lead to "adding to IPFS":

• user does not really care about data
  (just wants to add it to IPFS to immediately share it with a friend)
  • a replacement for sharing services that expire links after X hours
• user cares about data
  (keeps it available, shares references to it over longer periods of time)
  • personal semi-public data: websites, notes, photos
  • public data sets (added by IPFS Path)

I am not sure if we want to overthink it. More specific use cases will emerge with time after we provide users with basic UI for (i) adding (ii) managing (iii) sharing files.

[olizilla]

Agreed. I wanted to flag the idea that a user adding files to an IPFS app probably doesn't the same goal as a user adding a file to folder in the OS native file browser.

Also agree on not over thinking it. The 2 use-cases you identify are good ones to optimise for right now.