WordPress.org

Make WordPress Core

Opened 14 months ago

Last modified 45 hours ago

#38061 assigned enhancement

Rename the text window name on the editor

Reported by: lukecavanagh Owned by: afercia
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Editor Keywords: has-patch needs-refresh
Focuses: accessibility Cc:

Description

The text window on the editor name should be something that makes better sense to new users. Since the reality is it is a way to tab between the visual editor and actual view the code.

So if a new user who does not know this if they tab between Visual and Text it does not make total sense.

Attachments (3)

Editor Window tab text view.png (2.4 KB) - added by lukecavanagh 14 months ago.
Editor Text Tab Name
38061.diff (987 bytes) - added by lukecavanagh 14 months ago.
Patch Example
patch.diff (161.4 KB) - added by ctienshi 14 months ago.
Path for name "code"

Download all attachments as: .zip

Change History (27)

@lukecavanagh
14 months ago

Editor Text Tab Name

#2 @lukecavanagh
14 months ago

Yep but even renamed as Text is still confusing to new users to work out as well.

#3 @rseigel
14 months ago

So call it HTML. Problem solved. Doesn't require years of back and forth to fix. :)

@lukecavanagh
14 months ago

Patch Example

#5 @rseigel
14 months ago

I'd say calling them Visual Editor and HTML Editor the way you did in the patch is perfect.

If an end user doesn't know what an "HTML Editor" is they probably shouldn't be touching it anyways.

#6 @lukecavanagh
14 months ago

@rseigel

Hopefully that should help. Text and Visual could be clearer and hopefully this patch fixes that.

#7 @SergeyBiryukov
14 months ago

That's not a "real" HTML editor though. It allows using HTML tags, but does not allow editing the resulting HTML code, which includes some automatic transformations. See the discussion in #20993.

#8 @lukecavanagh
14 months ago

@SergeyBiryukov
So what should Text be named as then?

#9 follow-ups: @rseigel
14 months ago

Clearly the word "text" is confusing. I don't see the real problem with calling it "HTML Editor" at all. Does anyone really expect that they're editing ALL the HTML (header, footer, etc) when they're using the Text/HTML Editor tab?

I think this should be more about protecting users from themselves by clearing it up rather than splitting hairs.

#10 in reply to: ↑ 9 @SergeyBiryukov
14 months ago

Replying to rseigel:

Does anyone really expect that they're editing ALL the HTML (header, footer, etc) when they're using the Text/HTML Editor tab?

It's more about transformations done by wpautop(), shortcodes, and other filters, but yep, see @azaozz's comment:

However calling it "HTML" editor misleads the users that are familiar with html coding. These users expect to have access to all of the underlying html code which is not the case in the "HTML" editor.

I've seen similar sentiments on support forums in the past, so while "Text" might not be ideal, I think it's less confusing and more accurate than "HTML". But that's just me, let's see what others think :)

Last edited 14 months ago by SergeyBiryukov (previous) (diff)

This ticket was mentioned in Slack in #core by lukecavanagh. View the logs.


14 months ago

#12 @Presskopp
14 months ago

Code

(that's what I was thinking after reading)

#13 in reply to: ↑ 9 ; follow-up: @ctienshi
14 months ago

@rseigel I think text if fine. Renaming it to HTML would confuse people who don't have a basic knowledge about technical stuff.

#14 in reply to: ↑ 13 ; follow-up: @rseigel
14 months ago

Replying to ctienshi:

@rseigel I think text if fine. Renaming it to HTML would confuse people who don't have a basic knowledge about technical stuff.

Honestly, I 100% still disagree. I think the opposite is true.

Text sounds too 'friendly' - yeah that's the word. It should really be named "Don't Touch the Shit in Here Unless You're Willing to Risk Screwing Stuff Up" but that would be a tad long.

I like "Code" better as was suggested above.

#15 @lukecavanagh
14 months ago

@rseigel

Granted it is not a full HTML editor. But by having to explain to users what that tab is for, still means that something which should be clear is not.

#16 in reply to: ↑ 14 @ctienshi
14 months ago

@rseigel Yeah i guess code is more appropriate to minimize the confusion.

#17 in reply to: ↑ description @ctienshi
14 months ago

I have made a patch for the name "code".

@ctienshi
14 months ago

Path for name "code"

This ticket was mentioned in Slack in #core-editor by presskopp. View the logs.


4 months ago

#19 @Presskopp
4 days ago

#42627 was marked as a duplicate.

#20 @giuriani
4 days ago

  • Keywords has-patch added

But "Text" means Text and confused beginners users. I definitely suggest to use the label "Code". Also see ticket #42627

#21 @afercia
3 days ago

  • Focuses accessibility added
  • Keywords needs-refresh added
  • Owner set to afercia
  • Status changed from new to assigned

Following the argumentations on #20993 seems to me the change from HTML to Text was an improvement anyways, as HTML was a bit misleading. However, although Text is better than HTML, it still doesn't accurately represents what users see in the normal textarea, which is a mix of text and code. I'd agree this could be potentially confusing for new users.

@giuriani on #42627 made a good point Text may be confusing for beginners and also not so meaningful when read out of context. Ideally, any UI control should make sense even when read out of context. For example, screen reader users can jump to different parts of a page using dedicated shortcuts, and landing on a control that says just "Visual" or just "Text" doesn't help so much new users. Of course, with time users would learn those controls relate to the Editor, but making them a bit more explicit would help.

I'd also suggest to consider what's going to happen with Gutenberg. When switching to "text mode", what users see there doesn't really look like text :) there's a lot of code there:

https://cldup.com/fR-NuUOZKQ.png

I understand the available space is a concern, but I'd propose to expand a bit these labels to give better context, adding the word "editor" as 38061.diff does. Seems to me the word "Code" better represents what the textarea content actually is. To add some context something like the following strings could work:

  • Visual editor
  • Code editor

Gutenberg already has a lot of space for longer strings:

https://cldup.com/NUhzYnwVMG.png

Worth noting many other things should be changed, as done on #20993. For example:

  • documentation
  • inline comments
  • the contextual help tab content
  • translators comments and context, e.g. Name for the Text editor tab (formerly HTML)

#22 @mark-k
2 days ago

Just remove it.

The "text" tab shows what is in the post_content, which to anyone outside of the few that actually know how wordpress works, means nothing.

Back in the prehistoric days when editing was done in a textbox it was a mix of raw html to be displayed on the front end and text which was automatically translated into html. Not very elegant but you did not had to be a rocket scientist to get it.

Then came shortcodes, oembeds, massive use of the_content filter in general and now gutenberg wants to add raw data into it (and there is also the kses which might cause that what is saved is not what is displayed there) . This is a mess that I doubt anyone can describe in less than 10 minutes to anyone else no matter what is his technical understanding level. Too many things here are too much of wordpress internals.

The only reasonable name for that tab is probably "raw" which will probably cause everyone with 100 IQ to rightfully avoid using it, which leads to the question why should it exist in the first place. If tinymce now generates a good enough HTML, why can't the "html" editing be relegated into a plugin?
The other option is to actually define in positive way what that tab is, and then the name will suggest itself.

Last edited 2 days ago by mark-k (previous) (diff)

#23 follow-up: @afercia
2 days ago

which leads to the question why should it exist in the first place

@mark-k although the textarea is filled up with HTML comments, blocks meta-data, and stuff that make readability of the "code" harder, a native HTML textarea is the only guarantee the post content can be edited using any device and any assistive technology.

#24 in reply to: ↑ 23 @mark-k
45 hours ago

Replying to afercia:

which leads to the question why should it exist in the first place

@mark-k although the textarea is filled up with HTML comments, blocks meta-data, and stuff that make readability of the "code" harder, a native HTML textarea is the only guarantee the post content can be edited using any device and any assistive technology.

Since that is neither HTML nor "code" (whatever that means) I wonder how any assistive technology can make any sense of what is there. Can it really voice "[galley]" as "A gallery shortcode without parameters"? Can it differentiate between "youtube.com/nnnnn" as an embed and as a text?

IMHO it is not enough to just throw text into a textarea and just because there is an aria attribute, or whatever is needed, to call it assistive technology friendly. Maybe it is friendly to the technology but it is unlikely to be friendly to any human that uses it. How will it announce the gutenber json data?
Regardless of assistive technology, why would you even want to expose the gutenberg data to be edited by hand?

I have no knowledge of assistive technology, but it sounds to me that everything in an editor which should be friendly to people that need it, needs some semantic annotation of what everything actually means in addition to it being a general text. This probably should eliminate any usage of textarea for it.

.... no wonder even people that do not require the assistive tech, asks for codemirror to be applied to it to help make sense out of that big pile of not very orgenized text.

Last edited 45 hours ago by mark-k (previous) (diff)
Note: See TracTickets for help on using tickets.