I have no idea why this user-hostile functionality is present by default. It breaks ctrl+F, ctrl+S, the scrollbar, and loads of other browser functionality.
In a paginated thread, you can only Ctrl-F for stuff on the current page, and Discourse is no different; it's no more "broken" than a traditional paginated forum with manual page turning. Similarly, you can only Ctrl-S to save the current page, not the whole thread.
Many forums have a "search in this thread" feature, and Discourse does, too. In fact, if you click in the page and press Ctrl-F, it intercepts the keystroke and shows Discourse's "search in thread" search box; some forums with manual page turning do the same thing.
Some people seem to get really pissed off at automatic page turning; I kinda understand why, but there are clear arguments for automatic page turning. Why make the user click "Next Page" when the software could do it for you? You'll notice that all of the most popular feed-based sites (Facebook, Twitter, Pinterest, Instagram) use automatic page turning, too, and that's because experiments show that people engage more when automatic page turning is enabled.
None of this will make you any happier with APT, but hopefully it will annoy you slightly less to know that this is a data-driven decision and not done specifically to annoy you.
Here's a thread with 970 comments for example:
I guess I usually simply stop scrolling before I get to the very bottom of HN.
Just to be clear though, are we talking about a "next" link at the bottom of the page, or Reddit-style "continue" links for subtrees of comments beyond a certain depth?
Also this 4MB number isn't correct; I count 700kb. Feel free to double check my work:
Jeff, I respect you, but I don't understand where you are going with that comeback.
Namely, even with bloody awful markdown, HN still delivers 1000 comments in 1/4 of the bytes.
Another interesting idea, as almost everyone doesn't actually comment, wouldn't it make more sense to load the editor javascript dynamically? As far as I know, the silent majority read comments but never reply. In fact, I vaguely remember Jeff even having a blog post that most people never participate, they just consume (could be wrong!).
Also, I haven't kept up with it, but mobile browsers used to have fairly aggressive cache invalidation to save space on the phone, so serving big chunks of JavaScript in the hope it might get reused one day wasn't actually a great idea.
Are you sure this is correct? I count 700kb of total content (including the actual HTML and CSS), not 4mb, so I think your comments are premised on a number that's off by almost 6X?
So how you feel about this depends on "how often you use the app". If you only plan to visit that one page, ever, then it's not a great tradeoff (though 700kb -- no idea where you are getting 4MB from -- of images is basically nothing on a webpage these days). If you visit many discussions and many pages, it's a win.
In other words a single discussion doesn't need 4000 comments, you just need to read 4000 comments across all discussions all time. I'm not sure your math is correct here, either: I just visited meta.discourse.org in incognito mode and I see about.. 700kb of javascript?
I'm sorry but I don't know where you are getting 4 megabytes out of 700kb. See above screenshot.
Answering Macha, below:
- Your chosen example is missing http/2 so requests aren't batched
- Discourse homepage by default shows user avatars for each participant, up to 5 in each topic, so there will be "more images"
I suggest testing with meta.discourse.org (hosted) or discourse.codinghorror.com (self-hosted) to make sure you're looking at apples to apples, and properly configured sites.
72 requests, 50s load time, 3.5mb data. It would have been smaller if you'd served the screenshot of the page.
HN for comparison:
6 requests, 50kb, 0.72s
Now how about your contemporary forum competition.
Here's a Xenforo forum:
http://i.imgur.com/tlzZ5WN.png
19 requests, 2mb, 5s
And that's with the massive background image you can see, which is 1mb in size by itself.
EDIT:
Since Jeff stated the comparisons weren't apples to apples, xenforo.com/community vs meta.discourse.org . Both boards running in basically stock configuration from their own sites:
* Xenforo.com: 43 requests, 1.4mb, 4s
* meta.discourse.org: 73 requests: 3.2mb, 4.5s
Definitely a better showing than the ACEO forums, but still loses the comparison.
Too lazy to take more screenshots, but reddit is 50 requests, 1.3mb, 3s for comparison.
I'm unclear where you are getting 3.2MB from, since sorting by filesize, here are the largest network requests at meta.discourse.org:
As you can see, starting at 11.5kb and below it's all images (avatars).
I suppose you could try with images disabled. If you want to make a case that 'not showing avatars by default uses less bandwidth', then I guess I can agree with that. But these images won't affect actual load time, as images rez in later, and all the dimensions are set on the page.
Regarding the 4mb thing, I pulled it out of 1wd's comment. It would be best if 1wd came back and explained. That said, I believe the discrepancy is probably between the size of compressed javascript in the network and it's uncompressed size. Firefox dev tools show 3.1mb for meta.discourse.org. I don't know how to view the total size in Chrome's dev tools, but if you click the "use large request rows" in the Network tab you will see that application.js by itself takes up 1.5mb.
This brought me to thinking why browsers still save page as source code and not as serialised actual DOM? I mean developers still could use curl to save source code, but regular users will save what they see on the screen, similarly to printing to PDF.
I know this because I once saved a JS-heavy page and when I loaded it back into the browser, I discovered the JS-generated menus were already present in the source and were re-generated by the JS each time the page loaded.
yes, regenerated because js files are also stored. So the menu generating functions and all constants needed to generate menus were probably present in downloaded js files. But imagine, site that is also fetching data via ajax and render that data somehow. When you save and then reopen saved page, you might not get exact state as you were in time of saving. There are many reason why state would be different (you could be logged off, etc...) So if you send saved page to somebody, he/she will see different state of page than you. All of this could be eliminated if browsers saved state of DOM instead of page source code (and js,css resources).
I don't think it's the case that I and other users don't know what we want. I do believe that "people engage more" on infinite-scroll-style pages, but I have no reason to believe this makes them happier or more productive. On the other hand, the jerkiness/glitches, breakage of common navigational tools, and slowness of Discourse pages are very annoying.
I should have been more descriptive than simply saying "broken", but I figured I was probably preaching to the choir and so I didn't go into details. In particular, it becomes much harder to use tools like ctrl+F and ctrl+S because the page content is dynamic and after scrolling down a little there's no way to easily tell which bits of the page are still loaded and which aren't. ctrl+F is useful not just for initially locating a key phrase, but also for jumping between bits of the page you've already read for comparison. In a manually-paginated thread this works fine, and I know for sure whether posts are on the same page (where I can use ctrl+F) or different pages (which I can open in separate tabs).
Basically, it becomes very difficult for a user to maintain an accurate mental model of the page content that they're using a browser to interact with. This is quite different from static pagination systems, where scrolling never changes page contents.
The scrollbar really is broken, because users expect its size to show the length of the page, which no longer holds for Discourse or other infinite-scroll pages. The fact that Discourse unloads earlier content makes this even worse, as you can't even remember an old scrollbar position to scroll to something you just saw or scroll halfway to the top to go halfway to the start of the page. Yes, Discourse does provide an alternative way to see some of this information, but user interface changes (having to move from the native scrollbar to the Discourse summary box) are frustrating for users: they break muscle memory and require learning a new interface, since they never work quite the same as the other one.
It makes me no less upset to hear that data was involved in the decision to ignore users' needs. I don't think it's intentional to annoy users, but hearing that there was some level of analysis involved rather than mere accident is upsetting because it shows the slight to be willful. I don't think websites should push worsened usability on their users in the name of driving up engagement metrics.
I think the arguments about automatic vs. manual page turning mostly come down to questions of control and implementation quality: users want to be in control (because the computer is a tool, and tools must be predictable), and it's difficult to avoid bugs when implementing automatic page turning on the Web. I'm not sure exactly why the latter is the case, but I've never seen a system without glitches in the history list, visual glitches, or slowness.
He appears to have accepted your statement without hostility and provided a fair reply. Please be careful not to interpret the lack of a pandering tone or excessive niceties as condescension. Remember, project runners hear complaints all day every day, they're never going to be able to make everyone happy, and this is a technical audience.
I can read "War and Peace" [1] as an HTML document on my 7 year old cheapo Android phone. The browser even "streams" the data, displaying each chunk as it loads over a slow connection.
As far as I know, you're correct that all forum software I've used paginates large threads, but I'm curious if they "have" to - as in, I think a team could probably build forum software that didn't paginate large threads (for reasonable definitions of "large") and still have good performance on a wide range of devices, if they were willing to make the necessary trade-offs. Whether those trade-offs are worth making, I don't know.
You can get and read War and Peace (or other similarly large books -- I frequently reference Adam Smith's Wealth of Nations) at Project Gutenberg. As a single HTML file.
The ability to search for any particular text instance within that document through browser capabilities is useful.
As is, I agree at times, the ability to present the information as some sort of consistently paginated context.
I'm thinking that somewhere between the 21st and 42nd centuries, computers might advance to a state where this is in fact possible.
I suppose you're going to respond with something along the lines of "because it's better than the browser's search function".
But again: why is that?
Why do the built-in browser tools suck as badly as they do?
Example, outside of search: I realised some months back that a chief reason we have browser Reader Mode features, to uncrappify crappy site CSS, is because browser default styling ... is so horrible.
And again: why is that?
Why do we have craptastic CSS entity defaults when, with a very little work, every page could look, without any styling at all, pretty damned readable:
http://codepen.io/dredmorbius/full/KpMqqB/
(And if that's not your cuppa, then themes such that you get what you want -- Night Mode, or whateves.)
Whatever browsers are being built for, it's not the people actually using them.
/me looks suspiciously at Chrome => Google => Advertising....
Gee... I wonder why that might possibly be.
Again: why is cabapility-in-the-browser so impossible to provide?
Why isn't "search post" vs. "search comments" something scoped into a browser? If comments are a ... not entirely novel or unknown concept within Web design and activity, why are the abilities, say, to have browser-generated lists of authors, or search by author, or post/comment distinctions, or persistent reputations of commentators so that I can tell if @dredmorbius@news.ycombinator.com is just an asshat or a space alien cat who really knows where his towel is (and independent of whether or not dredmorbius maps to any particular known "real name")?
It's not like the question's just come up within the past 5 hours.
Really: Why is the browser so fucking limited in this regard?
Even Chrome on my i7 doesn't instantly respond when loading those Gutenburg URLs.
I already knew where the post was, because I scrolled down to it. I don't need to be told where it was, I need to know where the specific phrase I searched for is.
I've seen complaints about it from the past, but given that 3 years has passed and it's still like that, I just give up any hope of being productive when having to use a Discourse site.
StackOverflow has such a nice UI and UX. The UI is nice in Discourse too, but its UX needs more work. Bigger forums are hard to follow, infinite scroll comes with its own problems. The themes waste too much screen space.
Post counts: a metric for how long they have been here, also an attempt to let new members know if this person knows what they are talking about. Yes, post count is a poor metric for level of knowledge, but measuring level of knowledge is not an easy problem(see controversy over IQ tests). Displaying upvotes could be better, but see reddit where people post the same dumb jokes to farm karma, or steal jokes from other subs.
Signatures: People like to express themselves. I'm not a fan of this one either, but hey. It can be useful when you see someone say something intelligent/helpful/etc, and their signature has a list of threads they started. You might find those threads filled with useful info.
Badges: This encourages desirable behavior. It can also help identify those who have a high level of knowledge.
I would add avatars: Have you every heard someone say they can remember faces, but not names? This is an attempt to help members identify each other.
Edit: post metadata: seeing the number of upvotes on a post gives you an idea on whether it is true or not.
This itself causes some issues (like with spammers joining simply for the 'SEO' benefits), but it's enough of a pattern that changing it will often kill a forum dead, especially in the webmaster/tech/marketing field.
Other things that encourage members (but that are often seen as clutter) include reputation systems (like the green bars vBulletin had), forum cash (points given for posts and other actions), fictional shop items (purchased with said forum cash), etc. Again, a lot of people on these forums rather like said systems and often find them useful, even if to an outsider that might be seen as overwhelming.
http://wiki.c2.com/?SecondSystemEffect
(C2's new design is a bit of that in itself, IMHO.)
Unfortunately, they blew it. They created an over-engineered, over-complicated, bloated, heavy mess. Jeff bet on Moore's Law meaning that bandwidth/speed would eventually negate the bloat, but instead the world moved to low powered devices with mobile bandwidth.
They've spent years trying to get infinite scrolling working OK and installation OK. Why? Imagine if they'd actually used all their brainpower on features that forum owners actually wanted: automated spam tools, automated admin tasks, one-click install to any hosting plan (yes using PHP if necessary).
All the years of wasted talent, and now the other forum products have overtaken them on usability/maintainability. And they are STILL trying to fix the hijacked browser search feature, that you get lost in infinite scroll, and that you need to run a separate VM to run something as simple as forum software.
LESSON: beware second-system-syndrome, beware the CEO who has personal tech vendetas which are misaligned with your product strategy, and beware creating a team consisting solely of talented engineers who will do one thing: OVER-ENGINEER.
We're supposed to be building software with the users, while observing them, while participating alongside. This takes a few years to get right.
No plan survives contact with users, and that's as it should be.
I ran my own Discourse forum for a while. Users liked it well enough, but eventually I switched to using the free Steam community forums (it was a forum for a game) because it was costing me every month to run a separate server for it on Amazon.
During Discourse's life it also changed recommended install methods and auto-updates would occasionally break, so it was work to maintain. To be fair a lot of this was on relatively early versions.
I also found the Ctrl-F breaking and infinite scroll much more annoying than useful and tried to tell them[1] along with others. They listened somewhat and switched to only taking over Ctrl-F on long pages, but it's still not great. In fact I just tried to Ctrl-F for my post on the page I linked and got taken to my profile page instead.
[1] https://meta.discourse.org/t/discourse-taking-over-ctrl-f/16...
My instinct when I'm looking for something is to Ctrl+F, not scour the UI for a search bar.
Anecdotally, I know people who are not programmers who are the same way.
Maybe a better compromise would be including a modal or a hint highlighting the site-wide search box without suppressing the native Ctrl+F functionality.
Imagine Jimmy wants to know how to pin a topic on a Discourse forum. He searches Google for pin topic discourse or whatever, and he sees a result with a text preview saying "...icon in the upper right to get the staff menu for the topic; select Pin Topic."
That looks right, so he ends up here: http://www.phylobabble.org/t/discourse-admin-quick-start-gui...
That's a big post, so he Ctrl-F searches for "pin topic". Normally his browser would already be highlighting the text in the post, but nothing happens, so he tries clicking on the only result. This just refreshes the page and puts him back at the same post.
At this point Jimmy either leaves the forum to try another result that doesn't hijack his browser search, combs the whole thread manually, or mashes Ctrf-F enough that he discovers the Ctrl-F-F override and types "pin topic" again, instantly highlighting the section that he wanted all along.
Perhaps that's an option should you choose to self-host again? :-)
> one-click install to any hosting plan (yes using PHP if necessary).
Breaches on popular PHP forum software account for a disproportionate amount of the breaches we regularly hear about. It's caused issues for Linux Mint, Ubuntu, and the "Cosbycoin" compromise is hard to forget. I can't complain about any particular vendor because they have all had their share of issues in this space.
Yes, you can write good PHP - but start saying "one click on any hosting plan" and suddenly composer is out the door, every file is owned by the user the web servers runs as and you start pollyfilling for ancient versions. It means you can't assume SSL will exist, it means you can't get updates using git or any sane automation strategy, and look at how Wordpress deals with cron.
Wordpress is regularly lambasted for their support of ancient versions of PHP, which is something they do primarily to meet this goal.
In interested in what other options are out there. I rarely see Discourse on the open Internet and I cringe every time I get tempted to sign up to an old SMF or vBulletin installation.
Questions about feature priorities or technical architecture were met tersely and with a demand to know what kind of software I had ever built personally. So he wanted my resume rather that just discussing the merits of whatever topic.
Wasn't going to mention it but somehow your comment seemed to click.
Not sure what you mean about a tech vendetta, sounds like the tail end of a story.
"I’ve started to research Discourse as a general solution and started with embed capabilities. To be frank the whole situation seems to be a bit of a mess."
To be frank, I would describe what you posted more as rants than actual discussions about features. You wanted Disqus and were pretty rude about it. That's not what we're building at Discourse. If you have a problem with that, sorry.
seems apt, lol
https://meta.discourse.org/t/embed-discourse-comments-with-o...
I fully acknowledged the difficulty of your task, and tried to break down feed back into specific, actionable items.
Getting constructive criticism is not always fun, but it's part of our job. Besides that some people posting there are potential customers. Why call them ranters instead of a simple, we agree to disagree?
If I know something useful is on page 10... well I'm just out of luck.
>At least with numbered pagination you can choose to view page [whatever] to narrow down the posts you want to view
Assuming you mean sequentially, isn't this the same as scrolling but with a click involved? If you don't mean sequentially, how would you know which page to click?
>If I know something useful is on page 10...
How do you know something useful is on page 10? Is it normal for forum users to remember specific page numbers within a post?
I also like page sizes as "breaks" to follow up on links etc.
Discourse's implementation of infinite scroll isn't all that bad (it keeps position properly and doesn't seem to have strange glitches, although I haven't tried it on a bad connection), and at least navigation elements are there. But they feel strange and trip me up every time: the secondary "scroll bar", or in thinner browser windows the "progress bar" at the bottom that overlays the post content and you have to click to get the scroll bar pop up. It feels like a mobile app, half-way designed for touch, not a forum.