Opened 7 years ago
Last modified 2 months ago
#41876 assigned defect (bug)
Add inline help to Custom HTML widget
Reported by: | westonruter | Owned by: | rcreators |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Widgets | Keywords: | needs-patch ui-feedback |
Focuses: | accessibility | Cc: |
Description
There is no inline help in the Custom HTML widget for how to interact with the code editor. While the widget will add this to the help text on the widgets admin screen, this is not easily discoverable. Additionally, this help tab text is not displayed in the Customizer at all. Just like the Additional CSS section description in the Customizer, there could be a (?) icon in the widget, and once expanded it could reveal the same help text to guide usage of the widget. I suggest the icon could be placed in the top-right corner of the widget with the help text then appearing at the top when expanded, similar to the Customizer section description.
See also:
Attachments (1)
Change History (37)
This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.
7 years ago
#4
@
7 years ago
- Priority changed from normal to high
Bumping priority to high for visibility and alignment with 4.9 goals, and given proximity to beta 1 deadline.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
7 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#10
@
7 years ago
- Type changed from enhancement to defect (bug)
Changing to a defect
since it's needed for accessibility.
#11
@
7 years ago
Tried out a couple different positioning options in Widget with help.png.
(Note: I tried out a footer option, but I assuming that won't be viable because you'd get stuck in the editor before making it down there. Let me know if this assumption is correct.)
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
This ticket was mentioned in Slack in #core by westonruter. View the logs.
7 years ago
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
6 years ago
This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.
6 years ago
#18
@
6 years ago
My opinion is that the help icon contained within the widget header is the best proposal.
Linking to the help under the widget title pushes the widget functionality to far down.
#19
@
6 years ago
Is there a convention for the help icon in other places in WordPress? If not, I guess I prefer the help icon in the widget header, as it makes it visible too when the widget is collapsed. If this option is implemented, maybe add this to 10ups SketchPress document for future reference?
#21
@
6 years ago
- Milestone changed from 5.1 to Future Release
- Priority changed from high to normal
The 5.1 release beta 1 is today and this ticket still needs a direction and patch. Punting to Future Release. Pinging the Widgets component maintainers: @westonruter @welcher
This ticket was mentioned in Slack in #design by karmatosed. View the logs.
5 years ago
#23
@
5 years ago
Just going through this as part of design triage. @melchoyce do you have a preference for direction here? I ask as you were working on this.
#24
@
5 years ago
I'd love to see a patch writing up the header version, just to figure out if it'll work or feel janky (since the rest of the header open/closes the accordion).
This ticket was mentioned in Slack in #design by chaion07. View the logs.
3 years ago
This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.
3 months ago
#27
@
3 months ago
- Milestone changed from Future Release to 6.7
Reviewing this in the accessibility bug scrub, this is still relevant using the block widget editor, which still provides access to this UI using CodeMirror.
We do think that the help text could be streamlined significantly; this is extremely verbose, when really the only instruction that is relevant is how to exit the editor.
We prefer design #3 or a variant on design #2 with the icon moved after the heading, as having the icon inside the header causes problems with both click target size and with including an additional interactive component within the heading.
We'll experiment in patches, however.
#28
@
3 months ago
As @sabernhardt observes, currently the entire heading is a click area, so having the button inside the heading is a problem; with that in mind, moving below the heading is the only real option.
#29
@
3 months ago
Hopefully this clarifies the design numbering:
- Existing design (as it was in 2017, though it is not much different now)
- Add a button with a question mark icon in the header, and that button expands the help text. The image shows the button on the left side, and @rcreators suggested putting it on the same side as the triangle arrow. As noted in comment:24 (plus 27 and 28), this option could be troublesome when clicking other parts of the heading would control a different element.
- Add an expandable help section under the heading, with both an icon and text. The image shows a focus outline on the icon, but I would like the "How to use this widget" text inside the button that expands or collapses help information.
- Add an expandable section like option 3 proposes, but place it below the widget fields. I would prefer option 3 instead of 4.
This ticket was mentioned in Slack in #accessibility by rcreators. View the logs.
3 months ago
#31
@
3 months ago
I apologize if I'm not doing this correctly. Please correct me. I am using WP 6.7-alpha-58576-src.
I'm unable to re-create this on core themes.
The following have a Appearance > Widget menu, and Appearance > Customizer > Widget.
- twenty-eleven, twenty-twelve, twenty-thirteen, twenty-fourteen, twenty-fifteen, twenty-sixteen, twenty-seventeen, twenty-nineteen, twenty-twenty, twenty-twenty-one
The following do not have a Widgets menu.
- twenty-twenty-two, twenty-twenty-three, twenty-twenty-four
In all instances, Custom HTML
Widget resolves into a Custom HTML
Block. (below)
I'm not certain how to proceed to re-create the Widget Header in the mockup above.
#32
@
2 months ago
@rockykev2b This issue needs to be tested with the Classic Widgets plugin installed.
As suggested by @afercia, this can be generalized so that when you construct
WP_Widget
there can be an optionalhelp
parameter forcontrol_options
which, when supplied, would automatically be inserted into the widget control. In that way it wouldn't be something ad hoc for the Custom HTML widget alone but could be re-used by other widgets. I am not aware of other widgets that need help text, however.