Files: Make Files a more useful tool for people who frequently work with files

[eljefuri]

_[NOTE: Where the Elementary application Files is concerned, I will capitalize the F. Where it concerns files, I will not. Also I am not sure where else to put this kind of topic so I will just make an issue. Apologies to @cassidyjames and @jeremypw for any perceived clogging!]_

The UX of Files seems to be designed for someone who doesn't work with files all that much, or at least someone who doesn't use them in any complex way. I can understand where this general idea may come from, noting and appreciating UX decisions throughout Elementary: It is clear that one overall notion in your set of guidelines aims to mask or remove the need for any user _conception_ of files over time. This, presumably, is why applications for the most part remember their state upon closing, and so on.

The reason I bring this point up is because I am not convinced that the presently imagined target user of Files _is actually a frequent/serious user of files at all_. In other words, there may be a contradiction of intention: if you are targeting someone who would be perfectly happy with being as unaware as possible of the very existence of files, why over-simply the tool? The idea of the target has directed design decisions such that, for those who need to manipulate or otherwise work with files on a regular basis, the tool is too shallow.

I can imagine some hand-wave future where there is no Files app included with Elementary by default, followed by the requisite yelling and hand-waving of the general Linux community. I can imagine that this would not actually be a show-stopper for a lot of people who might use Elementary, especially as they are often coming from mobile devices which have little user-level notion of files at all.

So if you follow me so far, I ask you: why not change the target of Files? Beef up the app a little bit, add more features, improve navigation in a myriad of ways for so-called "power" users. Think of programmers, photographers, and designers of all walks. You don't necessarily need an intimidating, dual-paned Total Commander type of interface, but deeply contemplating at least the UX compromises that macOS Finder made through the years to serve its historic creative users in particular, would probably be quite helpful.

I'm so wanting to both love this _and_ support free software!

[tintou]

Damn it! I just read the whole report and am afraid that there is no action to take with this report.
Please open one report per issue describing the feature request.

P.S: I'm working all the days with files on Files, we know some well-known issues.

[jeremypw]

@eljefuri : Thank you for taking the trouble to give us your views! Files definitely needs more work done on it so any developers willing to help would be welcome!

[eljefuri]

@tintou Sorry, I am well aware per this that this sort of issue isn't welcome here. That said though, what is the appropriate channel for long-form/slow/thoughtful discussion of such topics? Where can it have an audience? Repeating what I said in the Music repo: Slack is chat with many threads and does not offer the same speed or thoughtfulness as a forum. Reddit isn't specifically oriented around the development and planning body. Does Elementary have a Discourse instance somewhere?

@jeremypw This is not so much a question of development resources yet, but really one of priorities and design direction -- don't you agree? I wrote this here to state an opinion and to attempt to get feedback on that aspect. I'd like to know who Files is really for, and why. Once I understand that it will be a great deal easier to figure out if I can help in any other respect.

[jeremypw]

The app description in AppCenter is:

"Easily copy, move, and rename your files, or use folders to stay organised. Whether you like files in lists, grids or columns, you can always find them right away. Access all your files, whether locally, on an external device or remotely using FTP, SFTP, AFP, Webdav, or Windows share."

So the priority is to make sure these advertised functions all work as well as possible.

Launchpad described Files as a "simple, powerful and sexy file manager". I would take "simple" and "sexy" to mean that it is easy (intuitive) to use and looks good (fits with elementary design ethos). Not sure what powerful means here, but the priority is make all the core functions work well. The main new thing in the pipeline is accessing cloud storage.

[jeremypw]

Can you detail functions other than the ones already implemented a power user may need? Files struggles with very large numbers of files (at least, in icon view) for example, and the search function is rather basic.

[jeremypw]

I suspect you are right that elementaryos tries to be usable by an 'ordinary' user, like a mobile phone, without using a separate file manager (or terminal).

[eljefuri]

You gave two great examples that I would have pointed out, in addition to the various keyboard-centric UI tweaks that I was suggesting in their own separate issues earlier today: #688, #689, #690, #693, and #697. I also think that previews (#438) would be extremely useful. Probably the best way to suss out quite a bit more would be to do some user testing of Files with a professional photographer, programmer, and maybe something like a digital archivist. If the results would be seriously taken into consideration, I could definitely figure that out and execute on it.

As for your suspicion about the ultimate use case, do you extend your weary agreement to the point of saying that Files _might_ not be for those users?

[jeremypw]

I would probably query why those professions are so dependent on a file manager. There should be specific applications that meet most of their needs. It would indeed be interesting to hear from them where the gaps are, and then consider whether these should be provided by a photo app, IDE, archive/backup app etc. Only generic things not suitable for specific apps should be considered for a file manager, I would say.

[jeremypw]

One compromise might be to extend the plug in interface to allow a greater range of third-party plugins to be written e.g. a previewer.