SoylentNews is people
SoylentNews
Hi there. Martyb again with an update of our progress on issues arising from the site update. (The new comment grouping and display code was necessitated by huge server loads as well as long delays on constructing and returning highly-commented articles.)
First off, please accept my sincere thanks to all of you who made the time to comment in the prior stories and/or engaged us on the #dev channel on IRC. Really! Thank you for your passion and willingness to provide steps to reproduce and ideas for overcoming the issues that have been found.
ACs: If you access the site as an Anonymous Coward, be aware that we have NOT forgotten you. We are still trying to ascertain what features work best for the most people and are holding off changing (and rechanging and...) settings until we have a better idea of what to change those settings to be. So, please speak up on anything that you continue to find problematic and help guide us to making a choice that works the best for the most.
Scrolling Within a Comment: From what I saw in the reports from Monday, one of the key issues had to do with the scrolling within comments. We heard you. Oh, did we ever! Scrolling within comments was quickly removed and replaced by setting a limit on how long a comment could be submitted. This was especially problematic on mobiles and tablets.
Display Modes: Another of the often discussed issues had to do with "Display Mode." This can be set in your preferences (for logged-in users) and ad hoc when you load a story.
Display Mode - Defaults: If, prior to the release you had chosen "Flat", then you were transitioned to "Flat" (Doh!) If you had anything else as your selection for "Display Mode", you were transitioned to "Threaded-TOS". That mode was intended, as best as we were able to do using only CSS, to replicate the behavior previously supported by the old "Threaded" mode. You CAN change this. Many have reported that changing "Threaded-TOS" to "Threaded-TNG" and setting a lower value for "Breakthrough" (in this mode, "Threshold" is ignored) seemed to do the trick.
Display Mode - ad hoc setting: For the ad hoc case, just load the story as you normally would. Below the actual story text and before the comments is a set of controls. If you are having issues with the current default of "Threaded-TOS" click on that text and change it to "Threaded-TNG". if you find you have way too many icons to click in order to read comments, choose a smaller value for Breakthrough (-1 displays all; in this mode Threshold value is ignored).
Spoiler: Another popular topic of discussion was the way the new <spoiler> tag was implemented. We've heard you, but have not as yet decided on a course of action on how to update its functionality... Stay tuned!
*NEW* and/or Dimming: A surprising (to me at least) number of folks had issues with how we flagged old/new comments. For logged-in users, again go to the "Comments" tab of your "preferences" page, scroll down a little, and there are checkboxes that you can toggle:
Highlight New Comments [ ] Highlight new comments with *NEW* tag
Dim Read Comments [ ] Dim already read comments
Please give those a try and see if that works for you. Our first implementation of "Dimming" was a bit too strong for most folk's liking - this has been reduced so as to be less jarring. As for the "*NEW*" text, there were several positive comments that on mobile devices especially, one could quickly search for the text and rapidly navigate comments to find out what was new. There was a suggestion that uppercase-only looks like YELLING. Yes, it does. On the other hand, whatever text is selected for display has to be a reasonably unlikely string to appear in the normal course of reading comments. (False positives, anyone?)
There were some suggestions on changing the color of the comment title to flag it as new. This sounds pretty simple, but the devil is in the details. We have some in our community who are color-blind and others who have very limited vision, if any at all. For them, any color changes could be well nigh invisible. But it gets worse. On the "Homepage" tab of the "Preferences" page, there are currently 11 different themes that one can choose as your default. Setting a new comment to have a lighter (or darker) title bar would not work across all of those disparate themes.
Chevrons: And as for those chevrons that control the display of a single comment and of a comment tree, yes we heard you. Work is underway to see if we can replace those images with single/double plus/minus characters.
Penultimately, I would like to add a call-out to Paulej72 who took point yesterday (giving TheMightyBuzzard a well-deserved respite) and worked tirelessly into the night to address the issues that were raised.
Lastly, again many thanks to you, our community, who have guided us through this transition. Your feedback matters. We listen and for those who have been following along, I hope you can see the changes and the progress. We continue to strive to earn your trust and support. Thank you!
Dev Note: Currently there is an issue with Flat mode and viewing single comments such as https://soylentnews.org/comments.pl?sid=18223&cid=472653. It just came to our attention and we will be working on it to fix it. This issue will cause you to get a server error. Workarounds are to either switch modes to anything other than Flat or avoid going to single comment views.
Continuation of:
Site Update 17_2
Comments Redux
(Score: 3, Insightful) by tangomargarine on Tuesday February 28 2017, @10:42PM (13 children)
Practically every other site on the net supports markdown now. Besides standardization there is a lot less typing - for example italics are just * characters like *this* instead of full-blown open and close i tags.
There is no clearly defined Markdown standard, apart from the original writeup and implementation by John Gruber, which some consider abandonware.[17][18] This has led to fragmentation as different vendors write their own variants of the language to correct flaws or add missing features.
If it's opt-in, okay whatever, but keep your auto-manglement out of my defaults.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Tuesday February 28 2017, @11:05PM
Automanglement like eating < signs?
(Score: 0) by Anonymous Coward on Tuesday February 28 2017, @11:37PM (6 children)
You seem to be implying that markdown isn't really standardized.
I could see how a naive reading of those quotes would lead you to believe that. But that would be an incorrect reading. It is true that various sites have indeed added their own extras in order to support extended functionality. But soylent isn't the kind of site that has much in the way of extended functionality. Hell, much of what is in baseline markdown doesn't even exist here - for example there isn't even support for drawing a horizontal line. So no, the standard baseline for markdown is more than enough for soylent's requirements.
(Score: 2) by The Mighty Buzzard on Wednesday March 01 2017, @12:03AM (5 children)
If you really, really want to be able to insert a <hr> tag, we can do that. In like two minutes. It's just not a highly requested feature.
My rights don't end where your fear begins.
(Score: 0) by Anonymous Coward on Wednesday March 01 2017, @12:47AM (2 children)
woosh!
seriously, you have huge forest-blindness problem
(Score: 2) by The Mighty Buzzard on Wednesday March 01 2017, @02:23AM
Man, I been coding for I can't remember how long over the past few weeks. You could throw a brick at me and I'd be like "huh?".
My rights don't end where your fear begins.
(Score: 2) by tangomargarine on Wednesday March 01 2017, @03:41PM
Being a software developer is a constant battle to figure out what the user *really* wants. In this case, the OP is apparently too lazy to type chevrons?
Q: I can't do this one specific thing.
A: I can implement that one specific thing for you. Next?
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 2) by TheRaven on Wednesday March 01 2017, @02:39PM
No, that's not what he's saying. He's saying that he wants to be able to type in a markup language that is designed for humans to type, rather than one that is designed to be machine generated. He points out that his preferred markup language doesn't support nice syntax for everything that HTML supports, for example horizontal rule, but that most of what it doesn't support is irrelevant for a site like Soylent. i.e. adding hr is precisely the opposite of what he actually wants.
I'd second the vote for Markdown, by the way, with a preference for GitHub flavoured Markdown [github.com], which anyone that has used GitHub is likely to be familiar with.
sudo mod me up
(Score: 0) by Anonymous Coward on Wednesday March 01 2017, @03:53PM
Honestly, there've been a couple times I really wished we had <hr> available, when I had both a direct reply, and a long semicoherent tangential ramble, and wished to clearly delineate them so sane people new when to stop reading. Or if I'm writing a big long post with footnotes, to clearly delineate footnotes from paragraphs. I just ended up using a line of -------------------- or ***************** or some such, but an <hr> would have been nicer.
Guess I should submit a feature request on github in a few weeks, once the devs have cooled off from this commenting business.
(Score: 2) by Marand on Wednesday March 01 2017, @01:27AM (4 children)
How about Asciidoc [asciidoctor.org]? It wasn't created by a prominent Apple fanboy so it's not as well-known, but it's mature — predating markdown by a couple years, in fact — more consistent, has actual conformance tests [asciidoc.org], and isn't "abandoned" and forked a million ways. It also has more formatting options available. I think we'd only need a subset, though, because the full asciidoc spec would be overkill.
Also, I agree about it being opt-in, at least for existing accounts. People's existing settings should never be changed unless there's a damn good reason for it. However, changing the default for ACs and newly created users is fair game. Make a new account, get the new default; use an account that predates the change and nothing changes.
(Score: 1, Interesting) by Anonymous Coward on Wednesday March 01 2017, @07:30AM (3 children)
Which has no real user-facing advantages and nobody knows it. Cool, eh?
(Score: 0) by Anonymous Coward on Wednesday March 01 2017, @04:10PM (1 child)
He does point out in his other comment about asciidoc that it uses the conventional _italic_ and *bold* conventions, whereas markdown uses weird *italic*/_italic_ and **bold**/__bold__, so that looks like a real user-facing advantage to me, but the reality is that, like VHS, markdown won (presumably because of ascii-pr0n?), so now everyone's using it regardless of merit.
If I were doing my own documentation for a project, I'd seriously consider asciidoc, but for a commenting system meant to be used by thousands of random people, popularity beats technical merit.
(Score: 2) by Marand on Wednesday March 01 2017, @08:23PM
There's actually quite a few user-facing advantages; if you're interested, check my reply to that AC [soylentnews.org]. That's not everything, since I was trying to limit it to things that I think could be useful in a comment system, but I think there's enough benefit that it would be worth at least considering it for its merits instead of just going with the PHP of lightweight markup. Also, there's enough similarity that people familiar with markdown should be able to use it without any major troubles. All you'd need is a cheat sheet link to some basic formatting symbols and you'd be good to go.
I'll admit I prefer asciidoc, because Markdown has enough inconsistencies and annoyances that I started preferring to use adoc instead of md where possible, but I don't have any strong preference for use here, because I think either one would be an improvement over our current options. I only mentioned Asciidoc as a possible alternative because of the remark about Markdown's fragmentation and issues with its undefined behaviour, and the possibility that it might be easier to implement a parser for the parts of it that would be relevant for commenting.
(Score: 2) by Marand on Wednesday March 01 2017, @08:07PM
Which has no real user-facing advantages and nobody knows it. Cool, eh?
Just because you don't know it doesn't mean nobody does. It's used for the git documentation [github.com], O'Reilly accepts it for books, and Github accepts it for documentation, READMEs, etc. as well as Markdown.
As for user-facing advantages for asciidoc over markdwon, here are a few:
* Using _ for italic and * for bold makes more sense than * and **, and makes bold+italic (_*foo*_) both shorter and clearer
* Superscript (^foo^) and subscript (~foo~) are explicitly defined in asciidoc, but not in Markdown.
* Support for horizontal rule with triple single-quote (''')
* Checklists with [*] syntax
* Link syntax is both simpler and less likely to result in parsing errors. asciidoc links are in form of example.com[Link Text] whereas Markdown uses [Link Text](example.com), which causes problems when a URL has parentheses in it. Having to manually replace parens with %28 and %29 in Wikipedia links is annoying with Markdown, for a real example of why this matters.
* Code blocks are marked by a matching line of dashes (such as ----) at the beginning and end of the block, whereas Markdown uses 4 spaces on each line. That means you have to change the actual code blocks to suit Markdown, but with Asciidoc you can dump the code without modification. The spec also explicitly defines a syntax for syntax highlighting, if needed, but in Markdown it's non-standard.
* Passthrough blocks (++++) allow selective embedding of HTML in cases where you need direct control