Stacks Editor development and testing

Question

Update April 10, 2025

We are planning an integration of Stack Snippets into the new editor (削除) and are looking for community members to join a working group to test it out. Those who sign up to be reviewers will receive an invite before the start date of April 21st. (削除ここまで)

Update March 6, 2025

Test Results

Our hypothesis for this test was that the Stacks Editor’s rich text functionality would be more accessible to more users, leading to an increase in answer task completion. Meaning that we would see an increase in users who started to type an answer, complete, and submit.

The Stacks Editor performed 8.6% better than the current editor for answer task completion. This means that the Stacks Editor can lead to +3,000 more answers a month on Stack Overflow, which is a significant increase.

Given the qualitative feedback from the research study and the test results, we’re excited to graduate this experiment in phases to general availability on Stack Overflow.

Next Steps

We’re going to release Stacks Editor to Stack Overflow in two phases:

1. Today, March 6, 2025, we will enable the Stacks Editor for all users answering questions on Stack Overflow, except for the tags that may get value from Stack Snippets:

   javascript html css reactjs angular node.js jquery react-native next.js typescript tailwind-css

2. Once we add Stacks Snippet support to the Stacks Editor, we will enable it for the remaining tags noted above. We will post an update here before that happens.

Bugs

While the A/B test was being conducted, we were busy resolving bugs from the existing backlog and some that were raised in the comments here:

In progress:

• Stacks Editor is doing rapid layout shift as I edit the body input - Fixed
• What causes single backticks on every line of code? - Meta Stack Overflow - Fixed
• Paste in code, remove code block, any text changes remove all line breaks - Fixed
• Arrow key navigation broken in code blocks in Stacks Editor - Fixed
• No way to advance above a code block that is the first element - Fixed
• Extra line inserted when advancing past code block to following HR element - Fixed

We’re committed to resolving the top-priority bugs and any new priority bugs that may be filed after the releases.

If you see bugs related to the Stacks Editor in the future, please write a new question with the details (one question per bug) and tag the question with bug and stacks-editor.

Opt-out

Given that some users may rely on user scripts that interact with the current editor, we will include an opt-out option in the user settings (similar to the opt-in that is there now for the Stacks Editor Beta) so that users who choose to opt-out can continue to use the scripts and provide the opportunity to update them to work with the new Stacks Editor.

Settings/Preferences page with Enable new editor option toggled on

Question Asking

Once we’re done releasing the Stacks Editor for answers, we’re going to work on testing it with question asking with a focus on creating a consistent authoring experience with one editor for everyone. We’ll set up a separate post to talk about updates on the question-asking focus of the editor once we are set to begin work on that phase.

Thank you for your help and feedback on this first phase of the experiment. We’ll be updating you and asking for more input as progress on the Stacks Editor continues.

---

Background

In 2021, we launched the Alpha of the new Stacks Editor. After incorporating your feedback, we launched Beta 1 along with Ask Wizard in July 2022, followed by Beta 2 a month later. We continued to collect your feedback and address bugs, but eventually, the project was deprioritized to focus on other work.

Since then, the Stacks Editor has been used by 21,000 users a month as part of Ask Wizard in Staging Ground on Stack Overflow and used by almost 11,000 users as part of the opt-in beta available to Meta. However, the Stacks Editor isn’t available across all of Stack Overflow.

Our ultimate goal is to provide a modern, intuitive, and consistent experience for asking questions, answering, and authoring any other rich content on Stack Overflow. Also, maintaining multiple experiences is also not effective from a technical and cost-effective perspective.

As mentioned in this post about our upcoming initiatives and how the product teams are embracing experimentation, we have jumped in with a usability study and a future A/B test.

Usability Study

Last week, we ran a usability test comparing the current editor with the Stacks Editor with both experienced and novice authors, and what we found is promising:

• Strong preference for the Stacks Editor with experienced and novice users
• Those who preferred the Stacks Editor liked that it’s "What You See Is What You Get" and the syntax highlighting
• Those who preferred the current editor preferred it because it’s familiar
• Suggested improvements include more keyboard shortcuts, automatically formatting code blocks, and a dynamic editor resizing

While this usability study gave us valuable insights, we recognize the importance of gathering more comprehensive data. To this end, we have decided to expand our user group and conduct a more extensive A/B test.

A/B Test

To better understand the Stacks Editor’s general availability readiness, we plan to run an A/B test on February 19, 2025 on Stack Overflow where half of users will see the Stacks Editor and the other half will see the current editor when answering questions. What we will be looking at during this experiment is:

• Does one editor lead to more:
  • Answers submitted
  • Number of edits
  • Number of comments
  • Number of flags
  • Number of deletions
• Do the editors perform differently based on a user’s experience level on Stack?

During our usability study, we initially focused on qualitative data. However, to fully understand user preferences, we're now shifting our attention to the quantitative data revealed through specific metrics. This shift helps us get a more complete picture.

For example, we'll monitor when users start typing and successfully post their responses, aiming to see this metric remain steady or improve over time.

We'll also examine other factors like edits, comments, flags, and deletions. These aspects can provide insight into the overall health of answer completion. If these elements increase, our efforts might not be as successful as we hoped.

In the end, our goal is to maintain a balanced view by considering the overall health of answer completion. We will be monitoring these metrics closely to determine the test's success.

Update: In light of the feedback received, we have opted to exclude HTML, JS, and CSS tags from the test to ensure that users working within these tags remain unaffected.

Next steps

After the test is concluded, we will conduct a comprehensive analysis of the data, segmented by user experience, to inform our investment decisions regarding the editor. Our primary objective is to assess whether the editor performs satisfactorily to warrant a full release to all Stack Overflow users. Furthermore, this analysis will aid in prioritizing our existing feature requests and more effectively addressing the bug backlog.

Our long-term goal is to deliver a consistent and user-friendly experience for content creation on Stack Overflow, and these tests are a crucial first step toward achieving that objective. Community input plays a vital role in this project, so please continue to share your feedback below.

• RobH: Maybe fix the known bugs before forcing anyone to use it (even if it's for testing. What good is testing if it's not release ready? The test results will not be valid.
• Kevin B: Have you investigated yet why users who use this editor routinely end up publishing posts that are entirely wrapped in a code block?
• Kevin B: Will editors be forced to use the stacks editor when editing stacks editor created posts so that the content won't be mangled when going from one to the other? and the reverse?
• Thom A: "Have you investigated yet why users who use this editor routinely end up publishing posts that are entirely wrapped in a code blocck?" That would explained 50% of the crap I see in the Discussions area, @KevinB .
• Kevin B: Can we get a "I don't like this, please take me back to the old editor" button, on the editor itself, even if only after the first few days or week, so that we can measure user sentiment of users who are actually using it instead of only relying on outcomes?
• JonH: Sometimes I truly am curious how development works at SO. Like the development team surely knows this is wrong, who on earth is managing these projects, setting priorities, who is in charge of fixing bugs. WHO? Why is no one being held accountable for the processes you guys seem to be making that are doing nothing to solve the problems we currently have. If you search on the meta you will find bugs we have been waiting to be addressed for years. We are going backwards.
• Thom A: "with both experienced and novice authors" where? Internally? Define me "experienced"; active users that contribute a large amount of the content that Stack Overflow depends on for the quality of content your site is know for?
• user1114: A lot of the company's decisions are wrong for subjective or value-related reasons, but this is just an objectively incorrect course of action. The Stacks editor is defective. It has many entirely showstopping bugs that make it literally unusable and block users from interacting with the site. If the company has, for years, been unwilling to spend the resources to fix those bugs, they must remove the editor from the site altogether, not spread it more widely. The folks in management who made these decisions are clearly not paying attention: You are actively breaking the site. Stop it. Now.
• Thom A: Honestly, these announcements followed by no staff response frustrate me as well; it's like a user on the main site, where they ask a question and then immediately abandon the question. If the site doesn't want the community's input/response on these things, I'd rather they lock the post after making it so that we can't comment and answer, and we just nuke the post with down votes...
• l4mpi: @Bella_Blue great! Now please exclude all the other tags as well.
• terdon: @ThomA come on. Complaining about "no staff response" when it hasn't even been 24 hours since posting seems a bit much. This was posted at 16:31 UTC, and your comment came at 9:49, less than 18 hours later. SE staff are human too, you know, and might even have a life outside work. We have loads of valid complaints against SE, but being annoyed because employees don't answer immediately, right this minute and not a second later is unfair.
• Thom A: I'll happily die on that hill, @terdon . Stack Overflow gave us less than 24h notice; the least they could have done was be responsive to answer; we expect the same from users on Stack Overflow.
• terdon: Well yes. And they were responsive. They just didn't respond in an unreasonably quick time frame is all. And don't forget time zones. Anyway, if that's the hill you want to die on, carry on. If I were you, I'd focus on their giving 24h notice, that is a problem. As is the frankly awful editor.
• VLAZ: "we are working on it" doesn't tell me why you decided to release it without the top priority bug being fixed. If you really expected the fix to be "soon" - why not wait a couple of days? Where does this deadline to push out the barely-beta editor come from?
• Lundin: Given that this isn't an isolated incident but how every bad, broken feature has been rolled out for well over a year, the person who makes the decision to launch these things needs to be stopped.

Answer 1

This experiment is another waste of time for everyone involved.

The stacks editor is barely usable. Forcing such a half-baked feature onto the main site without the ability to opt out will not end well.

Also, I am having a hard time understanding how you will get any relevant information about editor usability based on metrics you mentioned: answers submitted, number of edits, number of comments, number of flags, number of deletions.

What you should be asking is that users give you direct feedback on the editor, not using some vague metric that is only marginally related to what you want to verify.

• Kevin B: "For example, we'll monitor when users start typing and successfully post their responses, aiming to see this metric remain steady or improve over time." <-- that is the only metric i see that might provide some data on usability
• Dalija Prasnikar: @KevinB How much time is needed to type something does not solely depend on the used editor, but also what are you typing at the time. I can write fast or very slowly, depending on what I am writing. Used editor will have impact on time, but it is not a metric that can be used as such for determining the success of the editor.
• Kevin B: i mean... if it's being compared against a control group using the old editor during the same time period, presumably, if the group sizes are large enough and varied enough, it would be usable data. but i of course have no insight into how effective stacks A/B testing is at providing this
• Dalija Prasnikar: @KevinB I wouldn't get my hopes high...
• Passer By: @KevinB A few weeks late, but imagine the editor being so bad people open a separate editor and copy from there once finished. A miraculous reduction in editing time I tell you.
• AJM: @DalijaPrasnikar What do they mean by "start typing"? If I start by highlighting some text and using Ctrl-C to copy it (say a URL that I'm looking for an archive version of) does that count as typing?
• Dalija Prasnikar: @AJM I have no idea... that is something only SE employees responsible for the experiment would know.
• Ash Zade: @AJM those are two different events. We track copying and pasting separately from typing characters.
• AJM: @AshZade Thanks for clearing that up!

Answer 2

This will severely hinder people who are in the B group who want to add a runnable code snippet to their answers.

I personally do this a lot because I tend to answer JavaScript questions and I think giving runnable examples is important to illustrate my answer. However, since the new editor does not have any support for snippets (and even re-uses the snippet icon for something completely different), that means answerers across the html, css, and javascript tags (along with tags around these) will be unable to post proper answers.

• jsmb: Appreciate the feedback. We're taking steps to exclude html, css, javascript and a cluster of related tags from the A/B test. To provide some colour to what we were thinking here, we ran some numbers on the overall usage of Stacks Snippets and originally came to the conclusion that it was effecting a significantly low number of Answers (3-4% of all Answers); however you're right in that due to the nature of Stack Snippets, that particular community would bear the brunt of that friction. Naturally, that's not the intention here.
• starball: @jsmb what does "it was effecting" mean? did you mean "affecting"? affecting in what way? what numbers did you run? can you really call this "friction? friction means it's harder to do something- not impossible. if you call this friction, how great must the normal force be!? it's like you're trying to grind these users into the dirt. how are those people going to add stack snippets?
• jsmb: Stack snippets are not the sole means of answering questions regarding web-based languages. The friction I'm referring to is being able to write a good quality answer to those questions without using Stacks snippets; something that other language tags already do on a daily basis. Again, the data we have supports this approach, but it's a fair criticism that this ignores the human element that it's a tool that some users lean on more heavily, and so we're taking steps to rectify it.
• Thom A: That's because those other languages have other solutions that are external to Stack Overflow, @jsmb , such as "fiddles" for SQL questions, or Regex testers for Regex questions. Other tags on the site don't use the Snippets feature because it's no use to them, they have other tools, but that doesn't make Snippets not-useful for the parts of the site that the snippets feature is specifically aimed at... That a web based question/answer can be posted without snippets doesn't devalue snippets, especially when you make it impossible for the post to use the snippets feature.
• DavidG: You say 3-4% of answers, but what is the percentage of answers in the html, css and js tags? Or what about react or vue.js? etc.
• starball: even 3-4% is a lot of answers.
• jsmb: On web-based questions, its hovered around 14% in the last year. Roughly half of those would be affected. Given the tooling available for these tags other than Stack Snippets, and the short-running nature of the experiment we took the stance this was an acceptably small amount of users to be affected to run the experiment. Again: this is a decision we have since reversed thanks to your feedback.
• Bella_Blue: I have updated the post to reflect that we have excluded these tags from the test.
• M--: @jsmb "We're taking steps to exclude html, css, javascript and a cluster of related tags from the A/B test"... This reads like you're taking steps to test an incomplete and not minimally viable product. Reading the feedback here, you'd know that the editor is absolutely broken and riddled with bugs. Yet, I am sure this unsolicited feature will get more development time than all the positively received FRs on meta sites.
• jsmb: @M-- You're free to read it that way, and people are entitled to the opinion that the editor in it's current state is not an MVP. I'm asserting that snippets while useful are not what we consider to be minimally viable. The feedback here is a strong signal for what we already know: that there are bugs in the editor that need addressed. What it is not is proof that those bugs are showstoppers, and a good way of proving that is to test if it has a negative impact in the number of answers submitted.
• jsmb: The plan is not to kick the editor out as is, it's to measure where the best effort is placed moving forwards. As an example, thanks to this thread, we've moved up plans to add Snippets to the new editor. The fact is that the existing editor has a bunch of features, but it's also long-in-the-tooth and makes newer features more taxing to implement. While we're talking about changing how the developers and meta communicate, this is me attempting to fulfill my end of the bargin by talking honestly about the intentions of our team.
• M--: @jsmb to me it seems you're taking my comment a bit too personally. I understand it's tough not to; anyway, I have given up on posting answers on Teams or Discussions before. Last night, I gave up on posting a question (well, I couldn't post, do you consider it MVP?). This is not about how the devs and meta communicate. You're not to blame. It's about the top to bottom incentives. Almost everything needs to be something shiny worth showing to investors. Quality of life updates are rare. P.S. I don't mind if you leave this unanswered. Not my most pleasant comment but again not personal.
• jsmb: @starball It assumes nothing about stacks snippets, intentions of the user or contents of the answer. A/B testing is purposefully devoid of these nuances, in favour of raw volume. All we can say is "Did the new editor deter answers, on average?" and further dip tests of "did answers using the new editor get edited more than those did not?"
• starball: @jsmb in the context of the comment starting "you're free to read it that way" starting about stack snippets and ending about A/B testing about bugs, and how I see stack snippets not being supported as a bug, I assumed the two points were related, which may not have been what you intended.
• jsmb: Yeah, fair. I'm mixing streams a bit here, not the clearest of communication on my part.

Answer 3

I don't think A/B tests are the right tool for this. You need to actually test the editor thoroughly in various situations and fix all the bugs.

Quite a few are probably reported somewhere here, but many likely aren't because the SE power users tend to avoid the editor. An easy one for now, the Markdown + Preview mode flickers like hell, it's essentially broken entirely and unusable.

You also chose the most difficult kind of editor possible, a WYSIWYG editor with Markdown mode and the ability to switch between those. You really need to make sure the switch between those modes is robust, otherwise posts will break. Not just because the user switches, but also because later editors might use a different mode. You probably need some analytics and safeguards to detect these bugs in the editor itself, bug reports might not be enough (especially as many cases will be hard to reproduce).

Here are a few bugs I found just playing around with the editor for a bit:

• Blockquote button behaves differently in WYSIWYG mode and Markdown mode

• Inserting a link to an SE site creates an endless loading spinner

• Inserting links is confusing in Stacks Editor WYSIWYG mode

• Stacks Editor creates spurious newlines when pressing "down" key inside code blocks

Answer 4

Our primary objective is to assess whether the editor performs satisfactorily to warrant a full release to all Stack Overflow users.

I sincerely hope that does not mean forcing everybody to use it.

• Cody Gray: I have already stopped posting answers on Teams due to the Stacks editor being mandatory there. If it is rolled out to the main/meta site, I will have to do the same there, too. It is completely unusable for me. None of the bugs that make it unusable have been fixed.
• Sinatr: Fixing bugs or implementing demanded features is boring. Rolling mindless experiments is fun, so much fun to annoy users... I need everytime to click twice to start typing comment over a week already, going to get used to suffer here (the wish to help and share is so far greater than discomfort). You will get used to suffer too!
• Bella_Blue: Part of the decision for this test is to prioritize the list of bugs so that the usability of the Editor will be improved. Can you expand on which bugs you find most inhibit your authorship?
• VLAZ: @Bella_Blue I have userscripts that massively improve the old editor: Three Columns and Magic Editor. The new editor will kill them with no suitable replacement. Not to mention that using it is just unpleasant. Even in markdown mode it tries to add styles to what you write which tends to be very distracting rather than helpful.
• VLAZ: @Bella_Blue as for bugs - I can't point to many off-hand because I just avoid using the editor. That's not to say there aren't, but I just find the experience of using almost any WYSIWYG editor to be various shades of bad. The Stacks editor proved to be no exception.
• user1114: @Bella_Blue my top bug is this one which makes it impossible to edit large posts on iPhone/iPad. I’ve heard of similar bugs from Android users but I can’t see a bug report. Most of the internet has been spending the last decade trying to better support mobile users, and I know that the priorities are a bit different for resources like Stack but rolling out an editor that’s effectively broken for many (potentially most?) mobile users would be a disaster. It might be very difficult to isolate the impact in your analysis but I encourage you to try

Answer 5

Look, I can tell you already that if I get this editor on the main site, I will either stop or reduce my activity on the site close to 0. The stacks editor is VERY ANNOYING. It has no advantages in my opinion. I only use it on Meta because you force me to. I cringe every time I have to edit a user's post in SG and sometimes I just prefer not to edit it myself and let the poster suffer.

The Stacks Editor is terrible!

---

• I can't use userscripts with it
• It has weird glitches
• It has bugs that break the code when pasted
• Grammarly doesn't work with it

• Kevin B: wait, where on meta are you forced to use it? isn't it an opt in on meta? i don't get the new editor on meta,
• Henry Ecker: Stacks Editor is (currently, at least) opt-in only. Settings can be changed in profile settings and toggling "Enable new editor"
• Dharman: TIL I can turn it off
• Ryan M: "It has no advantages in my opinion" Undo and redo work correctly, resulting in much less work being unexpectedly deleted, as is the case in the existing editor. As an experienced user, I expect the bug and know how to work around it so that I won't lose work, though I lose the benefits of a working undo function. However, before discovering this, I had to redo a decent bit of typing.
• Kevin B: I generally see the new editor as a net positive, as long as they can fix the issues it has and it keeps having a markdown mode for those of us who prefer it. But... that work needs to be done. If they do away with the snippet editor I’ll certainly be disappointed... given it really shouldn’t be that difficult to just just trigger in the existing solution if it’s too much work to do it they way they’d like to.
• Makyen: @RyanM Fixing undo and redo in the old editor would be trivial for SE to do. All they have to do is rip out the decade+ old code that hooks those key codes, which they should do. Alternately, IIRC, a userscript could be created to prevents the SE code from catching the keyboard events for those keys and just having the browser default.

Answer 6

STOP DOING ALPHA TESTING ON THE LIVE SO SERVER.

I'm done asking nicely and I had it of constantly getting treated as a guinea pig for your next buggy experiment. This is nowhere close to professional.

The editor is horrible! Did you even try it once yourselves? It makes the whole web browser flicker as the bottom of the site bounces up and down with each letter you type. It lags when you type. You can't paste text inside quotes - the site apply formatting of the whole thing incorrectly. Code formatting is clunky and buggy. And so on.

It is ROLLBACK TIME. Yesterday, preferably.

• Thom A: I get that Stack Overflow is the site with the most users, and therefore likely to get the most feedback, but it's also the site where these bad changes are the most disruptive. It honestly feels like they should have a public alpha site, where it uses the same data as Stack Overflow, but has all the (bad) experimental features implemented; then people can try out the buggy site and report bugs, but escape the s(h)ite when they get fed up of basic functionality being broken. The feedback might even be more constructive then, instead of "You broke the site, I can't use it; change it back."
• Lundin: @ThomA Related: meta.stackexchange.com/a/406677/170024.
• Rosie: @Lundin I shared this on ThomA's earlier Answer, but this bug is the top priority in terms of fixes and we're hoping to be able to deploy that very soon. I'll post an update once it has been fixed.
• F1Krazy: @Rosie With all due respect, and I understand this may not be your department, this issue was first reported seven months ago. If this is really such a "top priority", then why was it not fixed before?
• VLAZ: @F1Krazy no work had been done on the new editor for quite a while. Until suddenly it's absolutely mandatory to release it for some reason.
• Lundin: @F1Krazy Because the company 1) desperately insists on feedback in countless feedback threads 2) completely ignores all feedback - they don't even read meta at all. 3) rolls out some half-baked crap that would never even pass 5 minutes of internal testing in normal companies 4) bemusedly wonder why everyone is so hostile.

Answer 7

Will the Stacks Editor have support for Snippets tomorrow?

Based on my (admittedly short amount of) searching, the Snippets feature is still not supported. If this is to be tested tomorrow, and snippets are still unsupported, how do users forced into "B" opt back into "A" so that they can add a snippet to their post? If they cannot do this, then that is severely detrimental to the users. This is already a problem in the Staging Ground (SG), where it's impossible to onboard new users into using feature; making it so that experienced users can't use the functionality to create "in-house" MREs for their questions/answers would be even worse.

• Bella_Blue: I have updated the post in response to feedback but in short, we have excluded the affected tags from the test.

Answer 8

I had opted into it a while ago, but opted out because Stacks Editor is doing rapid layout shift as I edit the body input. Really not a good user experience. I'd strongly suggest fixing egregious UX bugs like this before putting more eyes on it- both for the sake of the users, and for the sake of your image.

Does one editor lead to more:

• Answers submitted
• Number of edits
• Number of comments
• Number of flags
• Number of deletions

What is considered "good" for each of these? Why? Why would you expect there to be significant differences for each of these? I think the average person is unlikely to change whether they do something based on such a difference, unless one of them is bad enough to make them want to give up writing a post or making an edit. Why would there be more or fewer comments, flags, or deletions? What difference do the two editor implementations make to the issues behind those measures?

Is more edits good? Do you think someone will like one so much that they suddenly want to make more edits? Or is one buggy enough that the average user doesn't know how to deal with the bugs and just submits posts that curators have to make edits to fix?

Why not ask the user to give optional feedback like an experience rating after they submit a post or edit?

Do the editors perform differently based on a user’s experience level on Stack?

What does "perform" mean? How will you measure this quantitatively?

• dan1st: Also note that the stacks editor is weirdly escaping code
• Scotty Jamison: I wonder if they have a hard policy to make everything data-driven, even if it doesn't make sense? It feels like everything they do is tied to some kind of data-collection that's either tangentially related to what their objective should be, or worse, it's simply being set up to prove what they want to prove. You can prove anything you want with statistics if you pull out the right data. If, instead of an A/B test, they simply did a gradual roll out (after fixing the bugs and collecting more feedback), then used these metrics to make sure nothing was broken, that would make more sense.
• Bella_Blue: I think there is a misconception about the purpose of this test. We have a hypothesis that the Stacks Editor will lead to better outcomes for answers submitted, however there is no threshold we are trying to meet with these metrics. In this instance, this test is a way for us to understand what is happening so that we can make investment decisions going forward. Meaning, this A/B test is not looking to answer "why" questions; instead, it leads to "why" questions, like "why would there be fewer edits with the Stacks Editor?" Does that help explain our thought process?
• starball: @Bella_Blue that helps, and that's fair. I just find it hard to imagine how you would get the answers to those questions if/when they come up, given the part about focusing on quantitative rather than qualitative data. do you have anything planned?
• Mad Scientist: @Bella_Blue in all recent cases I can remember this kind of test was exactly what SE did before they graduated an experimental feature. So reading this announcement that was what I expected, that after the experiment is done SE is very likely to enable the new editor in more cases or even globally.
• Mad Scientist: @Bella_Blue And this is exactly what happened, just like every time before. You saw one nice metric in the test and immediately pushed this to production. It really feels like a waste of time to respond to these experiments.
• F1Krazy: @MadScientist And the bug this answer is complaining about hadn't even been fixed!
• Lundin: @Bella_Blue A/B testing is advanced testing. What was required here was the most basic of tests: to start the editor and observe it for 5 seconds while typing. "Uh... the whole site is jumping up and down like crazy while I'm typing. That's so incredibly bad and broken, I gotta fix it." That's the test that the developer should have been doing themselves while in the process of implementing it, before even showing this to anyone else internally. Why wasn't this most basic of tests done? And this is supposed to be a site for developers...
• user1937198: @Bella_Blue given the experance with experiments in the past, when you say there is no threshold, that's going to be interpreted as: 'We're going to look at the metrics after the fact and try and use them to justify the rollout we planned to do anyway'. Or in other words, we don't believe this is actually an experiment that could fail.
• user1937198: You don't need a hard go/no go boundary, but you do need a hard 'this is the minimum for the change to be considered' because a) it forces you to work out if your question is answerable from the metrics and b) helps avoid the presumption of success that comes from the desire to have achieved something.

Answer 9

I don't understand why we need to do a public, live, test of this on the production site when so many of the issues people have pointed out for this editor are issues that have existed for years and have been reported over and over and over again. There are plenty of things to fix already, you don't need to run another test and find a new list of bugs, fix what you've got first.

If we're just going to force it through and go live anyway, don't waste our time and energy with feedback posts. We already know you have no interest in updating the old editor or continuing its usage... so what's the point of all of this? So that you can have "data" to counter any discussion against it launching? So much feedback for this editor already exists from the places where its usage is already forced.

• zcoop98: Yeah... if we were already at one-to-one feature parity with the old editor, I could understand their angle better, but with a lengthy list of issues, bugs, and missing features already documented... it just feels like "alright, time to test!" feels extremely premature. Especially when it's already been live in various pockets of the site for a while, and in the case of Teams, for literal years. They should be able to glean usability data from these currently-live usages... yes, some things will be site-specific, but many won't, and I think they should start with those.

Answer 10

Wysywig editors are certainly sleek, and I'd even say popular, but they have several core issues that (in some cases) simply cannot be fixed... and they revolve around what the enter and backspace keys do.

Take tables for example. It's something that probably doesn't get used often, but, in wysywig mode editing a table requires interacting with a drop down menu. You can't add rows or columns without lifting your hand from the keyboard and interacting with the editor menu using your mouse, there are no keybinds (that I know of) that helps with this. (also... the dropdown currently overflows the bottom of the editor... yall should probably fix that.) I would generally expect pressing enter on the last cell of a table to create a new row, but if it did that then how would we ever exit the table to type below it? It just doesn't function the way you would expect which leads to frustration.

What about code blocks? to exit a code block you have to create an empty line in the code block that you don't want, then press enter again to escape the code block which removes the extra line. This is counter-intuitive and often leads to users getting "stuck" in a code block and just publishing their entire post as a code block. This also happens with block quotes, though to a lesser extent, I assume due to familiarity from other editors that they use block quotes in.

Still on the topic of code blocks, the new editor has two buttons for code formatting: inline code and block code. This is obviously confusing, because now users have to hover over the button to figure out which one is which, often resulting in people using the wrong one and either mangling their paragraph with a code block in the middle or publishing their post with their code block formatted as inline code.

Exiting empty blocks are inconsistent. For example, exiting a code block can be done by pressing backspace when it is empty, however exiting a list or a blockquote with backspace is impossible... you have to press enter...

On top of this... if you create a block quote using > instead of the button... pressing backspace exits from it... more inconsistency. How is this even possible?

It's not possible to create a code block without either using a keybind or using the button, because typing three ` inline results in an inline code block wrapping `. Maybe should make that a special case that doesn't create an inline code block?

---

Can we at least get some updates to this before doing A/B tests or further expanding the areas where it is forced?

• Dan Is Fiddling By Firelight: Wysiwyg tables via keyboard only are possible. 10-20 years ago I dealt with tables in MS Word frequently enough that I'd fully memorized the keyboard shortcuts to work the menu. OTOH I suspect MS had more developers working on tables in Word than SE does in total, so ¯_(ツ)_/¯
• Kevin B: Very well could just have enter create a new row, then another enter delete that row and make a new line, it'd at least be consistent with the rest of the block functionality.

Answer 11

I really "enjoy" the buzzing effect on the editor. Love it... Oh wait, no, the opposite. I HATE IT. PLEASE. MY EYES...

An awful buzzing image, oh wait, it's Stack Overflow

• Lundin: Just avoid typing when posting answers.
• Thom A: Ahh, so the new editor prompts submitting empty answers, @Lundin . Those are really helpful. I suppose that that'll help Stack Overflow's KPI they want to fulfil; answers will be submitted faster...
• Lundin: Nah just paste the output directly from ChatGPT. Just don't use quote formatting because quoting is bugged too.
• starball: (you can opt out, no? (I don't dislike it any less, for the record))
• Thom A: It's something that should have been fixed before it ever got to the public, in my opinion, @JourneymanGeek . It would be like selling a whole range of cars with faulty shock absorbers, and saying "We'll fix it eventually, but you can drive it 'fine' until we work out what the problem is." And then, finally, issuing a recall for the fix 2-3 years later, after all your customers have gone and purchased other vehicles instead.
• VLAZ: @starball I think we want SE to understand, they shouldn't shovel their broken crap onto prod and call it a day. Toggles for buggy behaviour are not acceptable any more to me. At best they can have an opt-in which is off by default (like before), so users can at their own volition elect to use the crap. I don't think we should accept "crap is on by default but you can disable it. Also, trust me bro, it's going to get better". The latter part is also a huge issue. See: all the abandoned projects of SE. Including this damned editor.
• starball: @ThomA ah. I suspected something like that assumption. they describe in the edited question post that there's opt-out, and the rapid layout shift is the top-listed thing to fix.
• John Dvorak: The real solution is to have a small enough monitor that you can't see the input box and the preview at the same time.
• Lundin: And here we thought "it compiles - ship it!" was a joke...
• Rosie: @thomA This is the first bug listed in the bugs list on the update I posted yesterday. It’s the top priority for the team in terms of fixes and is being actively worked on. We’re hoping we’ll be able to deploy a fix very soon. We’ll make an update on this post and update the status on the original post where the bug was reported.
• VLAZ: I find it baffling that the company knowingly released this broken crap. Oh, sure, it'd be fixed "soon". If it's going to be so soon, why couldn't it be fixed and then released? If it really was top priority, how could releasing it broken be topper priority than this issue?
• Ash Zade: To close the loop on this, it was fixed on March 10.

Answer 12

Our primary objective is to assess whether the editor performs satisfactorily to warrant a full release to all Stack Overflow users.

What does full release mean, exactly? Everyone has the option to opt-in to using it? Everyone starts with it but can opt-out of it? Everyone must use it?

Community input plays a vital role in this project, so please continue to share your feedback below.

In that, case please respond to the community input you have already been given before starting more tests. What is the point in providing input when you already have useful information you choose to ignore?

• PM 2Ring: The Op says: "maintaining multiple experiences is also not effective from a technical and cost-effective perspective". So they want to have a single editor, not two. Be afraid. Be very afraid.
• starball: @PM2Ring the non-stacks editor, right?
• V2Blast: @PM2Ring: Well, I think that ultimately, they plan to retire the old/original editor in favor of the Stacks Editor. But ideally they'll fix the bugs with the Stacks Editor before they actually make it the only editor.

Answer 13

Why are new users posting blank example tables as answers? This seems to have started happening since yesterday. Or at least it was noticed at that point. The only significant change is that they would have now been forced to use the new editor. I suspect there is a link but I cannot really prove it. Hence, the question goes out to the company - is the new editor making users post this nonsense?

https://stackoverflow.com/a/79490212

Random formatting with no substance - tables, quotes, code.

https://stackoverflow.com/a/79490838

Random formatting, just a markdown table with default values in it.

https://stackoverflow.com/a/79491976

Random formatting, just a markdown table with default values in it.

I searched for other posts with random tables in them. Some have tables with the default values but seem relevant (spent about 5 seconds looking at a post, so cannot guarantee it was always relevant) but there are definitely several which have the tables in there completely out of the blue. All of these have been created from the Ask Wizard, which means they used the new editor at the time. This seems to confirm my suspicion the new editor is at fault in some way:

• laravel filament implementing dark mode does not work
• Error :: File google-services.json is missing. The Google Services Plugin cannot function without it. on real android device testing
• Flutter information window googlemaps
• How to get the mid values from the line graph in Tableau
• Object detection in Sequence
• i have a problem to make list in django shell (take a look at the non-table formatting, as well)
• Pandas Filtering Syntax

• VLAZ: @starball when I was a child, me and my parents went to a table shop. One of the sample tables fell from the ceiling and crushed my parents. I rushed to their aid with my baseball bat but it was too late. I spent the rest of my years training to defeat all sample tables with my trusty bat. I am Batman.
• John Dvorak: I think we have found the 3000 extra answers that have appeared thanks to the new editor!
• Makyen: This is a sufficiently prevalent issue such that a separate question should be created on MSO, so we can status-review it and have SE staff take a look to see if there's something in the UI that's causing this. It seems likely that it's not intentional by the users, so it's something that should be corrected/prevented by the UI, otherwise it's just a bad UX for everyone. So, please create a separate MSO question.
• VLAZ: @Makyen The Stacks Editor leads to users posting table-only answers

Answer 14

Do you have any data that would hint as to why a different text editor would actually lead to a significant increase in answer completion?

I get that something easier to use to people unfamiliar with markdown would be easier to use, but why would that prevent people from sharing an answer if they had one, at a 8.6% rate? That's a fairly bold claim that we should be able to see the results of in a month through site analytics.

Honestly that seems a bit fishy to me.

What user groups were most impacted by the new editor?

---

Here's what that site data looks like today:

https://i.sstatic.net/pzlpCURf.png#.png

I mean... the gap certainly closed, but I'm not so sure it's due to the editor...

• DBS: It would also be nice to see some more stats on e.g. the average score of these extra answers or their deletion rate. It seem like issues in the new editor might be leading to some pretty unhelpful "answers" (See VLAZ's answer)
• Sinatr: I will never use WYSIWYG to compose posts myself, because I don't care how exactly end-result will looks like, I only care about it being correctly formatted and markdown does it with easy and independently from IDE. Until WYSIWYG editor become a standard everywhere (similar to markdown) people will prefer to learn one thing (markdown!) and use this knowledge everywhere, rather than learning different WYSIWYG editors (talking about ugly button, very non-intuitive UI, lack of help).

Answer 15

The new editor makes it really, really difficult to effectively change code blocks and I haven't yet figured out how to put in a code snippet. I'm kind of shying away from editing Staging Ground questions that need edits for the code formatting, just because it's a nightmare to see what's going on. The current editor is clean, easy to see where Markdown is, and IMO just really good and doesn't need changing.

Our primary objective is to assess whether the editor performs satisfactorily to warrant a full release to all Stack Overflow users.

Does this mean you're going to force it on everyone? Given the feedback we (the community) have provided which universally seems to be we dislike it, is there at least going to be an opt-out option?

Answer 16

Add a clear notice that the editor has changed

Just today, over on the global meta, we got a complaint that backslashes were being unexpectedly inserted into their code when pasting it. This is an intended feature when pasting in characters that have special meaning in Markdown, in order to ensure that the text is rendered the same way as originally intended.

The thing that did happen, however, is that users who were used to following the 16+-year-old workflow of typing in four-space indent and then pasting in code were finding that unexpected backslashes (escape characters) were being inserted.

A clear notice that the page editor has changed and a pointer to the link to either switch to Markdown preview mode as well as disable the new editor should be implemented.

• jsmb: This is a bug, not an intended feature.
• Sinatr: The dev-team behavior has changed, now they announce the beginning of crap and then become silent/hard to spot.. Really terrible when certain well known UI elements are irreversibly altered and there is no easy way to get help. Unless the aim is to create puzzle-web-site, with unexpected wonders every day (mostly negative, but hey, it's hardcore game, you should leave already!)

Answer 17

Ctrl + Enter no longer submits the answer and seems to brick the editor instead.

There still is no way to fix shitty indentation levels and the new editor is actually even worse at it since it just adds and removes backticks.

• sehe: Worse, my standard habit of tab, enter to post makes me lose the post because it navigates to one of the links in my answer instead...

Answer 18

bug

Submit button has weird tabIndex

When writing an answer, I expect to be able to press Tab, possibly twice to skip the "Community wiki" checkbox, then Enter to submit the answer. This is no longer possible with the new editor! The tab navigation order is completely messed up:

1. answer form textarea
2. answer form "community wiki" option
3. answer form discard button
4. cookie settings button (link?)
5. browser address bar (etc), then back to the page
6. answer form submit button
7. site search input field

<button id="submit-button" class="flex--item fl-shrink0 s-btn s-btn__filled sm:w100" type="submit" tabindex="120" autocomplete="off">
 Post Your Answer
</button>

WTF?

• starball: meta.stackexchange.com/q/407415/997587
• starball: "If you see bugs related to the Stacks Editor in the future, please write a new question with the details (one question per bug) and tag the question with bug and stacks-editor."
• Bergi: @starball Oh, I somehow missed that. I was actually even looking for it but still must have read over it.

Answer 19

When it comes to this 8.6% increase... were answers started in the old editor to questions that were among the excluded tags considered part of the control group?

Due to the way the snippet editor works... it's common for users to create an answer so that they can mess around with the snippet editor. If these posts were considered part of the control group... it's possible some amount of these abandoned answers were never going to be real answers to begin with. But if you were excluding those tags from the data then it of course would have had no impact whatsoever.

I'm not sure exactly how common it is for users to copy a snippet to an answer to mess around with it, just something that may not have been taken into account? I kinda expect it to be a common scenario on questions that include a stack snippet; imagine an answerer deciding to take a stab at a code snippet to see if they can diagnose the problem, failing, then moving on, abandoning the answer.

• VLAZ: In the same vein, I'd often try to edit a question but might toss the code in the answer box to try and format it better or even see if it forms a cohesive snippet. Then transfer the result to the question.
• VLAZ: On another "abandoning answers" perspective - I often use answers to upload images I want to use in a comment or in chat. Very often it's an "answer" to a JS-related question because very often I just happen to have one of these open.

Answer 20

I use this fairly regularly on main meta - and I'm a little surprised that there's no equivalent question there. I actually like the 'new' editor, other than it being a little buggy in two-pane mode (which is my preference, and was added in on community request - it flickers unusably).

That said, considering that development until recently followed a chasm model - where development halted for an extended period of time (aka dropped down a dark hole, where it's finally crawled out of), I don't think that without a clear plan for feature parity and gradual, sustained development (perhaps more of a waterfall model) perhaps, it's going to be a very hard sell to replace the current editor.

Done right - some of the bones of a decent replacement for the current editor are there, but right now, there are just so many small annoyances (and big ones) that it's a hard sell. I'd suggest a big bug squish first dealing with the existing bugs reported on main and SO meta, before trying experiments on experiences, and well, very, very heavy dogfooding. People use these tools for 20-30 minute stretches or worse. It's probably worth dealing with the feedback you have and sanding off the stabby bits of the tool before asking people how they feel about it.

• zcoop98: You've expressed the exact sentiment I wanted to, far more concisely than my attempts at drafting one... I don't understand, in light of the complaints and outstanding bug reports, why we're not starting with a bug bash first, and then launching A/B testing. A better editor is a Good ThingTM, and WYSIWYG is decidedly more user friendly and "modern" feeling, but it's gotta... you know, work well.

Answer 21

The Opt-Out should not be something I have to search for in Meta. It could be a fourth option on the right side or even better provide the old editor directly as the fourth option.

Not having a plain-old-text-area does not only kill (like mentioned before) user-scripts and browser-plugins, but also the feature of browsers like Qute to start your favourite editor from a text-input.

Granted, most likely a minority of the users here. But very likely a very dedicated core, that has high interest in providing top-tier answers, with proper formatting, spelling, and grammar.

Answer 22

The new editor on SO for answers disables some very useful control keys on macOS:

• Ctrl-A no longer goes to the beginning of the line, it goes to the beginning of the whole post
• Ctrl-E no longer goes to the end of the line, it goes to the end of the whole post
• Ctrl-Y seems to insert extra newlines

These bindings are the standard emacs bindings, making post and answer editing very efficient for emacs users and rebinding these keys makes the experience awful.

Could you please at least make this a selectable option is in the user profile?

• chivracq: Also posted as a standalone Bug Report: New Stack Editor redefines crucial key bindings

Answer 23

The editor does strange things with the <strike> HTML tag.

See this answer:

visual answer

The actual markdown is this (line breaks added by me):

<strike>
 dogs.Join(puppies, () => true, () => true, (one, two) => new Tuple(one, two));
You can do a regular join, but the selectors are both returning the same value, 
because I want all combinations to be valid. When combining, put both into one 
tuple (or a different data structure of your choosing).</strike>
 leftSide.SelectMany((l) => rightSide, (l, r) => new Tuple(l, r));
This should do a Cartesian product.

It looks like this in the rich text editor:

rich text editor

The top line can't be edited, only deleted when the cursor is on it, the rest of the test doesn't have strike-through format, and the closing </strike> tag shows as regular text. Of course this is not a correct representation of the markdown, but also, the rich-text editor can't be used to, for example, remove the strike-through and replace it by quote format (if that would be appropriate).

• zcoop98: Worth adding that <s> and <del> also appear to suffer from the same problem.
• Abdul Aziz Barkat: Seems to happen with most (didn't test with all) of the allowed HTML tags. The tag just needs to be the only thing on the line and then what would be the next paragraph (according to the markdown) gets wrapped in an extra div