UX Issues with SAFE Storage and proposals for improvements

General
,
1

The following is a complete copy of the above issue, to facilitate discussion outside github. Significant points should be made there, but I’m posting here to highlight the issue and to make it easy to answer simple questions about it.

User testing of SAFE Drive is highlighting areas of difficulty with the UX for SAFE containers. These are particularly hard to solve within SAFE Drive because of the limited feedback possible when the user tries something that is not supported, but I think improving the experience for SAFE Drive will also make it easier, and a better UX in other apps. For example, all apps that show the user a file save dialog will face these issues.

I realise some of this might change if the underlying implementation changes, due to adoption of RDF for example, but considering these issues will help us avoid similar problems in any successor implementation of SAFE containers :smile:

Issue 1) I have been simulating creation of directories as temporary structures which become permanent when the user saves the first file to them (because once a file is saved, the directories exist in the key of the entry recording the existance of the file). This works fine until the user tries to create a directory in one of the default containers (eg in _public) rather than within an NFS container under _public (ie under _public/myname/www-root).

So a user cannot save a file in _public, or in a directory they have created in _public until an NFS container exists there, even though it is natural to expect that this is OK. In SAFE Drive, I can only reject this with ‘Operation not supported’ because only a fixed set of FUSE / POSIX error messages are available. This will likely be problematic UX for any SAFE file browser app, or any app with a file save dialog etc, even if it is able to provide a more helpful error message.

Proposal 1): The first issue could be much alleviated by making every subdirectory of _public map to an NFS container. I like this, even though it means they can’t be grouped by public name as now. So that’s one change to consider.

The above change also solves a second issue, which is another reason I like it! :smile:

Issue 2) is that a user expects to be able to create directories in a default container, and directories within directories etc. But in order to save files in those directories, at some point we need to create an NFS container and this isn’t something the user expects to need to do explicitly, and it isn’t obvious where in the path this should be, and if not done sensibly,y it could cause problems later.

For example, within SAFE Drive you can:

$ cd ~/SAFE/_public
~/SAFE/_public$ mkdir dir1
~/SAFE/_public$ mkdir dir1/dir2
~/SAFE/_public$ mkdir dir1/dir2/dir3

Nothing exists there on SAFE Network yet, but the user sees a directory has been created and the file system behaves as expected, so they can now:

~/SAFE/_public$ cd dir1
~/SAFE/_public/dir1$ cd dir2/dir3
~/SAFE/_public/dir1/dir2/dir3$

We can create an NFS container at any point, but if so where? Do we follow the convention of the first level not being able to hold files (as currently)? Do we allow further subdirectories that can’t hold files?

Any application that provides a UI to the SAFE file system will need to solve this, in a file save dialogue for example.

Proposal 1 (requiring every subdirectory of _public and the other default file containers, to map directly onto an NFS container) greatly simplifies this, and makes the results predictable.

Issue 3) Not being able to save files in the root of a default container is problematic for UX, because users will expect this to work, and rejecting this will be poor UX. Particularly for SAFE Drive which can’t explain why it failed, and where a file system really just needs to work or users will easily get into difficulties. For example, losing files they thought had been copied to SAFE storage, but failed with an error they didn’t notice or didn’t understand.

Proposal 2) I suggest we support saving files in the root of a default container, perhaps with a hidden NFS container, just for that purpose. I think proposal 1) and 2) could work well together.

Combining proposals 1) and 2) means that:

  • every default container will have a hidden NFS container that holds any files that appear in the root of the default container (eg. in _public)
  • every directory within the root of a default container will map to an NFS container

This doesn’t mean you can’t group files within _public by public name, but if you did, it would mean changing the way that web services map to containers, and would put all files for all services within a single NFS container which I don’t think is practical with the current 1000 file/entry limit.

3 Likes
2

Aren’t issues 2 and 3 covered simply by using the NFS emulation on top of the default container you are trying to store the files and directories?
…well, it should also solve issue 1?

1 Like
3

Maybe, if we think it’s OK to store files there - ie actually in the same MD. I hadn’t considered that!

The reason I’d ruled it out is that users might fill the container up too easily.

But I guess another way to cope with that is to decide on how we handle MDs getting full.

That needs to be standardised too. Have Maidsafe got plans there yet?

4

Just having a think about this with my UX Designer hat on (which is the only hat I have :joy:) and without considering the underlying tech. I should also put a big caveat on any/all of this which is that these are only gut reactions/theories which should be tested and evaluated with real people, but…

I think it would be wise to think of folders/directory structures as data, because I think users may expect it to behave in a similar way, or they may think of it in similar terms. So I’d be wary about making temp structures client side that only get baked in when a file is saved to them. Will the user understand this connection?

For example, I might spend a fair bit of time creating an empty folder structure as a first task in building a website, or maybe when I am organising a photo library to upload to. It would be odd to then open another machine/client to begin adding content only to find my directory structure missing.

And If I close a client without saving any data in there, does my folder structure get dumped altogether? This could be very troublesome.

I would agree with this. When we having things like querying, and rich apps which can filter/sort/display user data in a variety of ways, I’d expect a large proportion of users not to really care too much about directory structure, nor creating folders when uploading data. They are likely to just dump files in a root directory, and use an app on-top to sort/retrieve, only taking more care about folders/dirs when they are specifically looking to have structure surfaced, say when making a website.

5 Likes
5

Good catch and very important. Its not unusual to have one computer (or vm) setting up structures and dealing with such things, then have another computer which actually has the content to then do the copying while more setting up of structures continue on the first computer. Saves time. Now if a team working on things only makes it worse if two are setting up parent directories to store data in their particular branch of the directory structure.

2 Likes
6

I agree about folders being temporary Jim, the reason it is this way at the moment is that SAFE NFS doesn’t support empty folders, or folders at all really. Instead folders are ‘deduced’ from the key used to index the file, which is by convention a path (eg once you save a file with index key ‘folder/another/file.txt’ we can deduce that ‘folder’ is a folder, and ‘another’ is its subfolder, which contains the file ‘file.txt’.

We could use empty slots to implement folders, eg by storing a key ending in a slash, but so far this has not been specified for NFS containers AFAIK, nor whether to allow subcontainers of an NFS container.

I might be wrong about some of this, it may be buried or implied somewhere or other, but it is still hard to find some of the info on these areas.

So it would help to pull all these threads together, thus opening the discussion to end users as well as clarifying things for developers such as how we will handle full MDs.

My guess is that someone in Maidsafe has thought about this, but I don’t know if there’s a complete picture anywhere.

I think it will be valuable to keep these issues in mind as we evolve the implementation of support for RDF (which could invalidate much of the implementation, but not the need for good UX) so I created the issue to help ensure that, and to invite more views.

So please keep that UX hat on! It is one of the most important hats, and as developers, I think we find it hard to keep it on while thinking deeply about complex implementation and creating pragmatic or elegant [cough] solutions :wink:

So anyone reading this thinking, mmm not sure about that or, what about this, please jump in. :slight_smile:

3 Likes
7

I’m lazy. Very lazy. Like most users. I also have preconceived notions. If we are going to have a “SAFE Drive” then it needs to look and feel like any other attachable storage whether its a USB stick, an NFS or Samba share, Google Drive, whatever. I expect (given appropriate permissions) to be able to read, write, create and delete files and directories anywhere within that storage I just attached to my computer.
So if I mount a SAFE Drive, I want to be able to do all that. And if I can’t we need another name rather than SAFE Drive cos as I say, that comes with expectations.

This is not a solution, merely a plea to just make it work the way Joe User would expect it to. I see @happybeing 's work here as a crucial part of the whole SAFE eco-system and would urge the other devs to bend over backwards and find a way of implementing it as I think Mark originally intended,
Yes RDF and SOLID will change the way we all think about storing data, but for now, if we can make a SAFE Drive that works “normally” like any other attachable storage will be a Good Thing for app devs and users alike. System architects may have some more headaches but thats always going to be the case.

5 Likes