In Drupal 7, we have the ability to disable the "sticky" table header if we do not want it. Currently it is the default, and so it gets enabled in a number of places where it would be better to leave it disabled.
In my particular site, users tend to enter really long labels for fields. This makes it so that when they view the "Table" results page, the sticky table header can take up more than half of the height of the page and really get in the way of reading the results. Sticky headers can be useful in areas like the permissions page, but even in this situation where we have a large table, the unknown size of the header can be a problem.
Lots of other places are unnecessary or equally problematic: The Grid component, number component results, list of e-mails... pretty much everywhere in Webform should probably have sticky headers disabled by default.
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | webform-disable_sticky_table-2321567-13.patch | 7.85 KB | danchadwick |
| #12 | webform-unsticky_headers-2321567-12.patch | 1.52 KB | danchadwick |
| #6 | sticky-header-tall.png | 61.77 KB | quicksketch |
| #1 | webform_sticky_headers-2321567.patch | 5.42 KB | quicksketch |
Comments
Comment #1
quicksketchThis patch disables sticky on the following tables:
- Individual grid component result displays.
- Individual grid components on input.
- Number component results.
- List of configured e-mails.
- Download "select format" radio button theming.
- Analysis tables.
- Resend e-mails table.
It leaves sticky on the list of submissions and the list of components, two areas where we have a fixed number of columns and potentially a large number of rows.
Comment #2
danchadwick commentedMany of these would be problematic for me.
- Individual grid component result displays. (I take this to mean submission display)
- Individual grid components on input.
I have grid components which are ratings. Scrolling the heading off the page makes it impossible to interpret the results, particular on a short (squat) display, like a smartphone held sideways.
- Number component results.
I'm not sure what this is. I don't see a table used to display a number submission.
- List of configured e-mails.
- Resend e-mails table.
I'm not sure how sticky is bad here. The table heading are static and short (e-mail to, subject, from).
- Download "select format" radio button theming.
If you are referring to the little samples in the download options form, I agree; sticky isn't displayed because the tables are too short.
- Analysis tables.
I would certainly want sticky here for my application where I have many questions in each grid.
I would say that if your use case requires this, sort of option is needed, at least for the grid component, to retain sticky headers.
Comment #3
danchadwick commentedComment #4
quicksketchPhones typify the situation that often causes a problem. As long as users are inputting one-word options (e.g. "Poor", "Good", "Excellent"), then it's not too bad, but even a relatively short answer like "Neither disagree nor agree" can take up 1/3 the screen on a landscape phone. Even with non-sticky labels, most users will be able to remember that the left-side is usually "poor" and the right side is usually "excellent", though the verbiage may vary. Scrolling back up is always an option, and less likely to cause usability problems with the form.
I should also point out that in Drupal 8, sticky is disabled by default now. So at least in D8, we already have sticky off on all tables. The *only* places where sticky is enabled still is on the permissions page. The reason we have any of these tables with sticky is not from a conscious decision but really just because it's there by default.
Comment #5
danchadwick commentedI think to summarize:
quicksketch has a use case where the options are lengthy, and wordwrap to take an unreasonable amount of space. The desire is for unsticky tables so the lengthy header scrolls out of view, leaving a useful amount of vertical screen space.
DanChadwick (I) have a use case where the options are terse, but the number of questions in the grid is high, so that it is desirable to have sticky tables to avoid scrolling the useful, short (terse) header off the page.
Both seem reasonable. Seems like we need an option for the grid components.
Comment #6
quicksketchOkay, well let's make a separate issue for Grid components then. Overall that's a less-common problem than some of these other places. Here's a screenshot of an example of the Results > Table tab that is very common on the forms I see. Now that labels on components can be longer than 255 characters (essentially unlimited now), we often end up with the table page looking like the attached screenshot, where the "sticky" header can take up >400px. On a phone and even some laptops, it's literally impossible to see any results at all because the sticky header is taking up so much room. I think sticky headers can be useful on this page because there are so many columns, but with questions allowed to be so long, it seems common than not that the headers get quite tall they prevent the page from being usable.
Comment #7
danchadwick commentedI think a better fix for everyone would be to limit the header for this table to something reasonable. That way when you are scrolled down looking at columns of yes's and no's, you have header, and when you look at a humongous header like yours, you might see something that is 20 characters long or so.
Or, alternatively, use sticky headers for this table when all the headings are shorter than, say, 50 characters?
I see the problem and and trying to manage both use cases. In my use case, not having sticky for the results / table would be horrible.
I think a MUCH better solution would be to convert the results / table to a view. The user is then free to adjust the default view to enable or disable sticky.
I'm willing to pitch in on this as it would solve a number of difficulties elsewhere (such as the sid versus serial number issue in the results list (not table)).
Comment #8
danchadwick commentedEh, views for the results / table-display is going to be tougher with views. The fields are created dynamically based on the webform.
I am imagining a "base" view with no components. This would contain the sticky option as part of the table style. Then webform would add components to it programmatically as additional columns. I haven't done this, so I'm not sure if there is an API for this or if you would just mimic what views exports to code.
Analysis would be similarly difficult.
Comment #9
danchadwick commentedI thought about this a bit more. I think there are 3 categories of sticky tables in webform:
For 1, I don't see the need for an option. If the webform creator doesn't like the column headings wordwrapping and being too long, he/she can be more succinct. I suggest we keep the sticky headers.
For 2, I see no harm in the sticky headers since they don't wrap and provide utility. Or make a case-by-case decision. For example, the export format preview obviously doesn't need them.
For 3, I suggest we set the sticky based upon the longest column title. Pick some threshold and any table with all the columns (other than the first) that are shorter than the threshold continue to get sticky headers. Otherwise no sticky header. Don't like this? Override the theme function (I think these two cases have theme functions, but I haven't looked).
Long term, if we convert to views, the use can just install views ui and override the default view to set what they want. This gives quicksketch short-term relief and doesn't introduce anything that we will regret later.
Comment #10
quicksketchFor situation 1, let's just leave the sticky on for Grid. I think you're right it's more commonly useful than not so.
For situation 2, we should disable sticky headers if there's no chance they'll be useful anyway. Less code on the page is going to be a good thing, even if it's a small amount of JS we're not executing.
For situation 3, I think it'd be a small amount of looping to determine if any labels are too long, but I'm not very keen on the magic of the proposal, automatically determining if labels are too long based on some arbitrary number or a site-wide option. Maybe we could add some CSS to the page that simply forcibly limits the height of the sticky header to 2em (or so) unless hovering over the header, in which case it would expand to full size?
Comment #11
danchadwick commented1) Grid components stay sticky for now. I think we are agreed.
2a) Worthless sticky (e.g. output format preview) -- I think we are agreed they should go unsticky.
2b) Worthwhile benign (sticky headers are useful and single line) -- e.g. webform submissions, webform-results -- I suggest we keep the sticky. No bad side effects, and I (and I suspect others) find them very helpful.
3) The hard part. You can't "hover" on a smartphone, and I'm not wild on the headers being truncated in (a probably ugly way) by CSS. How about if the "magic number" is a variable with no UI for setting it. Someone who doesn't like the behavior can set it in the database or settings.php? We see what the feedback is and add an admin UI if it seem needed. If we pick a good threshold, probably nothing is needed.
Or, alternativly, we add a setting to the advanced form settings about whether to use sticky headers for the results and analysis.
Or is there some other idea that's better???
Comment #12
danchadwick commentedJust to see what it's like, here a patch that uses sticky when the headers are less than a threshold. I only did it for the RESULTS / TABLE page. Not sure I like it.
I also tried various CSS techniques to see if I could get something to work on just the sticky header. I didn't like anything that I tried.
I think the best thing may be to give the user an advanced per-webform option. Something like:
( ) Use sticky headers for results and analysis tables.
The better solution might be for the jQuery to look at the window height and disable the sticky headers when there are too high a percent (25%?). But that would involve messing with the (very complicated and somewhat brittle) sticky header code.
@quicksketch -- thoughts?
Comment #13
danchadwick commentedGetting back to this. I modified quicksketch's patch slightly. The form and display tables of a grid element are now sticky by user choice. The default continues to be TRUE (sticky). This was accomplished by adding a new default for sticky => TRUE, a new form element in the definition form, and using the sticky setting for display and edit form generation.
All the other suggested tables were made sticky. A number of tables in webform were already not sticky.
The RESULTS/SUBMISSIONS and RESULTS/TABLE tabs were not addressed by the patch, but this related issue will allow site builders to control whether these two tables should be sticky or not. They default continues to be yes when the tables are generated by views. #2330557: Replace hard-coded tables with views