Posted by & filed under Content Views, Table View.

It’s time for PatternFly to revisit pagination within data views.  This includes tables, list, and card views. In the past, pagination was part of data tables but we recently wanted to start fresh with data tables and gradually add elements as we go. Pagination seems like a fairly simple and straightforward concept but with multiple pages, it could get messy if not done correctly. We looked at a variety of tables and reviewed how pagination behaves within them for this story

 

Before we move forward, let’s briefly discuss the persistent elements. Most elements/controls related to pagination would be found on the bottom of the table.  This includes:

 

  • See the number of items on a page and total number of pages
  • See how many pages of data there is.
  • View which page you are on (current location)
  • Modify how many pages are being displayed.
  • Skip to the next or previous page.
  • Skip multiple pages.
  • Navigate to the first/last page.

screen-shot-2016-10-19-at-10-05-06-am
 

Selection info will be shown in the top right of the table. With this story we wanted to add the ability to select all items across multiple pages. Initially, if you select all on a page, it will select all items only on that page. Then it would prompt the user to select all items across the table. Below I came up with two options to address pagination selection across pages along with the pros and cons of each.

 

OPTION 1
 screen-shot-2016-10-19-at-9-55-21-am
screen-shot-2016-10-19-at-9-55-28-am

 

The first option above shows a new row appearing within the table under the row headers, in the form of a message. This message informs you of how many items are selected and gives you the ability to select all.  Once all are selected, you have the ability to clear selection from the within the same message.

 

As you page through the table, all items will remain selected, however the message will not be shown. View below:

 

screen-shot-2016-10-19-at-9-55-34-amscreen-shot-2016-10-19-at-9-55-41-am

 

Option 1 Pros:  the addition of the message row is obvious and will draw the user’s attention.
Option 1 Cons: Table height would have to adjust to accommodate new message row.  Also, does the placement of the message make sense under the row headers?  Furthermore, it’s redundant to show the number of items shown twice (upper right, and in message)

 

OPTION 2
 
Option two addresses the cons of option 1.   Selection info will stay persistent in the top right, whether there are none or all items selected.  This way, the user always has the ability to select all or clear selection. They still have the ability to select all items within a single page as well as individual items.

 

screen-shot-2016-10-19-at-9-55-50-am
screen-shot-2016-10-19-at-9-55-57-am
screen-shot-2016-10-19-at-9-56-05-am

 

Option 2 Pros: No need for creating a new message row and shifting the table down.  No redundant info. Persistent location and info shown.
Option 3 Cons:  Might not be obvious that you can select all items. Does is seem hidden?

 

Overall option 2 was preferred. People liked the less obtrusive and simple behavior of it. However there were a couple concerns that surfaced:

 

  • Language: Does this language make sense? I thought it was helpful to have the “Selected:” label so that way it could stay persistent and we could still show info when none are selected.
  • Selection info shares the row with Filters.  As filters are added, they will appear in the same row to the left (below filter field) and if enough filters are added, they can run int the selection info. Would we then create an additional row for filters or truncate the list of filters and just have a drop down to view all.
  • Move selection info to left so it aligns with selection checkboxes. This makes sense but since filters are of the left, this would require an additional row.  I’m not sure if that’s the best reason to create another row, especially since that would be the only info shown on the row (rest of row would be empty, and thus look unbalanced)

 

I’ve also quickly mocked up how pagination would appear within the card and list view.

 

screen-shot-2016-10-19-at-9-56-20-am
screen-shot-2016-10-19-at-9-56-12-am

 

Another thing to note is that filters will work across pages.  I talked with Dan, who has been working on implementing the new data tables, and he confirmed that this will not be a problem, the technology he is using supports this.

 

Would love to hear your thoughts on option 2, especially concerning that feedback/concerns that we have already received. Next step we will refine this design for the final stages.

 

Please comment below, thanks!

 

2 Responses to “Data View Pagination Options – Conceptual Design”

  1. Matt Carrano

    I like the latest iteration of this. Just one question. In the card and list views, assume that the text “40 results” is based on the filters applied. What appears in this space if no filters applied? The total number of items (unfiltered)? Nothing? I kind of like having an item count there all the time. In storage we use these views to list objects and it’s nice to feedback how many objects of a certain type are present when the user enters the view. It is a bit redundant with the selection text on the right, but it also helps make it clear what I am looking at when I enter the view.

    Reply

Leave a Reply

(will not be published)