New UI uses fixed scrolling area instead of allowing page to scroll

[arakelian]

We have a large number of services registered with Consul (more than fits inside a visible page).

The problem with the new UI is that you can't scroll "the page" to view them. (Using arrow keys, or mouse wheel). Instead, you have to scroll "the DIV" that contains the list of services services by either (1) moving the mouse over the list of services and using the mouse wheel, or (2) clicking the DIV that contains the list of services to set focus, and then using the keyboard keys.

I understand that you're trying to ensure that the footer is always visible on the page, e.g. "© 2018 HashiCorp Consul 1.1.0 Documentation", but this behavior makes the makes far less usable (IMHO).

[dekimsey]

For what it's worth, I think the header/footer should be on the on their respective parts of the page and not forced into the viewport at all times. It doesn't add value and takes away from available screen real-estate for the important parts of the site.

edit: Maybe. Looking at Vault and Nomad's respective UI. I can see the desired design. Keeping the header makes sense. But that footer, I'd like to see that removed from the viewport. It does make large service lists unfriendly.

[hannahhearth]

Hi @arakelian and @dekimsey, thanks for sharing this feedback. We agree! It's already on our radar, and we plan to make this change after a few other priorities. We'll update you back here when it's been changed!

[arakelian]

Any update on this? Thanks!

[johncowen]

Hi @arakelian

Thanks for checking in on this, right now (short term) if you are looking to be able to scroll the listings in the UI using your arrow keys, this is something we haven't looked at yet (it is something on our radar and something we'd like to implement)

I believe you can use your mouse wheel to scroll, but yes, you must have your mouse cursor over the scrollable area to be able to so this.

Since the original issue was posted we have made the scrollable area cover a lot more screen real-estate so it is much easier to scroll using your mouse wheel, which goes some way to help here, but does not solve the issue completely.

Related to this is a feature coming short term which will effect how all this works (a more 'multi-pane' approach), which impacts how you interact with the entire UI. Once we've settled on a final layout approach we'll be able to work on the finer details such as better keyboard navigation etc.

Just as a side note, the reason we aren't just using native scrolling functionality (which would give us keyboard navigation and scrollwheel navigation for free) is that we cannot build a UI that deals with API result sets of potentially 100,000's items using native scrolling alone. The DOM count to visualize such recordsets using native scrolling would make the UI unusable. So we use a virtual scroller which recycles our DOM nodes for us and gives us much better UI performance. The downside is, we lose the 'free' keyboard navigation.

An alternative would be to use paging, so you would have to click through each page of say 25 items to see all of your dataset. This is much easier to make keyboard navigable, but the UI/UX experience with that is not as nice as a more 'desktop app' scrolling approach.

Potentially, adding keyboard support to the scrolling we have shouldn't be too time consuming, but I'd rather settle on our layout approach first before doing it.

Thanks for bearing with us! And thanks for checking in, it's good to know that this is still something you'd like to see.

John

[arakelian]

@johncowen Thanks for the detailed reply. I would offer the following observation (really, personal opinion) about Consul's approach using a virtual scroller.

By reducing the size of the 'scrollable area' from the entire page to only a subset of the page, you're making it harder for users to scroll with the mouse because they have to be conscious of where the mouse is positioned when the scroll wheel is used. Making things worse is that the mouse pointer is generally hidden after a period of mouse inactivity, so users have to move it first to see where it is.

I'm reminded of a book by Bruce Tog, who was a human interface designer for Apple (Apple employee 66), where he describes why Apple's menu bar was positioned at the top-edge of the screen (Ask Tog. The gist of it was that since users can't move their mouse past the top-edge of the screen, it's 'easier' to acquire the menu because you can simply move the mouse up -- way up -- and just click. Compare this with a Windows menu bar, when the window is not maximized, and you have to decelerate the mouse to ensure you don't overshoot the menu bar.

As far as virtual scrolling goes, I'm personally not a fan (again, just an opinion). I like to know when I've reached the bottom of the page, and I'm okay with hitting "More" or something similar to add additional items to the page. This is what GitHub does for example, in the beta home page / feed when I login.

Consul is an excellent product, and I enjoy using it everyday. Thanks.

[johncowen]

Hey @arakelian

Thanks for the detailed reply.

No problem, the least I can do! Appreciate the opinion no matter how personal, that's how we can understand everybody's needs and try to find the sweet spot.

Making things worse is that the mouse pointer is generally hidden after a period of mouse inactivity

Can I ask what platform you are using? So what OS and browser (plus version)?

I'm reminded of a book by Bruce Tog...

That example you give is an excellent example! I quite often look at Mail.app on macOS as an at least 'fairly good' UI for a similar dataset that gets a job done in at least a fairly good way (don't worry I know people have opinions on how good it is!)

If you open Mail on macOS (or a similar app), you'll notice a 3 pane view. Collapsable mailboxes on the left, a list of emails in the middle (a subset of the page) and a message on the right. If you move your mouse over the main tool bar at the top, so the 'chrome' at the top of the app, you'll notice you can no longer scroll the list view in the middle. You can only scroll this list view when your mouse is specifically hovering over the scrollable area. When you move your mouse to the right, you scroll the email message instead. So unless you have your mouse directly over the listing in the middle, mouse scroll will not scroll the listing. Interestingly I've just noticed cursor key navigation isn't absolutely perfect here either, maybe its just because I'm not aware of 'more than average user' keyboard navigation usage.

As far as virtual scrolling goes, I'm personally not a fan (again, just an opinion)

Completely get you here. For larger clusters unfortunately we can't have a native scrollable listing, we need to use this virtual scrolling technique (as far as I'm aware). I've recently uploaded a gif of this here #5070 (comment) (second gif down under Performance).

In the above example I show only 5,000 rows (plus all the 'potential' DOM nodes in those rows) changing every second, I've been running other tests aimed at and achieving 100,000 rows and above with the virtual scrolling technique. It would be pretty tough for native browser scrolling to cope with this number of rows.

As far as I'm aware this is also a similar problem that Apple encountered and solved with virtual scrolling in iOS ListViews.

An alternative is to use paging and I personally think paging here would make for an inferior experience.

Is there any other reasons apart from those you mention above as to why you're not a fan of virtual scrolling? I do think we may be able to look at somehow making the footer stick to the bottom of the scrollable content rather than the scrollable area, which may help matters. We have already reduced the size slightly of this footer but there might be options to do something else.

Apart from that, please keep the feedback coming, its all very much appreciated! 🙌

Thanks

John

[stale]

Hey there,
We wanted to check in on this request since it has been inactive for at least 60 days.
If you think this is still an important issue in the latest version of Consul
or its documentation please reply with a comment here which will cause it to stay open for investigation.
If there is still no activity on this issue for 30 more days, we will go ahead and close it.

Feel free to check out the community forum as well!
Thank you!

[stale]

Hey there, This issue has been automatically closed because there hasn't been any activity for at least 90 days. If you are still experiencing problems, or still have questions, feel free to open a new one 👍

[ghost]

Hey there,

This issue has been automatically locked because it is closed and there hasn't been any activity for at least 30 days.

If you are still experiencing problems, or still have questions, feel free to open a new one 👍.