The new Reply tool reminds me of other comment tools in websites with deep nested threaded conversations, in particular Reddit and Slashdot (and to some extent Stack Overflow).

Since my previous comment I've discovered a workaround to the workaround. The goal is: load arbitrary bookmarked filter X; disable sub-filter Y; re-enable sub-filter Y with minimum mental load (i.e. re-enabling sub-filter Y should be made by muscle memory over a visible item, without making a choice on an initially hidden widget.)

In T200986#4472989, @Trizek-WMF wrote:

How to get that default set back immediately? The only solution is to remove all filters to have access to the "restore default filters" link. That's not obvious at all.

In T200986#4472364, @SBisson wrote:

@dialmove You can reset the state of a Saved Filter by reselecting it from the "Saved filters" menu.

My user at all Wikipedia projects is [[User:Diego Moya]].

In T44138#3162853, @Jan_Dittrich wrote:

Roan suggested perhaps changing "Save page" to read "Save page...", which would give the user a clue that it's going to be a process, not an immediate action.

I think this would make sense – it is an established UI standard and can be found in many desktop applications.
I would love to see an improved wording on the button itself, but util then, I’d go with …

In T153306#3158440, @Jdforrester-WMF wrote:

In T153306#3153368, @dialmove wrote:

IMHO the Preview panel should have its own separate button rather than being available in a dropdown (thus requiring two clicks).

If we were to take over (even) more room on the toolbar, we would have to demote other features from the toolbar for space (we're currently at the limit for space for the average desktop user, at 1000px wide at normal zoom on Vector).

Which do you propose to make this work? Should we get rid of the Cite button? The link and menu buttons? Fundamentally, preview is not more important thank anything already in the lists, I fear.

A very typical wording for the save button would be "Review and save" (or "Review and publish"). It shouldn't be merely "Save" or "Publish", since the page is not immediately saved when pressing it.

A very typical wording would be "Review and save" (or "Review and publish"). It shouldn't be merely "Save" or "Publish", since the page is not immediately saved when pressing it.

User experience

P.S. It looks like me and the other users posting at this thread are not the only one who prefer plain text as the default for copy/paste operations; it seems to be a frequent pain point, when it's got applications specifically built to solve it. [1] I've never met someone asking to paste formatted text when working with code. (Syntax highlighting doesn't count, it's a different beast entirely).

In T153315#3031416, @Whatamidoing-WMF wrote:

Your browser will let you paste plain text, with a key command of Command–Shift–V or Control–Shift–V. As the dev noted above, the "receiving" software doesn't have a lot of control over what your computer sends it.

Another use case to consider for you designers of this "feature", which just happened to me:

In T153315#3021583, @Esanders wrote:

Browsers don't allow paste to trigger programmatically for security reasons. The user must initiate a paste using ctrl+v.

The simplest solution is to create a button for "paste formatted code". In the 2017 wikitext editor, other "magic" features for creating wikicode automatically (tables, sourcing and templates) are enabled by buttons in the toolbar. It would be inconsistent for the standard "copy/paste" tool (the one supported by the browser's standard key bindings) to behave differently, and introduce wikicode when pasting from web pages with rich format (but not when pasting from other sources, so its behavior would feel random).

In T155821#3020506, @Whatamidoing-WMF wrote:

Think about it from the POV of the person who started editing in the visual mode. There, if I copy something with formatting (e.g., the 'suggested citations' that are common on scholarly sites), it gets automagically transformed into something that works on Wikipedia. So if I'm in the wikitext mode, I probably still expect automagic transformation of content into something that works on Wikipedia.

You have changed the title to "selecting text beyond the screen with mouse is glitchy", but it also happens with the keyboard, and with the text selector on mobile (I don't know if my fingers count as "the mouse") ;-)

In T153315#3003479, @Whatamidoing-WMF wrote:

In T153315#2945065, @Samwalton9 wrote:

is there any evidence that users who use the visual editor first and then switch to source editor actually expect their pastes to bring formatting across?

Several comments in the Feedback page point in that direction: 1 2 3 4 5 6 - plus Samwalton9's and Dvorapa's comments above. This matches my own experience as well; the whole point of using a wikicode editor is having direct and full control over the text, and any magic from the editor breaks that expectation.

I can confirm Pearli's report of the editing experience at the Overwatch article. Repeatedly pressing shift + up will perform weird screen flashes, and eventually revert the scrollbar to the starting position.

In T155732#2976906, @Esanders wrote:

On a reasonably sized article, scrolling between the wikitext and the preview is not quick, each time you have to find your place again.

In T155732#2957068, @Esanders wrote:

at the same time.

For a non-stub page this is already not possible, you can't see the wikitext and the preview at the same time (although the preview could be easier to switch to).

In T155821#2956880, @Esanders wrote:

The wikitext editor should make exactly zero magic transformations like the above, treating everything copied or pasted as a raw Unicode string without formatting.

You can always use CTRL+SHIFT+V to force paste plain text.

Edit: I've noted that this only happens when I copy the text from the HTML page, not when I copy it from a plain text editor, so this is likely related to the text formatting.

I've opened a related feature request to improve the usability of the Preview panel, matching that of the classic Wikitext editor.

This way, we power users could still set particular preferences for special topics, but quickly change the global settings for everything else (all the topics that we have not tweaked explicitly).

As for Capt_Swing concern that per-topic settings override the Notifications panel, that could be solved by adding a new entry at the "Notification volume", and making this the initial value for new topics:

I like the overall design. I wanted to provide a little feedback of a few problems I've found while testing the prototype, before reading the description of how it's supposed to work.

There should also be some kind of "previous" and "next unread" buttons, for discoverability, maybe placing them in the current floating bar that contains the ToC.

I've posted a bug for the Reply button, it seems it's an instance of this problem. I've added an instance with real data here.