Files page: buttons and inconsistencies

[hacdias]

From #1114

@ericronne
Yep. Actually any interactive element should look clickable by default, otherwise users may not ever know to hover over it. Here are two ways we could telegraph clickability in regards to this feature set …

ps wearing my "user hat," i'm still not sure what to make of the house icon. My brain expects that to be a number, in keeping with the pattern set by the blocks and pins counts. The word "files" may be part of the problem, as it suggests "X files" 👽 (number of files) to me.

Would changing the label to "home" make sense?

@lidel
No, "home" feels out of place. Now that I think about it, do we need the "files" as a navigation item in the section on the right at all?

Clickable "files" is already present as the root of breadcrumbs on the left:

My intuition is to remove it or replace clickable icon with non-clickable count.
It could be total size of files in MFS (CumulativeSize from ipfs files stat /

Thoughts?

[hacdias]

@lidel then, if you went to pins section, how'd you reach 'Files'? You could certainly click on the navigation bar on the left, but...

[ericronne]

Ah, yes, i thought i was forgetting some conversations.

I think @lidel's intuition sounds good: perhaps we make the blocks pins files box merely a non-clickable counter. To @fsdiogo's point from a while back, it's an odd mix of clickable / non-clickable items.

Ignore the following if it represents an utter lack of proper grokking of things! …
Might a pull-down selector be a good solution for the breadcrumb region of the interface? Maybe we even include a blocks option summarizing anything we know of their blocks (if anything beyond the count), for completeness. (And so as to avoid a pull-down with only two options.)

[hacdias]

Calling scope to the dropdown and path to everything that follows it, I don't believe it is a good idea. On my mind, changing the scope would keep the path.

I don't know if what I just said is understandable. Let me know.

Also, there are situations (when the user writes a /ipns, /ipfs path in the browse box), where we do not have any badge on the left.

[lidel]

Might a pull-down selector be a good solution for the breadcrumb region of the interface?

yes, but not for pins: they do not share file paths with MFS, only low level CIDs are used.

pull-down would be a good UI for switching between "files" and "blocks" views of the same path, but as @hacdias noted (if I got it right) the file path breadcrumbs on the right would have to be dropped when switching to "pins". This would produce inconsistent user experience (path getting lost when switching between views).

---

We can revisit pull-down when adding "blocks" view/stats, but for the problem at hand I would start with a small change and replace home icon with size of MFS, and group+indicate clickable items for easy switching between "files" and "pins" (as suggested by @ericronne in past):

MFS size is not the whole picture, so I also added global "repo" disk use (files + pins + cached dags, could be also named "cached") as a read-only stat next to block count.

Size values in bytes can be read via:

$ ipfs files stat / | grep CumulativeSize # value for "files"
$ ipfs repo stat | grep RepoSize # value for "repo"

Would that be intuitive enough?

[hacdias]

We've fixed the inconsistencies on the "stats"/buttons bar! Closing this