Slashdot Discussion System Updates

This week we have a few new functions for you comment readers guaranteed to amaze and enchant. Or at least to make your day a little more efficient. The biggest update is that the system should remember what comments you've already read (for a few weeks anyway) but there's some other less interesting stuff as well. Hit the link below to read more.

So D2 now remembers what you have read. This will mostly be useful to readers who use the key bindings to navigate -- we didn't really want to guess if you've read something, but if you use the WASD keys to navigate, moving on from a comment flags it as read. Read comments are slightly faded, and if you re-enter a discussion a few hours later, it should remember what you've read.

We've simplified comment retrieval as well. If you get to the 'End' of a discussion and try to get more comments (either by clicking one of the various 'More' links, or by pressing a keybinding like S or D that tells us to move on to the next comment) a dialog box will show up asking you if you would like to lower your threshold. So if you normally read at Score:4, and read to the end of the Score:4 comments, it will offer to lower your threshold to Score:3 either for all time, or just for this page. This means you don't need to constantly raise and lower your threshold to handle discussions of different sizes. This works really nicely.

Lastly is a user preference in the pref pane labeled 'Collapse Comments After Reading.' I'm actually considering making this one on by default but I'm open to feedback. It does what it says -- after you've navigated off a comment (using the keybindings again), it collapses the comment you just left. This makes it very easy to keep your place in a discussion as it grows. This is especially useful in discussions where you want to leave a tab open for several hours, or else come back later and figure out what's new.

There are undoubtedly bugs: feel free to email me or post them to the bug tracker. Thanks to pudge for hacking all this stuff too. Especially the bugs -- he wrote those first.

Comments

Re:Display bugs

[Blakey Rat]

I posted a whole bunch of display bugs to Slashdot's tracker:

http://blakeyrat.com/bugs/

Nobody's done jack about any of them. In addition, the one bug that *was* resolved was only confirmed and resolved for the "D2" discussion system, even though I filed it for the original discussion system. (I have no idea if the fix worked for both; the example thread I have in the bug report seems not to work.)

Anyway, like open source projects, Slashdot isn't actually interested in reading or fixing bugs. Don't bother.

You guys have blown it completely

[cjames53]

You guys have completely lost track of every web usability lesson. This "improved" navigation is a perfect example of geeks gone wild, of an open source project run by a bunch of programmers with no idea what usability even means. Slashdot now has a "user interface" that is completely at odds with every standard on the web. This is so counterintuitive it's unbelievable. The idea that you should "RTFM" is boneheaded. The comments you're getting in this thread are ALL FROM PEOPLE WHO HAVE FIGURED OUT YOUR NON-STANDARD INTERFACE. Normal web users may be trying to read this, but they'd quickly become frustrated and depart, their comments unheard. Do you guys even read Jacobsen? Do you even know what a hyperlink is? The web has standards, boys. Get used to it. Work with it. But don't invent your own.

Re:Display bugs

[mikesd81]

And what kind of bugs are you submitting? Keep in mind big projects get alot of bug sumissions. Did you do the research and see if it's a dupe? Is it a security bug, they'll probably get looked @ first. Then they'll look if it's cosmetic or functioning. You're the one that attacked OSS, so I figured you're a MS fan boy. If I'm wrong then I'm wrong. Most open source programs, except for big ones like DEs and distros or office programs, etc, most developers aren't getting paid to make and are writing them in their spare time. I don't know what your profession is or what bugs you actually submitted or to what projects, but when submitting a bug, evaluate how important it is, to everyone, not just you, and set your expectations. If you can code, then submit a patch.

Re:Require Downmodders to Justify

[Doc Ruby]

Metamods could use more info when they metamod. These justifications would do that, even on top of their deterrent effect on people who won't do them (and who then can't downmod).