WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#35796 new enhancement

"Permalink Settings" admin page is largely blog/post specific

Reported by: johnjamesjacoby Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Text Changes Keywords: 2nd-opinion
Focuses: Cc:

Description

The current verbiage in options-permalink.php is a little cryptic, and in a world pull of custom post types (including Pages) it's actually a bit confusing:

Here's the current verbiage:

Permalink Settings

WordPress offers you the ability to create a custom URL structure for your permalinks and archives. Custom URL structures can improve the aesthetics, usability, and forward-compatibility of your links. A number of tags are available, and here are some examples to get you started.

I'd like to see these changed to something more like:

Post Link Settings

WordPress offers the ability to customize the URL structure of your post and post-archive permalinks, improving the aesthetics, usability, and forward-compatibility. Several tags are available, and we've included the most popular configurations below:

In addition, I'd like to propose we include the permalink tags in the dropdown Help section, rather than link off to WordPress.org.

All of this would offer several UX improvements:

  • Keep the user on the same page rather than link off and open a new browser tab for WordPress.org
  • It better expresses to the end-user that this settings page is largely dedicated to posts, implying that pages and custom post types get pretty URLs largely as a consequence
  • Now that unregister_post_type() is in trunk, we should start thinking about trimming the options down to "Pretty" and "Unpretty" if the "Posts" type isn't even registered anymore. (There are likely to be many other considerations in this circumstance, but it's relevant here.)
  • It's a friendly nod to developers to remind them that this page won't help them with their custom post types, taxonomies, or rewrite rules for other purposes.

Attachments (1)

Screen Shot 2016-02-11 at 6.12.55 PM.png (126.1 KB) - added by ericlewis 2 years ago.

Download all attachments as: .zip

Change History (11)

#1 in reply to: ↑ description ; follow-up: @johnbillion
2 years ago

Replying to johnjamesjacoby:

  • It's a friendly nod to developers to remind them that this page won't help them with their custom post types, taxonomies, or rewrite rules for other purposes.

We could be even more explicit here and mention this. Something like "These settings won't affect custom post types or taxonomies."

#2 in reply to: ↑ 1 @mordauk
2 years ago

Replying to johnbillion:

Replying to johnjamesjacoby:

  • It's a friendly nod to developers to remind them that this page won't help them with their custom post types, taxonomies, or rewrite rules for other purposes.

We could be even more explicit here and mention this. Something like "These settings won't affect custom post types or taxonomies."

Except that they do in a minor fashion: loading this page and/or saving the settings rewrites permalinks, which can have an effect on custom post types and taxonomies.

#3 @ericlewis
2 years ago

At a high level I agree with this critique.

we should start thinking about trimming the options down to "Pretty" and "Unpretty"

Absolutely. This is a top-level setting for permalinks which is currently nested into the post permalinks configuration, which is confusing.

If plain permalinks is selected, we could disable form elements and gray out text appropriately.

If we separate out this general, top-level setting, then we can make the sub-sections more specific. Riffed on this a bit here.

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


2 years ago

#5 follow-ups: @jaragozzine
2 years ago

Instead of "Pretty" and "Unpretty," can we move to something less subjective and more telling of why one would choose one or the other? Possibly "pretty" becomes "human-readable" and "unpretty" is better stated as "machine" or something to suggest that those URLs do not inform humans where the link goes or its subject matter? We don't pick "pretty" permalink because they look better; we pick them so that a person can read the URL and get an inkling as to what they would get if they click.

#6 in reply to: ↑ 5 @johnjamesjacoby
2 years ago

Replying to jaragozzine:

Instead of "Pretty" and "Unpretty," can we move to something less subjective and more telling of why one would choose one or the other?

I'm okay with this, though "Pretty Permalinks" has become more of a noun than an adjective (thanks to it having been around for so long and it being somewhat cryptic.)

  • Human readable, SEO Friendly, there are a few different directions that could go
  • Machine, Short, or just Default might suffice for the unpretty replacement

There's also an argument for pretty/ugly to be insensitive or offensive, so this may be worth exploring further.

#7 @rousseln
2 years ago

Let's take into consideration that the average person using this setting won't be a developer. So using "pretty/unpretty" or "human readable/machine readable" is still pretty obscure.

SEO Friendly isn't so bad, but still implies that the person knows what the acronym SEO means.

My suggestions:

  • Legible or Readable instead of pretty
  • System formatted instead of unpretty

#8 in reply to: ↑ 5 @DrewAPicture
2 years ago

Replying to jaragozzine:

Instead of "Pretty" and "Unpretty," can we move to something less subjective and more telling of why one would choose one or the other? Possibly "pretty" becomes "human-readable" and "unpretty" is better stated as "machine" or something to suggest that those URLs do not inform humans where the link goes or its subject matter?

I'm -1 on moving away from "Default" or "pretty" permalinks nomenclature lacking data or research that suggest a change would be beneficial.

I think "pretty permalinks" conveys fairly closely the difference between word-based permalinks and "default" query string-based ones. It's also worth mentioning that this vernacular is well established in tutorials, guides, user, and developer documentation throughout core and the community. A small change here can easily inspire confusion elsewhere.

We don't pick "pretty" permalink because they look better; we pick them so that a person can read the URL and get an inkling as to what they would get if they click.

Actually, I think vanity is and can be very much part of the decision. Whether "pretty" is the best way to convey the difference, I don't know. It seems to have worked reasonably well over time, however.

Either way, before considering a change like this I'd think we'd need to see data or research that demonstrates need.

#9 @johnjamesjacoby
2 years ago

I'm in full agreement with Drew. And admittedly, somewhat bias due to the alliteration that "pretty permalinks" comes with, which has been proven to be a physiological win for the majority.

It's a good exercise through, to consider what alternatives may exist and how viable they may or may not be.

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


2 years ago

Note: See TracTickets for help on using tickets.