wordpress-mobile
Enable toolbar in HTML mode
Description:
User's should be able to use the toolbar in HTML mode.
Details:
Applying styles in HTML mode can be non trivial if our intent is to also generate valid HTML.
We'll just enable buttons that will wrap a selected range inside a specified tag. Our default model to implement this will be based on WordPress's Calypso Post Editor.
I just realized this might not work as I was thinking. Right now, the icons all dim when switching to HTML mode, so it's obvious that you're in a different mode. But if we decide to not dim the toolbar buttons, there will be no indicator that something's changed (other than a subtle highlighting of the HTML icon). Maybe best short-term solution is to swap the HTML icon for the Visual [eyeball] icon when switching modes?
I'd prefer moving to the alternate toolbar that I had designed previously, but this might be a quick fix.
I agree with the problem @iamthomasbishop raises - a toolbar button is not a good place for a "mode toggle".
Applying styles in HTML mode can be non trivial if our intent is to also generate valid HTML.
I was under the impression the visual editor already handles HTML it doesn't like (sometimes by deleting it). I don't think it affects the implementation of this feature.
Are these the only blockers to implementing this? If the toolbar becomes slightly more confusing, I suggested another approach in the Wordpress-iOS bug:
From discussions I understand that some of the rationale behind disabling the toolbar buttons is to avoid confusing users that may have entered HTML mode accidentally. If that's the case, I don't think it's a good reason to disable the buttons. A warning message before entering HTML mode should be enough. Disabling the simple formatting options hurts no-one but users who DO wish to edit HTML and have to manually type the tags, which isn't a good experience on a touchscreen keyboard.
I agree with the problem @iamthomasbishop raises - a toolbar button is not a good place for a "mode toggle".
The toggle in the toolbar is indeed a really bad idea because it requires a field to have focus for you to switch mode. This was initially not in there for Aztec but was moved due to a design request.
I was under the impression the visual editor already handles HTML it doesn't like (sometimes by deleting it). I don't think it affects the implementation of this feature.
Depends on the expectations (which was the point of my comment). I personally consider it a bit of a poor experience for our style buttons to generate something like:
<em>Hello <strong>there</em>, World!</strong>
That said, this is not enough reason not to have those buttons working.
Are these the only blockers to implementing this?
There are no blockers to implementing this feature.
If the toolbar becomes slightly more confusing, I suggested another approach in the Wordpress-iOS bug:
We need a static indicator that you're in HTML mode. An alert is not good at that, especially if we ever decide to remember your preferred mode.
Depends on the expectations (which was the point of my comment). I personally consider it a bit of a poor experience for our style buttons to generate something like:
<em>Hello <strong>there</em>, World!</strong>
I take issue with this philosophy so I'll try to argue against it:
It's the user's choice to enter HTML mode, which is by design plain text input mode (although I think you turn <br>'s into newlines..). That's the experience users expect, so they should be able to type "garbage" (that's accurately parseable by the HTML5 standard's algorithm).
This is what the web-based WordPress HTML editor allows, and many other editors. Just because this is a mobile phone doesn't mean it should hand-hold the users more, or decide for them.
If I choose to go back to the visual editor, and make edits, THEN it's welcome to normalize the HTML (hopefully according to the HTML5 algorithm) before modifying it.
There are no blockers to implementing this feature.
Great! If there's no expected timeframe maybe I'll try tackling it myself.
We need a static indicator that you're in HTML mode.
OK, what if it was still on the toolbar, but you had to first toggle its availability in the options? Then it would be possible to categorize it as an "advanced feature".
I believe the current approach (with a full active toolbar) was how the old WordPress app worked. Was there a problem with that behavior? Did it confuse users?
A bit of an update:
We worked on moving the "mode toggle" last week (both on iOS and Android for consistency) - which allows you to switch modes - to the top toolbar, and out of the formatting toolbar (which currently houses the visual editor shortcuts for Headings, Lists, etc). This means the entry point is clearer and separates the mode-switching from the formatting options - a more obvious separation. You can see more on that change here: https://github.com/wordpress-mobile/WordPress-iOS/pull/8860
With this change (better location for the toggle itself), I'd be open to making the changes requested in this issue - allowing the user to apply/wrap elements in markup on the editor while in HTML mode. The formatting buttons would instead not disable, allowing the user to utilize them as shortcuts to add as HTML.
Awesome clarification @iamthomasbishop!
I don't mean to kill an important discussion from continuing but the scope of this issue is pretty much defined and atomic. For anything else regarding the mode toggle change, we should open a [Discussion] type issue separately from this one.
It's the user's choice to enter HTML mode, which is by design plain text input mode (although I think you turn
's into newlines..). That's the experience users expect, so they should be able to type "garbage" (that's accurately parseable by the HTML5 standard's algorithm).
This is a no-discussion to be honest. As I mentioned in my previous reply: "this is not enough reason not to have those buttons working.".
Meaning: let's go ahead with this.
Great! If there's no expected timeframe maybe I'll try tackling it myself.
That'd be awesome. Let me know if you need anything.