Just want to quickly share an update and request feedback on some general UI improvements I have been working on. This is a part of our Q3 OpenTEAM ACTION funding, more details here.
These changes are focused on improvements to the display of the records tables in farmOS (assets, logs, quantities, etc). We use these tables quite extensively and often get feedback that they can include too much information & are overall “too big”. I also carried over some of these improvements to the dashboard since we views are included there and it occurred to me some relatively easy changes I could make.
I’ll open a PR for these changes soon, any and all feedback is quite welcome! Overall I don’t think there should be many “breaking changes” to the general farmOS UI. The only thing I can think of is potentially less information being shown in the record tables, specifically because text is now truncated.
Here is a quick overview and screenshots of the improvements I’ve found:
Removing unused space
Various parts of the page in & around these tables have extra space. I was able to decrease the size of:
Horizontal margins (on all pages in farmOS!)
Space between map, filter, footer, decrease the table header
Exposed filters text size, spacing and input size
Table rows, no text wrap so rows maintain consistent height, add ellipsis for text overflow
This is a very small change adding rounded corners to the map. It is small but I think it adds a really nice touch, keeping things consistent with the rounded UI elements from Gin.
how it will play with Gin layout density setting (/admin/appearance/settings/gin)? maybe some changes should be applied only when ‘Narrow’ density is selected?
how/if it will impact accessibility, Drupal is striving to attain WCAG 2.1 AA, so farmOS ui changes probably should also be tested with this goal in mind.
Yes, so I meant to say that all the screenshots above are with the “Default” setting. With “Narrow” the tables get even more compact. But none of these changes leverage the Gin layout density setting option. I did learn how it works, though! This is using the --gin-spacing-* variables, but the equivalent --gin-spacing-density-* variables use the configured density.
What I’ve seen is that this density setting really only changes the height of the views rows (specifically the vertical padding within table cells). Most of the changes I made are trying to remove unused space that IMO should really be the default experience all around. But we could make some of these changes more reactive to the density setting, I would suggest:
Horizontal page margins
Dashboard layout spacing
But even then, I’m not sure the configuration adds much value like it does to the table rows. I don’t think either of the above need smaller spacing, and larger spacing seems unnecessary. If we did use the layout density setting I feel like the “Default” would be less of an improvement, and I’m trying to improve the default experience. What do you think?
Great question, I agree we should strive for this as well. This is something I’m not too familiar with but would like to learn more. Is there anything in either the current or proposed changes you think we should be looking into? Maybe we could start a new thread on this.
The main thing I would check for in these changes would be target size. Done some quick testing, and it looks like this requirement is met. Although for buttons in ‘Metrics’ block on the dashboard currently target size is passing AAA level (at least 44x44px) and after changes will be passing only AA level (at least 24x24px).
Only other issue I found is heading tags order, on the dashboard after changes there is h1 ‘Dashboard’ and then directly after h6 for entity types in ‘Metrics’ block without other heading levels in between. While this is not strictly required to pass wcag requirements, it is a good practice to use heading levels in sequential order.
It also seems that there are some accessibility issues in farmOS ui not related to proposed changes. For example ‘Add Asset’ button on the top of the dashboard page has not enough contrast (4.34:1 while AA level requires at least 4.5:1) or search button on the map doesn’t have any discernible text. It would be probably good to at some point do some more accessibility testing of farmOS ui and fix found issues.
The proposed changes also improve accessibility of the dashboard since green link color doesn’t have enough contrast on light green background (for example in the Metrics block) but after changes, on white background minimum contrast requirement of 4.5:1 is passed.
Since the changes don’t interfere with the layout density functionality, I would go without making them dependent on this setting. The only exception I would consider would be the buttons in the ‘Metrics’ block. Since currently proposed changes to their size lower the WCAG level which they pass regarding target size, maybe by default they could be bigger and only when switching to the ‘Narrow’ layout density they would be made smaller.
Looking at the images, I came to think of the Change column order in logs view thread.
The ID takes up space and are rarely used (but still used).
Possible to toggle the field on/of?
Would give some extra space for longer titles.
Could be standard off, and toggled on when needed.
Also done/pending could save space with a checkmark or x to mark done, but maybe not, since the column name takes some space too.
Filters:
The status field in log filters are expanded. That makes sense since the number of choices are constant and few. In the assets filter, the is loaction, is fixed, and status fields could also be expanded. Would make fewer clicks to filter.
Thanks for all this info @wotnak. I agree, this is a good reason to use density for the metric buttons. Technically it’s actually a little challenging because we are trying to keep the gin-specific styling isolated to farm_ui_theme and this is provided by farm_ui_metrics. It might make sense to create some more dashboard CSS variables like --dashboard-content-spacing or ?? which we could override more easily in farm_ui_theme without specifically targeting the Metrics. I’m curious your thoughts on this? https://www.drupal.org/project/farm/issues/3291697
Yes - I hope to revisit this too. I agree we probably just need to work in a toggle, not a big complex feature, but just specific to the ID column.
Glad you mentioned this… I was actually going to propose the opposite, that we condense almost all of these “select” filters… The expanded filters exist so that you can select multiple values and eg: see all logs that are done OR pending. This might make more sense for log category vs log status. But I wonder how often people use this, and if it would be an overall improvement to make them all single select dropdowns so they take up less space.
But I had not considered the amount of clicks, I think you are correct. But IMO I might prioritize the condensed UI over number of clicks. Although on mobile the multi-select may actually be confusing/require more clicks: Log Category defaults - setting or avoiding them
Maybe not a superfan of that. They don’t take up much space when not using them, and when used it does clear view of the filter possibilities.
On mobile the filters are as minimized as they can get as far as I can see. Makes sense to have them collapsed there. Perfect for me.
On the desktop I feel that once the filters are opened, there’s enough space to have them expanded. It also makes it alot easier to decide what filters to use.
It’s on the desktop I do more complex filtering.
Maybe a toggle for that too?
I’ll admit I do less filtering now that I have the shortcut module.
Great points, especially being able to see the possibilities. Some of the filters are a bit crazy when expanded (like quantity tables) but others aren’t too bad. I do agree space is less of a concern.
The other thought I had regarding these multiple select filters is that there could be some ambiguity to how they work when selecting multiple values. Basically it could mean AND or OR, logs with category_1 AND category_2 vs category_1 OR category_2. Currently we’ve chosen to use the OR strategy for all the filters because it is the safest. Collapsing them to a single option would remove this ambiguity, but would also remove the functionality.
The expanded filters exist so that you can select multiple values and eg: see all logs that are