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
1) The ability to move panels around is great! It is deeply unintuitive to me that you do that from Settings. I actually didn't realise the Settings button existed due to where it's placed (attached to the subject line) until it was pointed out to me, and even if I had seen it I would not have thought 'this will let me drag and drop panels around' - since it's attached to the subject line my immediate inclination is to think it's settings for the post. Some clarity as to the fact that it's actually page settings that persist after you post this specific entry, and what exactly you can do in those settings, would be nice.
2) It would be amazing if we could have the sidebar on the left, move things like icon, date, &c above the subject/entry, and move tags, currents, the journal we're posting to &c above the post button. Doing that sort of stuff first - especially when I'm, say, archiving backdated fic to my fic comm, or making sure that I'm posting fandom exchange posts to the relevant community rather than my personal journal - is an integral part of how I post.
2.5) Actually nevermind part of that, I found the standalone 'Post Entry' button below the tags and stuff after I scrolled. Still find it weird that there's two Post buttons, but less annoying than I'd thought.
3) Any chance of the Casual HTML/Markdown/etc thing being tabs on the textbox instead of a dropdown, or a thing we can set a default for elsewhere, or becoming a moveable element? It's just. Really awkwardly placed, imo. Especially when I'm keyboard-navigating, i.e. trying to move from subject to entry just by hitting tab, it's jarring to have something in between the two.
4) I like the tag and icon browsers! I like being able to hide things like crossposting that I'll never use! I do not want to be an endless fount of negativity!
5) Are we locked in to there always being two columns under the entry form, even if one is empty? It would be great if the tags &c modules could expand to fill the whole space rather than being scrunched over to the left like in this screenshot [Firefox, Windows 11]
no subject
You can set your Casual HTML/Markdown choices and they should stay. Go to Account Settings>Display>Entry Editor Default, and there's an option for 'Last Used'.
no subject
no subject
2) Unfortunately, there is a list of reasons longer than my arm for why the only place you can put modules in the "sidebar" option is on the right side column (and not the top or the left) -- the biggest one is accessibility (the technical limitations of how the page is generated and the details of the kind of HTML elements that are on the page itself means that placing modules before the text box would violate several different accessibility rules, plus there is a cognitive accessibility issue with hitting the sweet spot between "just customizable enough that people can set it up to their own workflow, not so complicated that it causes cognitive overload") but there are a number of other reasons, both technical and usability, that are individually relatively minor but build up to cause A Big Problem that's almost impossible to solve. (We had to solve a depressing number of issues just to make it possible for the modules to be moveable in the first place.)
(The reason there are two post buttons is to accomodate the two major workflows that people use -- our analysis basically showed there's one group of people who set their settings, write the post, and then hit post, and one group of people who write the post, set their settings, and then post, the distribution is about 50/50, and the workflow analysis we did with each group said that one group strongly preferred the "right under the text box" post button and one group preferred the "after the settings panels" post button. That was one case where the answer could be "put them in both places" without it complicating things, so we did that.)
3. This is yet another case of "we agonized over the placement of that one and everywhere we put it was wrong so we had to settle for the least wrong for now". There's going to be a future change to some of the modules to regroup a few settings involving post formatting options, at which point we'll probably put it in there, but it has to wait until we can do a specific major project that we've been stalled out on (partially because of the demoralizing effect of having all this half-done stuff lying around, partially because part of it does need more of code conversion to be done in order to avoid having to do a lot of extra unnecessary work, partially because the project itself is going to be incredibly huge and technically very complex). tl;dr: yeah, it kinda sucks to have it there, I'm sorry, all the other places we tried putting it for now sucked way more and the more ideal long-term solution is held up by a lot of work that's going to be a complete pain in the ass so we haven't been able to do it yet.
5. There was no way to make the modules stretch to fit across the entire space there without them being seriously distorted -- we tried with various minimums and maximums, and the current width range was the best we could come up with. The exact number of columns that fit under the entry text box depends on the width of your browser window and the resolution of your monitor: it's not always two columns. (I think the minimum number is one and the maximum number is four, but it's been a few years since I looked at the details of the breakpoints.) My update page has three, for instance, because of the resolution I have my laptop set to and the width I have the browser window set at, and I can trigger it down to two by making the browser window about 2" less wide.
My suggestion there: either try playing with your browser window width a little bit (while you have settings mode open: that way you can see the column outlines and observe the breakpoints at which the overflows get triggered) and see if you can come up with a width that's not that much larger or smaller than you had it but makes the overflow behavior better visually for you, or try moving some of the modules you've left toggled on into one of the other columns to spread them out over the space.
no subject
2) That's ... sighs, gonna be much less workable than I'd thought then. Oh well, good to know now.
3) Actually I have since gone back and nuked it with uBlock's element picker since I never use anything but casual HTML and at least this one thing is totally fixed for me now! Not sure I recommend it as a wider solution, but it doesn't seem to've broken anything for me personally. (Cue me forgetting and wandering back three years later when you've finally moved it somewhere else going 'why is there a giant blank space over here' or something)
5) Augh, I suspected but the confirmation doesn't feel great :| I have to make my window extremely small to get just one column underneath (small enough there's no room for the sidebar and the icon choice is back underneath, and that the preview button is awkwardly right-aligned on its own line) and the reason I asked was because I don't want anything in the second column.
FWIW, even though I've hated that every answer you've given here/in other comments on the post boils down to 'sorry, you still won't be able to look at the new Inbox/journal entry pages or set up a workflow you like in the new Create Entries page' I truly, deeply appreciate the amount of personalised troubleshooting you've been doing for people. I know I probably sound real grumpy (and I kinda am, tbh), but it's fully a ... state of the modern internet in general thing, not a you thing.
no subject
-- Good to know that uBlock can block that; I'll keep that in mind for recommending to other people who have issues.
I will be completely honest with you: it is incredibly demoralizing, disheartening, frustrating, and discouraging to every single person who works on this project to be repeatedly accused of malicious intent, to spend significant amount of time explaining the compromises we've had to make in order to deal with the very real, very severe, and very urgent constraints we are operating under only to have those explanations characterized as dismissing people's concerns or deliberately choosing to harm someone, to be accused of changing things for nefarious purposes, to be accused of deliberately harming people with visual design changes or not caring about people who experience visual sensitivity to screen-based content when we have spent considerable time and effort consulting some of the world's experts in neurobiology and the processing of visual data in order to assemble and be guided by the most comprehensive amount of state-of-the-art information about visual sensitivity to screen content available to any website I am aware of, and generally to be treated like providing the honest, pragmatic answers of "we know this is a problem for some people, but it's a compromise we have to make to solve these other problems", "we know this is a problem, but fixing it would require resources we don't have", and "we know this is a problem for some people and we'll keep trying to fix it, but a solution may not be technically possible" are indifference, personal attacks, or deliberate insults.
I am the only person who works on this project who is even willing and able to do this sort of communication anymore, and I am only willing to do so because I have no other choice because it's my website and someone needs to do it. Every single volunteer developer who has put an unprecedented, amazing, and heroic amount of time, effort, and energy into doing the work that desperately needs to be done in order to keep this site alive with the smallest amount of disruption we can manage to achieve to everyone's routines and habits -- and I am not exaggerating in the slightest about the level of urgency and severity that this work carries -- has eventually had to completely stop handling feedback, bug reports, and reports of UI and UX issues due to the vitriol and accusations of bad faith they've received for it, and the vast majority of instances of us trying to find a workaround for someone who's experiencing problems now takes multiple rounds of back-and-forth communication in our backchannel systems because I need to be the middleman and spend a great deal of effort and emotional labor stripping the vitriol from the summary of the problem and attempting to parse out the core of the problem into something that can be addressed or remediated. This urgent project has burned out double digits of talented, passionate people (people who have critically, urgently-needed skills we have been desperate for for years) to the point where they are unable to continue working on the project for their own mental health, and it has made multiple more people decide that they will never touch anything user-facing again. This conversion project would have been done years ago if it weren't for the fact that the majority of people who have worked on it do one conversion and the process is so unpleasant for them to experience that they never touch another.
I am, as I've said multiple times, both extremely sympathetic to change aversion and deeply aware of how much it sucks when something becomes less usable to you because of the compromises that need to be made in order to make it more usable to another group of people. I hate that we can't make things ideal for everyone no matter how hard we try. But we spend more time and energy to get things "close enough" for as many groups of our users as we possibly can than literally any website on the internet, to an extent that it often winds up impeding our ability to make changes that are desperately needed and our ability to add features that people have been asking for for years. Doing all of that work and putting in all of that effort and still getting accused of malice is an incredibly shitty experience.
I am very frustrated and very burned out by this, and I absolutely admit it is inevitably coloring some of my comments no matter how much effort I am putting into keeping it out of them. But having yesterday's "I spent 18 consecutive hours engaging in emotionally gruelling work, while also blowing well past my physical capacity to perform that work in a way that will have negative consequences for me for weeks because the work needed to be done relatively rapidly, in order to try to find workarounds for people who are having issues with things that have been in development for years' worth of experimentation, compromise, and balancing competing needs" characterized as me saying "sorry, you still won't be able to look at the new Inbox/journal entry pages or set up a workflow you like in the new Create Entries page" is just unfair, come on.
no subject
Sorry, I absolutely don't think you're doing any of that and if I've come off that way I've failed to differentiate my disappointment in stuff that doesn't work for me and my appreciation for everything you do, that's on me. I wish I could be more excited about the changes partially because I know how much work and care you've all put into it.
...Yeah, no, reading back the last bit is far more flip than what I meant and over the line for what's appropriate for newspost comments regardless, I'm sorry.
no subject
no subject