ovirt: Suggest paginating display when there are a lot of VMs(more than 15) display in oVirt Machines Cockpit UI. Currently, the UI displays all the VMs in the one page.

[kenzhaoyihui]

Description of problem: Suggest paginating display when there are a lot of VMs(more than 15) display in oVirt Machines Cockpit UI. Currently, the UI displays all the VMs in the one page.

Version-Release number of selected component (if applicable): RHEL 7.5 cockpit-ws-154-1.el7.x86_64 cockpit-bridge-154-1.el7.x86_64 cockpit-system-154-1.el7.noarch cockpit-ovirt-154-1.el7.x86_64

How reproducible: 100%

Steps to Reproduce:

1. Install the pkg cockpit-ovirt on the RHEL7.5
2. Login to the cockpit and check

Actual results: After step2, cockpit display all the VMs on one page.

Expected results: cockpit can paginate while have a lot of VMs(more than 15).

Additional info: The picture: Cockpit ovirt

[mareklibra]

@andreasn , @garrett , can you please give suggestion here?

[mareklibra]

In extreme, there might be hundreds of vms defined/running on a single host, no matter common expectation is <20.

In the oVirt's Cluster or Template view, there might be hundreds and even single thousands of entities in the list.

[garrett]

I disagree with forcing pagination for >= 15 items.

(Clarification: I'm not disagreeing with pagination as a concept, but just saying something should be paginated if there are a lot of things can be a disservice to someone using the software.)

Considerations

• People generally like to scroll more than click
• It's usually easier to scroll than to click a small region, as far as accessibility goes
• On mobile devices, scrolling is usually a better experience than scrolling, tapping a small target, waiting, repeating
• Pagination breaks in-browser find
• When there's a lot of pagination, it doesn't necessarily get someone to the wanted item, unless it's at the end (there's a bit of hunting and jumping around)

Related reading:

• http://www.hugeinc.com/ideas/perspective/everybody-scrolls
• http://uxmovement.com/navigation/avoid-the-pains-of-pagination/

However

• With many items, it may make sense to be able to filter somehow regardless of scrolling or pagination
• Anything under the list is difficult to get to
• Once an item is found, getting back to anything above the list is difficult

Questions

1. What's an actual common amount of VMs? (We shouldn't design specifically for extreme cases, but should still consider them.)
2. The screenshot lacks context. What's displayed above and below? (What's on my machine might not be what's on yours, so I want to be sure we're talking about the same UI. Plus, we're not running oVirt here and it's a bit of a challenge to set up.)

TBD

I'll discuss with @andreasn about what might be best here.

[andreasn]

I think I'm missing some context here. What is the exact problem with 15+ items? The issue misses to describe the problem and jumps straight to the solution. Does the page become slow? Does it become hard to navigate? Does the page break? Something else?

[garrett]

In IRC, @andreasn also mentioned Patternfly Pagination guidelines @ http://www.patternfly.org/pattern-library/navigation/pagination/

• Pagination is optional.
  • Pagination is not necessary when there is a small amount of content.
  • Pagination is not necessary when an application uses “lazy load” to load content as a user scrolls.
  • Pagination is not displayed when there is no data to display.
• Pagination can be “sticky” and remain fixed to the bottom of a user’s browser.
  • A sticky footer is not recommended for views with content below pagination.

[mareklibra]

What's an actual common amount of VMs? (We shouldn't design specifically for extreme cases, but should still consider them.)

As I wrote above, the expected amount is <20, on PPC in hundreds of running VMs. The amount of those just defined (means e.g. in shut down state) can be theoretically unlimited, but more than hundreds would be hard to maintain without any higher-level tooling.

Large RHV setups can recently have thousands of defined VMs which can eventually land within the Cluster cockpit-ovirt view.

[garrett]

Would someone using RHV that extensively also use Cockpit for VMs?

[mareklibra]

The cockpit-ovirt is not meant to be sort of "light" version of oVirt UI. It is a lower-level management tool for host fine-tuning and troubleshooting. To do related tasks, list of all VMs running/defined on the particular host needs to be rendered leading us to the potentially long list of entries on a single page.

This is similar case for cockpit-machines as well. Moreover, we can expect the list to be even longer since on a non-oVirt host there are the shut down VMs too (they are undefined on an oVirt host).

[garrett]

Which of the following is the problem?

1. performance related talking to oVirt
2. performance related with rendering the UI in Cockpit
3. possibly having thousands of VMs in the UI for those who use oVirt a lot

(The answer could be between 0 - 3 of the above.)

[atiratree]

I agree with @garrett, pagination brings many problems.

We could implement infinite scrolling, so the performance would not suffer when the number of vms gets too high.

[kenzhaoyihui]

If it is not necessary to paginate , then close this issue and ingore the RFE.