dev.to
uses an infinite scroll to render more articles as a user scrolls through the page, this makes it almost impossible to ever get to the footer of the page. When the navigation bar is dragged down to the footer, it takes only a few milliseconds before new articles are loaded and the footer is no longer in view.
The footer contains some relevant information and hence should be viewable and interactable.
Thanks for the issue! We'll take your request into consideration and follow up if we decide to tackle this issue.
To our amazing contributors: issues labeled type: bug
are always up for grabs, but for feature requests, please wait until we add a ready for dev
before starting to work on it.
To claim an issue to work on, please leave a comment. If you've claimed the issue and need help, please ping @thepracticaldev/oss and we will follow up within 3 business days.
For full info on how to contribute, please check out our contributors guide.
@ludwiczakpawel I know you've talked about infinite scroll, do you want to weigh in on this issue?
By 'weigh in', you mean contribute?
@Gbahdeyboh I would like Paweล's opinion on how we should fix this issue, he is one of our designers and may want to give feedback before we make start implementing something!
I don't want to suggest that we write code for this right away because dev.to is undergoing a lot of design work and this might already be something our design team is thinking about.
I'm pretty sure @ludwiczakpawel has something in the works.
@jacobherrington I totally understand, such decisions are to be made by the design team.
Linking this issue which is related https://github.com/thepracticaldev/dev.to/issues/5670
@Gbahdeyboh
That is correct, we've been thinking about footer and infinite scroll and we came up to conclusion that probably the best scenario would be to stop loading feed items automatically at certain point. Probably one of those two solutions:
Hi @ludwiczakpawel, both look great. I get that you're trying to reduce the number of load more's
that should be clicked, but you also have to consider users who might want to go to the footer after about four or five scrolls. Both allow you click load more just once, so you can only see the footer the first time and not at will. How about this.
I'm more concerned at people being able to access the footer whenever they want rather than just once.
I think having this button only once makes more sense because when you scroll down to the bottom of the page you have one of the two intentions:
I don't think users would be interested in seeing a footer after loading feed items 2 or 3 or 4 times.
We have quite a lot of feed items in our initial batch so I think it would be just enough to see "load more" button but I have nothing against increasing that number a little bit more. Honestly, the "infinite scroll" experience should be seamless enough to not make anyone think that something has been loaded in the background.
I landed myself here after a few frustrating infinite scroll because I want to reach footer but never managed.... maybe I'm old-fashioned but I don't like infinite scroll. I want to take control of my time and what I choose to see. I prefer "load more" button always, and perhaps a progress bar indicating how many are loaded already and how many left. Of course I understand it is impossible if you want to load in an infinite way.
How about this: the first time you will see load more button, and infinite scroll button, and footer. If people click on infinite scroll, they will enter the current mode that dev.to has... if they click on load more, they will always have load more and always can access footer.
@AnnieTaylorCHEN yeap, that's pretty much the approach we want to take (see other comments in this issue) ๐
Sorry to barge in @ludwiczakpawel.
I hope I am not overstepping here, I just have a suggestion.
How about keeping the footer hidden but allowing the user to show it?
For instance, showing a toggle button at the bottom-left / bottom-right corner like this:
Since the feed does not cover the entire page's width, it will not interfere with anything that needs to be visible.
It also allows for the "Load More" button to be implemented in either of the proposed ways.
1- Footer never shows on its own:
2- Footer is shown before the first "load more" click:
Also, it is possible to turn off the "Show Footer" toggle any time it was on and the user scrolled down again or loaded some more feed (assuming the user showed the footer after at least 1 feed batch loading).
Sorry to barge in @ludwiczakpawel. I hope I am not overstepping here, I just have a suggestion.
@JulianBroudy All good, I really appreciate all suggestions and ideas :) It's open source world!
Anyway, I think any of these two proposed ideas would be nice addition (I'm probably leaning towards 1st idea more). But we still have to figure out stopping the infinite scroll part AND resuming it with "load more" button. But yea, the "show footer" idea is overall pretty neat. I'd personally make some different UI choices here but the concept is good :)
Is this something you'd like to work on?
Is this something you'd like to work on?
Of course! I would love to.
I'd personally make some different UI choices here but the concept is good :)
Absolutely, this was just to illustrate my point as I was short on time.
But we still have to figure out stopping the infinite scroll part AND resuming it with "load more" button
Could you elaborate please?
Could you elaborate please?
So right now we simply load feed items infinitely. If we want user to see the footer at any point, we have to be able to "stop" loading feed items. So that's one thing. Another thing is: once we stopped loading feed items we need to give user a way to continue loading feed items again - so we need "Load more" button then.
Does that make sense?
Does that make sense?
Very much so.
For some clarification, let me paint you a scenario and tell me if I got it right?
If so far so good, then I am unclear whether now, after the footer is shown, should the user be able to load more batches while the footer is shown?
I am asking because I totally agree with what you previously said:
two intentions:
- you wanna keep browsing feed cards.
- or you wanna get to the footer.
So to me, it seems that if the user wants to continue browsing, there is no point in keeping the footer visible.
I am thinking we could alter the "Show footer" text to "Keep loading feeds" once it is ON. Then, clicking "Keep loading feeds" would re-hide the footer, change it back to "Show footer" and load next batch?
Did I understand your intentions correctly? What do you think?
- The user enters the feed, "Show footer" button is visible at the bottom-right corner (correct?).
I think the "Show footer" button should show up once you scroll to the bottom (to the point where we load another batch of feed items for the first time). You won't want to see footer _that_ often so I guess there's no need to make it a permanently visible button.
- The user clicks "Show footer", page scrolls to the bottom of the page and shows the footer without loading the next batch.
It should then also hide the "Show footer" button and append "Load more" button at the end of the feed.
Does that make more sense?
Does that make more sense?
It does, thank you for that.
I am still unclear what happens after clicking the "Load more".
The new batch is loaded and once the user scrolls down again then what? Do new batches always load or do we keep showing "Load more" for every new batch? What if the user loaded some batches then decided he needs the footer?
After clicking "Load more" we should probably just get back to default behavior: we load another batch of feed items, user scrolls down, another batch is loaded and button shows up, user scrolls down, another batch is loaded. In other words: behave like user has never clicked that "show footer" button...
(Thanks for all the questions and discussion - I really appreciate it, especially we haven't had this flow figured out earlier and I'm literally thinking through it while typing answers here :))
(Thanks for all the questions and discussion - I really appreciate it, especially we haven't had this flow figured out earlier and I'm literally thinking through it while typing answers here :))
Of course, I'm just hoping I'm not asking too many of those.
This would actually be my first official contribution if I end up taking it. So I might need some pointers if that's Ok.
That's alright :) I'm sure all folks here at DEV will be happy to help :) Would you like me to assign you to this issue?
Would you like me to assign you to this issue?
I would like that very much thank you.
Thank you.
Does this mean I can go for it or are there any prior procedures other than reading the full Contributor's Guide?
All yours @JulianBroudy. Go for it. ๐
Hey @JulianBroudy it seems we've started an ongoing discussion internally about infinite scroll and how it should behave with the footer itself. Could you please put this one on hold for now? I'll get back to you ASAP once we have some agreement internally. I really apologize for that - we had folks starting a debate about what should be the solution/flow literally few minutes after I've assigned you to this issue...
๐๐
@ludwiczakpawel hi again, just checking in...
Hey @JulianBroudy I'm extremely sorry for getting back to you so late :/ No good excuse for that, but we've been having an ongoing internal debate about it and also things derailed for us because of series of events and other priorities on the plate. Nevertheless I should have get back to you much much earlier. So once again - I'm very sorry for that..
In terms of the issue itself, it seems like we don't have a green light for this. Infinite scroll is bad and good at the same time. Bad because it's obviously much harder to get to the footer. And good because it does help with content discovery and engagement.
We had a pretty nice idea to add a button "show footer" instead of disabling infinite scroll right away but that also caused the debate internally whether or not adding another sticky element to the interface is a good idea.
It does seem like we want to step away from Infinite Scroll one day but we need better "alternative" rather than just "Load more" button - alongside this button we'd probably want to show some more stuff to discover content (links to tags, etc). But we don't have that figured out just yet.
That being said, we unfortunately have to put this one on hold until we figure out what we really want there as alternative. And we do need an alternative right away so we can partially fill the potential gap in numbers after turning off the infinite scroll.
@ludwiczakpawel Thank you for your detailed answer.
If I understood correctly, this is currently more of an internal debate and there isn't much I can offer on my side.
If anything changes, please feel free to fill me in and I will do my best to help out whether it's with brainstorming or actual implementation.
That is correct, yes. and thanks so much for your understanding! ill definitely keep you posted when we figure things out on our end.
What is the downside to just having a 'load more posts' button?
https://codepen.io/perpetual-education/pen/JjXygRw?editors=0100
We've never seen a precedent for toggling the footer in a website before.
@perpetual-education the downside is it could potentially decrease the engagement. Infinite scroll is kinda "addictive" in a good way and it definitely does a good job for our numbers (you know, at the end of the day - business is business :D).
Makes sense! Except that it's possible that we'll never see the "listings" - so, it feels like there no point in buying credits for anything - which seem like part of that 'business.' We're happy to hear your honest reasoning. If you could find a way to clearly address everything that is in the footer - _somewhere else_, then - in theory - you wouldn't need a footer at all. That is another way to solve the problem. Good luck! We'll be curious to watch as things unfold. : )
Except that it's possible that we'll never see the "listings"
@perpetual-education what do you mean here? Listings appear on the top of the right sidebar (as its own "widget") as well as link in the main navigation in the left sidebar.
If you could find a way to clearly address everything that is in the footer - somewhere else, then - in theory - you wouldn't need a footer at all
We're actually working on a proof of concept that would kinda remove the footer on views with infinite scroll and put its content somewhere else... But that's still pretty far on roadmap :)
Our feedback would be that _we_ couldn't find it. (It's there) - but we couldn't find it / and there isn't much of a story told about the things in that widget. So, throughout or time surfing around - we've found pages and resource types that we didn't know existed and didn't seem to be in any menus. Things are folded up / and maybe they just blend in with the 'tag's and stuff. In cases like that, it seem to be a go-to/convention to look for a footer with a site-map to help explain how things are organized. In our case - we couldn't get to a footer. We're not trying to be argumentative. We just want to share our 'experience' as users. Besides the main feed and some filtering, the goals of the other things are a little unclear for us. Carry on! : )
@perpetual-education gotcha, that makes perfect sense and thank you for that feedback - I really appreciate it!
We definitely gonna address that issue in one way or another we just don't know exactly how yet. Information Architecture as well as how we present our navigation and things you can do on Forem/DEV is pretty important - no doubts about that. So please bear with us and keep sharing the feedback :) We just haven't had enough time and resources to put enough attention to these things. YET. :)
so this is being hold, right?
for later visitors, I'll sum up above debates.
Problem : User can't see footer on main page because infinite scroll feature keeps bringing older contents in.
Solutions until now :
1) add 'show footer' button to toggle or disable infinite scroll feature.
2) add 'load more' button instead of voluntary infinite scrolling.
3) move footer's contents to other position then remove footer. (ex. facebook)
Current status : holding because internal design team are debating about this issue (of course this is heavily design stuff). Besides, some other tasks are so poured that the conclusions keep postponed.
--
Just my two cents : if user keeps scrolling down without a single glimpse -- for example, keep pressing PgDn
key -- it'd better stop load posts because it might mean that (1) User doesn't care what showed up, (2) User want to see footer, (3) User just want to consume dev.to's network traffic! ๐
So, this makes sense in some way : "If 5 'load content events' are fired in 5 seconds, stop the events and show User a 'load more' button. If the User clicked the button, no more restriction. just... leave them do that, all day." This only one chance to see footer feels like easter-egg, fun, but not intuitive....
Just my flash idea :)
@roeniss everything you mentioned above is correct! Thanks for summary. We will get back to this when we have better solution in house and more resources :)
I like the idea of the "show footer" button... but I feel like it could be stylized a lot better with the label as "โ scrolling" with a material switch. Or maybe instead, the โ could be crossed out with a universal no when infinite scrolling is turned off. Might be a little more elegant. I don't have a mock-up so I'm not quite sure.
Note that I was trying to find the github repo to suggest this (since I know dev.to is open source), and I was trying to get to the footer, only to be frustrated by the fact that I couldn't get to the footer because of the infinite scrolling.
So, this makes sense in some way : "If 5 'load content events' are fired in 5 seconds, stop the events and show User a 'load more' button. If the User clicked the button, no more restriction. just... leave them do that, all day." This only one chance to see footer feels like easter-egg, fun, but not intuitive....
I really like this idea too.
Dropping in to say that I ran into this issue today (I was actually looking to find my way to this GitHub to browse issues).
Reading through the earlier comments, I don't believe I've seen this proposal:
This would let the user get to the footer in the expected way, and get additional content in the expected way, however, I think this requires the footer to be pretty minimal to prevent this behavior from being annoying.
@dev-dull let's see a prototype.
@sheriffderek Ah! That was a good exercise. It revealed to me the issue of the footer that's constantly trying to pop up and disappear as I scroll. I'll go sit in my backend dev corner now ๐
Most helpful comment
so this is being hold, right?
for later visitors, I'll sum up above debates.
Problem : User can't see footer on main page because infinite scroll feature keeps bringing older contents in.
Solutions until now :
1) add 'show footer' button to toggle or disable infinite scroll feature.
2) add 'load more' button instead of voluntary infinite scrolling.
3) move footer's contents to other position then remove footer. (ex. facebook)
Current status : holding because internal design team are debating about this issue (of course this is heavily design stuff). Besides, some other tasks are so poured that the conclusions keep postponed.
--
Just my two cents : if user keeps scrolling down without a single glimpse -- for example, keep pressing
PgDn
key -- it'd better stop load posts because it might mean that (1) User doesn't care what showed up, (2) User want to see footer, (3) User just want to consume dev.to's network traffic! ๐So, this makes sense in some way : "If 5 'load content events' are fired in 5 seconds, stop the events and show User a 'load more' button. If the User clicked the button, no more restriction. just... leave them do that, all day." This only one chance to see footer feels like easter-egg, fun, but not intuitive....
Just my flash idea :)