= 27d567bc2d48d9f40e9ccc20ea370b15)
HughRistik comments on Proposed New Features for Less Wrong - Less Wrong
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (169)
Another suggestion: a super-parent feature. Let me explain.
Often I hit a comment from the recent comments feature that turns out to be in the middle of a big discussion. How do I get to the beginning of that discussion, i.e. highest-level parent that the comment is replying to? The default context is only 1 parent comment. I can hit "show more comments above," but I will have to hit it multiple times to get to the top level parent comment in a big discussion. And even after that, it only shows replies to the top level parent that the original comment is in reply to, and you will not be able to see the other comment branches in response to the top level parent, meaning that you don't actually see the whole discussion.
For example, let's say that someone runs into this comment from the recent comments sidebar and clicks it. The reader will now have to hit "show more comments above" 3 times to be able to view the top level parent. Yet to actually see all the replies to the top level parent, they will have to click its "permalink" (notice how many more replies to the top level parent there are that weren't showing as the context of the original comment).
So for a comment at level n, it takes n - 1 additional page views to see the original post that sparked the comment, and all its replies (and this is if you find it off recent comments; if you found it via a permalink from someone else, then you must go through n page views to view the top level parent and all its replies).
There is a way to cheat, and cut things down to two operations, but you have to manually edit the url. If I took the original url from the recent comments and edited the "context" parameter to something ridiculously large, like this, then the context is large enough that it will show me the top level comment, and all I have to do is hit permalink.
Does anyone else often find themselves wanting to easily view the original comment that sparked a reply that they found from the recent comments (or elsewhere)? If so, do you also want to see all the branches of responses, not just the ones that contain the recent comment?
At least, it would be nice to have a link on every post that enlarges the context of a comment to the max, and shows all of its parents. It could also be nice if that link just takes you straight to the super parent / top level comment (whatever you want to call it), and shows all comments in response.
Agreed, such a feature would be desirable.
Actually, the "context" option only goes up to 8; numbers higher than that still only show 8 extra comments. I usually don't hit permalink, since I'm usually only immediately interested in the thread leading directly to the post I'm looking at, but in threads more than 8 comments deep it'd be nice to be able to skip to the top immediately rather than having to add context=8, click permalink, add context=8 to the new URL, click permalink again, and so on an unpredictable-in-advance number of times to finally reach the top of the thread.
This would be nice. But a tree map of a thread, where every comment has its place and connections inside this tree, drawn by lines similar to those used for boxes framing every post - and very clickable - would solve the most. Just hovering above a named node could open or enlarge it.
Navigating through post that way would increase the readability.
As NancyLebovitz has continually hammered, this is a solved problem, and the answer is threaded Usenet news readers.
Do we want an NNTP frontend for LW, then?
I did not mean to say that the software existed in a perfect form, only that the design and separation of concerns exhibited by Usenet was exactly what was needed, and that the nicest news readers had an extremely well-designed interface -- exactly as useable as Thomas's wishlist.
A straight NNTP frontend would be quite nice -- it solves the reading, tree-navigating, and catchup problems. What it leaves unsolved is voting, private messages, and drafts. Of these, I only see the first as critical.
Of the ways to get such a separation of concerns, publishing the database via NNTP seems the easiest to me. It's still nowhere near a trivial "plug these two pieces of code together", of course. I'm not familiar enough with the reddit codebase to know how well it maps to NNTP, and how long it would take. My rough estimate would be a month or two to get something useable from a programmer working full time.
Then we have to figure out how to do voting, which means (a) defining an extension to the NNTP protocol, (b), implementing it on the server, and (c) patching a few clients to use it. This I'd expect to take on the order of a week or two, if everything else was working.
When the Web was born in 1990 or so, most of the discussion on the internet that LW readers would consider interesting or worthwhile occurred on newsgroups. (The other big chunk occurred in mailing lists.) In fact, starting in 1992 and continuing for many years, reading comp.arch and sci.military.moderated was my favorite way to learn about general rationality. (Discussions on those two newsgroups ranged over very many topics, much like discussion here does.)
I would be more enthusiastic about a proposal to add an NNTP interface to LW if the proposal explained why the newsgroups have drastically worsened and most of the interesting and worthwhile discussion now occurs on the web.
Hmm, my thoughts on some down sides of newsgroups.
The lack of someone in control of each newsgroup made many types of change trickier. A newsgroup couldn't add voting buttons as easily as a web forum, for example, they'd need to change a whole lot of newsreader software to do it. Or if you wanted to display a captcha before letting people post. Some types of innovation were easier, because you could add features to a newsreader without needing support from an owner of each newsgroup, but some needed support from the software of both the poster and reader of a message, or for both a poster and moderator.
Links and bookmarks are better on the web - the old browsers with newsgroup support probably handled these well, but you couldn't depend on everyone's software handling them. If you could just follow an nntp link to a post on another newsgroup on another server, that could have allowed the same balance of powers blogs do - the blogger has total control of moderation on their own site, but the expectation is that people don't just stay on one site and all the links make it easy to move between them.
As it was it felt like you had to stay in the same newsgroup if you wanted people to read your stuff. I think this meant you couldn't have much moderation without feeling stifled, and also that newsgroups would grow large without being able to split easily.
Google.
Google's buying dejanews and renaming it Google Groups, you mean?
ADDED. If so, I tend to agree, since Google Groups changed so as to provide effective competition for Yahoo Groups, which changes tended to be at the expense of the health of the newsgroups.
ADDED. In particular, it was in Google's interest to blur the distinction between a global newsgroup and a mailing list run by the Google Groups software, with the result that people who came to the newsgroups through Google tended to get a misleading picture of the newsgroups and how they worked. (E.g., they never formed a model of the client-server architecture. E.g., they never learned that the global newsgroups formed a "global commons" owned or controlled by no one. Since the newsgroups were maintained almost solely through voluntary pro-community efforts, this obscuring of how the newsgroups worked was a loss in the newsgroups ability to govern themselves.)
Actually that wasn't what I meant, although it is possible that was a factor.
I was referring to the fact that Google solved the search problem and so made it far more likely that people would happen across forums that contained subject matter of interest to them. Part of the reason that Google was able to solve the search problem on the web in a way that it was never solved for news groups is that hyperlinking is an integral part of the web and aside of any intrinsic benefits of hyperlinking in the kinds of discussions that often take place on forums, Google recognized that analyzing the graph of links on the web was the key to developing effective search.
Newsgroups died because despite containing a lot of useful material that material was hard to discover for someone searching for information on a particular topic. Web forums have a tendency to draw in new participants who happen across them through a web search intended to answer a specific question of interest to them and discover a community with shared interests.
I agree that that was an important factor in driving worthwhile discussions to the web.
Another important factor is that web client software became ubiquituous whereas news client software had to be downloaded and installed before a person could read the newsgroups unless of course the person relied on a web interface, the most prominent and important one being Google Groups -- but like I just said, Google Groups had serious deficiencies.
I have to chuckle at "the nicest news readers had an extremely well-designed interface". Which news readers do you mean? I mostly used trn and the newsreader in lynx, though I tried slrn, tin, rn, pine, the newsreader in Netscape Communicator and IIRC a text-mode client named nn (but not Emacs GNUS, which I did not have the hardware resources to run). When I stopped using trn, I promised myself I would never again use software with a user interface as badly designed as trn's user interface.
ADDED. My low opinion of trn's user interface does not come from a general dislike of text-mode interfaces. I was a happy user of text-mode emacs and Unix shells for 18 years for example. ADDED. The client-server architecture and general design of the whole newsgroups infrastructure was in contrast well designed, IMHO.
ADDED. And yes, I did make use of the tree diagram in the upper-right corner when using trn.
My preferred usenet reader was slrn, though GNUS was acceptable.
The textmode interfaces were not pretty, but they could be extremely usable. This is not the same as easy to learn to use effectively. But common things were quick. I have never found anything that was as good at selectively browsing large amounts of constantly updating text as slrn. The closest would probably be gmail. gmail encourages you to archive everything, making it no longer visible. slrn autohides every article as you read it. Both make it easy to rewalk the tree of conversation as new messeages arrive.
Speaking of which, LW used to publish an RSS feed for each "post" or "top-level submission," which makes it easy to use an RSS reader to rewalk the tree of comments under that post in basically the same way.
ADDED. A better "place" for me to have "put" this comment would have been as a reply to this feature request though that feature request and the ensuing discussion suggest that people would prefer to use an interface like lesswrong.com/comments/ instead of an RSS reader to meet the need expressed in the feature request.
What do you mean by separation of concerns?
As for "continuously hammered", it's been approximately five posts among hundreds, but it's nice that it's starting to register.
Could be done (even) better, as some things here are already better than elsewhere. I don't think that my suggestion is the best possible. I think that the further technical development of this site is a must.
Fine, adopt the "Usenet news readers", if it fits the best.
I meant not that the we could switch over immediately, but that your suggestion for interface had already been more-or-less implemented in Usenet news readers, and that this separation-of-concerns is the right way to do things.
See my reply to ata.
Time to switch the codebase to LISP! That language is perfect for request to go n nesting levels up. :-)
Seriously, that would be a great feature to have. Maybe not top priority for me personally, but definitely useful.