So, after a little cogitation whilst cutting the grass, a few more more-or-less related thoughts.
I really, really, really don't like infinite scrolling as a way of reading a thread, even if you could somehow make it magically work "properly" without having to reimplement half a browser in a half-assed way using javascript to do it (and still end up with a totally WTF solution). It's also extremely "faddy" and I suspect that once the newness and coolness of "infinite scrolling is ther besterest" appeal of slapping it everywhere has gone away your product is going to look very dated.
That said, as a way of navigating a thread list, however, it's great. Right tools for the right jobs and all that.
Now, you are opposed to "traditional" or "dumb" paging for reading, and as far as I can tell, that's because it adds no semantic information. I can totally get on board with that. However, as far as I can tell, infinite scrolling doesn't do any better in that respect. Indeed, once you get to a longer thread, it's an active hindrance to reading, at least for me. See also Lorne's posts regarding the "wall of text" aspect, and, of course, ignore the irony that this post is becoming an unreadable wall of text itself...
So, what would be better in semantic terms than paging, and more readable than infinite scrolling?
My absolute criteria would be:
- You absolutely must not break the browser's OS integration. Any current browser's OS integration. The scrollbar must work as expected, integrated search must work as expected, back button must work as expected without shitting over history ... <expand list as required to cover all the other subtle ways in which Discourse currently breaks the browser>
- The view of a single thread or part of it must be digestible.
- How the thread is split must be easily understandable by the person reading.
- You've gotta provide some easy way of distinguishing what's been read from what's not been read.
- You absolutely must cater for those who are using screenreaders and the like.
There's also a few very nice to haves:
- It should work functionally on all current browsers and most past ones. That means (largely) making the googlebot view functional enough that those with (for example) low-bandwidth phone connections to use without eating their bandwidth quota.
- It should work functionally on low-powered devices. The future appears to be aiming for "more from less", and a website shouldn't thrash something like my development box.
- For the love of god, it should work without Javascript. Remember the web when it was all goddamned flash? That's what Javascript is becoming. A good deign ethic is "If it doesn't work with Lynx, it's doesn't work period".
So, what metadata do you have?
You have the "posted in reply to" information; that gives you a tree structure. You also have "quoted text from this post" information, which pulls the tree into a crosslinked webby sort of thing. You have authors, from which it would be possible to identify (possibly) back-and-forth arguments, stuff being expounded upon by people I like, and so on (although I'm personally of the opinion that stuff like "friend / enemy" lists merely encourage confirmation bias). Like counts, and information on who liked what. And, finally, you have the words themselves, from which you could potentially extract some sort of "tag cloud".
As an aside, for keeping stuff ontopic, the "+ Reply" and current implementation of "⤺ Reply" buttons are your worst enemy. The first generates a context-free reply to "the thread" rather than any particular post, but places it under the first comment, and the second doesn't go to the lengths of quoting the text; I can hit any one and type random shit with no cognitive dissonnance, if there was quoted text like on every forum software everywhere forever, it might make me think a bit if I really meant to do what I just did.
Maybe more later.