Too many things!
-
-
That's a good question. In the next beta, the system pushes that button for you every 15 minutes to keep you under 80% of 500 instead of nagging you
Seriously? Are you shitting me? Why are you making those kind of choices for the user! What the hell? Maybe I've had a busy fucking month and eventually would like to come back? Maybe a topic I track blows up. Neither of those mean I want to ignore EVERYTHING I AM TRACKING. The collateral damage is absurd
Because the server sends a load of information about the Unread/New topics down to the client - so it was capped to avoid sending way too much information down, rather than simply sending less down like y'know just the fucking total.
And yet this is the one thing that ISN'T INFINITE SCROLLED???
Defroster? Who needs a defroster? I live in LA, my windows don't frost up.
Oh no, you can definitely use a defroster, but only once every two months. Why would you ever need it more than that?
-
Why not send the total numbers, plus the first X IDs
If what they do works for entering topics (giving a full list of the post IDs), then why not do the same on the list of topics themselves (giving a full list of the topic IDs)?
Filed under: Oh, wait...
-
At the bottom of /new and /unread
/new and /unread helpfully don't include the controls to jump to the bottom of the page.
So in order to click those buttons you have to scroll, wait, scroll, wait, scroll, wait, etc. etc. etc. in order to see the buttons you need to click to tell the forum you aren't interested in the topics you've just sent an unholy amount of time scrolling past and staring at while it fetches more.
-
Oh look! More brilliantly thought out design!
-
That's a good question. In the next beta, the system pushes that button for you every 15 minutes to keep you under 80% of 500 instead of nagging you.
Wow.
Here's a puzzler for you guys: is there a worse way to handle this situation?
-
The notice showed up for literally everybody at Hello Foros because they get more than 500 new topics a day.
Ah, so you have a great beta testing and UX process too, and are really concerned about user experience.
Goddamned. How is it possible to be as incompetent as the Discourse team?
-
Here's a puzzler for you guys: is there a worse way to handle this situation?
It could also kill the battery on your phone while it does it...
Oh...wait...it already does that.
I suppose the devs could come by your house and kick you in the gonads while dismissing your unread posts?
Why the hell are they doing this anyway? Just get rid of the stupid notification. Is it causing performance issues?
-
Why the hell are they doing this anyway?
I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a [solution to this problem].
It's so retarded, my brain simply has no circuitry capable of handling it.
I mean. Seriously. It's staggering. When I read that, I just stared at my monitor, mouth agape. With Atwood's retarded idea that the "Mark As Read" button should also unsubscribe to the topic, well, ok, I could kind of see some semblance of logic behind that behavior. It was just implemented in a piss-poor fashion, and without any copy explaining what the button did. But this. But this!
-
That's not bad design.
There's enough room for that C at the end, therefore the whole thing can shift.
-
ad posts?
Why the hell are they doing this anyway? Just get rid of the stupid notification. Is it causing perf
No. See comment earlier about data sent to client.Also.... cool quoting mobile.
-
The button should show at the top after X amount of topics unless that's a Discosetting we have disabled. @riking?
-
But this. But this!
This is what happens when someone decides to do a thing, without ever considering why they want to do it.
-
Aka all Discourse development.
-
Does anyone know the story behind that picture?
-
I don't usually seek out such knowledge. It usually makes it less funny. You end up finding out that the installer cost the company a ton of money and a lost contract, subsequently he was fired and then committed murder suicide.
Without knowing such things I can assume it all ended like an 80's sitcom.
-
Apparently it's either a joke or Photoshopped.
-
You beat me to it. I found the same articles.
Either way, it makes the meme less funny.
-
@codinghorror and @sam need someone to throw them a beating. I got tired of their stupid new banner, did what said banner told me to do, and this shit is still here.
Fucking fuck, does anything work around here?
-
The buttons themselves are also discoursistent - within any given category I can see the dismiss buttons if I go to Unread but not if I go to New - even if I go to the very bottom of the category.
For bonus points the help text says 'Dismiss New or Dismiss Posts' but the only choices I've seen are Dismiss Posts and Dismiss Topics.
-
This warning no longer exists in latest, the issue self corrects.
-
Why does this issue exist in the first place? These are the kind of bugs that the most basic of testing would catch.
And all of that is before we even get to the question of why this is a thing in the first place...
-
You can read some of the history here https://meta.discourse.org/t/new-unread-counts-missing-when-too-many-tracked-topics/32922
The banner should be gone though on reload, on the version you are running
-
This warning no longer exists in latest, the issue self corrects.
By "self corrects" you mean "deletes information relevant to the user without their knowledge or consent", then... yes.
-
So because of past poor design decisions, we have to continue serving past poor design decisions by destroying ostensibly useful data?
If I used that sort of bullshit circular reasoning at work, I'd be involuntarily looking for a new job.
-
By "self corrects" you mean "deletes information relevant to the user without their knowledge or consent", then... yes.
If you are going for an inbox ONE MILLION and objecting that we do not support that ...
Sorry.
Or if you really want to... let me know how to rewrite this without a limit so it does not rape us.
WITH x AS ( SELECT u.id AS user_id, topics.id AS topic_id, topics.created_at, highest_post_number, last_read_post_number, c.id AS category_id, tu.notification_level FROM topics JOIN users u on u.id = 576 JOIN user_stats AS us ON us.user_id = u.id JOIN categories c ON c.id = topics.category_id LEFT JOIN topic_users tu ON tu.topic_id = topics.id AND tu.user_id = u.id WHERE u.id = 576 AND topics.archetype <> 'private_message' AND (("topics"."deleted_at" IS NULL AND tu.last_read_post_number < topics.highest_post_number AND COALESCE(tu.notification_level, 1) >= 2) OR ("topics"."deleted_at" IS NULL AND topics.created_at >= GREATEST(CASE WHEN COALESCE(u.new_topic_duration_minutes, 2880) = -1 THEN u.created_at WHEN COALESCE(u.new_topic_duration_minutes, 2880) = -2 THEN COALESCE(u.previous_visit_at,u.created_at) ELSE ('2015-09-09 21:12:17.314182'::timestamp - INTERVAL '1 MINUTE' * COALESCE(u.new_topic_duration_minutes, 2880)) END, us.new_since) AND tu.last_read_post_number IS NULL AND COALESCE(tu.notification_level, 2) >= 2)) AND (topics.visible OR u.admin OR u.moderator) AND topics.deleted_at IS NULL AND ( NOT c.read_restricted OR u.admin OR category_id IN ( SELECT c2.id FROM categories c2 JOIN category_groups cg ON cg.category_id = c2.id JOIN group_users gu ON gu.user_id = 576 AND cg.group_id = gu.group_id WHERE c2.read_restricted ) ) AND NOT EXISTS( SELECT 1 FROM category_users cu WHERE last_read_post_number IS NULL AND cu.user_id = 576 AND cu.category_id = topics.category_id AND cu.notification_level = 0) ORDER BY topics.bumped_at DESC ) SELECT * FROM x LIMIT 500Limit can be set by admins ... but at 500 it's already taking 150ms here for my account, so yeah we could bump it up to 100000 in site settings here and people with one million unread can wait an hour to get the front page.
So win.
-
So because of past poor design decisions, we have to continue serving past poor design decisions by destroying ostensibly useful data?
How many unread topics do you have?
-
Here? Apparently too many. Because I don't use those tabs in my workflow whatsoever, and I just came back from extended hiatus. What if I actually want to read the backlog?
Instead I rely (probably incorrectly) on the category pages to give me shiny stuff to look at.
At work? The closest analog in my systems has several tens of millions of things that a user hasn't looked at but may need our want to in the future.
-
I actually tried to find the "source" image, which I did but only as a basis for meme engines, and plenty of sites that offer it as
of their own. I would like to think that it is genuine. But it is corporate suicide. in that several magnitudes of more people would ridicule it, than those that would appreciate the subtle humour of it.
-
If you are going for an inbox ONE MILLION and objecting that we do not support that ...
Why not? Outlook supports it. Gmail's fine with it. Hotmail, back when I used that, had no issues. And that was before the rewrite, when Hotmail's code was ancient.
My Gmail right now has 64,402 items in my inbox, and it's about an order of magnitude more responsive than Discourse has ever been.
Hell, I'd wager Lotus Notes does a damned sight better than 500.
Sorry.
Sorry in the sense that you're apologizing for not supporting that?
Or "sorry" as a description of your team's engineering skills, to fail to match the performance Gmail had back in 2008?
Or if you really want to... let me know how to rewrite this without a limit so it does not rape us.
Ok, first of all, I find that usage of the word "rape" to be really offensive, what the fuck man. Rape is an actual crime which has actual victims; you're talking about a piece of software that takes slightly longer than you'd like. Not equivalent. You've been working with Atwood too long.
Secondly, I would be happy to quote you my hourly rate. But I'm sure as fuck not going to touch that shit for free.
There's a few really obvious things you could do to improve the performance of that query.
-
usage of the word "rape"
Jesus Christ, is that called "eye rape: the plugin?"
Why the fuck are we talking about not being able to read a clock while ignoring the anally-raped muppet face in the room!
Hey guess what? I don't give a flying fuck about learning markdown. Also you're fucking wrong, look up a line. Now it's one of those rape-victim faces with a semi-colon surgically-attached to its ear.
-
also, I could probably get inbox one million going here if I spent a couple of weeks on it, but honestly I would prefer spending the time on fixing t/1000
-
I could probably get inbox one million going here if I spent a couple of weeks on it, but honestly I would prefer spending the time on fixing t/1000
OK. So do both? In the time honored tradition of issue prioritization and triage "some numbers look funny but the feature otherwise works" is obviously lower priority than "server falls over". So don't waste time on hacky workarounds for the cosmetic issue. Come back and fix it properly later.
-
No, no, no. You don't get to silently delete data relevant to the user. You do not have permission from the user to do that by definition. That is wrong. I'm not just talking about software engineering, I'm talking about ethics.
Especially when the issue could simply be fixed with a tiny bit of copy. "You have more than X unread items; only the latest X will be listed."
-
Explanatory text is evil! Except when it toasters to tell you shit you already know.
-
-
Especially when the issue could simply be fixed with a tiny bit of copy. "You have more than X unread items; only the latest X will be listed."
Not that simple, we re-sync the in memory data when we load the unread stuff, so I need to change it so it displays 250+ or something like that, its not a simple change.
The original complaint was that unread can not be trusted.
-
Not that simple, we re-sync the in memory data when we load the unread stuff, so I need to change it so it displays 250+ or something like that, its not a simple change.
Ok.
-
I'm sorry that software development isn't all happiness and roses and doing things right sometimes takes non-trivial amounts of effort, and
-
that's still no fucking excuse for deleting data relevant to the user without confirmation.
"Oh noes! Doing this correctly is slightly hard! Better DELETE ALL THAT USER'S DATA FUCK USERS I HATE USERS I'M A DISCOURSE DEVELOPERS!!!"
-
-
-
Discourse was actually "released" at some point, but since then it seems to have regressed because I've only heard of "betas" for months and months.
-
@riking said:
That's a good question. In the next beta, the system pushes that button for you every 15 minutes to keep you under 80% of 500 instead of nagging you.
I sincerely hope that I misunderstood this. If not...you have to be fist fucking me?
I think it's actually worse. I was reading on meta.d this morning and they are going to push the button for you so that your new messages are at 40% of max and unread are at 40% of max. Based on the discussion I was reading, it sounds like you could be all caught up on unread topics and still only see 200 new topics even though you should be able to see 500 according to the site settings.
-
Discourse was actually "released" at some point, but since then it seems to have regressed because I've only heard of "betas" for months and months.
That's because we're in the "beta" track. At least it's marginally better than when we were in the "latest" track. Back then we had new bugs daily.
-
still only see 200 new topic
New topics are capped at the site level to 2/5th of max_new_unread_topics, out of the box that is 200.
I will revisit this stuff eventually but the banner is not a solution, just a support nightmare.
-
Discourse was actually "released" at some point, but since then it seems to have regressed because I've only heard of "betas" for months and months.
I'll take your word for it. I made the mistake of going to discoure's website to try to find out what the current version number is. FAQ? Nope. About? Nope. Blog? Nope. Every page, of course, has a different layout, making finding information even harder. Some single column, some multicoumn. Some have headers, others don't. Different font style on each page. It looks like a Geocities page whose .css file didn't load right. Then someone farted on it.
-
This post is deleted!
-
they are going to push the button for you so that your new messages are at 40% of max and unread are at 40% of max.
They keep using that word, but I do not think it means that which they think it means.
-
Funny story: The last company I worked at had 100MB limits on our Exchange accounts. This is in the 2010s. The company had less than 10 people.
The boss (a type-A micromanaging fuckhead) insisted that everyone use Exchange exactly like him. Every email should be color coded, and create an offline folder for every client you communicate with. Move every email you are done with into those folders. This is THE ONLY WAY to keep emails organized, and the 100MB limit would force you to learn to do things THE RIGHT WAY.
We regularly sent QA/UAT reports with megs of screenshots, and design documents with mockups pushing 10-20MB.
"Cleaning up your email" would take at least an hour each week. Amongst the ~10 people, assuming a very VERY conservative average billable rate of $100/hour for coders, that's about $1000 of wasted effort every month. Plus the fact that people got used to just deleting emails rather than filing them-- plus the fact that offline Outlook folders weren't backed up, so entire reams of mission critical data was either being tossed or put at risk of data loss.
Hard drive space was ~$100/TB back then.
Anyways, to sum it up: 500.
-
New topics are capped at the site level to 2/5th of max_new_unread_topics, out of the box that is 200.
So...if I read this correctly...you put a cap at 2/5ths of maximum?
I don't think you know what the fuck "maximum" means.
I will revisit this stuff eventually but the banner is not a solution, just a support nightmare.
So get rid of the stupid fucking banner.
-
@Lorne_Kates said:
Funny story: The last company I worked at had 100MB limits on our Exchange accounts. This is in the 2010s. The company had less than 10 people.
As a guy who owns a company that attempts to support people who both keep 20GB of shit in their inbox and complain that Outlook runs like shit...I wish there were more people like him.
-
Umm I think I am one of those - I never delete an email unless it is spam (by my definition or the email client's).
