Improvements to Live Data tables

[tkrieck]

Hey everyone, I would like to propose some improvements to be made on the default tables and cards of Live Data.

Identified Problems

• Columns and headers

  • Waste of space in columns with column title and the filters;
  • The filters are not properly indicated, they can be mistaken by content input fields;
    

• Configuration Panels

  • The distribution of info is not very optimized and lead to waste of horizontal space.
  • The configuration panels remove the user from the context of the table, as it is necessary to scroll up and down depending on the screen size and resolution;
  • Each needs to be opened and closed individually, via a menu that’s hidden by default. So the order of interactions is: open menu > open panel 1 > open menu > open panel 2 and so on. All of this while the LD menu keeps changing its position due to the fact that the panel was opened above the table.
    

• Cards

  • The point in which useful information is shown inside cards, shifts with every field (the columns in table view). This hurts legibility as the eye need to have constant movement in two dimensions to find the relevant information.
  • The information on card view is really packed and could get a little breathing room
    

Proposed Solutions

Column View

• The proposal for columns is to have its header and filter clearly differentiated from the line contents, creating a grouping via background color.
• Font sizes and input paddings were reduced a bit to make more space for content.
• Input filters have a placeholder and icon indicating its intended use to the user.

Options Panel

The different panels opened via the menu were condensed inside a single panel. This way the user have a single place for configurations and each one of them is collapsible. We can still maintain different buttons inside the menu, but they all will open the options panel and expand its intended option.

To optimize use of space and keep the user in context of changes, this panel opens on the right side of the table. This way, any change that is made here will reflect in view of the user.

The move handles and the remove icon are always visible so the user, in a glimpse, can discover these features.

Card view

Here the changes were mostly visual to keep information organized. The biggest one being the change in disposition of the field title and its information. Before they were inline, the proposal changes them to two lines, one for field identification and the other one for the information itself. While this indeed takes more vertical space, it also frees horizontal space. It also provides a clear line of information in the vertical so the user spend less time looking where the relevant content begins.

To lighten up a bit, the strong bold style of field titles was changed to a lighter semi-bold.

Changes in context

Important: the pagination changes are being discussed in this topic: Pagination template of LiveData and LiveTable

Here we have all the changes applied to the “Page Index” LD table.

Option panels closed (default)

Options panel opened.

So, all in all these are my proposed changes, I hope I made them clear enough but don’t hesitate to ask if some need more clarifications.

Thank you all for reading and please, let me know what do you think. See ya .

[MichaelHamann]

In your mockup, it seems that filters can be moved - why?

Also, panels are extensible. For example, the Live Data exporter application adds a panel for export. We also discussed adding a panel for a tag cloud when implementing tag cloud support. Thus, you cannot really make any assumptions how they use the horizontal space.

Even ignoring that problem with extensions, I’m not a fan moving the panels to the right. This has several problems:

• Horizontal space is usually a problem with Live Data, and we should reserve the horizontal space for the table itself.
• Resizing the columns when the panels are opened doesn’t seem nice and could lead to strange layout changes.
• This doesn’t work at all on small screens, and opening all panels above the table at once on a small screen could be quite disorienting for the user.

The remaining changes look good to me.

[tkrieck]

Hey @MichaelHamann, thanks for the reply.

@MichaelHamann

In your mockup, it seems that filters can be moved - why?

The handles appear in XS but on closer inspection it seems that’s not the whole filter that’s movable but only the constraints inside of it. My mistake.

About the right panel and the extensions, thanks for heads up, I was not aware. Maybe I will just update the visuals then and keep the panels where they are.

Regarding mobile, there are ways to handle these kinds of panels, usually showing them taking the whole screen with a lot of custom CSS. But if they won’t be moved, this will not be necessary.

Thanks again

[CharpentierLucas]

@tkrieck

Input filters have a placeholder and icon indicating its intended use to the user.

+1 for the icon, +0 for the placeholder. The placeholder needs to be done properly if we want it to be useful. IMO a placeholder should provide more specific info than just Filter (see <input>: The Input (Form Input) element - HTML: HyperText Markup Language | MDN). Doing it properly would mean at least providing a new parameter for each column so that the livedata creator can specify whatever placeholder would fit the column filter.

@MichaelHamann

Horizontal space is usually a problem with Live Data, and we should reserve the horizontal space for the table itself.

+1
Maybe we can implement this idea in another way :

• Replace the content of the right side panels with the options (with a button to close them and display the regular panel-column content). IMO this could be nice because I don’t think there’s not many use cases where the user would look at the livedata options and want to quickly use anything in the right side panel. A big downside is that it would break consistency. Users expect panels to be here, and we’d replace them.
• Display livedata options in a modal (maybe even a drawer without a backdrop?)

@tkrieck

Regarding mobile, there are ways to handle these kinds of panels, usually showing them taking the whole screen with a lot of custom CSS. But if they won’t be moved, this will not be necessary.

I don’t know the exact solution we would go for, but implementing responsive designs with modern CSS should not be difficult given we think about it when creating the DOM templates. Having a “mobile” design for the layout would make sure we properly take it into account (and would make the choices in HTML implementation that much easier to take ).

@tkrieck

Card view

Overall
I’m still having issues with the way we don’t highlight and/or separate actions but that’s discussed in parallel in Style Live Data actions as buttons - #6 by mflorea , I won’t go further into it here.

@tkrieck

To lighten up a bit, the strong bold style of field titles was changed to a lighter semi-bold.

As a side note, it might be interesting to provide the font-weights we use often as variables. As of now, I see a lot of font-weights in our codebase that are hard coded.

don’t hard code colors in properties

from https://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/XhtmlCssCodeStyle/#HCSS. We have this codestyle to ensure we are consistent across UIs on colors, but we should probably do the same for font-sizes ^^’

---

Thanks for your proposal!
Lucas C.

[tkrieck]

@CharpentierLucas

Having a “mobile” design for the layout would make sure we properly take it into account (and would make the choices in HTML implementation that much easier to take ).

You’re right, I will prepare one, hopefully this week. At least for validation, even if we don’t go with the right panel.

@CharpentierLucas

As a side note, it might be interesting to provide the font-weights we use often as variables. As of now, I see a lot of font-weights in our codebase that are hard coded.

Agreed. What I’ve been seeing from other design systems if offload these to CSS custom properties. So if one font-family looks better with font-weight: 500 and another one with font-weight 600 we just assign the appropriate value to them in the color theme as --font-weight-semibold for example. The same can be used for spacing, so we would have a set of predetermined spacing options.

[mleduc]

@tkrieck

Column View

• The proposal for columns is to have its header and filter clearly differentiated from the line contents, creating a grouping via background color.
• Font sizes and input paddings were reduced a bit to make more space for content.
• Input filters have a placeholder and icon indicating its intended use to the user.

+1, though as already mentioned, the filter placeholders might not be easy to implement because:

1. we need to provide labels
2. we need to check is all filter types would work

@tkrieck

Options Panel

I feel like a modal, following the same logic, would be a better fit than side panels.

@tkrieck

Card view

+1

[pdwalker]

Just a thought,

the same columns and header improvements could also be made to the sortable table class.

mind you, I have no idea how hard or easy it would be.

[tkrieck]

Hey everyone. I’m back with some changes and thoughts about this proposal.

I changed the filters on the headers per your feedback, so now they don’t have the title, but retained the icon. This icon was moved to the left to keep with reading order (and probably should be on the other side for RTL themes).

@MichaelHamann

Horizontal space is usually a problem with Live Data, and we should reserve the horizontal space for the table itself.

I agree with the premise. However, we have to keep in mind that when the users has these panels open, they are usually altering the table’s functionality by sorting, filtering, etc. Therefore, it’s not something that would be open at all times, like @CharpentierLucas said. Additionally, when it is open, the user can see changes made immediately instead of needing to scroll.

Opening the panels in a dialog

@CharpentierLucas

Display livedata options in a modal (maybe even a drawer without a backdrop?)

@mleduc

I feel like a modal, following the same logic, would be a better fit than side panels.

While this would indeed fix the positioning problems of the panels, making them open this way would not provide a way to build filters/sorting and see immediately the results. So there’d be a lot of back and forth between opening the options and closing them again until the user is satisfied with the results.

• Keeping the panels in their current positions
  If we go this way, I would then update the visual design to keep them more compact, so there’d less scroll between panels and table content.
  

UI extensions

@MichaelHamann

panels are extensible. For example, the Live Data exporter application adds a panel for export. We also discussed adding a panel for a tag cloud when implementing tag cloud support. Thus, you cannot really make any assumptions how they use the horizontal space.

I did some tests with dev tools to update the design, making them open to the side and install the aforementioned extension. Everything went well, and the extension worked just like it would with a mobile view. So, IMO if the extension works well in a mobile environment it should work well here too.
Mind you, the extension was not changed, this was possible mostly with CSS and a little bit of HTML of the Live Data component itself.

Mobile view

@CharpentierLucas

Having a “mobile” design for the layout would make sure we properly take it into account (and would make the choices in HTML implementation that much easier to take ).

On mobile, currently, the panels open above the table and the user scroll up and down. In this situation, I think we can provide a dialog to the user. While we’d still have the switching of context (opening and closing the dialog, as I commented above) at least is quicker and more precise than scrolling up and down.

So this is it, sorry for the delay in these updates. Personally, I feel we can still at least do a test on the sidebars to see if they would work as intended. And as a plan B we can maintain where they are now, but make them visually more compact. What do you think?

Thanks for reading.