Too much focus on the file list headings
Closed this issue · 5 comments
This was discussed during the process of developing the heading toggles but must have fallen off. :)
It would be nice if the file list heading goes to the previous style of:
- Being color-text-maxcontrast
- Not being bold
Otherwise the heading overshadows the actual files and folders:
cc @marcoambrosini @szaimen – and also @susnux @ShGKme since you were in the discussions of the headings when we did that in person.
This is not part of the vue components but of the files app
We could make it easier to have all of our a11y and design decisions implemented for table headers and provide a NcTableHeader
component that already implements this.
I think they're really nice and help speed up understanding what's what.
If they were maxcontrast
and non-bold, they would be indistinguishable from the actual data of the file element. Making things more disorienting to the user.
Especially taking into account that we might have an “owner” and “share status” columns in the future. I think it makes sense to keep them as they are.
Note to people that are not familiar with the CSS variables: our var(--color-text-maxcontrast)
text is actually the light gray in the screenshot, so really it's mincontrast :)
Here are all the possibilities, whole viewport:
Bold headings and file names | Current 28 with bold table headings |
---|---|
Normal font weight but no maxcontrast | Going back to how it was before |
- Bold headings and file names: (Just as experiment) This is definitely too much. It’s like seeing one thing that shouldn’t be so present and making the next thing more present, creating overload.
- Current 28 with bold table headings: Well, the table headings are too present for what they are for. It is a pretty simple table, sorting is not going to be changed that often, filename being the most obvious thing – it is just unnecessary to bold it.
- Normal font weight but no maxcontrast: Already better but still the headings have the same importance as the file names which makes little sense
- Going back to how it was before: Well, this is how the proper information architecture should be, and why it was like that before. Headings are not that important.
As a sidenote, mostly as info @nextcloud-libraries/designers: It sometimes happens that there is a code or architecture change, and with it comes an unplanned design change. This happens either because it was an oversight or there wasn’t enough time (or both) – either is fine. When afterwards issues (basically design regressions) are noticed and brought up though, often it already being like that is used as an argument to just roll with it.
I have to say I don’t feel comfortable with this as it feels like design changes are being introduced without thinking about it and then reasoning about them afterwards. We should keep code and design changes separate discussions – especially when it has been discussed and reasoned about before, otherwise it’s very exhausting. Hope that’s understandable. :)