Make WordPress Core

Opened 8 years ago

Last modified 3 years ago

#34991 assigned feature request

Introduce a typographic measure for the admin screens

Reported by: afercia's profile afercia Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots needs-design-feedback needs-patch
Focuses: ui, accessibility, css Cc:

Description

For optimal readability, lines of text shouldn't exceed a certain length. In typography, this is called measure and looking around for references you will find several (different) recommendations, starting from 45-50 characters per line till 90 or even more.

By the way, there's no such a thing as an absolute, perfect, number to fit all the different cases. It depends on many different factors, starting from the typeface used, its metrics, if it's a single column or multi-column layout etc.

That said, when a line of text is really, really, too long, then readability, usability, and accessibility, they're all seriously affected.

I'd like to encourage typography lovers and designers to start some discussion, research, and development with the long-term goal to improve typography in the admin screens. Trying to implement a measure could be a nice start.

Also, I'd like to propose to consider the introduction of a new "typography" focus tag for Trac.

In the screenshots below: a couple examples of some admin screens rendered on a large display with the browser's window maximized.

https://cldup.com/Lqn6W2CVsy.png

https://cldup.com/CV2JcdQI1w.png

Attachments (7)

34991.patch (377 bytes) - added by rishishah 7 years ago.
34991.2.patch (905 bytes) - added by rishishah 7 years ago.
34991.3.diff (890 bytes) - added by xkon 6 years ago.
Updated for svn use.
34991.3.patch (890 bytes) - added by rishishah 6 years ago.
Hello @afercia and @melchoyce I have update my old patch with src.
34991.diff (895 bytes) - added by afercia 6 years ago.
privacy settings measure.jpg (145.0 KB) - added by afercia 5 years ago.
privacy policy guide with measure.jpg (199.1 KB) - added by afercia 5 years ago.

Download all attachments as: .zip

Change History (45)

#1 follow-up: @michaelarestad
8 years ago

You mean like in Tools?

https://cldup.com/jQy9xf2q17.png

Note: this is NOT an ideal solution, but I'm working on it. :)

#2 in reply to: ↑ 1 @afercia
8 years ago

Replying to michaelarestad:

You mean like in Tools?

Yep, Tools visually renders the idea. Was thinking more to a reusable CSS class to be used where necessary in the admin, setting a max-width to the actual content (not the container) and probably expressed in em. Probably needs some research.

#3 @michaelarestad
8 years ago

Yep, Tools visually renders the idea. Was thinking more to a reusable CSS class to be used where necessary in the admin, setting a max-width to the actual content (not the container) and probably expressed in em. Probably needs some research.

Yep. Definitely was planning on doing something similar that, which makes the container a bit more flexible.

This ticket was mentioned in Slack in #glotpress by ocean90. View the logs.


8 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


8 years ago

#6 @rianrietveld
8 years ago

  • Milestone changed from Awaiting Review to Future Release

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

#8 @afercia
7 years ago

  • Milestone changed from Future Release to 4.8
  • Owner set to afercia
  • Status changed from new to assigned

Quickly discussed in today's accessibility meeting and one option could be introducing a max-width for some elements to begin with. Thinking for example at paragraphs in the settings screens. And then progressively extend the new rule to other screens, where necessary. Moving to 4.8 for discussion and experimentation.

Last edited 7 years ago by afercia (previous) (diff)

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#10 @afercia
7 years ago

  • Milestone changed from 4.8 to Future Release

Punting as we're running out of time for the 4.8 release.

#11 @afercia
7 years ago

  • Milestone changed from Future Release to 4.8.1

#12 @rishishah
7 years ago

It looks like it's a CSS issue, So I have added the css code to the '.contextual-help-tabs-wrap' class so now the text is showing in the limit.

http://i.imgur.com/0104vSB.jpg

@afercia Please check my patch and let me know if there is any changes needs to be done by me.

@rishishah
7 years ago

#13 @afercia
7 years ago

  • Version 4.4 deleted

@rishishah thanks! The best option would be creating a new, re-usable CSS class so that it can be used also in other places.

Worth nothing patches should be created from a version-controlled copy of WordPress trunk installed from the develop repository https://develop.svn.wordpress.org/trunk/ (trunk doesn't have .rtl files, they're generated during the build process).

You can read more about the whole process on the WordPress handbook:
https://make.wordpress.org/core/handbook/contribute/
https://make.wordpress.org/core/handbook/tutorials/installing-wordpress-locally/
You can either choose to manually install a local server or use VVV (Varying Vagrant Vagrants)
https://make.wordpress.org/core/handbook/tutorials/installing-a-local-server/installing-vvv/

Also:
https://make.wordpress.org/core/handbook/tutorials/working-with-patches/#creating-a-patch
Patches should be created from the root directory of your WordPress SVN install so that paths within the file start with src/.

#14 @rishishah
7 years ago

Thanks @afercia for the instruction. I have added c new class "typographic-text-wrap" for the re-usable CSS on this particular class. I have a added a second patch please review it and let me know if anything. Thanks,

@rishishah
7 years ago

This ticket was mentioned in Slack in #accessibility by rishi. View the logs.


7 years ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

#17 @afercia
7 years ago

  • Milestone changed from 4.8.1 to 4.9

Punting to 4.9 as per today's bug scrub.

#18 @afercia
7 years ago

  • Keywords has-patch has-screenshots added

It would be great to have some feedback from the design team :)

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


7 years ago

#20 @melchoyce
6 years ago

  • Keywords ui-feedback added

#21 @melchoyce
6 years ago

I'm having trouble applying the patch since it was done on trunk, not src — can someone with more svn knowledge add a patch from the right location?

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


6 years ago

#23 @afercia
6 years ago

@melchoyce it's 3 lines of code :) can also be changed manually, Will try to refresh the patch as soon as I have time.

@xkon
6 years ago

Updated for svn use.

#24 @xkon
6 years ago

@melchoyce I guess 34991.3.diff will be ok for you.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 years ago

@rishishah
6 years ago

Hello @afercia and @melchoyce I have update my old patch with src.

#26 @afercia
6 years ago

Thanks @rishishah !

General considerations:
in typography, a line length is called measure so I'd consider to rename the classe from .typographic-text-wrap to .typographic-measure or simply .measure

Not sure it should be expressed in pixels or em, and not sure about the value. It should result in approximately 80-100 characters. I'd try something like 44em since it should be based on the font size.

It is meant for general use, not just for the help tabs, so I'd place it in common.css in a general section (even if the file sections have lost a clear distinction over time).

@afercia
6 years ago

#27 @afercia
6 years ago

Patch did not apply cleanly because of very recent changes. Refreshed and updated accordingly to previous comment.

#28 @afercia
6 years ago

For a comparison, see the screenshots in the ticket description above and the ones below:

Help tabs:

https://cldup.com/B4wFO8Nzqb.jpg

Discussion settings (not applied on the current patch):

https://cldup.com/PKGvTRNZGh.jpg

Worth reminding the proposed new CSS class is meant to be a general utility class and can be applied on any text block, when necessary. I'd propose to introduce it in core and keep it simple to start experimenting with it.

In the future, maybe consider to extend it and introduce a set of "measure" classes with different values, for example:

.measure-40 { max-width: 40em; }
.measure-44 { max-width: 44em; }
.measure-48 { max-width: 48em; }
...

This ticket was mentioned in Slack in #design by afercia. View the logs.


6 years ago

#30 @afercia
6 years ago

  • Keywords ui-feedback removed
  • Milestone 4.9 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Closing as per today's discussion on Slack #design (see link above).

Opinions differ and there's no consensus. It was pointed out that the max-width issue should be addressed with new designs in the "views" themselves, not with a generic class.

#31 @afercia
5 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

For reference, adding to this old ticket one new example where long lines of text makes readability a bit challenging: the Privacy Settings page.

I'd like to propose to reopen this ticket for new consideration.

#32 @afercia
5 years ago

  • Keywords needs-design-feedback added
  • Milestone set to Future Release
  • Owner afercia deleted
  • Status changed from reopened to assigned

#33 @afercia
5 years ago

  • Keywords needs-refresh added

Worth noting the Privacy Policy Guide page in WordPress 5.2 does set a max-width in the content (see screenshot below), though it appears to be a very unique case in the admin pages.

It would be great to establish a solid pattern to be applied to all the blocks of text with very long lines in the admin.

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


4 years ago

#35 @melchoyce
4 years ago

@drw158 has a typography proposal that would be a good pre-cursor to exploring this issue: https://make.wordpress.org/design/2019/10/11/proposal-a-consistent-type-scale-for-wordpress/

Let's try to get that implemented, and then revisit line-length.

#36 @afercia
4 years ago

  • Focuses css added
  • Keywords needs-patch added; has-patch needs-refresh removed

Thinking now that there's a CSS component, this issue might be of interest of the CSS team.

This ticket was mentioned in Slack in #design by paaljoachim. View the logs.


3 years ago

#38 @carike
3 years ago

If I understand correctly the only change this makes to the privacy policy is to reduce the number of characters per line? :D (Would love that, by the way!)
Thanks for the ping, @paaljoachim. I don't see any issues from a privacy side, but it is always nice to be asked beforehand, rather than having to fix bigger issues later! :)

Note: See TracTickets for help on using tickets.