I want the table to scroll horizontally so that the map can stay visible.
The two complaints I've had from users about this are:
1. They didn't realize it could be scrolled, so they missed out on the extra columns. I'm probably going to fix this using some kind of visual indication - maybe a shadow.
2. Mouse users have to scroll to the very bottom of the page in order to find the horizontal scrollbar. I'm looking at adding a duplicate scrollbar at the top of the table using the trick implemented by https://github.com/avianey/jqDoubleScroll/blob/master/jquery... (re-implemented not to depend on jQuery)
I'm in Firefox on Windows and would not have noticed that the table is scrollable either.
The horizontal scrollbar is way down below row 100 (about 6 pages of vertical scrolling to get there), and since column sorting is set at the top you don't go down to the bottom of the table unless you're looking at it thinking "I wonder what dam has the 100th largest capacity?"
Maybe different for someone taking a serious look through the data, but for anyone getting a glanced impression off of it they're going to sort by X and look at the top 10-20 rows.
As for the Mac people with no visible scrollbars, I don't know if there's a fix. Maybe you just rely on 95% of them being on trackpads where they're much more likely to notice a horizontal scrolling table than people with scroll wheels.
I wish we had some standard but more compact UI affordance to indicate scrollable content without needing a scrollbar. Like an ellipsis for truncated text. But touchscreen phones have definitely driven user behavior to "just try scrolling everything, if it doesn't scroll that's how you know it's not scrollable."
Not great for scroll wheels, and I'm sure there are plenty of phone users who have issues with this too. Not everybody is constantly touching everything to see if it works. But the only thing you'll see is sometimes there's a line of text that's only half visible. And with the amount of whitespace everywhere lately, that's not even likely to happen most of the time.
If you constrain your table with respect to the viewport, with overflow scroll, your horizontal scrollbar will show at the bottom of the screen if enabled (similar to how google sheets does it). Either way having a shadow to indicate more content this way on the right side would indicate to touch users and scollbar hiders that this element can be scrolled. If you pin your header row in place your table will become a lot more scannable.
Even with scroll bars always visible, as they are on my system (Firefox on macOS 10.15), I can't see that there's a horizontal scrollbar until I go down several pages.
If I change from "Always" to "When scrolling", the only way I can make the horizontal scrollbar appear is to start scrolling by pressing my mouse wheel to the side. It's otherwise utterly invisible, even when I hover over that region. Edit: the table doesn't initially have focus, but if I click it, I can also use the arrow keys.
When I wrote a page to display a very information-dense table, I tried very hard to avoid horizontal scrolling. I abbreviated, used icons and colors, and allowed wrapping. You're implementing a general purpose utility that can have arbitrarily many columns, so you can't really control that.
I'm not much of a web dev, so I may be off base, but I think part of the problem is that you're mixing a page-wide vertical scrollbar with a div- or table-specific horizontal scrollbar.
Can you paginate your tables to fit the window height?
That would obviously fit less data by default, but allows people to see the scroll bar and you can just offer an option to increase the number of rows (at the bottom of the table)
If you can, try to cut off the content as the visual indication at the edge of the page. You might try bumping up the contrast of the headings as well so that the cutoff is more obvious.
Not quite as complex a dataset, but the NHL + MLB have done a reasonable job of making their various stats & standings tables responsive:
https://www.nhl.com/standings/2020/division
Maybe, something like `max-height: 90vh;` helps. (So, without interfering too much with the browser UI, a user should eventually see the entire viewport of the table. It even provides some extra space for a textual hint, which is obviously, how we do usability nowadays.) Moreover, the table head may be a classic use case for fixed or even sticky positioning inside a scrollable element.
re #1 that's one of my pet peeves on ios, but for vertical scrolling components.
Because there's no affordance that says "there's more scrollable content down there!", I never know if the last item that I can see is actually the last item or if there's more. If the height of the scroll area is nearly exactly a multiple of the height of each item in the area, these can hide all over the place, so I end up trying to swipe up on tons of things that aren't actually scrollable.
ios has all kinds of affordances for accessibility ("button shapes" and "on/off labels" as two examples that actually change how apps look), why not one more toggle that makes standard scrollable views end with a fade-out effect or something if there's more stuff in that direction?
1. Consider using Excel style sticky headers and sticky left columns to give users column and row headings. Here’s a proof of concept: https://output.jsbin.com/qiqozum (sorry my example isn’t larger than viewport like your example, but it can be made to work with a large scrollable body on a smaller screen).
2. You can make the second scrollbar position:sticky so that it sticks to the bottom of the viewport (I think your idea of putting it at top would confuse users)
3. You can measure the “thickness” T of a scrollbar by looking at the difference between content height and container height for a div with a forced scrollbar at bottom.
4. I think you can get the second scrollbar to hide using CSS when the real scrollbar comes into view. You could use a container div with overflow:hidden and a negative margin at the bottom of height T, and put the scrollable div within, with an extra margin at the bottom of of it if T. Put the position:sticky scrollbar inside the container div. Edit: IGNORE this bullet point - it’s only relevant for small scrollable area, not whole body viewport.
5. You now run into the problem where the user doesn’t know they can scroll vertically to see more. Perhaps add an extra 20px of transparency below the sticky scrollbar, perhaps a little dark opacity, so user can see scrollbar is floating and that there is more data.
Things to watch for:
1. NEVER use the fake scrollbar as a 100% replacement for a real scrollbar... they are janky (JavaScript cannot provide smooth scrolling) and there are many many ways for the scrollbar to not show properly and screw the user over.
2. Scrollbar thicknesses can change dynamically. You can detect this as an event, but it isn’t necessarily simple.
3. Page zooming can cause troubles. Pinch zooming can cause troubles - needs lots of testing on touch laptops or Windows tablets.
4. Only Chrome, Safari and Firefox engines. Microsoft Edge before Chrome transplant is your enemy - nothing will work right. You can get everything above to work well in IE11 including jankfree sticky column and row headers, by using JavaScript, but it takes tricks that are not well known.
5. Test in Safari on Mac by switching on scrollbars in preferences.
6. Take a lot of care to ensure the second scrollbar never occludes the real scrollbar (bottom or right) - there is a risk the user can no longer scroll.
7. I haven’t had much experience using a fake scrollbar to scroll the viewport as needed by your example. I am fairly sure I am missing a couple of difficulties because my experience is mostly for scrollable elements rather than a scrollable body, and I know there are some troublesome differences between the two.
8. Keeping the scrollbar synchronised to content is not always as easy as you might think. Use non-blocking onscroll event so jank is not introduced.
Sorry but horizontal scrolling is just abhorrent UX for everything but maps, and I'd argue that that interaction is not actually perceived as scrolling by the user.
I'm glad that it hidden scroll bars make that more inconvenient,
feels like a win win situation to me.
As for your datasette use case:
Why not have explicit buttons to move between colums at a time, or the ability to toggle and reorder individual columns, so that they become more wieldable, or both.
I'm planning on adding the ability to toggle columns, but the whole goal of Datasette is that you can point it at ANY data - including some crazy government data CSV file with a hundred columns in it - and start exploring it without having to do any customization first.
Compare the scrolling behaviour of OPs example table, with the scrolling behaviour of Excel or Numbers.
With OPs version you get immediately lost in the grid because the headers don't float along with the scrolled view, which makes this best case useless, worst case harmful (e.g. confusing important columns).
If you have thousands of columns you're not going to do manual eyeballing of values anyways, you'll lose track because scrolling is not accurate enough, so you might as well represent rows as documents which densely shows the fields/columns and values, and which can then in turn be shown in a vertically scrollable list.
The problem you describe isn't horizontal scrolling, it's scrolling as implemented by OP. It also applies to vertical scrolling, as the headers don't follow around.
If you have both horizontal and vertical scrolling, gesture-scrolling systems (like touchscreen and two-finger trackpad) behave weirdly. It either wobbles back-and-forth, or it locks to a particular direction.
Also, mice with physical scroll wheels can only scroll in one direction.
You can have pretty much as many things as you want in one dimension, but the other dimension has to be limited in turn, or people will get lost and confused.
If your users start to hold a piece of paper up to their screen to not loose their row you've failed as an UX designer.
Give them the ability to make sub-selections, and to reorder data. And compress the rest into interdependent interactive charts where selecting a data point in one, highlights the corresponding values in the others.
That's awesome that your suppositions work for your use case. But they are not universal truths.
Try comparing five Medicaid plans, in a method that is easy for people with an eighth-grade reading level to understand, that will also pass the scrutiny of three different government agencies.
Sub-selections, reordering data, and all the other things you list won't matter a whit.
I want the table to scroll horizontally so that the map can stay visible.
The two complaints I've had from users about this are:
1. They didn't realize it could be scrolled, so they missed out on the extra columns. I'm probably going to fix this using some kind of visual indication - maybe a shadow.
2. Mouse users have to scroll to the very bottom of the page in order to find the horizontal scrollbar. I'm looking at adding a duplicate scrollbar at the top of the table using the trick implemented by https://github.com/avianey/jqDoubleScroll/blob/master/jquery... (re-implemented not to depend on jQuery)
It's really frustrating how tricky this is.