Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement toolbar buttons for text mode #569

Closed
afercia opened this issue Apr 28, 2017 · 13 comments
Closed

Implement toolbar buttons for text mode #569

afercia opened this issue Apr 28, 2017 · 13 comments
Labels
[Feature] Code Editor Handling the code view of the editing experience [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Question Questions about the design or development of the editor.

Comments

@afercia
Copy link
Contributor

afercia commented Apr 28, 2017

About the editor text mode, currently (April 28th) the plugin displays a toolbar that visually mimics the "quicktags" buttons.

screen shot 2017-04-28 at 23 48 06

Given the presence of the "close tags" button, I'm guessing it's going to replicate also the quicktags functionalities.

None of the buttons works so far, that's perfectly understandable since the plugin is in a heavy development phase, so there's not so much to test. However, I'm wondering if replicating the current functionalities is a good idea in the first place.

Maybe worth considering removing most of them, also taking into consideration what emerged from the editor survey:

https://make.wordpress.org/core/2017/04/07/editor-experience-survey-results/

Do you use the markup buttons?
While a vast majority of respondents use the Text Editor, almost half never use the markup buttons.

47.2% No
34.9% Sometimes
17.9% Yes

Has this ever been discussed? Any plans I may have missed? Any new ideas of improvements planned?

@mtias mtias added Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Question Questions about the design or development of the editor. labels Apr 28, 2017
@afercia
Copy link
Contributor Author

afercia commented Apr 29, 2017

See also:
https://wordpress.slack.com/archives/core-editor/p1475103109000800

is it time to remove the Quicktags buttons from the Text editor?

@afercia
Copy link
Contributor Author

afercia commented Apr 29, 2017

Whether the Quicktags are going to stay or not, worth reminding any UI control should be properly labeled. Currently, just the content of the button is available to assistive technologies and in most of the cases, it doesn't help so much users as it's just i or b, etc.

For example, the plugin:
<button>ul</button>
vs. WP:
<input type="button" id="qt_content_ul" class="ed_button button button-small" aria-label="Bulleted list" value="ul">

@jasmussen
Copy link
Contributor

No firm decision have been made yet.

Philosophically I'm leaning towards them staying. Back when we started on this adventure I did a little very anecdotal research on how people use the editor, and though not very many people used the HTML editor (did not ask specifically about quicktags), those that did use it used it all the time and were very, very passionate about it.

Since we are doing such major changes to the editor, I feel like the text editor might serve as the one holdover from the old world, a 0,0,0 coordinate in a universe that's about to change a lot. And for that reason alone, I'm reluctant to rethink that too much.

@joyously
Copy link

joyously commented May 1, 2017

those that did use it used it all the time and were very, very passionate about it.

I'm one of those people. I agree that text mode mostly unchanged would be a stability point, but really, it's the only way I can see what's actually in the content and make it say exactly what I want. Don't remove features from the one tool I rely on.

@afercia
Copy link
Contributor Author

afercia commented May 1, 2017

I think no one wants to remove the text editor 🙂 it is also an a11y very important feature, since only a native textarea is really fully accessible. Just wondering about the buttons to insert opening/closing tags. They're hard to use, and very few uses them.

@joyously
Copy link

joyously commented May 1, 2017

I was referring to the buttons, not the text editor. The very small sample of respondents to that survey had very few who used them. But as part of the stability thing, I think they should be left as is.

@dmsnell
Copy link
Member

dmsnell commented Jun 14, 2017

We're creating a new programming language in a very real sense. Why not make the text view an IDE.

For basic editing it looks plain with a few small enhancements. Maybe we somehow indicate where the blocks are (poorly, for example, with colored backgrounds) and dim the block comments, etc… When someone accidentally mangles their blocks they will get an immediate visual response right there. We could even emphasize certain spans of text according to certain knowable properties of it from the parse.

For advanced editing we turn on syntax highlighting and error messages. This view would feel more at home to people with some coding skills and the error messages could provide a good environment for a developer/agency to go in and recover a messed up post.

@jasmussen jasmussen added this to the Beta 0.8.0 milestone Jul 5, 2017
@afercia afercia added the [Feature] Code Editor Handling the code view of the editing experience label Jul 10, 2017
@mtias mtias removed this from the Beta 0.8.0 milestone Jul 27, 2017
@mtias
Copy link
Member

mtias commented Jul 27, 2017

@jasmussen clearing from milestone as it'd be good to have only actionable tasks there that have been decided.

@danielbachhuber danielbachhuber changed the title Plans for the text mode Implement toolbar buttons for text mode Jan 23, 2018
@danielbachhuber
Copy link
Member

As of Gutenberg 2.0, it appears the Text Mode toolbar is still inoperable:

textmode

@danielbachhuber danielbachhuber added the Needs Decision Needs a decision to be actionable or relevant label Jan 23, 2018
@karmatosed karmatosed removed the Needs Decision Needs a decision to be actionable or relevant label Jan 30, 2018
@bobbingwide
Copy link
Contributor

They've disappeared in the latest build I'm using a0e5933

@jasmussen
Copy link
Contributor

Yes, we removed them because they were just dummies. That doesn't mean they can't still be built, just that it was misleading to have them when they didn't work.

@aduth
Copy link
Member

aduth commented Feb 8, 2018

Related: #4803

@jeffpaul jeffpaul added this to the Merge Proposal milestone Feb 8, 2018
@jeffpaul jeffpaul added the [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). label Feb 8, 2018
@jeffpaul jeffpaul modified the milestones: Merge Proposal, Bonus Features Feb 8, 2018
@afercia
Copy link
Contributor Author

afercia commented Jun 6, 2018

In the last versions, all the buttons were removed from the text mode. This issue can be closed. Worth opening a new one to consider to add a few buttons for the main functionalities related to authoring content (e.g. Insert Link and Add Media).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Code Editor Handling the code view of the editing experience [Focus] Accessibility (a11y) Changes that impact accessibility and need corresponding review (e.g. markup changes). Framework Issues related to broader framework topics, especially as it relates to javascript [Type] Question Questions about the design or development of the editor.
Projects
None yet
Development

No branches or pull requests

10 participants