MyBB Community Forums

With newer forums removing pages in favor of loading posts as you scroll, it would become increasingly important to keep track of a users last read post in a thread.  

The question is, what would be the best way to do this?  With some forums having hundreds of thousands of posts, and thousands of members that seems like a butt load of data.  

I haven't really seen any forum software which are actually successful which do it.
Please list some big names which are planning on doing this?
Is XenForo planning to remove pagination? phpBB? MyBB? SMF? vB6? IPB?

I know that some really new software are trying to do this as a gimmick (for some reason, there are tons of forks and new forum software wannabes appearing left and right), but as you said.. Many of them don't really think about the advantages of pagination like keeping track of where you've read up-to and end up having to implement something which would normally be handled by the browser.

Most of the time, they tend to just think.. Ooh, shiny! with endless scrolling, and they implement it without really thinking about the consequences. One of the main reasons for this is due to them having no hope of competing with existing software, as it would take a very long time for them to have the same number of features.

(2014-10-25, 03:12 AM)Axareal Wrote: [ -> ]I haven't really seen any forum software which are actually successful which do it.
Please list some big names which are planning on doing this?
Is XenForo planning to remove pagination? phpBB? MyBB? SMF? vB6? IPB?

I know that some really new software are trying to do this as a gimmick (for some reason, there are tons of forks and new forum software wannabes appearing left and right), but as you said.. Many of them don't really think about the advantages of pagination like keeping track of where you've read up-to and end up having to implement something which would normally be handled by the browser.

Most of the time, they tend to just think.. Ooh, shiny! with endless scrolling, and they implement it without really thinking about the consequences. One of the main reasons for this is due to them having no hope of competing with existing software, as it would take a very long time for them to have the same number of features.

No "Big" names do it yet.  I have my suspicions that all of them may within a couple of years.  Some sooner than others.  And I know of at least one post of one of the MyBB dev's expressing interest in this future, but I suspect it goes much larger than that. NodeBB and Discourse are both growing in number by the day though.  It's only a matter of time before they pass up all of the outdated current big names. Just give them some time to grow.  The names you consider big have been on the block a long time.    

The feature itself is only popping up on all of the other major websites (non forum I guess).  It's becoming the standard on the web.  Facebook. Google+.  Twitter?  Email providers.  Um... Thousands of others.  Of course, if you want to seriously discredit how things are obviously going that's not my problem.

Now, if we can get back to my question please? 

Well, there's only really two ways to do it. Store it on the client side or store it on the server side.
Doing it on the client side would probably do the trick around 90% of the time, whether you do it on the server side comes down to whether your site has the resources to cope with this and whether it's financially feasible.
HTML5 Local Storage comes to mind here. As for the server side, you could throw up a database table for it.

(2014-10-25, 04:11 AM)HolyPhoenix Wrote: [ -> ]

(2014-10-25, 03:12 AM)Axareal Wrote: [ -> ]I haven't really seen any forum software which are actually successful which do it.
Please list some big names which are planning on doing this?
Is XenForo planning to remove pagination? phpBB? MyBB? SMF? vB6? IPB?

I know that some really new software are trying to do this as a gimmick (for some reason, there are tons of forks and new forum software wannabes appearing left and right), but as you said.. Many of them don't really think about the advantages of pagination like keeping track of where you've read up-to and end up having to implement something which would normally be handled by the browser.

Most of the time, they tend to just think.. Ooh, shiny! with endless scrolling, and they implement it without really thinking about the consequences. One of the main reasons for this is due to them having no hope of competing with existing software, as it would take a very long time for them to have the same number of features.

No "Big" names do it yet.  I have my suspicions that all of them may within a couple of years.  Some sooner than others.  And I know of at least one post of one of the MyBB dev's expressing interest in this future, but I suspect it goes much larger than that. NodeBB and Discourse are both growing in number by the day though.  It's only a matter of time before they pass up all of the outdated current big names. Just give them some time to grow.  The names you consider big have been on the block a long time.    

The feature itself is only popping up on all of the other major websites (non forum I guess).  It's becoming the standard on the web.  Facebook. Google+.  Twitter?  Email providers.  Um... Thousands of others.  Of course, if you want to seriously discredit how things are obviously going that's not my problem.

Now, if we can get back to my question please? 

To be fair, I have much bigger problems with NodeBB and Discourse than their implementation of endless scrolling, although that's not really relevant to this discussion.
What is relevant is that they implemented endless scrolling without implementing things like this before hand, and now it's become an afterthought.

Growing in number by the day? It'll grow in size to whatever size and then, it'll stop there. Rapid growth in the beginning and stabilization later on isn't really unusual for a new niche.
The only thing which has continued to show rapid growth for a long time is Wordpress. In Wordpress' case, it's due to it's ability to be used as a CMS which you can slap onto just about any site for little to no effort.

Only a matter of time before they pass the outdated big names? The only reason that the big names aren't growing is since not everyone wants to run a forum. Running a forum is a lot of work, compared to something like say.. A blog. Sure, they're growing faster relative to the big names, but the forum market itself isn't exactly growing, so the big names aren't going to be getting any new market-share without cannibalizing each other.

Most of these "modern features" like like buttons, alerts, mentions, etc. which make the big names "outdated" can be added within 15 minutes with a few plugins.
At the end of the day, there's not really much that the big names are missing.
I know that people go around saying how forums are doomed and how forum software are backwards.. But, taking over market-share based on features which I can throw on via a quick trip to MyBB's mods site? That's a non-issue.
That leaves endless scrolling which is controversial in itself, depending on the community.

Let's find an example of a new major version from a big name. One which hasn't been released yet. How about.. IPB4.
Right off the bat I can see.. What's this.. Pagination.
A major version would have surely been the perfect opportunity to try pulling off a major shift like what you suggest.

As for the social networks, most of the information on them is junk. You're not going to be searching through endless feeds on a social network for a hint of gold. You'll just see whatever messages whenever they pop-up and you won't really care about messages posted in the past. Even if you do care, there's no hope of finding a Tweet from three months ago without tons of digging. On a forum, I will usually find much more useful information and I can actually sit there reading through topics.

(2014-10-25, 04:47 AM)Axareal Wrote: [ -> ]Well, there's only really two ways to do it. Store it on the client side or store it on the server side.
Doing it on the client side would probably do the trick around 90% of the time, whether you do it on the server side comes down to whether your site has the resources to cope with this and whether it's financially feasible.
HTML5 Local Storage comes to mind here. As for the server side, you could throw up a database table for it.

I wouldn't consider client-side an option for this at all. I have a computer, laptop and a phone, having each of these remembering me being at a different point in the thread is pointless.

SMF currently keeps track of the users last-read post in a thread (by page) server-side, it should just be a case of updating the threadsread table to store the time of the last PID on the page instead of the time the user accesses the page. Of course there'd need to be some changes to the handling of that to stop it going backwards if a user views previous pages.

(2014-10-25, 07:38 AM)Cameron:D Wrote: [ -> ]I wouldn't consider client-side an option for this at all. I have a computer, laptop and a phone, having each of these remembering me being at a different point in the thread is pointless.

SMF currently keeps track of the users last-read post in a thread (by page) server-side, it should just be a case of updating the threadsread table to store the time of the last PID on the page instead of the time the user accesses the page. Of course there'd need to be some changes to the handling of that to stop it going backwards if a user views previous pages.

But using a database scares me. Do you know how SMF handles on "less" resourceful servers? Or, am I just being overly fearful of data?

On a side note, it should be possible to make a plugin for this, if people really need it that much.
The fact that plugin authors aren't writing plugins for endless scrolling generally means that there isn't that much demand for a plugin for endless scrolling. If not then, someone would likely pick it up eventually. At the end of the day, it's better to have a core that isn't so bloated.
Granted, it would be a big project, so you would have to be assured that MyBB isn't just going to break it completely with some sort of full rewrite? I'm looking at you here, MyBB 2.0.

Either way, you need pagination for search engines anyway.

(2014-10-25, 03:22 PM)HolyPhoenix Wrote: [ -> ]

(2014-10-25, 07:38 AM)Cameron:D Wrote: [ -> ]I wouldn't consider client-side an option for this at all. I have a computer, laptop and a phone, having each of these remembering me being at a different point in the thread is pointless.

SMF currently keeps track of the users last-read post in a thread (by page) server-side, it should just be a case of updating the threadsread table to store the time of the last PID on the page instead of the time the user accesses the page. Of course there'd need to be some changes to the handling of that to stop it going backwards if a user views previous pages.

But using a database scares me. Do you know how SMF handles on "less" resourceful servers?  Or, am I just being overly fearful of data?

Well, you could dump it to a file, I suppose. It's not like most hosting packages have a shortage of actual space, these days. That would be much slower though.

(2014-10-25, 03:22 PM)HolyPhoenix Wrote: [ -> ]But using a database scares me. Do you know how SMF handles on "less" resourceful servers? Or, am I just being overly fearful of data?

MyBB is also already storing the read state of each thread in the databaseand it already gets updated on each thread view.
The difference between SMF and MyBB is that SMF logs the time of the most recent post on the page and MyBB store the current time. That makes SMF allow you to jump to the most recent page after you last read it, even if you didn't read to the end.

What can be done is you update the last post read each time it loads a new set of posts via ajax. You update it with the last pid loaded. While they may not have technically read all those posts, it will be too server intensive to try and update it after each post gets scrolled past. Innodb would have to be the storage engine for a table if that was how it was going to be handled since it allows for row level locking instead of full table locks that MyISAM uses.

Localstorage for this kind of thing scares me, though as does using the database. If I was developing for myself and not having to distribute, I'd likely just throw a redis instance up and store the user ID, thread ID and last loaded post ID into it. It should be able to handle a large quantity of data and still load quickly enough.