Mel Choyce 6:29 pm on July 14, 2017
Tags: page on front ( 2 )

A Better “Page on Front” Experience: Previous Ideas

A problem that’s plagued WordPress for years is the confusion and ambiguity around setting your “front page.” The addition of making new pages in #38164 was a big jump forward, but there’s still work we can do to make this a better experience for people setting up their sites.

Here’s what it looks like now:

Customizer

wp-admin

Let’s try to tackle this issue again in 4.9 and see if we can at least make some incremental improvements.

To start us off, let’s use this post to take a look at some of the ideas proposed in the original ticket and chat them:

Concept by @mmuro [Source]

Concept by @lessbloat [Source]

Concept by @lessbloat [Source]

Concept by @chexee [Source]

Concept from @SergeyBiryukov and @lessbloat [Source]

Concept by @lessbloat [Source ]

Concept by @drewapicture [Source]

Concept by @lessbloat [Source]

Concept by @ThemeZee [Source]

Concept by @folletto [Source]

Concept by @folletto [Source]

Concept by @folletto [Source]

(Explanation for those three concepts)

Concept by @westonruter [Source]

Concept by me [Source]

This slideshow requires JavaScript.

How WordPress.com currently handles Home and Blog pages in the Pages list

Any great ideas stand out within these previous iterations and conversations? Any gut reactions?

#page-on-front

Tammie Lister 6:40 pm on July 14, 2017

One idea we played with a little but never released on .com was focusing on page templates through Customizer. This was called ‘make me a homepage’. I think it’s worth sharing this idea just as one way of thinking.
Mel Choyce 6:44 pm on July 14, 2017
Some thoughts and ideas:
- We should definitely rework the labeling of this to say Homepage, not Front Page or Page on Front.
- The idea behind this itself feels backwards; you always have a homepage, you’re just choosing what content you’d like to display on it. “What do you want on your homepage” vs. “Set a page as front.”
- Within the Pages list (edit.php?post_type=page), we should highlight your homepage and blog with icons for additional clarity.
- We should let people set a page as home or blog from their Pages list.
- Should your homepage always exist at the top of your Pages list? Maybe even called out separately?
- What if we asked during site setup if people want a website, a blog, or both?
- What if we defaulted to creating a new, static “Home” page when people set up sites? And then change the setting to control whether or not they want to show blog posts on that page?
- What if we integrated the “Posts per page” setting into picking which page to display your blog on?
- What if we removed Page on Front from Settings, and only had it exist in the Customizer?
- Will Gutenberg make these settings irrelevant?
- Joy 9:51 pm on July 14, 2017
  - I don’t agree that Homepage is a good term. “Home” maybe.
  - You don’t “always have a homepage”. Your site always has a Home page, but that could be showing Posts, and you could have it set to show at most one. (I have a client site like this.) It makes sense to me for a blog software to default to Posts, not Pages.
  - The Pages list already highlights the front page and blog page. I suppose people like icons for that. I don’t.
  - I can see the value of setting a front page from Quick Edit in the Pages list, although it’s rare to change it, so to me it’s a minor thing.
  - No, the Home page should not be at the top of the list of Pages. That list is default ordered by menu order, and you can sort it other ways. If your Home is Posts, it is not in the list, so it should be consistent, which you get with menu order.
  - What good would asking if they want a website be when they are setting up a website?
  - I don’t like the idea of defaulting to creating a Home page. The install already creates a Page, a Post, and a Comment, which you have to delete or edit in order to make it your site. Defaulting to Posts on front makes sense for blog software.
  - I don’t understand the concept of integrating “Posts per page” for which Page the blog is on. I’m not sure why it even needs a Page except to have an address.
  - Please don’t eliminate perfectly good settings pages! Not everyone likes the Customizer. It’s not as if it isn’t already in there, but why should I have to load all that overhead just to do a rare change to what is on Front?
  - I don’t understand what Gutenberg would be supplying that would make a difference for what is shown on front. Can you explain how an editor influences what the theme shows for the main address?
- Davide 'Folletto' Casali 10:56 am on July 16, 2017
  
  We should definitely rework the labeling of this to say Homepage, not Front Page or Page on Front.
  
  +1
  Would be nice to have a test to be sure, but in my experience “homepage” is how people usually refer to this.
  
  The idea behind this itself feels backwards; you always have a homepage, you’re just choosing what content you’d like to display on it. “What do you want on your homepage” vs. “Set a page as front.”
  
  +1
  
  Within the Pages list (edit.php?post_type=page), we should highlight your homepage and blog with icons for additional clarity.
  
  +1
  
  We should let people set a page as home or blog from their Pages list.
  
  +100
  This is very important. The assumption I have is that the Pages list is often how people think about their site structure / architecture, so configuring the homepage there makes sense.
  
  Should your homepage always exist at the top of your Pages list? Maybe even called out separately?
  
  This is tricky, I don’t think it can be answered in isolation of a redesigned mental model to frame this.
  
  The “Pages” structure is currently a strict list of pages (content wise). This is ok, but if we instead shift the mental model where “Pages” is actually the site structure (which… outside of the WP technicality, is what people refer to “site pages” from the outside), then that page can contain any kind of content that is part of the site structure. That shift imho would be beneficial, as the current division comes from how the DB is structured, not from a user need.
  
  With this mental shift, we should consider the “Pages” really being the site structure, so it’s in a sense more about “urls” than “pages” in the db sense, and it would work really well then to have “Latest Posts” or “Homepage” there too in some form. It’s a “page” in common parlance, and it’s part of the site structure.
  
  What if we asked during site setup if people want a website, a blog, or both?
  
  I’m neutral on this. If done well can be useful. The only note I would make here is to resonate a bit what @karmatosed was saying above that maybe it’s better to think this in terms of templates?
  
  What if we defaulted to creating a new, static “Home” page when people set up sites? And then change the setting to control whether or not they want to show blog posts on that page?
  
  WordPress changed a lot over the years, and I think this can make sense, especially once we make changing it intuitive. I’d consider this one something that should be done only after we have a solid, intuitive design to change it.
  
  What if we integrated the “Posts per page” setting into picking which page to display your blog on?
  
  You mean showing the option around the same UI that switches it? I think it makes sense in quite all scenarios, as it’s in practice the “content” of such a page.
  
  What if we removed Page on Front from Settings, and only had it exist in the Customizer?
  
  +10
  This UI shouldn’t be duplicated too much, and has really no relationship with Settings. In terms of admin information architecture, it’s either Pages or Customization.
  
  Will Gutenberg make these settings irrelevant?
  
  Possibly, as it would make possible to just have a “Page” and add the Latest Posts block. It’s too early to tell, but the pieces are all there.
- Jon Brown 10:05 am on July 17, 2017
  
  First, I’m super happy people are looking at this age old point on confusion for so many users. Thanks Mel!
  
  I agree with all of what Joy wrote above, especially about disagreeing with calling it “home page”. That not the confusing part of the UX and calling it a “home page” just makes things more confusing. It’s a front page and should be called a front page.
  
  Every site does have front page, it’s just a matter of which page you assign to show on the front.
  
  A user thinks of it from the perspective “this is what I want to show on the front of my site, how do I make that happen?”. They don’t think of it from static vs blog (non-static?). That’s the confusing part. Neither of those terms makes any sense to most people because most people’s front pages aren’t static, they often still have all sorts of dynamic craziness still going on on that page.
  
  I think if we were doing this today we’d give that power to each theme to just authoritatively make the decision for users… if we could just kill deprecate blog.php that’d be wonderful… but… I find that unlikely.
  
  A sensible UX that doesn’t break back compat would be to default to “Use default blog template to show latest posts on the front” (even if this is the minority of most sites). Yes, that’s wordy, but it’s crystal clear. Decisions over options, but also clarity over confusion.
  
  Then stop using the term “static page”. That’s insider speak that requires you know the difference between posts and pages, something most don’t when they’re first setting up their site. Simply say “Select a page to show on the front”. Let them select a page from the drop down or create a new one. Bonus, determine if the theme has a front-page.php template and if it’ll be used, display a help note saying “This will be shown using the Page template” or “This will be shown using the Front Page template”.
  
  Then prompt for “Use a placeholder page for your latest blog posts” and again a drop down to select a page.
  
  TL:DR; the problem isn’t “home page” the problem is “static page”
  
  +1 to being able to set the front page from the pages list, but also +1 on this being pretty minor since the only time I’ve never seen a site “change” the front page is when changing it from a “coming soon” page to the live front page… and then never again.
  
  What if we asked during site setup if people want a website, a blog, or both?
  
  Again, I think this is a problem of confusing language that requires they know things they don’t at the time of setup. I know .com did something like this in their theme selector, and it makes sense there _at theme selection_, but it doesn’t make sense when someone is setting up their own site and may or may not already have a theme in mind. This again warrants considering surrendering this option entirely to theme developers with add_theme_support to proactively make a choice here.
  
  -1000 on customizer only. We still disable the customizer entirely on most custom sites we build. It’s just not worth the hassle, cost of development and confusion it causes for bespoke sites. That said, we do fully support it for distributed themes (still somewhat begrudgingly, but more willingly than a year ago, I suspect the same uptake curve will be true of Gutenberg for a few years). Hence, the UI should be nearly identical in the customizer as on the traditional admin settings page. Frankly I really wish more of that code was actually reusable between traditional settings pages and the customizer…
  - Drivingralle 12:22 pm on July 17, 2017
    
    +1
- Nick Halsey 3:08 am on July 31, 2017
  
  What if we removed Page on Front from Settings, and only had it exist in the Customizer?
  
  Great idea. We should definitely move the “posts per page” setting with it, so that that can be live previewed. It’s a super confusing setting as a new user, and the preview makes it clearer that it can make a dramatic difference on certain themes (especially when they’re grid-oriented). In fact, that’s also a setting that would benefit from live preview during the theme switch/setup process. The technical implementation should be trivial to preview it using the existing base customize API.
WhirledPress 3:24 pm on July 15, 2017

Personally, I think we should eliminate the concept of “posts” being a displayable item. In my opinion, a post does not a webpage make. If we thought of “Pages” as the containers that WordPress displayed, then Posts would become content types like they should.

To display a single post, you would then use the “Single Post Page” to display it. It even sounds better. To display a custom selection of posts, you would use the “Post Collection Page” type or “Post Archive Page” type if you are a purist. You would no longer have search results displayed because they belong in a “Search Results Page”. And media no longer is displayed on it’s own, it’s displayed in a “Media Page” or “Media Collection Page”.

And besides the built-in defaults, you could then create a custom page that you’d use for specific posts that would be a “Contacts Collection Page” or “Contacts Archive Page” for example.

So under Page menu in the admin screen, you would then have simply:
Add New Single Content Page
Add New Content Collection Page (Add New Content Archives Page).
Add New Custom Page
—
For Single Content Pages and Content Collection Pages, you would select the content type to display:
Post Content
Media Content
Search Content
Author Content
Category Content
Tag Content

And for any “Single Content Page” types, you could then create a page that encapsulated the post-parameters, but included a title and introduction.

New Content Collection Page:
=================================
CONTENT TYPE: Posts
TITLE: Funky Posts
QUERY: Category contains ‘funky’
CONTENT: This is an introduction to funky posts
POST-TEMPLATE: 2 COLS EXCERPT
PAGINATION TYPE: next/prev
===================================

New Post Single Page
=================================
CONTENT TYPE: Post
TITLE: Sticky Page
QUERY: postID=3939
CONTENT:
POST-TEMPLATE: featuredPost
PAGINATION TYPE: next/prev
=============================

And the default Post-based Page Types that are dynamically built are:

New Post Single Page
TITLE: Latest Post
Query: “latest post”
Content:
Post-Template: singlePost
Pagination Type:None;

The default Post-Based Types would not need to be listed under “Pages”, unless you wanted to override the generic “Latest Post” page, then you would create one and edit the content to add a preface to your latest post that applied to your latest posts always.

This would completely simplify the concept of determining which content you wanted to display for home. You could simply select from two categories of pages:
—-dynamic pages—
Latest Post – single
Latest Posts – archive
All Posts – archive
—-custom pages—
sample page
————————–
Create new page

When you create a new page, it would ask what kind of page:
Single Content Page
Content Collection Page /Content Archives Page
Custom Page

This would completely eliminate the confusion that plagues WordPress with different content types. Every page rendering then simply becomes a “Page Type”.

This is particularly nice for Category Pages where you want to have an introduction to the category that always displays before the content. Plus, by selecting a content-type template, you can easily determine how your “funky” tagged posts are displayed. Plus you can easily enable user-interface options to view as a single post, infinite scroll, grid, columns, etc.

Sorry to ramble on, but the idea of displaying “posts” just has never set well with me. You don’t view web posts, you view web pages. And one of the kinds of web pages you might want to see could contain posts. It eliminates all of this confusion for once and for all.

And if you look at your questions or concerns or the replies to your questions or concerns. you can see how quickly and easily this answers all of those concerns.
- jayash101 11:21 am on August 11, 2017
  
  You have written whole article in this comment. Lol
Mel Choyce 6:53 pm on July 17, 2017

Another concept from @lessbloat: https://davemartinsblog.wordpress.com/2014/10/27/wcsf-contributor-day-idea/

(This was the broken link from https://core.trac.wordpress.org/ticket/16379#comment:129)
- thomasunthank 7:52 pm on July 21, 2017
  
  I believe a possible solution would be to state in the initial install that the default is the display of post on the front page and explain the option of using the ‘static page” [ could use a better more descriptive name] and the instructions to setup of the “static page” [ this seems to be similar to the ‘home’ in the default setup] as a hidden page with the new content page to show as the initial page on the site. The traditional naming of these pages seems to be the main problem and could be served by developing new names for these functions and provide very clear documentation at the install level for these choices.
  
  I have not had a problem using the current concept/structure after reading the documentation. Better highly visible documentation at the initial installation could be a major tool in solving this long standing problem.
Mel Choyce 5:10 pm on July 26, 2017

Comment from @ajamm:

For me, I never have auto-add to menus activated – so whenever I publish a new page, I have to go and add it where I want it to the menu if I want it on one.

Wondered if we could add an option on the page creation screen “Add to Menu’, which then gives you an option of which menu you’d like to put it on.

This could apply to posts and others too, and could be turned off in the page options.

Good tie-in to how menus and pages are currently poorly linked, and how any work done onto “page on front” could potentially lead the way for a better page/menu relationship in the future.
Nick Halsey 3:04 am on July 31, 2017

This seems like a good time to consider merging the Front Page Custom Post Type plugin into core. Its functionality is critical for many sites (such as portfolios that have secondary blogs) and feels like something that should be possible out of the box. The implementation there may be a nice standalone addition in the customizer as-is, or it could be part of a larger rethinking.