questions to consider

[joyously]

How would a user add a class to a block? (is there still a raw mode to use?)
Can a user put inline styles on anything?
Can you paste HTML in? Can you copy content within the editor (to paste in another spot or in external document)?
Will diff for revisions still work?
Has anyone tested with users creating a new post (empty) instead of editing what is there?

[jasmussen]

Many of these questions feel like they've come from the shortcomings of the UI prototypes, so it should be important to note that they are just that: UI prototypes to test out some of the new interactions we're exploring. They are not meant to be compared 1:1 with the current editor, but rather explore specific parts of how blocks could work inside the editor. Things are likely to change further as we build the real thing.

How would a user add a class to a block? (is there still a raw mode to use?)

There should still be an HTML mode, yes.

Can a user put inline styles on anything?

In the visual editor we have an opportunity to show the most right controls in the right place. For example we probably don't need text-color or strike-through on an image, or code for a headline. But if that's what a user really wants, they should still be able to do that in the HTML editor.

Can you paste HTML in? Can you copy content within the editor (to paste in another spot or in external document)? Will diff for revisions still work?

Sure.

Has anyone tested with users creating a new post (empty) instead of editing what is there?

The UI prototypes haven't been in a place where this was possible, but that'll definitely be part of tests when it's doable! :)

[joyously]

Many of these questions feel like they've come from the shortcomings of the UI prototypes,

Not at all. They come from the perspective of users that never use the visual editor. We don't want to lose the flexibility that currently exists. And if adding a class or inline style (or debugging bad syntax) would require switching to the other view, that scenario needs to be considered from the beginning, as it's part of the interface.

Regarding the diff for revisions, I was thinking of the way the content is stored (old way vs. new way). Would there be a conversion of the old to new? If yes, diff is no problem. If not, diff could show changes where there are none.

The UI prototypes haven't been in a place where this was possible,

Sure they are. Just don't put all that content in, or have a step in the test where you delete it all to "start over". But the thing that I see that could be a problem is that it would look too empty, with no indication of what can be done.

[anna-harrison]

it would look too empty, with no indication of what can be done

Interesting point. @jasmussen do you think it's worth starting a new issue "Making getting started with new page/post user friendly"?

[jasmussen]

Interesting point. @jasmussen do you think it's worth starting a new issue "Making getting started with new page/post user friendly"?

This is a problem will probably naturally present itself and suggest iteration as we start working more in context of the admin UI. For example the flow of starting a new post includes the intentional clicking on Posts → Add New. Does that change the context compared to looking at the UI prototypes? Unknown, but it'd be good to have that as part of any tests. Never anything wrong with creating tickets, though.

[jasmussen]

Closing for now as the questions are answered, and tickets can be re-opened if and when they become relevant in the plugin phase.