-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Update/list view outline information about post #50414
base: trunk
Are you sure you want to change the base?
Update/list view outline information about post #50414
Conversation
…ucture to get content into two columns
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@n2erjo00 Thanks for the PR. I think this is a nice chance to make this section more accessible to screen reader users. Instead of using a visual 2 columns, let's use a table here instead? Visual columns are just that, visual columns.
@alexstine Good catch. One table coming up. I'll whip it up today at the evening |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@n2erjo00 Code looking good. One suggestion below.
@WordPress/gutenberg-design Might want to give this one a visual review for me?
</caption> | ||
<thead className="screen-reader-text"> | ||
<tr> | ||
<th scope="col">{ __( 'Metric' ) }</th> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These are duplicated. Only need 2, not 4.
return { | ||
headingCount: getGlobalBlockCount( 'core/heading' ), | ||
paragraphCount: getGlobalBlockCount( 'core/paragraph' ), | ||
blockCount: blocks.length ? blocks.length : 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The TableOfContentsPanel
panel uses getGlobalBlockCount
here as well.
gutenberg/packages/editor/src/components/table-of-contents/panel.js
Lines 17 to 27 in 074443a
const { headingCount, paragraphCount, numberOfBlocks } = useSelect( | |
( select ) => { | |
const { getGlobalBlockCount } = select( blockEditorStore ); | |
return { | |
headingCount: getGlobalBlockCount( 'core/heading' ), | |
paragraphCount: getGlobalBlockCount( 'core/paragraph' ), | |
numberOfBlocks: getGlobalBlockCount(), | |
}; | |
}, | |
[] | |
); |
I left a small note, but from a code perspective, this looks good. This implementation uses @afercia, you reviewed the original content structure PR. Was there a reason for choosing the list markup over tables? |
Sorry I'm late to the party. I'd totally agree to add back the information about "Headings", "Paragraphs" and "Blocks" and I'd support this PR's effort, thank you! I don't see any good reason to remove important information. @Mamaduka @alexstine regarding the table, I'm not sure this data can be represented correctly with a table. Well, it could be, but the table should have two columns: metrics and value. The table in this PR has 4 columns: metrics and value and again metrics and value. Actually, the 4 columns are used for visual purposes. Repeating metrics and value twice doesn't seem ideal to me. For clarity, I copied and pasted the HTML output from this PR in a codepen at https://codepen.io/afercia/full/PoxOMLZ so that it can be tested more easily. Screenshot: Aside:
Overall, I'm not sure. a table is appropriate in this case. I'd just use a list. Worth mentioning the current HTML on trunk is just a bunch of divs and spans, which is totally unsemantic and, honestly, a poor document structure. A regression in semantics quality compared to WP 6.1. Lastly, I'm not sure the info about Characters / Words / Time to read / Headings / Paragraphs / Blocks should live in the 'Outline' tab. This tab should only contain the Document outline. I'd consider a third tab dedicated to the statistics. |
@afercia Nice catch. I totally missed that. I just got really annoyed with how this info was being displayed so thought a table could make sense. At least the table could give us data relationships vs. a bunch of divs/spans for a fake list. |
@alexstine thanks. When you have a chance, what about this point?
I would like to make the 'Outline' tab contain only the document outline, in the first place. |
@afercia That's probably a fair point to make, just not sure what we would put in the Outline tab since List View tab is probably closer to an outline users would expect. |
@afercia @alexstine Is the consensus that what we need is
|
@n2erjo00 thanks for the ping. |
Sounds fine to me, as long as it is a proper |
…component. These data fields will live in separate component
@alexstine Gentle nudge |
@n2erjo00 Sorry about this. I guess I forgot about this PR with WordCamp US happening. Can you give this a refresh from latest trunk? Packages have changed and my NPM is too new to build this now. Thanks. |
@alexstine No worries even I had completely forgot the existence of this 😅 Latest trunk merged to this branch |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@n2erjo00 This is testing well. A couple fixes:
- There is no space after the ":" so screen readers read out as "Characters:10" vs. "Characters: 10". Does not sound like a large issue until you listen to it for yourself. Is there a way you can add spacing, maybe outside of the translations? I'm not sure it is a good practice to include whitespace in translations but might be wrong about that.
- The
useInstanceId
hook takes a second parameter, prefix. You could simplify the code. I left a comment with specific examples. Be sure to apply it to both files.
<div> | ||
<div className="edit-post-editor__list-view-overview__container"> | ||
<p | ||
id={ `edit-post-editor-list-view-overview-outline-${ instanceId }` } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
id={ `edit-post-editor-list-view-overview-outline-${ instanceId }` } | |
id={ instanceId } |
@@ -63,24 +64,37 @@ export default function ListViewOutline() { | |||
headingCount: getGlobalBlockCount( 'core/heading' ), | |||
}; | |||
}, [] ); | |||
const instanceId = useInstanceId( ListViewOutline ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
const instanceId = useInstanceId( ListViewOutline ); | |
const instanceId = useInstanceId( ListViewOutline, 'edit-post-editor-list-view-overview-outline' ); |
…readers read more clearly
…early. Simplified code by using second parameter of useInstance
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@n2erjo00 Thanks for all the hard work here. This is testing well for me.
Tagging @andrewserong for final review.
Thanks for the ping, and for the work here @n2erjo00! Adding a new tab is a fairly prominent change, and I think it's a great idea listing out more stats about the number of different blocks within the document, whether that's included in the existing Outline tab, or in a new Info tab. From playing around with the change, it looks like it could use a pass from a designer to ensure that the text is visually consistent with other areas of the app (e.g. spacing between the text and edge of the window, sizing, colours, etc), so I'll just add the Needs Design Feedback label to this PR. Here's how the Outline and Info tabs are looking for me currently in testing:
Nice work so far! |
@jameskoster Sure they could live in same tab 😄 Looking back at the discussions on this PR simpler the better was the reason to split between Outline and Info. Based on the mockups I'd go with Outline and Info split. Since Outline already contains the heading structure (and it can eat a lot of space) putting black-and-white statics at the end would make Outline too crowded and little taxing to find them (if lot of headings). I think I have time on upcoming weekend whip up the following
|
@jameskoster Did the things, honest but brutal feedback appreciated 😄 PS Mocks contained changes to "Multiple H1..." warning box. I did not implement these changes since they are not what this PR is for. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for continuing on with this @n2erjo00! Code-wise it's looking pretty good to me.
In re-testing with some shorter blog-post-like content, I think it's pretty common to have posts that don't have very many headings, and in these cases, it means the Outline tab can be fairly empty. In playing around with this in my test environment, I think my personal preference would be to keep the Information as a footer section within the Outline tab as in James' mockup #50414 (comment). Having a separate tab for Info feels to me like it'd be more useful for posts that have very complex heading hierarchies, which I suspect are in the minority. And the footer idea for the Info section sounds like it could be a good way to mitigate that situation, too.
Here's a couple of screenshots of how it's looking for me:
Outline tab in a short post | Info tab in a short post |
---|---|
That's fine :)
I tend to agree, the outline tab is often sparse, and the info tab isn't exactly dense. It would be nice to keep them combined.
Perhaps @afercia could elaborate on why the separate tabs are preferred. Is there an alternative such as labelling the tab "Outline & info", or even just "Info" if a case can be made that the outline is informational? |
@afercia Gentle nudge. See comment above ☝️ |
@afercia Gentle nudgy-nudge-nudge |
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
What?
In the editors list view outline section added "Headings", "Paragraphs" and "Blocks" fields, which show total amount of mentioned element in the post.
Created new tab "Info" to house requested fields.
Also HTML structure changed from divs and spans to ul to improve HTML quality and accessibility
Why?
Issue was brought up in here #50280
How?
Added code which calculates the total values of the elements.
Changed structure of HTML to split content between two columns.
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast