Replies: 9 comments 7 replies
|
A good question for this feature is: what happens when the pinned rows fill, or more than fill, the viewport? Do we have a 'maxPinnedRows' or a 'MaxPinnedViewportPercent'? |
|
I added the grid option Lines 231 to 236 in 8ad6dcc Line 293 in 8ad6dcc |
Pinned-row overflow — design notesWhat happens when pinned rows fill, or more than fill, the viewport? The core factThe invariant "every pinned row is always visible" is physically impossible once pinned 1. Budget metric — percent primary, count secondary
2. The rule that prevents the catastrophe — reserve the bodyThe real failure mode is zero scrollable area left: the top and bottom stacks meet and
3. What happens to the pins that don't fit —
|
| Strategy | Behavior | Trade-off |
|---|---|---|
'conveyor' (default) |
The docked stack is a bounded FIFO of K slots. Scroll past more summaries than fit and the earliest-docked row un-sticks and scrolls away as the next arrives. | Loses all-visible, but degrades where it hurts least — a summary far above your position isn't useful. Matches the "luxaflex" metaphor. Needs no per-row metadata. |
'clamp' |
Excess rows simply aren't pinned; they behave as normal rows. | Dead simple, predictable, but silent — can surprise. |
'collapse' |
Overflow condenses into a compact expandable bar ("▾ 3 more pinned"). | Keeps everything reachable; adds a UI affordance + complexity. |
'priority' |
Per-row pinPriority; evict lowest first (grand total stays, quarter summaries drop). |
Most control; requires authors to assign priorities. |
Ship 'conveyor' as the default (least surprising, zero metadata); offer 'priority'
for power users — e.g. "Net Profit / YTD never leave; individual quarter summaries roll off
first." The two compose: conveyor with a pinned high-priority row reserved in slot 0.
4. Splitting the budget across two edges
Pinning happens at both top and bottom, so the budget must divide.
- v1 rule: give each edge its own share (
budget / 2) and apply the overflow strategy
per edge. Simple to reason about. - Nicer variant: allocate dynamically by how many pinned rows currently sit above vs below
the scroll position. Defer to v2.
Recommended config surface
{
maxPinnedViewportPercent: 50, // primary, responsive budget
maxPinnedRows: null, // optional hard secondary cap
minBodyRows: 3, // guaranteed scrollable detail region — wins over budget
pinnedOverflow: 'conveyor', // 'conveyor' | 'clamp' | 'collapse' | 'priority'
pinPriority: (row) => 0, // used by 'conveyor' slot-reservation / 'priority' eviction
}Mental model to document: budget-first, body-protected, conveyor-overflow. Percent
decides how much screen pinning may claim; minBodyRows guarantees you can always still
scroll; the conveyor decides who rolls off when there's more context than screen.
Implementation note (SlickGrid virtualization)
Because a pinned row scrolled far out of range has no DOM node, the docked stacks are best
maintained as overlay clones recomputed from scrollTop each scroll: partition pinned
rows into above-fold / in-view / below-fold, keep the nearest K per edge (K derived from the
body-protected budget), and the evicted ones are simply the ones genuinely scrolled off-screen
— so "eviction" costs nothing; you just stop cloning them. The demo mockup-overflow.html
implements exactly this.
|
The pinnerOverflowStrategy is basically already implemented, that's another problem that the AI often does and tries to reimplement something that already exists (see my previous comment above). Please don't duplicate things, we can improve what is already implement instead I do like these videos that you've showed, it's very modern and I wonder if that would be taking less lines of code compared to our current freezing implementation or more!? Also how would that compare against your other PR #1238 |
|
Side note what @GerHobbelt was talking about in the PR wasn't actually sticky columns or rows (at least I don't think so). What he was actually talking about is a completely different subject which is the issue that you could get when using coll/row spans in combo with column freezing, so for example if we have a span that spreads from column 0 to 5, then if we freeze on column 1 or 2 (in the middle of the span), it would break the spanning and we don't support that either because it's a very problematic challenge and @GerHobbelt |
|
Not entirely - he commented on a lot of things, one being the Rowspan/colspan issue, and one being the 'sticky columns'. I started off this discussion with a direct quote from @GerHobbelt's comment about sticky columns, and the first mockup bears his name for it 'luxaflex'. This discussion was to tease out exactly what he meant by this comment. I've tried with the mockups for examples that would be easy to refine incrementally until we all agree what we're talking about. The above pinnedOverflow strategies relate specifically to the sticky rows mockups, though I see it has used the heading 'pinned row' - we need to instruct it be more exacting with the terminology (and we need to agree what the terminology is!). What is the name of the already implemented case? I wasn't aware of that. |
|
ahh I must have missed that part, too much to read 😆 |
|
Wow!👍
Yes, my comment was multi-subject and the visual demo by @6pac is precisely what I had in mind back then.👍 Ok, took some time as I had to focus and remember/recall why this never got done/finished and, well, exploded in my face when I attempted to write it. There's, to my mind, several subsections to this 'luxaflex' design, it gets complicated in a hurry so I'd better structure my usual stream-of-conscience writing here: I'll try my best to keep the items separate by using chapters... And please do keep in mind this is based off recall and rethought coming from several years ago; I'm currently not working on any desktop UI software myself. (1) section: language suggestion because pinning and freezing may be confusedBefore I commence, and started by my mistake to use the term pinning for this grid behaviour earlier, so my apologies: I would like to suggest and use a new, unambiguous phrase for this behaviour to clearly identify and separate it from the 'frozen rows and columns' as exemplified by ubiquitous Microsoft Excel and many others. 'pinning' is often used for that 'freezing' behaviour, which makes 'pinning' confusing as I used it for a different behaviour ('luxaflex design') -- because that's how I always verbalised it for myself back then. The suggested new phrase is sticky rows and columns: already at the time I was attempting this the latest modern browsers were introducing CSS based 'sticky DIVs' which did not need any JS to create the 'sticky' behaviour at the top and bottom of the html page. Fallback there was to use JS, some active monitoring and flipping from relative/auto positioning to absolute -- with a bit of calculus added to make it work. Provided your html page/div layout enabled you to get this sticky look. So 'sticky rows and columns' it is and the (1 dimension: row only) look is exactly the look demonstrated by @6pac in an earlier message above. 👍🥳 Now, the stuff I ran into and still see as 'problems' (challenges to success if you will) if you want to do it right: (2) section: pinning rows filling up real estate, no space left for scrolling (non-pinned) rowsExcellent identification of this problem by y'all; it sure helped me recall the same train 😅. Indeed, supposing you don't have control over the amount of sticky rows in your table/grid, these can fill up, take up all space so there's no space left for the scrolling lines. Yes, the stickies can even overflow to available space. One way to arrive at this scenario is to have 2 users for the application, one with a huge 4K or 8K screen stack (2x2 displays, 4K or 8K each) because he needs this. Let's call him Mr Star Trek and he has just created a new, nice looking, large grid with lots of detail and (sub)summaries, using sticky rows and when grab a chair to view this monster on site (at his desk), you are happy with it. Looks good, good visuals too, so it's a go. So he opens the same sheet and the whole system croaks, he can't see a darn thing for all the sticky rows, too many, making a total mess of it all. so what was my solution to be?First, determine the ratio between maximum allowed 'sticky space' and 'scrolly space' (or total real estate, which is This percentage is to drive the layout of the grid and help manage the stickies on everybody's screen; the percentage is probably low (say 20% sticky-vs-total) as you want 'be able to see the forest, scrolling through it'. Second, you need to triage the stickies: when I pose this as a question I'm sure everyone is quick to generate some good ideas about how to go about that: 🤡 all stickies are equal, but some stickies apparently are to be more equal than others 🤡😅1984 My solution (envisioned, not built, because I aborted the development; hence this has not been user-tested re usability -- still I think it would be a nice start and we'll need to listen to our users and adjust according to their feedback) was to have 2 things (not just one of these, because there's always someone who can produce a grid where you 'run out'): A: a hierarchy of stickies: it is natural to have summary lines of subsections and summary lines of encompassing sections (chapters), and so on: the implicit hierarchy in the summary lines is obvious and also made visible in their formatting already, so you should have 'heading styles' a la Microsoft Word: these styles help to organize your huge Report/grid and they work exactly like you're used to when writing Word documents including 'section folding': that's what the sticky rows are for -- I reference ms office because this feature we're discussing is primarily useful in complex office and finance settings, and that audience understands ms office anywhere! Then, having this priority levels thing for sticky rows, you look at how you want the view to compress when space gets tightened: the further you are away from the scrolling portion of the screen, the further you compress = drop sublevels. Doing it gradually or (more obvious) per chunk is to be user-tested, here I favour disappearing chunks at a time, but at the top level of the hierarchy you'll need some 'gradual' behaviour anyway. Let's do an example to help visualizing and reasoning about the behaviour design: Say I have a 3 level stickies hierarchy, 6 rows at top level, each subsection 5 items: 6:5:5 hierarcy. 1, 1.1, 1.1.1, 1.1.2, 1.1.3, 1.1.4, 1.1.5, 1.2, 1.2.1, ... you get the idea, this is large ... , 6.5.4, 6.5.5 Of course this is ridiculous, but ridiculous happens. I've seen it happen, often. So it's not ridiculous, it just happens. Now what do I mean by 'compressing' the sticky area, which is restricted by that real estate percentage ~ ratio? Say, right now, all the stickies are at the bottom of the screen and you have space for only so many; what do I see then? Say I've got enough space to show at least the entire top level: 1,2,3,4,5,6. I also have enough space to show the entire second level -- if I go with my original gut feeling/intuition to do this 'in chunks'! :: 1.1, 1.2, 1.3 and so on ... 6.3, 6.4, 6.5. presto! Say all I have left as allowed space for stickies is enough to show the entire 1.1 subseries (level 3) 1.1.1 ... 1.1.5 (5 rows of sticky) but NOT enough to also show the others: 1.2.1 ... 1.2.5 etc.: then the idea was to only show what fit entirely inside the allowed space and is closest to the scrollable region: 1.1.1 ... 1.1.5 because I said the current view has all stickies at the bottom, so 1, 1.1, 1.1.1 are those nearest. Things start to get a little bit hairier (and you'll see me run into trouble) once the user starts scrolling: you had, hence you have, enough space for levels 1 and 2, but now there will be TWO level 3 chunks 'closest to the scrolling region' and we already know there wasn't, so there isn't, enough space for both of those! What to do?!
So we have only room for one chunk of level 3's, but how come we need TWO of those at some point? This happens when you scroll through and cross a level 2 'boundary', say sticky row 3.2 is in the middle of the screen right now... That means the upper half of the scrolled region belongs to / leads up to 3.2 (because this report has summary lines at the bottom of each section, but that's not the only way these stickies can be used. 🤯🚨The sticky rows MAY be 'introducing' something important (sticky first, then its related scrolling lines follow!) and you feel the headache coming, but we try to keep it simple here in this example so in this example grid every sticky is a summary type: its related scrolling lines are all directly above it. So our simple example, where all scrolling lines only have 'concluding/follow up' sticky rows, has a simple answer: all scrolling lines above that middle 3.2 belong to that one, so we do not need to display the level 3 chunk 3.1.1 ... 3.1.5 in the top sticky region. Meanwhile, all scrolling lines below the middle 3.2 belong with sticky row 3.2.1 as that's the next one coming up, so we need to display the bottom level 3 chunk 3.2.1 ... 3.2.5. That's fine for we had=have space for one level 3 sticky chunk so we're good. However... How about the same example setup, but now we have sticky rows 'leading into/announcing' the next bunch of scrolling lines? If we only have that kind of sticky row usage/intent, things seem simple again: show only the top level 3 chunk as the scrolling lines now belong to 3.1.5 and 3.2 after that middle one there, so not a problem, right? 🤔😉. Uh-oh - now we need to know what KIND of intent the user has with those stickies. Uh-oh! More metadata? (Nope, that won't save my bacon, we do have a problem!) Do keep in mind both these sticky types: the key take away here is that the grid software cannot know perfectly which scrolling lines are 'related' to which of the two adjacent sticky rows: these scrolling lines may 'lead up to' the sticky (summary line, below) but the sticky may also be 'announcing' the scrolling lines following it, e.g. a sticky carrying important configuration parameters used by the calculus results presented in the scrolling rows following it. Hence you will need an extra ruling for the given scenario when there's only space for one chunk at the focus level, but you need two because your grid software cannot flawlessly sniff out the intent of the human author of this grid. The sticky attribute is assigned by human, not by strict machine, so expect variability in intended use / meaning. And the software must facilitate this to be deemed useful and usable. So with the 3.2 sticky line in the middle, this says you should ideally have 3.1.1 ... 3.1.6 in the sticky zone at the top because some of the topmost scrolling lines MAY be related to 3.1.6 and another couple of them to 3.2 itself (following up on 3.1.6 and leading up to 3.2). Ditto for the scrolling lines below that 3.2 in the middle: 3.2.1 is related, so we should show 3.2.1 ... 3.2.6 as well. But there is not enough allowed space to do both! That's a hard problem because now we MUST break our own 'per chunk' rule somehow as it's not good enough on its own. The answer I had to that was to compress the next hierarchy level(s) further, while those are 'further away' from the scrolling content lines: remove all level 2 items *not directly in line with the currently viewed level 3 scrolling content', I e. Hier the sticky rows 6.1 ... 6.5, 1.1 ... 1.5, then 5.1 ... 5.5, always the 'chunk of stickies farthest away from the actual scrolling detail content' and hide enough of that stuff so the *mandatory level 3 chunks' can be rendered in the allowed space. Which I knew would produce another problem, or more correctly: I anticipated the next problem: when you do this, as described above, and you scroll FAST, you get disoriented ('where AM I right now?') because those level 2 chunks are quickly hiding, changing, re-appearing, so finding your way through this huge sheet with the 6:5:5 sticky hierarchy is becoming an (anticipated) cognitive burden for a stressed/tired user. And then... things will go wrong, mistakes will be made. Which is why 'sticky rows and columns' is an expensive feature: you will need to run this by several users, interview and observe, because your final benchmark is not the sales pitch that sold sticky rows, but the harsh reality of humans pushed into exhaustion and then what happens? So the alternative design approach, to get a 'quieter' display over time while skipping through a mega grid like this, was to have all but the currently 'focused' hierchy levels (sic) 'fold away' = hide, unless directly in line. In the current example, with 3.2 sticky row in the middle, the 'focused' sticky hierarchy elements are: 3.2, 3.1.6 (remember the leading/following intent argument above: you, the software, CANNOT perfectly know where the scrolling lines relate to, as it depends on the humans using you for presenting their story) and (oddly, if you think only in 'summary lines' terms) 3.2.1, following the same knowledge vs intent argument. Hence we MUST show, at a minimum, sticky 3, 3.1, 3.1.5, (3.2), 3.2.1 -- we may add to these as makes sense and as sticky space ratio limitation allows, starting with the top level: 1, 2, 3, 3.1, 3.1.5, (3.2), 3.2.1, 4, 5, 6. Now that i write this stuff down I note that it makes more sense (to me) to show 1, 2, 3, 3.1, 3.1.5, (3.2), 3.2.1, 3.3(!), 4, 5, 6. Why? Because i failed my own intent/relationship argument once inside the hierarchy: as I don't want to bother the human user with annotating all intended relationship details (which, now that I recall, WAS an option for me because I was looking at financial models and their grids and there, at least THEORETICALLY, I can deduce the hierarchy and the relations by analyzing the dependencies in the calculus/math presented through the grid -- it becomes another metadata upkeep issue when you, instead, start with, say, a database query dump where many interdependencies may be obscured or otherwise unavailable by the time the data reaches the grid! Anyway, back to why I added 3.3 to the minimum list there: if I follow my own proposed logic rigourously, hence have to deal with lack of precise knowledge about wether a sticky is leading up to or summarizing of something (or BOTH at the same time!), then it follows that 3.2.1 CAN be part of 3.3! This is where using chapters style numbering had me go astray all this time while writing this, so careful about analogies! I keep this fault in here so you can observe and see where that alleged complexity kicks in and mistakes are made, easily, already at the design stage: it's not advanced math but producing a consistent, 'logical', behaviour for a feature like this is non-trivial. hence: suggested RATIO for driving decisions about which stickies to show, and when.As you have read above: I consider 'jumpiness of the screen over time as I run around in the grid' an important design factor that mandates user trials and close attention to their feedback and observe them at work: some people don't like the apparent 'ineffectiveness' of me/you sitting down with someone and simply observe them doing their thing, while chatting about mundane nothings, so you get a chance to discover thought patterns that otherwise don't show up -- at least, I haven't seen a better, more efficient method, to find out surprising stuff that's going to kill your architecture/design. (Got a chest filled with war stories on that subject.,😅) The key issue I've ran into times and again is two-fold:
To be determined. This is turning into an essay, so we table that one. On to the next chapter Then there's the question what to do when you don't have the space to render the top level, plus 'mandatory, closest sublevels'. (My plan was to then reduce to the direct hierchy chain only.) (3) the added troubles thanks to variable=adjustable cell height (and width)Given all the above, are we done now? Nope, we are still not done, as there's variable height rows to consider: we MAY run out of space, thanks to one sticky row being very high, and unable to display even that smallest subset: the direct hierarchy chain. Who is to win this contest: clip the large (high) sticky row, or do we further cut back by dropping sticky rows which are even a little further away: the higher hierarchy levels disappear now? Answer: I don't know, that stuff was filed until user feedback time; pick one and expect to throw away and re-implement another idea/approach. That's for sure. The worrying thing here is, once again the jumpiness of the actual view as you scroll through the grid, while sticky rows show and disappear in their limited display area, and where a single very high sticky row can result in the entire sticky region jumping like mad as the logic decided to, momentarily, drop more sticky rows to allow that very high, momentarily most important, very high sticky cell to display properly, only to jump back to the previous display set once that very high sticky row becomes unimportant and is removed from the rendered set. (As always, same goes for überwide sticky columns, of course.) Are we there yet?! Nope. How about the sticky row being so high, all by itself, that on mr. Oversight's screen at least there isn't even enough allowed space to display that sticky row, all by its lonesome? That's an edge case, sure, but these happen and the question then is: can we deal with this situation? (4) section: the trouble with merged cells 'sticking out'The driving question for me there always was: how do I deal with these? How do I make sure a human user can quickly and easily identify CLIPPED merged cells as they happen anywhere in the center of the grid real estate, rather than at its very edge, where clipped cells are expected to exist, 'obviously'. At least 'obviously' for people who gave been using Excel and similar tools professionally, intensively, for quite some time. Hm, I better make a sketch of what I mean/'see' here, as to remove any confusion: to be posted in a later message as im not around paper & pen while writing this. My plan was to have those merged cells clipped and clearly identifiable as such, because I've seen mistakes being made there if the visual signaling wasn't obvious. (5) section: 2 dimensions of sticky, rather than 1: rows and columns. And the triage/render problems are aggravated for columns.Excel and others offer frozen rows and columns. Its also pretty usual to have row-based 'luxaflex' reports and similar visuals in ERP and finance software packages' digital reports, very similar to the movie/demo of the feature by @6pac in an earlier message, above. The new thing, which I haven't met yet, at least not in an editable environment, is doing this in two dimensions. I have observed many folks working and struggling with their tools, thus coming up with the notion that this feature might be useful for them, e.g. in detail/overview/performance analysis sheets where focus is two dimensional: timeline in columns (years, quarters, months, from left to right) while drilling into the geolocation aspect vertically, i.e. continent, country, province/county, city, ... (f.e. when going through an international supermarket's financial data). Of course, if you think that way, there's obviously more than two dimensions, but the 'projection' into the grid can easily communicate 2 (X + Y axes), so having this hierarchical folding / sticky rows & columns thing MAY be a boon to speed you up, iff done properly so you don't get disoriented by all the sticky stuff at the edges producing attention-grabbing movement. That has been my biggest non-technology worry while working on this thing: in one dimension I can see or at least think my way through into an experience that is helping instead of obstructing by merely being 'cool tech'. In the horizontal axis, even with HD and today's 4K 16:9 displays, there's the elephant that's hiding in the columns: those are always much wider than they are high! This goes for (financial) numbers, but most certainly for TEXT cells and the way people are dealing with those is often using the most insane abbreviations: they are not insane, but very company/group specific jargon and a necessity if you want to compress-fit an item description into the smallest possible number of horizontal pixels. Now I show up, with the sticky columns idea, and things get bad pretty quickly as you run out of columns to view and scroll through very quickly: while I've seen 100 rows of grid on screen, readable from that chair, I don't believe I have ever looked at a 100 columns all at once, apart from 'flags sheets' -- an excel idea I saw someone use for some cells in his management report and then stole his idea and abused it in complex parameterized trading sheets: the idea is to have no cell content (at least not readable!) and merely use the cell as your basic voting colouring rectangle: custom formatting style expressions drive the color (say a gradiënt or simple 'traffic light' red, yellow, green); editing such a cell is 'knowing' you can enter a (transparant) space, asterisk, +, -, digit or whatnot in there if you want to override or change the visualized setting -- the custom formatting formula observes your cell content change and adapts the color accordingly so you can see which ones have manual overrides, and so on. While that gives you 100+ columns to see all at once, it's very niche, might benefit from categorising and thus sticky column use, but that doesn't take away from the fact that I fear there's very few columns' worth available for real useful column-oriented stickyness, sticky columns, other than a visual 'optimization' of frozen columns as people complain about those taking up too much space or being not-useful: the hierarchical row design idea, as described earlier, can maybe help pick which (ahem!) frozen columns are important to view right now as we scroll along horizontally. Which shows us another use case detail of frozen rows & columns: if I visualize the description above, this means sticky columns are not necessarily related to their immediately adjacent scrolling columns! Off we consider this as desirable sticky rows/columns vegaviour. Or... we declare this behaviour 'hierarchical frozen columns' (or rows! Some folks create their grids 90/270 degrees rotated to what you or I are used to so reckon what you can do in one dimension, some people will want to do in the other as well!) The column dimension therefor is cause for more consideration; I pondered it, doodles a few concepts to show and discuss back then, but I stopped before creating this in software: it simply took too much effort at the time and I knew from some experiments that I was facing some real hard time with the legacy browsers that were on the mandatory support list. I did consider redoing the slickgrid core as a flexbox + sticky CSS layout render engine, but my time and energy were needed elsewhere, so that never got off the ground, not past the experimental stage anyway. IIRC we then went and did a subset of this feature, which was akin modern code editors' "folding sections": the user identifies a folding row and when its 'section' disappears out of view, only the folding row remains. And then, after N rows like that, they start walking off screen themselves as you move on through the large grid, so you don't get drowned in sticking rows. I wrote this on mobile and am crap at drawing without Wacom or paper & pen, so I tried to create the visuals in text. It definitely helps yourself to take the time and draw/sketch each state in the timeline of scrolling through a grid like that to help identify the details of each state/scene and the decision making which the software will have to do. I know I did that when I was working on it, back then. Now, I'm sure there a few gotchas I missed today. Sticky + variableSize + mergedCells is a heady mix! |
|
Dang! I suggest to use 'sticky' and I completely miss my already written headings talking about pinning. MY FAIL.😳😳 |
|
gosh I was also using these 2 terms interchangeably (freezing and pinning) in all our recent conversations 🤣 FYI Ag-Grid calls it "Pinning" (which equals to our freezing), so yes we need a new term while googling more, I found this another data grid project which has both freezing and sticky in the same grid, however instead of freezing they use "fixed". So in that grid the first/last columns are "fixed" but the "address" column (3rd col) is "sticky" and so only that one sticks when scrolling completely to the right I do like the term "sticky" and I think it makes sense more than "luxaflex" which after googling returns window blinds 😆 |
|
@6pac: re your subsequent comments (excellent writeup with the chapters 1,2,3,.. btw):
Just my 2 cents, but, today, I would not include ’maxPinnedRows’ as you already have that real estate ratio in the form of your 'maxPinnedViewportPercent' setting. Why? Because, 1, userland programmers will use that initially very intuitive maxPinnedRows and believe they are done, until actual use of their app hits the fan, thanks to a user twiddling a few rows and cols' width and height and suddenly things look crap or broken. 2, the real estate ratio makes the behaviour obviously portable across user displays, from small Chromebooks, tables, up to Mr Star Trek 'the bridge' multidisplay rigs: if you say the sticky rows and columns get 20% of total space (maybe a separate ratio for columns and one for rows, but the argument here remains the very same) then they get 20% on anybody's screen, wether small or huge or anything in between. If the end user wishes it to be otherwise, they can fiddle with their in-app settings to tweak that max percentage number(s) for themselves. MaxPinnedRows feels like a hold over from fixed row height times, is super simple (or at least looks like it is, for the naive userland slickgrid programmer) and does not adhere well to the actual reality, where each row and column has it's own width & height in pixels. Yes, most grids are fixed height through and through. Still. Row count feels like an oversimplification. MaxViewportPercent on the other hand allows slickgrid to calculate how many row and column pixels are available in either direction, for the current screen and real estate alloted to the slickgrid DIV right now -- which is another thing that may change if the user resizes the browser window. Which few people do, but it's there, anyway. I really like your table in chapter 3, which is great. I was mostly talking about flavours of your COLLAPSE mode and how to deal with each situation, I suppose. 😁 From the calculated pixel budget, given we have rules on which sticky rows make it through triage, you get the available number of sticky rows "right now" -- again, this will change when the context changes: scroll event, page resize, ... Of course I like your 'nicer' option over the brutal budget/2 for top, bottom allocation, but I do realize that makes implementing 'good looking' triage filters all that much harder: just a thought, but I would try to see if I can throw all them stickies in a single heap, feed that in priority sorted order to the triage algorithm chain (I expect triage to become more sophisticated over time, thus a chain of rules, rather than just one, and the priority sort is a part of them) and then distribute the ones that made it through to the top or bottom section, where they currently belong. Just a thought and thoughts are cheap vs implementing them, so do as you like! Given your 4 modes table in your chapter 3 (COLLAPSE, ...), it might help if I rephrased the triage of the sticky rows: which ones to show?: For all render modes: Any sticky row which, during the current render of the grid, does not make it through triage, will have its sticky attribute temporarily ignored and is consequently to be rendered as any other regular cell: these show in the scroll area of the grid and when they happen to be positioned outside that area, are simply hidden/discarded, as usual. That phrasing would, for me at least, make all the triage modes, such as COLLAPSE, simply filters (triage algorithms), while the question what to do with the ones who didn't make it is uniform: we treat them as if they don't have the sticky attribute. Do we then provide visual feedback about sticky rows actually having been discarded? A side effect of the triage, if you like? Possibly... I have no preconceived ideas there, maybe show a special thin separator line (red?) to show stuff got dropped by the wayside but this is clearly highly user/application dependent: sometimes you will want to know (financial reports!), sometimes it's a bother and you can do without it cluttering the screen.
Ultimately, I expected, and still expect, to end up with almost all of your listed modes, (well, maybe not the second, IIRC), supported in slickgrid as I expected high variability in user feedback once I got this stuff going myself -- which never got beyond experimental mockups for feasibility testing: user field testing was consequently extremely restricted and limited, but the first noises I got back was all of the same vain while each very different in X: "oh nice! But if it can do this, that it surely can do X too now, right?! This is great!" (Gulp! No, I hadn't thought of it that way, let me walk crabwise exit stage left, flee from the premises as I need to regroup. -- with merged cells, for example, some people really wanted to 'paint' non-rectangle shapes, a kind of amoeba or T as a single cell. To them, that made perfect sense and was functional. And it made sense, if you listened. That took some careful explaining to deny and it showed me those were not thinking the same thoughts as I ever would. Talk about wow. Off topic lament: GitHub for mobile app seems to rewrite my lines 🤬 when I end them (or later), so not just spellcheck/autocorrect word at the cursor as you type, but also some after-party screwing around I didn't ask for. Now I have to re-read my stuff twice... |
|
Personally what I wonder is it you can this "sticky" behavior in the grid, then do we really need both features "freezing" and "sticky"? Personally I would say no, but I'm sure some users would still prefer to really freeze certain columns but only have other columns just sticky which isn't all the time... but supporting both features means more code, imagine if we merge them into a single sticky feature and remove freezing, then that would most probably simplify the code quite a lot... again this is just my my 2 cent and personal thought |
|
That is an excellent thought. |
|
@6pac considering that your access to Fable at 90% off on promo will expire soon (on Sunday I think you said), then I think you should just go ahead and implement it in a PR and perhaps drop and replace the previous open PR #1238. I'm saying this because I know you could get few conflicts with other open PRs, but what would typically be expensive in this case is the "thinking" part with Fable, but on the other hand resolving merge conflicts and diffs is rather cheap and that could be done without Fable in the future... Also I think we should finish the variable row height first, so that implementing this sticky columns/rows also works and is implemented considering the variable row height. Variable row height can be merged in master and release at any time since it doesn't have breaking changes (though I would consider this sticky implementation as breaking change, because I'm sure it will touch a ton of files and lines) I would also consider this to go into a next major version (aka breaking changes) and so to be merged into a |
|
Yep, agree. Initial plan is: variable row height and misc fixes -> current |
|
@GerHobbelt Just FYI, I'm not sure you noticed, but these mockups and follow up posts are all generated by Claude Code based on your suggestions and comments. Attribution was a bit wobbly at the start (as I got it set up), but from now on I post as @6pac and Claude posts as @6pac-ai. I'm posting claude's response to your above comments, along with two documents it generated. Of course I read everything it generates, and often get it to tweak things a bit, but I'm generally impressed by the suggestions and nearly always am in agreement. And it saves a ton of time. The Heirarchy Design (more detailed look at comments below) and the work plan to build this feature on top of the frozen row/column changes PR Note that I am also evaluating the idea of having a small default ViewportMgr class that only supports a single pane (ie no frozen rows/cols) with an external (much larger) module containing the ViewportMgr with all the Frozen Rows/Cols logic. Sticky rows/cols could be an alternate module, or added to the Frozen Rows/cols module. Here's Claude's reply to you, it is a little weird as AI tends to be, but it managed to work in a joke or two: Thanks for taking the time to write this up — it's effectively a failure post-mortem from the Naming (§1): agreed and adopted — the feature is called sticky rows/columns throughout; Real-estate ratio (§2, first half): adopted, with one addition. The budget is Triage / hierarchy (§2, the hard part): this is where we ended up refusing one of your The lead-in vs summary intent problem: you're right that software cannot sniff it — so it's And the metadata-upkeep worry mostly evaporates: DataView's grouping already produces exactly Jumpiness (your top worry, and ours): instead of dropping far ancestor levels under budget The overlarge sticky row (§3): we adopted your answer verbatim — if a single row alone Merged cells (§4): out of scope for v1 (sticky + rowspan is declared unsupported initially); Overlay performance (§5): worth flagging that the design here is not the 5–9 If you have the appetite, the two rule-sets we'd most value your eyes on are: (1) the |
Uh oh!
There was an error while loading. Please reload this page.
From @GerHobbelt:
I wanted to produce a grid that features row and column pinning: imagine frozen rows & cols but now not as one edge range for both coordinates but true 'pinning' of arbitrary rows and columns, e.g. rows 1,2,20,40,60,83 and 89: these then are, like modern html/CSS can do pinned/'sticky' divs, always in view, while you scroll.
The use case?
For example: taking a large financial reports with lots of details and monthly/quarterly + year summary rows (at 20,40,60,83 and 79 in my example): these summary rows are formatted to be clearly identifyable and for ease of overview, always visible, hence 'pinned', while the remaining screen real estate allows the user to smoothly scroll through the details while the summary rows, (pinned) farther at top and bottom, travel along when part of the current viewport and then stick to the top when we scroll further down.
I call this 'luxaflex UI' but that was an old Dutch aluminium window screen brand which gives me a strong visual association. I might translate this as 'picture carrousel style' or some such now -- sorry, here I fail as English is my second language and I have some 'gaps' (tongue in cheek).
IIRC modern CSS has a 'sticky' attribute which is used to accomplish a similar open/close-while-scrolling experience.
@GerHobbelt is this what you want?
Mockup of sticky rows:
Mockup of sticky rows and cols:
All reactions