pauamma: Cartooney crab holding drink (Default)
pauamma ([personal profile] pauamma) wrote in [site community profile] dw_dev2016-12-31 03:31 am
Entry tags:

Question thread #48

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.
siderea: (Default)

[personal profile] siderea 2017-01-09 08:00 pm (UTC)(link)
That one has to have inbox notifications on for anything one wants email notifications of.

That, and I'm just curious. I'm glad I asked if only because your answer was interesting. (If anybody doesn't have anything better to do than indulge my curiosity and wants to tell me about the specific tradeoffs that had to be made for performance, I'm interested in a scalability-case-study sort of way. Not because I have any agenda for changing things, but because knowing examples of this sort of thing makes one wiser about development.)

ETA: Also, when I was explaining to someone about how notifications work, I was struck by how the notifications system is both pervasive and extraordinarily customizable. That combination – pervasive + highly user customizable – is often deeply terrible to implement, for a whole host of reasons, including performance. Pretty much any time anybody twitches on DW, a whole cascade of logic has to be checked to see who needs to be told about it. So it occurred to me to wonder how DW does it, and how DW feels about its solution.
Edited 2017-01-09 20:05 (UTC)
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-01-09 08:19 pm (UTC)(link)
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.
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)

[staff profile] denise 2017-01-09 08:28 pm (UTC)(link)
also, re: your edit, which came in while I was replying and I forgot to address in my response BECAUSE I'M RAMBLING TODAY BECAUSE IT'S BETTER THAN DEALING WITH THE UMPTEEN BILLION EMAILS STILL IN MY INBOX: highly customizable was the LJ theory for just about everything for a very long time and we try to keep it the DW theory as much as feasable, and "deeply terrible" is a good description of it. Not only performance issues, but UI/UX issues as well -- LJ/DW is so customizable that it's not intuitive for a lot of people and there are a ton of things that are difficult to explain. Conversely, however, the fact that it is so customizable is a major selling point for a lot of people, and removing or redesigning options/making things less customizable risks angering people or breaking edge-case uses -- and there are a lot of edge-case uses. (Like, most people only use 20% of the site features and options ... but everyone uses a different 20%.) Witness the uproar every time LJ makes radical changes to something...

I'm a lot more willing to support options and under-utilized features than [staff profile] mark is (he always wants to rip things out, lol) but we've tried to do a lot of simplifying, and there's still a lot we could do.
mark: A photo of Mark kneeling on top of the Taal Volcano in the Philippines. It was a long hike. (Default)

[staff profile] mark 2017-01-15 08:41 pm (UTC)(link)
DEATH TO EVERYTHING RIP IT ALL OUT

The code machete makes life better. It keeps us sane. Removing code removes bugs! Deleting things deletes security holes! It is all better!