Question thread #48

[pauamma]

It's time for another question thread!

The rules:

- You may ask any dev-related question you have in a comment. (It doesn't even need to be about Dreamwidth, although if it involves a language/library/framework/database Dreamwidth doesn't use, you will probably get answers pointing that out and suggesting a better place to ask.)
- You may also answer any question, using the guidelines given in To Answer, Or Not To Answer and in this comment thread.

Comments

[denise]

Aha! That is one of those "frequently asked for changes that we haven't done yet because Reasons" things -- back in 200-mumble when the notification system was added, it was coded originally to consider the inbox notification the default version and all the other notif methods the copy, and so it counts on there always being an inbox notification object. It would require a vast overhaul to make the change. When LJ changed it a while back, it was a huge changeset, and it was done after we'd diverged enough that we couldn't just adopt it wholesale; it would have been just as much effort to merge it as rewrite it ourselves, especially since they had more resources to throw at performance inefficiencies and so weren't as diligent about optimization as we had to be at the time.

Then, every few years I start thinking "we should go ahead and do that ridiculous amount of work and make email-only notifications possible", and something promptly happens like half the email providers on the internet deciding that our email is spam and stop allowing us to email their accountholders YET AGAIN, at which point I look at the whole thing, am reminded that email is a Terrible Horrible No-Good Very Bad Protocol, and decide that it's not worth doing that ridiculous amount of work if it means losing the on-site backup record of unsent email notifications that people who are missing notifications can consult. (Like, yeah, if it were only a little bit of work I'd say we should go ahead and do it and anyone who turned off inbox notifs would just have to live with missing/delayed email when it happened, but the combination of it being a terrible horrible amount of work plus no longer having the on-site backup for when email is being Terrible again means I keep deciding it's just not worth it. Especially since, again, we have a ton of Modernize This Thing Into Something That Was Created This Millennium projects, and the existing system does work, just not with optimal UX.)

Personally, I just use the delete-all button on my on-site inbox a lot. ;) (Or filter by entry and delete-all for that entry.) There are definitely a few more UI improvements we could do to make it easier to manage large numbers of inbox notifications, we're just hampered by not really having any UI specialists.

There are a lot of things that annoy people about the site where the answer is "because in 200-mumble when it was added, there were no best practices yet and/or the people who made it didn't understand the use case and/or the userbase came up with some new weird way to use it that nobody thought of yet, and to change it now would be a much bigger deal than you'd expect." I blow people's minds sometimes when I point out that our code doesn't date from 2009 when we opened, it dates from 1999 when Brad came up with the first version of LiveJournal, and therefore becomes old enough to be a legal adult in the US this year. (I have a talk I give about working on DW that's called "When Your Code Is Old Enough To Vote" that goes into some of the upsides and downsides of working with a webapp this old.)

There's a shitton of downsides to having used the LJ code when we started, definitely, but there were (and continue to be) enough upsides that I still think it was worth it. I just wish we had more designers and UI specialists and frontend gurus sometimes.