Editor Onboarding: "The Basics" help section - Details Part 2 #34018
Conversation
Avoid duplicative code by leveraging the existing abstraction.
Adding the "header" role provides improved audible cues of the content structure.
This particular image attempts to communicate the location of the text formatting controls.
Clicking is an action specific to cursor input devices, which is not relevant for touch input devices.
Declaring text elements as headers where appropriate improves the ability to navigate and understand content structure.
Various spacing and sizing changes were required to match the design.
To improve navigation, scroll the help content separately from the heading that remains fixed atop the bottom sheet.
Fix a few broken images. Include assets for higher pixel density displays.
dcalhoun
added
Mobile App - i.e. Android or iOS
|
Size Change: +3.83 kB (0%) Total Size: 1.03 MB
ℹ️ View Unchanged
|
This matches the design comp and the title found elsewhere in other bottom sheets.
|
Wow, the help section is great! Feel like the type of onboarding to introduce in other aspects of the app too! I made a quick pass using the WPAndroid installable build 113968 (I understand @jhnstn will also do his passes too), and here are my notes. Most are about the UX so, pinging both @kyleaparker and @dcalhoun on this 👍 Potential blockers
back-nav-small-hit-target.mp4Non blocking (non-blockers for this PR or out-of-scope)
I'll pause at this point as the comment is already getting too big, sorry about that. Let me know if anything is unclear, thanks! |
|
Thanks for the review, @hypest. 🙇🏻 Potential Blockers
Good catch. I was able to reproduce this and it appears to be specific to the Android bottom bar back button. I'll investigate.
The copy is from the design comps, but I agree the copy could be misinterpreted. I suppose the editor context could either be a post or page. I believe we could use the
It does appear the smaller back button target is fairly small throughout the app for other bottom sheets as well. I will attempt to improve this. Non-Blockers
I agree, the images do have a high amount of contrast in Dark Mode. @kyleaparker if you agree and are willing to create Dark Mode visual illustrations, we could likely swap out the images based upon the Dark Mode setting fairly easily. The only downside I perceive is that we'd double the amount of images we bundle with the app.
I am struggling to follow and identify what you are referencing with this comment. Would you be willing to elaborate further please?
That makes sense to me. It is easy to remove. @kyleaparker WDYT about removing the section heading for now?
This could be a nice enhancement. From researching briefly, we could enable |
That would work yeah, and now I wonder if we can instead just go with a slightly more general title, to avoid having to specialize it. Like, how about "How to edit content". Totally open for more ideas, it feels we should be able to find one that is general enough but usable.
Thanks! It's almost out-of-scope for this PR but yeah, since the user would probably navigate through the sections exploring the info, the small hit target can get frustrating. Sounds like something to try to tackle in a timebox manner and take it to a separate PR if it proves too much for this PR.
Oh sorry. I was referring to the "Remove blocks" asset and how we use the same in the "Customize blocks" case. I was mistaken there though: we are not using the same asset. I guess that glancing at those 2 assets wasn't enough for me to see that in the Customize Blocks one the blue dot is trying to indicate the cog icon, not the 3-dot menu :(.
Thanks for looking into that already David! Since word-level is not yet well supported, it's better to leave this for a separate discussion, perhaps trying out the |
Improve readability of large quantities of help content by leveraging a full screen height bottom sheet. In order to render the nested `ScrollView` at the correct height, `flexShrink: 1` was added to the bottom sheet header element and the `listProps`. The latter is applied to the bottom sheet child scrolling element. Additionally, `height: 100%` must be applied to the top-level element of the child view rendered in this bottom sheet. This matches the link picker implementation and ensures the element fills the parent bottom sheet.
We can change it so it's more contextual for now and say "How to edit your post" or "How to edit your page". The thought behind the original title was that this would be relevant with FSE when people are focused on creating or editing their website. Most people talk about editing their website rather than posts/pages.
If I make dark versions of each image are they easy to switch out?
As a future iteration we could use animations instead of static images. The dot is also meant to help people with the first step of knowing where to go to find certain actions and I had originally imagined it as a pulsating dot to draw the eye a bit more.
We are planning to try out a full height bottomsheet which may fix this issue |
@kyleaparker yes, from a quick exploration, I believe swapping images for Dark Mode should be an easy switch.
The "What is a block?" content in particular will likely always exceed the height of a small device. Also, landscape orientation may experience overflow more often. So, this may still remain an issue in some contexts. That said, my suggestion would be to consider it out of scope for this work and an opportunity for further improvement later. |
The current `BottomSheet.SubSheet` implementation does not reset a given sub sheets visibility when navigating backwards via the Android back button. This results in the child content remaining visible. When subsequently navigating to a new child, the previous child is also displayed. We might be able to hook into React Navigation events to resolve this, but my exploration felt forced and not all that valuable.
Including a close button will make it easier to dismiss the Help section on Android.
Better align with OS defaults to meet user expectations.
Some code is unused, other changes were not necessary or discussed with the original author.
Replace "site" with "post" or "page" base on the current content type. We may reinstate the term "site" once full-site editing features are included in the help articles.
The panel title provides more confusion than value as we only have one panel currently. Once we have multiple panels, reinstating the title would be helpful.
Allow selecting and copying text from help content to improve ability to copy terms into search engines and elsewhere.
Improve usability of UI via larger tap targets for buttons.
|
@hypest @kyleaparker I believe I have addressed the feedback and agreements so far. I am going to consider all other feedback as non-blocking, and opportunities for future improvement. Please let me know if I am mistaken, as I have also requested @jhnstn provide his review so that we can move towards merging this work when possible. Thanks! Completed Improvements
Future Improvements Opportunities
|
Just wanted to link to a relevant ticket and decision here where we'll be adding some scrollbar related tweaks to improve visibility and we could do the same in the help sections too. |
Related PRs
Description
Fixes #30626. Iterates upon the work completed in #33790. This work improves accessibility, copy, and design of the editor help section.
How has this been tested?
Help Section: Visual
Help Section: Audible
Existing Bottom Sheet Headers
Screenshots
UX Interactions
RPReplay_Final1629904800.MP4
Screenshots
Types of changes
New feature
Checklist:
*.native.jsfiles for terms that need renaming or removal).