1 | ||
1 | ||
1 | ||
1 |
It's a new month, so time for another feedback round. A couple of changes have been implemented since last month's feedback round. The chat box has been improved, as it now dynamically fills up the vertical space on your screen and has a connection indicator. The reply button now toggles the box instead of spawning a new one each time. More changes are listed here.
You're hereby invited to provide additional feature requests, bug reports, and/or other feedback.
I actually considered switching to a bi-monthly format so as not to overburden you with requests, but then again I want to request some of them now. Others I'm holding back for next month. And I will nag you about some requests I've already made based on how important I think they are. (I believe you invited me to do that?)
High priority: improve the design
I personally love the look but I get this issue from so many directions that I'm thinking it shouldn't be ignored. I actually hate the idea of compromising on this design to appeal to more people, but maybe a middle ground can be found so that more people can stand it but it still has that retro vibe. When people say they don't like the look, I ask why. Here's what they listed:
Medium priority
Low priority
It's interesting. I was playing around with the link color space. I found that lighter is better. In posts I think I'm actually using black with an underline and it seems to work as well. Out of curiosity I tried to find a transition path between the two ok colors just to see if I could find one (pure curiosity). I couldn't find one. Instead what I found is that within that color space there is a straight-ish line of really bad perseptability dividing the two. The current color happens to be pretty close to the line. So it's interesting that making it lighter and darker both make it better because it moves it away from that line.
A few visual findings:
Original:
.
https://img.gvid.tv/i/47g8rQm3.png
Same as post text:
https://img.gvid.tv/i/2RKx9ukt.png
Lightened blue:
https://img.gvid.tv/i/Ja2BZDgH.png
Black:
https://img.gvid.tv/i/DTiUXkEv.png
Darkened blue:
https://img.gvid.tv/i/3839E7eb.png
It's still bad but it shows that there is marginal improvement in both directions from the current.
Actually I think the "maximally awful line" splits into a y shape because as you get lighter or darker immediately near the current color it actually gets worse before you hit some threshold.
I just find that interesting. I'm leaning toward the white underline to match text post formatting. It's really a mistake it didn't get applied to comments. They both have some common css and some seperate css and it looks like I just need to move that bit of css to the common.
Now what's really interesting to me after having made that comment is that the images I linked show a darker background than where they are inlined. I figured out why but I think that's kind of nice that you can screenshot something here, inline it, and tell it's a screenshot. The why is that the whole page is going through filters to increase contrast at least from where it was before.
Maybe I should add a contrast slider, observe where people set it, and then use that to update the default. I do in fact have telemetry on the chat resizing and I've been meaning to use it. Potentially also using that concept on the sort preferences. I think I need to scale them on the back end to the variance each has. The fact that everything here has very similar score after everyone upvotes, but the proportional time variance can range anywhere from a couple of hours to months means that time dominates the sort until you set time to 0.1 and score to 5. I'd rather it be that if you had score set to 2 and time set to 1 that you should start to see an effect. You only start to see a gradation between a hot sort and a top all time sort when both are almost maximally different. To mean 0.1 time and 5 score should be almost identical to top of all time. It's caused by the differences in variance in log(stat) for those two stats. log(2) and log(6) are almost the same number. log(1 hour) and log(4 months) is a huge difference.
Edit: Problem with just re-scaling them.
The sort functions exactly like it should currently when age:score is 1:1. Re-scaling would mess with that. Currently with 1:1 if a post gets double the score it will stay on the front page twice as long. That's what we'd expect from a default hot sort or at least not far from it. The furthest I could see a default hot sort deviating from that is 1:2, where the sort factor is (score)^2 / age, or 2log(score) - log(age) [Same thing].
So a better approach would be to scale the users deviation from 1. So 1:1 is still 1:1. But 1:2 would be translated to 1:4 where being +1 on score translates to being +3.
Now the downside of that. If someone were to set a score to zero. 1:0 currently means only consider age. That's reasonable. But that would make 1:0 translate to 1:-2, which would make it actually hate posts with a good score. Maybe that's a useful sort to have but isn't very semantic with what a user wants with 1:0.
Last idea. Use powers on the user's sort factors in some way related to the proportional variance of a stat. So maybe the score factor is squared.
User selects 1:2 and that translates to 4log(score)-1log(age). 1:5 would get you 25log(score)-1log(age) which would get you closer to the result you want without having to drop age to 0.1.
Then you would not do the same thing to age because the stat has more variance.
Edit 2:
Or maybe, crazy idea, it's fine how it is. If you scale score to 5 you do see some effect. Very few users would want to do that with the current post volume because who wants to see 5 day old posts anyway. So making it slightly more convincing for that user to use 2 instead isn't a priority. It just feels weird that you can double a number and see no effect.
Matrix honeypot confirmed. I knew it.
This is actually what I was getting at a while ago. You dismissed it as working as intended then but my point was that age didn't work naturally for what we expect. I'm glad you recognize it now.
For inspiration on how to make the score work, you may want to read How Reddit ranking algorithm works from 2015. It seems that Reddit looks how many seconds after its creation some day in 2005 have elapsed since a post's submission. You'll have to double check the math and see if it's useful for you or will still give you the same problems.
Personally, I would simplify the sorting method significantly and not burden the end user with too many options in the form of sliders. Just have buttons for Hot, New, Top, Active (which prioritizes bump) and For you (which prioritizes proximity), while you tuck the sliders away in the settings page.
Furthermore, don't present numbers but rather the words Low, Medium, High. Or, if you want to have similar customizability to now, add Very low and Very high. But the trick is to hide 1 behind the lowest option, not 0. That enables 2log without making it averse to the variable when the lowest setting is used. In this schema, I would default the sliders to the lowest setting (interpreted as 1) so that the user can think about which variables they want to have priority, and increasing the slider will have the most notable effect. This way it will feel like their decision actually had an impact. So the defaults are just as they are now (all set to 1), but any option below 1 is hidden, the slider is empty at 1.
Oh yeah, but this is the big difference with the current sliding mechanism. Assuming you include very low and very high, there are the same numbers as now, 1-5. But there should be nothing in between very low and low. It should just jump from 1 to 2 behind the scenes, and visually for the user as well, the slider should go in relatively big steps. This way you aren't burdening them with the decision between 2.3 or 2.4 when they just want to visit a link aggregator. And it feels like their decision is more significant, and not arbitrary. Personally I like the feeling of making a slider increase in big steps each time.
There could also be a "Matrix secret sauce ranking algorithm" (can't think of a good name right now) which is based on lots of testing, or simply your telemetry for people who opt into a custom ranking algorithm. I think that's only interesting for later, though. But maybe age should be a significant factor in the Top, Active and For you pages anyway, because who wants to stare at the same list of posts every time?
I'm really not too interested in implementing reddit's algorithm directly. The seconds from 2005 bit is pretty arbitrary. If you are doing it right you can change the point of measurement or the time units and the math will give you the same sorting. Milliseconds from 1970 is basically the standard. I ended up deviating from that a bit just to shrink the numbers down that are being fed into c standard library functions. But it's not really a human meaningful selection. Just what would give me an acceptable reduction in floating point inaccuracy and fit the smallest and largest numbers it would see through the function.
In a lot of ways matrix is a custom kind of database with a UI over it so I like to give people flexibility.
I think a lot of what wasn't working right in terms of age was proximity. There also was a bug I fixed in the position system that was causing some y values to explode. So now all dimensions are clamped between -10 and 10 and no numbers are exploding.
The main thing people noted for the variance issue is it felt like the sliders weren't doing anything. I'm thinking adding a power to the scale for the less variant stats is the way to go if I do make a modification. That or halve the time and bump scales since they correlate so much. It's practically like setting new to 2 by default, having two factors so correlated.
But there are more I want to add, and maybe have some of them defaulted to zero. Comment count and most recent upvote time being two options. Comment count is something I'd gladly set to 1.
What I like about it is that it doesn't look at absolute age, but rather the age of a post compared to other posts. This makes it so you don't have to look for active hours as an ideal posting time: if the website is less active at certain hours, there will also be fewer posts, thus your own post will have more longevity. It will age at an accelerated rate again during active hours when other people post more stuff, but that's also when yours will receive more views. The article I linked to doesn't point that out. I'm thinking about an article from 2011 perhaps, although I cannot find it now.
However, I brought "seconds since Reddit's creation" up because of this:
It made it seem like you don't work with epoch time. I thought, if age is measured as seconds since epoc time (or any arbitrary date), then the difference between one month ago and five minutes ago isn't so big that the age metric will dominate all others. I may be misunderstanding, though. It seems more like epoc time is used to calculate the age in the first place, but the algorithms still look at a post's absolute age, i.e. how many seconds have elapsed since they have been posted, right? Then this point of mine may be ignored, it doesn't provide a solution to age being dominant.
Then additional clients could be a long-term goal, no?
I will say that my suggestion of getting rid of 0 was purely a solution to the issues that comes from 2log. My initial hunch, when the Custom page was implemented, was that everything should default to 0. You could still do this (and not use 2log). I just want the user's specifications to have a really significant impact. I will look for another algorithm to propose later.
Zero isn't really an issue. I wrote 2log to avoid asterisk because it will trigger italics instead of appearing. So that's 2 times log. If I meant log base two I would have written log2. The alg doesn't really care what log you use since all logs stay proportionate. Zeros are only scary if the stat being fed into it is zero. That's an area where comment counts as a stat could be a problem. I would just +1 the stat. Also it's a problem for scores. It would be a problem in the multiplicative form of the alg too because you would never see anything with a negative score ever, which is something a single person can make happen easily and makes censorship too easy.
So the solution with score is to map zero and negative values to fractions 1->1, 2->2, 0->1/2, -1->1/3, -2->1/4
This doesn't seem like much of a mystery to me. It happens because the background sits somewhere in the middle between light and dark, so you have to go in either direction to get a contrast. It leans toward the dark side, so as a result white body text looks better than black, and the same is true for light links as opposed to dark ones.
But I'm not sure you can get rid of contrast issues so long as the background colour sits in the middle. You can only contrast them so much, and once you've reached the lighter colours, you'll have to make the background darker to add even more contrast. But then you end up with a dark mode website that has a different feel, is less original, and can be a pain to stare at. That's why I proposed going the Color-Blinds route of flipping the two: make the background lighter (but still gray), so that you can use black body text and the usual dark blue links. This has the same feel but is much easier on the eyes. Perhaps as an afterthought, I can imagine you want to experiment with the current theme or to see if it can be saved.
Regarding the screenshots, I don't like how the light blue above looks. I just don't register it as an unclicked link as that colour is never used for that. The orange links inside the chat look really good, though. Maybe some kind of orange can be used for links on the website itself?
Another solution to the contrast issue is to just very carefully make the background darker to make the white body text work. I see that it's slightly lighter for comments. But perhaps comments could have the shade currently used for the page background, and then the page background can be a little bit darker. You have to look for the right proportion where it doesn't flip toward a typical night mode, but just has better contrast.
Note from Musky on Saidit:
Fix comment width issue on mobile since migration to new markdown engine.
Basically now that the new engine properly uses p tags and not just br, the prior mobile hacks are irrelevant.
Backlog for a future thread