Reminder: Beta features are available to test!
It's been a while since we've reminded you of the existence of the Beta Features collection. This is where we make new features and major page redesigns available to people in advance of changing them for the whole site, so people can help find the weird edge case bugs, let us know about usability and accessibility problems, and generally bang on certain changes before we make them the default behavior so the deploy runs more smoothly.
I'm posting about beta test opportunities because 2023 has been the Year Of Finishing That Last 10% On So Many Things, and part of that is us making a real push to get some more things out of beta. In particular, the redesigned Create Entries page has been in beta for an absolutely mortifying length of time by now, and we are absolutely determined to finish up the last few things that are blocking us from releasing it and get it out the door relatively soon.
This is the last call for "I'm having a problem with this page that will keep me from being able to use the site if you make this the only way to update". If you haven't enabled the New Create Entries Page beta to test it, please consider doing so soon! It's a full, ground-up rewrite and redesign of the update page in order to modernize it, make it easier to maintain, significantly improve usability and accessibility, and generally give us a lot more opportunities to improve the posting process. In particular, the page is fully customizable: if you hit the "Settings" link in the upper right corner of the page, just above the "Subject" field, it will let you customize which panels show when you load the page, change some visual settings about how the page behaves, and (if you scroll down) move around the individual panels so they're displayed in a place you find logical for your workflow. We think it's a massive improvement from the old update page, and we're ready to do the last bits of work we need to do in order to switch everyone over.
We will soon be removing the New Create Entries Page beta and making the new, improved version of the page the only option for everyone who uses the site. This is your last chance to let us know if something is very broken for you: checking now, and reporting any problems you might have, will prevent future disruption to your use of the site. Please take a moment and enable the beta so you can help us find any last lingering issues.
The other major beta we have running right now is the New Inbox Page conversion. This is part of our ongoing modernization efforts: Dreamwidth itself was launched in 2009, but because it's based on LiveJournal's open source code, parts of the site date as far back as February of 1999. (If you're as bad at math as I am: that means three months from now will be the 25th anniversary of the code that runs the site existing in some fashion. Please don't tell me if my website's source code is older than you are; I already feel old as hell just thinking about it.) As you can imagine, the technology that runs the internet has changed significantly in the last 25 years, and we've been engaged in a long, slow-motion project of updating the code that generates all of the pages on the site to use more modern technology. Like with the new Create Entries page, this makes it seriously easier to maintain and allows us to benefit from the accessibility, usability, and bugfixing work that other people using the same technologies have done: the old way of doing things was unique to DW, while the new way of doing it uses more widely-used frameworks and modules so we can benefit from many other people's work.
Converting site pages to the new way of doing things involves a complete rewrite from the ground up, though, and while we try to keep the two versions looking as similar as we can, it's not always possible: some changes to how the pages look and feel are inevitable. There's also, of course, the opportunity for new and exciting bugs. So, when we've been converting major pages, we run it through a few rounds of beta first. The inbox is one of the last remaining big user-facing conversion projects, and we wanna get it done and dusted so we can pick off the last outstanding pages to convert and finally be done with this massive albatross of a project we've been working on for-freaking-ever. (We're about 80% done, and this fact is very exciting after having been working on it for so long.)
If you haven't enabled the New Inbox Page beta to test it, please consider doing so soon! (And if you had previously enabled it and found a bug that made you turn it off, please try turning it back on: we've done a lot of bugfixing work.) Because of how old the old Inbox page was, this is one of the more dramatic "things will look different" conversions we've done and the new version may take a little while to get used to, but all the major functionality should match and it includes a number of bugfixes that the old version of the inbox doesn't have.
We will soon be removing the New Inbox Page beta and making the new, improved version of the page the only option for everyone who uses the site. This is your last chance to let us know if something is very broken for you: checking now, and reporting any problems you might have, will prevent future disruption to your use of the site. Please take a moment and enable the beta so you can help us find any last lingering issues.
Finally, a few years ago we converted the journal entry view from the old code to the new code. Despite us aggressively running it through the beta system before making it the default for everyone, a few people experienced some dramatic bugs (including some wetware bugs: it triggered photosensitive migraine in a small number of people). While we worked to fix the problems people reported to us, we enabled a beta flag to let people turn the new code off (as opposed to our usual method of using the beta flag to turn the new code on).
We've done a significant amount of work on the problems people reported with the new journal entry view, including working with a number of experts on photosensitive migraine and a panel of the users who reported that the new code triggered photosensitive migraines for them. At this point, we're reasonably sure that we've fixed every issue that was reported to us, and we're making preparations to remove the beta flag that allows people to turn the new code off. (Keeping two versions of the code for this long is a lot of maintenance overhead, and we can't keep the old code around forever.)
If your account has the "Temporarily revert updated journal page components" beta flag on -- that is, if you previously experienced a site-breaking bug with the new code and had to disable it while we fixed it -- please go to the beta page and turn that beta flag off. This will switch your account to using the new code that every account created since the conversion has been running and let you verify that the particular issue you were having has been fixed. This is probably the most critical action for people who had problems with the conversion to take, because we really need to close out that beta and stop having to maintain two versions of the code, but we don't want to break things for you again!
We will soon be removing the "Temporarily revert updated journal page components" beta and making the new, improved version of the journal entry view pages the only option for everyone who uses the site. If you previously enabled the beta flag in order to temporarily use the old code while we worked to fix it, it is very important that you turn off that flag now and verify that your issues with the new code have been fixed. Please take a moment and disable that beta if you have it enabled so you can help us confirm that the problem you had is fixed.
(The remaining individual beta flag, two-factor authentication, is a very early test that was released as a beta so people can test out the process of configuring an optional two-factor authentication setup. While you can set your 2FA preferences, none of the site login pathways actually use 2FA yet, so enabling it won't do much. The final flag, "site-wide canary", is a generalized "this is the cutting edge code that we've just committed and will be released in the next site update" setting, and you should only enable it if you like living dangerously and occasionally finding that everything breaks horribly.)
For all of these beta flags, if you enable them and have problems, check the Beta Features page listing for that specific beta flag listing: there's a link to the specific entry in
dw_beta where you can report problems or bugs.
I'm posting about beta test opportunities because 2023 has been the Year Of Finishing That Last 10% On So Many Things, and part of that is us making a real push to get some more things out of beta. In particular, the redesigned Create Entries page has been in beta for an absolutely mortifying length of time by now, and we are absolutely determined to finish up the last few things that are blocking us from releasing it and get it out the door relatively soon.
This is the last call for "I'm having a problem with this page that will keep me from being able to use the site if you make this the only way to update". If you haven't enabled the New Create Entries Page beta to test it, please consider doing so soon! It's a full, ground-up rewrite and redesign of the update page in order to modernize it, make it easier to maintain, significantly improve usability and accessibility, and generally give us a lot more opportunities to improve the posting process. In particular, the page is fully customizable: if you hit the "Settings" link in the upper right corner of the page, just above the "Subject" field, it will let you customize which panels show when you load the page, change some visual settings about how the page behaves, and (if you scroll down) move around the individual panels so they're displayed in a place you find logical for your workflow. We think it's a massive improvement from the old update page, and we're ready to do the last bits of work we need to do in order to switch everyone over.
We will soon be removing the New Create Entries Page beta and making the new, improved version of the page the only option for everyone who uses the site. This is your last chance to let us know if something is very broken for you: checking now, and reporting any problems you might have, will prevent future disruption to your use of the site. Please take a moment and enable the beta so you can help us find any last lingering issues.
The other major beta we have running right now is the New Inbox Page conversion. This is part of our ongoing modernization efforts: Dreamwidth itself was launched in 2009, but because it's based on LiveJournal's open source code, parts of the site date as far back as February of 1999. (If you're as bad at math as I am: that means three months from now will be the 25th anniversary of the code that runs the site existing in some fashion. Please don't tell me if my website's source code is older than you are; I already feel old as hell just thinking about it.) As you can imagine, the technology that runs the internet has changed significantly in the last 25 years, and we've been engaged in a long, slow-motion project of updating the code that generates all of the pages on the site to use more modern technology. Like with the new Create Entries page, this makes it seriously easier to maintain and allows us to benefit from the accessibility, usability, and bugfixing work that other people using the same technologies have done: the old way of doing things was unique to DW, while the new way of doing it uses more widely-used frameworks and modules so we can benefit from many other people's work.
Converting site pages to the new way of doing things involves a complete rewrite from the ground up, though, and while we try to keep the two versions looking as similar as we can, it's not always possible: some changes to how the pages look and feel are inevitable. There's also, of course, the opportunity for new and exciting bugs. So, when we've been converting major pages, we run it through a few rounds of beta first. The inbox is one of the last remaining big user-facing conversion projects, and we wanna get it done and dusted so we can pick off the last outstanding pages to convert and finally be done with this massive albatross of a project we've been working on for-freaking-ever. (We're about 80% done, and this fact is very exciting after having been working on it for so long.)
If you haven't enabled the New Inbox Page beta to test it, please consider doing so soon! (And if you had previously enabled it and found a bug that made you turn it off, please try turning it back on: we've done a lot of bugfixing work.) Because of how old the old Inbox page was, this is one of the more dramatic "things will look different" conversions we've done and the new version may take a little while to get used to, but all the major functionality should match and it includes a number of bugfixes that the old version of the inbox doesn't have.
We will soon be removing the New Inbox Page beta and making the new, improved version of the page the only option for everyone who uses the site. This is your last chance to let us know if something is very broken for you: checking now, and reporting any problems you might have, will prevent future disruption to your use of the site. Please take a moment and enable the beta so you can help us find any last lingering issues.
Finally, a few years ago we converted the journal entry view from the old code to the new code. Despite us aggressively running it through the beta system before making it the default for everyone, a few people experienced some dramatic bugs (including some wetware bugs: it triggered photosensitive migraine in a small number of people). While we worked to fix the problems people reported to us, we enabled a beta flag to let people turn the new code off (as opposed to our usual method of using the beta flag to turn the new code on).
We've done a significant amount of work on the problems people reported with the new journal entry view, including working with a number of experts on photosensitive migraine and a panel of the users who reported that the new code triggered photosensitive migraines for them. At this point, we're reasonably sure that we've fixed every issue that was reported to us, and we're making preparations to remove the beta flag that allows people to turn the new code off. (Keeping two versions of the code for this long is a lot of maintenance overhead, and we can't keep the old code around forever.)
If your account has the "Temporarily revert updated journal page components" beta flag on -- that is, if you previously experienced a site-breaking bug with the new code and had to disable it while we fixed it -- please go to the beta page and turn that beta flag off. This will switch your account to using the new code that every account created since the conversion has been running and let you verify that the particular issue you were having has been fixed. This is probably the most critical action for people who had problems with the conversion to take, because we really need to close out that beta and stop having to maintain two versions of the code, but we don't want to break things for you again!
We will soon be removing the "Temporarily revert updated journal page components" beta and making the new, improved version of the journal entry view pages the only option for everyone who uses the site. If you previously enabled the beta flag in order to temporarily use the old code while we worked to fix it, it is very important that you turn off that flag now and verify that your issues with the new code have been fixed. Please take a moment and disable that beta if you have it enabled so you can help us confirm that the problem you had is fixed.
(The remaining individual beta flag, two-factor authentication, is a very early test that was released as a beta so people can test out the process of configuring an optional two-factor authentication setup. While you can set your 2FA preferences, none of the site login pathways actually use 2FA yet, so enabling it won't do much. The final flag, "site-wide canary", is a generalized "this is the cutting edge code that we've just committed and will be released in the next site update" setting, and you should only enable it if you like living dangerously and occasionally finding that everything breaks horribly.)
For all of these beta flags, if you enable them and have problems, check the Beta Features page listing for that specific beta flag listing: there's a link to the specific entry in
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
no subject
Because we forked from LiveJournal's open source code, Dreamwidth itself is 14 years old -- which by itself is old enough that we would be having bugs and issues manifesting with code that was written when the site first started -- but the code that runs it is actually three months away from turning 25. The world of technology has changed so dramatically in 25 years -- both in terms of how people access and use the internet and in the underlying technology of browsers, operating systems, and internet standards -- that it's barely recognizable to me sometimes, and I was there and personally involved for the entire time. At this point, the code that runs Dreamwidth is so old that whenever a major browser manufacturer releases a new version of their browser, whenever the internet standards committee releases a new version of the standards that govern the web, a desktop or mobile operating system manufacturer releases a new version of their OS, or one of the third-party modules that allow the site to operate releases a new version of their modules that incorporates a critically necessary security fix, there is about an 80% chance that at least some part of the entire site will break horribly (sometimes to the point of refusing to even run at all, for anyone) and we need to drop literally everything we're doing and spend an incredibly urgent several hours trying to solve the problem and let people get back to using the site.
We used to be able to say "oh, we have this minor bugfix for a thing that's been annoying people, let's get that running on the site itself so people stop having that bug" and just do it. It's been years since that's been possible, because every time we need to do a code push to get the new changes and bugfixes running on the site, we need to find a time when multiple people can be available for a solid 8 hour window afterwards to fix the disasters that are going to happen -- and that's after we've already tested even the simplest changes to death in our development and testing environments, found the most obvious ways in which it's going to break when it hits the live site, and fixed them. A solid 95% of our development time and effort that isn't going into desperately finishing the modernization process is going to trying to keep the 25-year-old bits of the site that haven't yet been updated from dying. We have dozens of intermittent bugs and weird issues that nobody can figure out how to fix, because the answer is "something ancient has just stopped working, and it is no longer possible for us to identify what in particular". Technology is entropy, entropy always wins, and we are doing our very, very best to hold back the entropy enough that y'all don't notice it, but it gets harder and harder literally every day.
I know you love Dreamwidth. I love how much our users love Dreamwidth. Please understand that I love Dreamwidth just as much, if not more. I have devoted a decade and a half of my life, worked at the absolute limit of my physical capacity even during the worst of my disability issues and even when it's made my disability issues much worse, and sacrificed, at a conservative estimate, approximately $2m in lifetime career earnings, all in order to prove that it's possible for a small group of dedicated people to run social media in an ethical and aboveboard manner that puts users' needs first and refuses to resort to advertising, venture capital, or sacrificing users' privacy. I have devoted (and continue to devote) significant amounts of time and effort to the legal efforts to fight back legislation that would endanger internet users' privacy (and we won the latest one, at least so far: Dreamwidth is at least partially responsible for the fact you will not have to scan your face or upload government ID beginning on July 1 2024 in order to use social media if you live in California).
We don't make changes because of marketing, or advertising, or shareholder profit, or metrics, or venture capitalists, or the CEO's ego, or any of the malignant motives that other social media sites are motivated by. We do not give a fuck about profit: we have promised ourselves and we have promised you that we're keeping Dreamwidth running for as long as our users pay us enough to cover the cost of server power, professional services, and an extremely modest honorarium to the few people who need direct database access to do their work for DW and therefore have access to a significant enough level of sensitive data that it means "us paying them so they're considered employees and therefore agents of the company" provides everyone involved an additional layer of legal protection against government subpoenas. We do not have any venture capitalists or outside investors demanding that we make the line go up or insisting that we show unsustainable growth quarter-over-quarter. The only factors that affect the decisions we make for Dreamwidth is "what's best for our users" and "what will make it possible for us to continue to keep Dreamwidth alive for as long as possible". When I tell you that I have a thirty-year plan for this site, I am not exaggerating.
We are past the point where "modernizing the code that generates the site" stopped being "an important project, but one that we can work on in between everything else" and started being "if we do not finish the last of this project within the next several years, eventually the site is going to break to the point where it will not be possible to unbreak it without heroic efforts". Dreamwidth cannot continue to exist unless we finish this work. We're going to extreme amounts of effort and doing our very best to do it with the minimal amount of disruption to everyone's routine as possible, but it has never been a choice between "make these changes or keep everything the way it was". It's a choice between "make these changes or the site dies". I love Dreamwidth and I don't want it to die.
no subject
no subject
Thank you for all that you and everyone else involved do... I wish it were easier on you. What you do is really, really appreciated.
no subject
no subject
no subject
Thanks you for the work you—-and all the others on Dreamwork’s team—-do to keep this site running.
As someone whose been into fandom since the tail end of livejournal and been trying to get back into focusing on long format online content in the last few months, I know I am one of many who has been guilty of taking Dreamwidth for granted.
We go “well Dreamwidth is always there!” and we don’t think about the massive amounts of work (and oodles of personal sacrifice) that has to be done to ensure it stays here.
So, thank you.
no subject
no subject
no subject
💔 Thank you for all you do, Denise.
no subject
no subject
no subject
no subject
no subject
no subject
Thank you so very much for keeping this awesome place running! I love that you're willing to communicate the changes with us! And I very very much hope that you will be able to be done with this project as soon as possible, and that you'll eventually be able to do the things you'd want to do with this site. Again, thank you for proving that such a website can, indeed, exist. I wish you and the teams the very best of luck!
no subject
no subject
no subject
In particular, image embedding and cuts are now seamless in the post editor, and I find the new inbox layout easier to navigate.
Thank you for all the hard work. There's a reason this is my online base of operations.
no subject
no subject
no subject
I just read this again, and it's such a wonderful essay. I'm so glad that I chose for Dreamwidth.