WordPress.org

Make WordPress Core

Opened 23 months ago

Last modified 3 months ago

#20956 new enhancement

Navigation changes: Posts/Pages

Reported by: jane Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.4
Component: Posts, Post Types Keywords: has-patch
Focuses: ui, administration Cc:

Description

  1. Explaining the difference between Posts and Pages to new users is time consuming and often frustrating. We've all done it, have our best/fastest version of the talk down pat, but it still takes longer than it should to get many new users to the point of understanding the difference.
  1. Back in 2.7, when we set up the left navigation we put Pages at the bottom of the content nav section because in testing 2.5/2.6 so many people complained about accidentally clicking Posts/Pages by accident because they were close together in the old UI and both started with P (blame it on capital_p). Because of this, Pages falls below the less-frequently accessed areas of Media and Links, and people don't necessarily see it right away because they expect it to be higher up.

I've been testing out two changes to the left navigation aimed at reducing these two issues on my test blog for some time now, and have been using it during demos with both new and existing users to great success, so I think it's time to propose it for core.

Change 1: Change the Posts label to Blog. All Posts can remain as is, or could be reduced to just Posts, since the reason we added the All in the first place was that Matt thought it looked weird to have the same word shown twice.

This change reduces the amount of time it takes me to get a new user really understanding the difference between posts and pages by about 75% (very informal testing, have kept track with about 30 new users by just keeping an eye on the computer clock to see how long it is before we move on). The dynamic blog/static site difference is much easier to grasp when they see that familiar word Blog instead of Posts because "posting" is an action that applies even to static content, and even posts are displayed in web pages (vs Pages).

Change 2: move Pages up the menu to sit below Blog, so the two most important content types are at the top. Since they wouldn't look similar (ha ha capital_p) there would be much less risk of accidental misclick based on letter shape (poor manual dexterity would not be affected, but in that case those people are already clicking the wrong things, right?)

I've attached a screenshot showing what the navigation would look like with these changes.

Attachments (3)

Screen shot 2012-06-14 at 10.24.07 AM.png (21.5 KB) - added by jane 23 months ago.
Proposed navigation changes
20956.diff (3.3 KB) - added by Mamaduka 23 months ago.
20956.2.patch (818 bytes) - added by martythornley 23 months ago.
Adds filter and new array to allow changes to $menu

Download all attachments as: .zip

Change History (39)

jane23 months ago

Proposed navigation changes

comment:1 Mamaduka23 months ago

  • Cc georgemamadashvili@… added

Mamaduka23 months ago

comment:2 follow-up: Mamaduka23 months ago

  • Keywords has-patch added; needs-patch removed

20956.diff changes "Posts" to "Blog" and "All Posts" to "Posts", also re-arranged core menu items positions, now: Pages - 10, Media - 15 and Links - 20.

comment:3 circlecube23 months ago

Great idea, I also think this would go a long way from separating the 'post' term from the blog itself. Since we now have custom posts and a 'post' can be anything. The default post type for posts is really a blog post type, so why not call it blog?

comment:4 in reply to: ↑ 2 ; follow-ups: nacin23 months ago

Replying to Mamaduka:

20956.diff changes "Posts" to "Blog" and "All Posts" to "Posts", also re-arranged core menu items positions, now: Pages - 10, Media - 15 and Links - 20.

Re-ordering the $menu array is not going to be easy — I could absolutely envision a plugin doing unset( $menu[15] ) to get rid of Links, which would now get rid of Media. We didn't have remove_menu_page() and remove_submenu_page() until only a few versions ago. Unless we can come up with something surgical, this will probably necessitate doing quite a bit of changes to the "$menu" "API".

comment:5 in reply to: ↑ 4 Mamaduka23 months ago

Replying to nacin:

Re-ordering the $menu array is not going to be easy — I could absolutely envision a plugin doing unset( $menu[15] ) to get rid of Links, which would now get rid of Media. We didn't have remove_menu_page() and remove_submenu_page() until only a few versions ago. Unless we can come up with something surgical, this will probably necessitate doing quite a bit of changes to the "$menu" "API".

Right, this example has backward compatibility issues. We will have same issue without re-ordering other menus and only changing Pages menu order e.g $menu[6], if plugins are removing Pages with unset( $menu[20 ). (which I think would be much rare case that with Links).

Anyway more backward compatible option would be great.

comment:6 in reply to: ↑ 4 ; follow-up: jane23 months ago

Replying to nacin:

I could absolutely envision a plugin doing unset( $menu[15] ) to get rid of Links, which would now get rid of Media.

Maybe also a good time to propose eliminating Links as a standalone content type and make a shift toward putting links in a custom menu or something?

comment:7 in reply to: ↑ 6 nacin23 months ago

Replying to jane:

Maybe also a good time to propose eliminating Links as a standalone content type and make a shift toward putting links in a custom menu or something?

Eliminating Links at the same time we move/rename Pages/Posts makes sense from a user perspective, but it won't help solve our API/code considerations. It's a good idea, but it'll also probably require some kind of a refresh for widget and/or custom menus, as well.

comment:8 kovshenin23 months ago

  • Cc kovshenin@… added

comment:9 johnbillion23 months ago

  • Cc johnbillion added

comment:10 ocean9023 months ago

  • Cc ocean90 added

comment:11 kpdesign23 months ago

  • Cc kparsell-wp@… added

comment:12 martythornley23 months ago

  • Cc martythornley added

comment:13 martythornley23 months ago

This has two areas I've always wanted to see discussed - the placement of Posts, Media, Links, Pages and the ability to better re-order menu items.

Thanks for sharing the reasoning behind the Pages being below Media and Links - get asked about that all the time. :) Totally makes sense when explained that way.

In my experience, both in dealing with clients and seeing the changes of WordPress away from "just a blogging software" to a "real CMS", the renaming of Posts to Blog seems like a step backwards. Many ( too many ) people have a negative connotation towards "blogging" and have to be convinced that it is not a blog but their "news" section, or some other take on it. Others see a blog as unprofessional. They want a "professional website"... All just perception of people who have never had a website before but it is a real concern from the people we are building sites for.

On the developer's side, I could suggest a few reasons for not doing this too. It is fairly easy to set up as many page templates as you want that display different categories of posts. So we could have a "News" section and a "Blog" section and just use different categories of posts. By limiting all "posts" to just a "Blog", it would make it necessary to use custom post types for other things. Not a huge deal, since custom post types are fairly easy to setup at this point, but it could add items to the menu. Take a magazine/news style site. This could be literally hundreds of categories and subcategories and no one thinking of it as a "blog".

Just my initial reaction based on how I see client's sites being used. I see the confusion between Posts and Pages being next to each other but I think renaming it to Blog creates some bigger confusions.

Just an idea.. but what if there were just two simple filters or hooks of some kind to give theme/plugin developers control over the default post types? So we have Posts and Pages which are added to all sites and stuck into the menu where they are. On some sites, I have had to NOT use posts at all because they don't use it and just want a simple five page site ( I know crazy but it has happened ) and they get stuck with a "posts" section that doesn't do anything. Or sites where they wanted only a blog and so pages are hidden.

Couldn't we add a way to quickly rename Posts and Pages and decide whether they are being used at all? If there was a filter to alter post types, we could rename them, and if there was a filter for all registered post types, we could decide whether to add, remove post types. Haven't even looked at how or where to do this but it sounds like a much more flexible way to do it.

martythornley23 months ago

Adds filter and new array to allow changes to $menu

comment:14 martythornley23 months ago

Just added a quick patch that allows a filter to change the $menu array by either name (edit.php) or the numerical key.

http://core.trac.wordpress.org/attachment/ticket/20956/20956.2.patch

I used the following to alter the "Posts" menu item to read "Blog":

add_filter( 'menu_items' , 'custom_menu_items' , 1, 2 );

function custom_menu_items( $menu , $menu_pages ){
	$menu[$menu_pages['edit.php']][0] = "Blog";
	return $menu;
}

I think there might be a few places within that same file to add similar filters. I just added it at the top, before some other changes are made to the menu. But it seems to work. :)

Last edited 23 months ago by martythornley (previous) (diff)

comment:15 hd-J23 months ago

  • Cc jeremy@… added

comment:16 sabreuse23 months ago

  • Cc sabreuse@… added

comment:17 Ipstenu23 months ago

Since my internet crashed right when I was replying to Jane's blog post...

Perhaps we could merge it so the 'author defined content' was in one section:

Blog
Pages
CPTs
Media
Comments

And then the poor stepchild, Links, could get tossed down under appearance until it goes away? There's no good spot for it anymore, and since you can put menus in widgets, it's become even more dead-weight. it's just the moving that becomes the hassle...

comment:18 shawnkhall23 months ago

  • Cc shawnkhall added

I'm with martythornley - this would be such a huge step backwards for WP as a CMS, especially with the condescension that "blogging" already receives.

comment:19 knutsp23 months ago

  • Cc knut@… added
  1. The common capital P problem only exists in English. WordPress is an international, multilingual platform, with an American base and origin, isn't it?
  2. Introducing "Blog" is a step backwards and may harm WordPress' reputation. "So it is a blogging platform after all?"
  3. Of course a new user will expect to find Posts (or Articles, at least) as a main menu item in a CMS
  4. "Pages" is used for too many things. Rename it to Documents, Statics, or whatever if you must rename one of the two content types

comment:20 DrewAPicture23 months ago

  • Cc xoodrew@… added

comment:21 toscho23 months ago

  • Cc info@… added

comment:22 kobenland23 months ago

  • Cc obenland@… added

comment:23 johnbillion23 months ago

Jane made a good counter-counter point to the word 'Blog' being (re-)introduced:

Actually, the ‘just a blogging platform’ is exactly what this would combat. By showing that Blog is only one part of what WordPress has to offer, and all of the navigation isn’t blog-specific, I think it would be much easier to show that you can put a blog in your website, just do a website, or just do a blog.

comment:24 in reply to: ↑ 4 ; follow-up: mikeschinkel22 months ago

Replying to nacin:

this will probably necessitate doing quite a bit of changes to the "$menu" "API".

A huge +1 to that.

comment:25 in reply to: ↑ 24 ; follow-up: nacin22 months ago

Replying to mikeschinkel:

Replying to nacin:

this will probably necessitate doing quite a bit of changes to the "$menu" "API".

A huge +1 to that.

The day of that comment, there was a follow-up conversation in IRC: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-06-14&sort=asc#m407841

comment:26 in reply to: ↑ 25 mikeschinkel22 months ago

  • Cc mikeschinkel@… added

Replying to nacin:

The day of that comment, there was a follow-up conversation in IRC: https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2012-06-14&sort=asc#m407841

Thanks for the reference. If I can help with this in any way I will contribute, just ask for my help. I'd be willing to contribute a lot of my time to improve the admin menu system.

ALSO, on the topic of this ticket, my vote would be to place Pages as the first menu page in the admin menu because it's the post type thing that applies to everyone; who doesn't have at least a few pages on their site? JMTCW.

Last edited 22 months ago by mikeschinkel (previous) (diff)

comment:27 mbijon22 months ago

  • Cc mike@… added

comment:28 ericlewis22 months ago

  • Cc eric.andrew.lewis@… added

comment:29 lorangeo22 months ago

This is a very good idea indeed. And if we take it further, what’s about moving the whole blog feature into an extension that would be installed by default on WP (but not activated)? We would then have a very clean menu with: “Pages”, “Medias”, “Comments”. The “Blog” menu would be added only for THOSE who need a blog on their site (by activating the plugin, like they actually have to activate a “forum” plugin if they want a forum, a “wiki” plugin if they want a wiki, or anything else that they want to be included within their pages (which are esentially the base of any kind of website – a site is made of (web) pages). Sorry for my limited English.

comment:30 lorangeo22 months ago

  • Cc lorangeo added

comment:31 emzo20 months ago

  • Cc emzo added

comment:32 SergeyBiryukov19 months ago

#21927 was marked as a duplicate.

comment:33 beaulebens19 months ago

  • Cc beau@… added

comment:34 pjad19 months ago

  • Cc pete@… added

comment:35 DrewAPicture15 months ago

  • Component changed from UI to Administration
  • Keywords ui-focus added

comment:36 jeremyfelt3 months ago

  • Component changed from Administration to Posts, Post Types
  • Focuses admin added
Note: See TracTickets for help on using tickets.