We have RG’s that continually load lists as you scroll. However, many of them only load data for the top 1/2 of the page and never get to the bottom half. Users have to scroll more to get them to load top 1/2 of page again.
Anyone know what’s causing this? Or, better yet, how to fix it?
Thanks,
Scott
I am experiencing something similar as well and still investigating it.
For now, what I get is that an RG is with extendable vertical scrolling only load more elements when you reach the bottom of the page, not the bottom of the currently displayed entries (I don’t know why ???).
This might be a bug ?
Thus in my case, it seems that it is because my page is quite high, because hidden group don’t seem to update the height of the page even with the collapse height option. I have to investigate this further…
Edit : I solved the page height issue but the half loading RG issue is till there… Did you fill a bug form ?
I submitted a bug report and Bubble pushed a fix for this.
I’m not sure that I understand your bug. I believe the extendable vertical scrolling is meant to load pages through to the bottom of the page by design. If you want it to show a fixed number of rows that match the height of the element, then I’d set that to full list and set the number of rows you want displayed. Perhaps I’m misunderstanding your desired behavior for this RG though.
Well you might still want to have a small space after your RG, for instance to display a footer.
Extendable does not mean infinite. You can have many items and reach the end.
In all cases, I am stille xperiencing the exact same bug you described.
It can be easily reproduced, so I sent them a bug report with an example app.
Okay.
I think the UX community has discovered that if there’s a footer, then people don’t know that the feed/RG is still scrollable so the UX community considers it to be best practice to have the feed go all the way to the bottom of the page.
Furthermore, if the feed doesn’t yet show items that are loading, it’s okay to display a footer while they load, but it’s not okay to expect users to be quick enough to click items in the footer, so as part of the best practice, sites should have all of the links in the footer available elsewhere on the page. In my experience, they are often included on the menu that’s displayed if you click the user’s name in the header, but really depends on where the links go.
I’m simply sharing this info in case it’s helpful in crafting your application. Clearly, your audience is different than other sites so the generic best practice may not be best practice for your product and your audience.
Best,
Scott
Hi @sridharan.s
(sorry for reviving this old thread)
Could you let us know what was the feedback of Bubble’s support team regarding your bug report?
I am considering filling one too, because after experimenting for a while, I noticed that for me the problem is due to my cells’ height being (on purpose) reduced by hidden groups with the “collapse this element’s height when hidden” option activated.
Bubble seems to be calculating the number of cells to load for the extended vertical scrolling setup based on the full height a cell can take, and not based on the actual visible height.
It’s a real issue in terms of UX. Users who do not have a pad or a mouse enabling them to scroll cannot show the additional cells (unless they resize the browser window), nor can they guess that there are more cells than what they see, because a scrollbar won’t necessarily be offered by the browser (which seems somewhat confused with the overall page height).
This is problematic because it prevents a lot of design arrangements to work in the expected manner, and it’s quite often very hard to come up with designs that would. In my example above, the hidden group is a DropArea, enabling users to rearrange rows by dragging and dropping. I can’t make the DropArea visible at all times, this would be a really poor design, and I would lose the visual effect of row “insertion” users are so familiar with…
I don’t recall Bubble’s response at the time. I have found this works much better now than it used to.
Any chance there’s a clever workaround for your scenario. For example, perhaps you have a RG (let’s call it RG1) that loads with content but doesn’t display any of it. Then, another RG (say, RG2) that references RG1’s list of things. This way, you could use RG1 to, essentially, indicate to bubble how many items to load since its cells could be fixed height, and RG2 would reference those things so that they’re not reloaded? …just an idea.
If this or another workarounds works, then great. If not, then I’d submit a bug. I think your instance of collapsing height within it could exacerbate the problem, and on mobile I can see how it’d be particularly problematic.
One solution for Bubble might be to give us the ability to control how many things below the bottom of the screen are loaded within each RG. I know I’d prefer on many pages for RGs to continue loading below the fold so that when a user scrolls the content is already loaded more of the time.
Thanks Scott.
Unfortunately, that workaround wouldn’t work in my case.
I have replicated the issue on a test page for Bubble’s support to investigate.
Setup:
Result (page fully loaded):
Result after scrolling:
