Pagination template of LiveData and LiveTable

Development
,
#1

Jira: Loading...

Hey everyone, as part of a bigger proposal to improve the design of live data, I would also like to propose some changes to the pagination layout of both LD and LT, to keep them in sync.

For context, I’m talking about these two:

Context

Note: I know that Live Table is on its way out, however I feel it’s important to keep them both as similar as possible until we have migrated everything to LD.

Some problems identified and proposals to improve them:

  1. Inconsistent Layouts: Live Table (LT) and Live Data (LD) have different visual layouts for tables. Let’s aim for consistency between the two implementations.
  2. Secondary Placement of Pages: The pages listing is currently secondary in the reading flow. Considering the navigation importance, let’s prioritize the pages within the results info. Of course this would need to be reversed for right-to-left reading flows.
  3. Complex Results Info: The current format (“Results # - # out of # per page of #”) is hard to interpret. It requires the user to read the whole sentence to make sense of the numbers. Let’s split it into two groups for clarity: one for displayed results and another for results per page.
  4. Subtle Selected Page: The selected page is indicated with subtle bold text. I suggest increasing contrast by using the primary action color as the background.
  5. Small Interaction Area: The space for mouse interaction on each page is narrow. Let’s increase padding on page buttons for better spacing and accessibility. Also, enhance hover/focus styles.

All in all, we would get something like this:

example table

The difference between LD and LT would be only the LD action button, on the right:

Live Data:
Live Data

Live Table
Live Table

And here we have a more contextualized mockup for these changes using Live Data:

final mockup

I would like to know from you, what do you think of these changes? Should we really improve LT even if it’ll be eventually upgraded to LD?

Thank you all for reading!

Improvements to Live Data tables
#2

@mleduc has been working on those upgrades, I think he might have a good idea on this question :slight_smile:

  • Do we really need 11 pages to move to in the primary info section? It’s quite heavy and I think most users could do with less: 1st page, current-2, current-1, current, current+1, current+2, last page. If need be, we can also probably add an input for the page number quite easily. I’m not sure what’s the best for UX but I think it should be considered for an improvement :slight_smile:
  • Results # - # out of # is secondary info, but IMO it’s still too much and it clutters the UI. I don’t see a use case where the Results # - # would be useful. In the few cases where it’d be useful, this info is redundant and can be found without much trouble with basic arithmetics: I know I’m at page 12 with 15 entries per page. There are 11*15 = 165 entries before this one, so the first entry is the 166th. The last entry is the first between the last entry of the table or the last possible entry of the page. I knwo the table has 200 entries, which is higher than 166+15=181. So I can figure out that the last entry of the page is 181. Written down like that it doesn’t look that easy. :sweat_smile: Subjectively speaking those values are useless. It would be interesting to find a use case where they are needed.

Except for those two improvements on the content side, it looks good to me :slight_smile:

Thanks for your proposal!
Lucas C.

1 Like
Close/move issues related to LiveTable?
#3

My take is that we should close as “won’t fix” all jira issues that exists for LT and that don’t apply to LD + move all LT issues that exist for LD, as LD issues. Ie. focus our energy on migrating to LD (and improving LD) as fast as possible.

This is potentially a question that would merit its own thread (I was asking myself the same question today to decide if I should close some LT issues as won’t fix for today’s BFD ;)).

EDIT: Started a thread about this → Close/move issues related to LiveTable?

2 Likes
#4

This is an interesting take, I haven’t thought about it yet, but I’ll try to have some mockups to test. I guess the only situation in which this approach would complicate things is when the user knows that his result will be in page number #, but also, I don’t know how common this situation would be. An input field would indeed mitigate this.

Makes sense. I can see some value on the total number of results for the table, if I am filtering for example. But not on the partial “Results 1 - 15”

#5

Off-topic but I feel like pagination is becoming more and more something of the past and tabular UIs now mainly show the top X results based one the current pagination and filters, and an action to show more.
If an expected result is not found in the top X results, users either change the pagination and filters, or click on “show more”.
Note that this approach could solve the issue we have where we have to show N/A for results that a retrieved from the database but can’t be displayed to the current user because they do not have enough rights.

PS: This might not be a solution in all cases, but an alternative to consider.

#6

I find this information quite important. In particular, the total number of results is not shown otherwise (or do you really suggest I should go to the last page and count the rows to know the number of results?).

Exactly, this basic math might be easy to do if you’re good at math, but it would still be useful if XWiki could do it for you as it as lot more effort to do it by hand.

Also, I find that the page selection is missing a label. I find these numbers not intuitive enough. I also think the idea of displaying a select input (or a text input) for selecting the page explicitly is good.

Apart from that: +1.

#7

Would it be enough to show only the string “# Results”?