getodk / central-frontend

Vue.js based frontend for ODK Central
https://docs.getodk.org/central-intro/
Apache License 2.0
32 stars 59 forks source link

Give time columns (e.g. in backups or logs) a fixed or maximum width #432

Closed lognaturel closed 3 years ago

lognaturel commented 3 years ago

Time columns have a known maximum width. Currently they are responsive just like other columns in the tables meaning they become unnecessarily wide even on not-so-wide screens. It would help with readability if it were fixed or had a maximum width.

Context from comment:

This came about because I was looking at other systems' logs and those felt a lot tighter to me. I think it's because they either have more columns (e.g. Zoho) or have a fixed-width table (e.g. WPEngine). All that had this tighter feeling seemed to have some columns with fixed width (and/or match the content width). Not saying we should do any of those things but that's how I ended up thinking in this space.

matthew-white commented 3 years ago

I think that would make a lot of sense for some tables, including the audit log. In that table, there's a lot of information to display, and more width for the Time column means less for the Initiator, Target, and Details columns, all of which have the potential to overflow.

As background on our table styles, most columns are either a fixed percentage width of the table or a fixed px width. That keeps widths predictable and allows us to specify table-layout: fixed;, which speeds up rendering. Most time columns are a fixed percentage width, and in general, it should be straightforward to change a time column from a fixed percentage to a fixed px width.

However, in some cases, I'd worry about the effect on the other columns. For example, in the app users table, there are columns for Display Name, Created (creator name + creation time), Last Used, Configure Client, and Actions. Right now only the Actions column is a fixed px width: the rest of the width is equally divided among the four columns. We could probably give Last Used and Configure Client fixed px widths, but on a wider screen, Display Name and Created would become quite wide, and quite a bit wider than the other columns, which I think might look unbalanced.

Coming back to the audit log, right now all five columns have a fixed width of 20%. I think giving the Time column a fixed px length would work well there, because there's a high chance of overflow somewhere within the other columns. Maybe it also helps that it's the leftmost column? I think we could also consider giving the Type column a fixed px length. The backups table reuses the audit log component, so these changes would apply there as well.

Curious about whether there are other tables where you think giving a time column a fixed px width would be helpful?

lognaturel commented 3 years ago

giving the Time column a fixed px length would work well there

Yes, sounds great! We should do a quick sanity check with other languages and give a bit of extra room.

consider giving the Type column a fixed px length

Yes, I agree that this also seems like a good candidate. Same comment about other languages.

I agree the App Users table is not a good candidate for making a subset of columns fixed with.

This came about because I was looking at other systems' logs and those felt a lot tighter to me. I think it's because they either have more columns (e.g. Zoho) or have a fixed-width table (e.g. WPEngine). All that had this tighter feeling seemed to have some columns with fixed width (and/or match the content width). Not saying we should do any of those things but that's how I ended up thinking in this space.

issa-tseng commented 3 years ago

This came about because I was looking at other systems' logs and those felt a lot tighter to me. I think it's because they either have more columns (e.g. Zoho) or have a fixed-width table (e.g. WPEngine). All that had this tighter feeling seemed to have some columns with fixed width (and/or match the content width). Not saying we should do any of those things but that's how I ended up thinking in this space.

it would be really helpful to hear the motivations before/rather than/along with the suggestions! if we start from this observation instead of proposing a fix i can point out that we literally use more space and padding and a larger font size and that's why it feels looser. we can always slim it down if you're looking for a more technical look.

lognaturel commented 3 years ago

really helpful to hear the motivations before/rather than/along with the suggestions!

Mea culpa, I only realized after Matt's response that I had skipped a whole lot of stuff that's only in my head. I do agree that I should always provide context and that there's a broader conversation we can consider One Day™️.

That said, I'm hoping we can consider the cheap change of making a couple columns fixed width. Even on a fairly narrow screen, there's a lot of space after columns that have fixed-width content and then the columns with longer content are tight. Addressing just that would go a long way, I think, and likely even fully resolve my feeling of looseness for this table.