Skip to content
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

[UX] Add a default Home Page layout #1042

Closed
jenlampton opened this issue Jun 27, 2015 · 38 comments
Closed

[UX] Add a default Home Page layout #1042

jenlampton opened this issue Jun 27, 2015 · 38 comments

Comments

@jenlampton
Copy link
Member

jenlampton commented Jun 27, 2015

Since the most common use-case for using a different layout is for the front page of a site, I think we should add another layout to the standard install profile.

One column layout containing:

Other things to think about:

Do we change the variable for site_home_page from node to home

YES

Do we enable the default Front page view and add a block display to it (also enabling the path frontpage

YES

Do we add a new (cloned / similar) view for the home page block.

NO

Are we okay with losing the text that appears on a fresh install (with a link to create content, if you have access) or should we add this as a block on the new home page, easily removed?

YES

What happens to the /node page, do we remove it?

YES in 2.x See #2114

What happens to the rss.xml page, do we remove that in favor of the view?

YES.

If we remove rss.xml, do we remove view-mode and post-count settings at admin/config/services/rss-publishing?

NO. These also affect taxonomy/term/% paths (which should also be replaced with views) so we can't remove them until that is done. See #145

If we don't remove them, how do we account for the fact that they no longer affect the home page rss feed?

I don't think this is actually an issue, the view has a setting for "Use site-wide RSS settings" and we can take advantage of that if we want. This will also need to be removed when the taxonomy/term/% views get in.


PR from @jenlampton at backdrop/backdrop#1500
PR from @jenlampton at backdrop/backdrop#1539

@quicksketch
Copy link
Member

The suggestion is to ship with a layout pre-configured, e.g. a layout configuration with a path like "front", that is also configured to be shown as the front-page of the site. New users tend to find things easier to modify than to create something new (the same reasoning behind #519). As it's likely that sites will want to customize their front page differently than other pages on the site, providing a preconfigured layout that is already set as the front page can help new users understand the concept of layouts and help them on their way towards customizing their site.

@docwilmot
Copy link
Contributor

The confusion here for me was of course you were saying 'layout' I was thinking 'layout template'. We really need to fix that.

With your explanation (and my recognition), very good idea.

@sutibun
Copy link
Member

sutibun commented Sep 6, 2015

We should have nice defaults. How about a swanky homepage.

I took a look and found this, which lists different homepage layouts. I liked these in particular.

A simple one page layout basically.

I don't know if this can all be done with Layouts but this is my vision for a default Backdrop homepage

homepage

  • Nav section Self explanatory. Menu links.
  • Featured image section - what if the user can click here and upload a custom featured/cover photo. The default is an automagically generated image with the site's name on it along the lines of Wordle
  • Latest posts A View listing the latest content with a link to the hello world post
  • Extra content section Another block for user to add more text
  • Footer section Self explanatory. Footer links and copyright info.

This default homepage offers new users something to play with immediately without looking deep into settings, views admin, etc. Just click and edit.

On top of that, a Backdrop's default look will stand out from a Wordpress' default.

@quicksketch
Copy link
Member

Thanks for chiming in here @sutibun! From what you've described, the homepage would use a single-column layout template (which we already have). The only trick to doing what you've suggested is making the new blocks for the out-of-box experience. I think we could get a long ways towards what you're describing by making some kind of "Background image" block, or allowing a custom background image to be added to the header block through configuration.

@sutibun
Copy link
Member

sutibun commented Sep 6, 2015

Yes, @quicksketch single column.

I just don't think a sidebar belongs on a homepage (Depends really but I'd say usually) because then it looks like a blog. I usually create a different section for the blog http://www.example.com/blog I find myself trying to modify (correct?) this. On Wordpress, I can achieve this look since WP theming is fairly simple to me.

For my Drupal site, I've given up trying to make it look how I want it to. I already know how to design using CSS and HTML but I don't want to invest tons of time to learn Drupal design. It took me a few years to finally be at a decent Drupal builder level. I'd rather delay hitting the design curve for Drupal.

This is likely just my preferences talking, but I think a homepage should look different from the rest of the site.

Since you brought it up, blocks should also have the ability to add images in addition to text. My current Drupal hack is to upload an image on an article type, copy the image URL, and paste the image URL on the block. Blah.

@quicksketch
Copy link
Member

Since you brought it up, blocks should also have the ability to add images in addition to text.

This will be solved later this month when 1.2 comes out. 😄 See #1088.

However the ability to make a background image is a different thing entirely and should still be a separate feature for us to work on.

@sutibun
Copy link
Member

sutibun commented Sep 6, 2015

@quicksketch Ah, nice. Thought the editor was for text only.

Maybe it doesn't have to be a background image for the homepage. Simply an image.

@quicksketch
Copy link
Member

Maybe it doesn't have to be a background image for the homepage. Simply an image.

We could go both ways on it for sure. Having a built-in background image option may be useful because users typically aren't allowed to input CSS to make such a background. If we decide to just support uploading an image at all, perhaps putting a focus on making blocks fieldable would help: #100

@docwilmot
Copy link
Contributor

Layouts can do this of course, even though for now the background image would need to be specified via CSS. My Senjo Layout layout, coupled with the Colihaut theme, in use on Wilmurt.com is similar in design to what youre suggesting I think, though nowhere as slick as your sample sites.

Should be a good idea to design a block that allows placing a configurable image background and superimposed menu and text. We could probably even 'improve the slider to have multiple text overlay regions.

And the area below the slider is fullwidth if you dont add any blocks to the sidebar.

But it can be done, at least.

@sutibun
Copy link
Member

sutibun commented Sep 7, 2015

If the block with a background image will take too long, we can go with a regular image for now. It'll be good enough for 1.0 version. There's no need to delay the default homepage layout. We can swap them once the functionality is there.

@sutibun
Copy link
Member

sutibun commented Sep 11, 2015

Yay. This thread got mentioned in the design meeting even if briefly.

Just two thoughts.

  1. I understand that one page layout look can be considered a design trend.

    What I am really for though is a default homepage that looks different from the rest of the site. It doesn't necessarily have to be what I suggested with the featured image.

    The default homepage design of most CMSs all look like the blog homepage (2 columns, header, recent posts in asc order & footer ) including the category page, the tags page, etc. It's like there is no thought going beyond this design pattern. Sure, it fits for the blog but must this design pattern extend to the whole website?

    I'd even go so far as to say the category/tag page needs it's own design. Doesn't need to be radical. What if the category page listed posts with just its title. Is this great? Maybe. Maybe not. But, at least, one can visually tell when they're on the homepage, the blog, and the category/tag page. backdrop-layout

    It's one of those little things that can help Backdrop stand out. If everyone is zigging, you zag.

  2. I liked what you said earlier.

    New users tend to find things easier to modify than to create something new

    I think we also need to consider the Backdrop onboarding experience. By giving new users a default design they can play with and customize immediately (e.g. upload their own featured shot, add custom text after the post listings) it'll impress on them that Backdrop is easy. It'll get them editing instead of thinking where to start.

    And what would be a good idea is if every Backdrop version (maybe just major versions?) comes with a new default theme. (I think Wordpress does this) What happens to the old design? It becomes a contrib theme that old users can keep if they want. Every major new version of Backdrop will look different (think iOS 1.0 vs iOS 7)

@quicksketch
Copy link
Member

I think we're all in agreement at this point that adding a default out-of-box layout configuration for the homepage would be a good idea. And that using the single-column layout would also be a good fit for today's sites. The nice thing is we're not really committing anyone to a particular structure with this. It's just the default configuration, not functionality we need to write or support in the future (and it doesn't affect existing sites). Meaning we can change it to fit with the times if another approach becomes dominate later.

I'd even go so far as to say the category/tag page needs it's own design.

I think this may be a good idea as well, these pages are sorely neglected. Let's make a new issue for this.

And what would be a good idea is if every Backdrop version (maybe just major versions?) comes with a new default theme.

That is the hope. We mention this just about every design call. Even if we created one mid-release, we'd be happy to include it (if we could agree upon it). I think the way this will go is a theme would need to be contrib made first, then absorbed into core if it fits the bill. I don't think there's an issue for this. I'd rather see this as a one-issue per attempt rather than a 300 comment monster.

So maybe for starters here, we've all kind of agreed that having a front-page layout configuration would be a good idea. Should we ship with a single-column front page configuration out-of-box and work to add the key blocks later (e.g. a callout block of some kind)?

@sutibun
Copy link
Member

sutibun commented Sep 24, 2015

I say let's start simple and build off a basic foundation. We don't need to build anything complex immediately.

Ship with a single-column layout with

  • a wide image featuring something abstract or motivating. (minus the words)
    • no slideshow. no background image. Just a simple image tag embedded there via a block.
  • some preloaded text (e.g. "welcome to your hompage. Take a look around. Feel free to customize this by hitting the edit button and make the site yours.")
    • Just make sure there's a limit to the width of the text section. It becomes unreadable if there's more than 60-70 charaters per line (something to that effect. I forgot my design theory) Basically make sure the text section doesn't occupy the whole width of the screen.
  • a view listing recent posts

We can all argue some more for the other key blocks or how to implement it.

@klonos
Copy link
Member

klonos commented Sep 24, 2015

We can use Drop as an image and have some link to point to the admin UI that allows to change it. That way, we are not only shipping with an image out of the box - we are also "teaching" the user how to do things.

@sutibun
Copy link
Member

sutibun commented Sep 24, 2015

@klonos ah, the dragon! Yeah, we should definitely have that (him/her?)

I always hated the Drupal logo. Looks ugly and creepy. It was always the first thing to go. But everyone likes dragon. I do.

Maybe what we can do instead is subtly show off the dragon logo, something similar to how Github does theirs.

image

It's small and deemphasized but still there. Something like the Nike logo placement in ads. It's not overt… but more like a gentle reminder.

image

And because they're tasteful and subtle, we could add them both on the header and footer and get away with it.

@klonos
Copy link
Member

klonos commented Sep 25, 2015

Just to clarify... I was mostly referring to the dragon image in https://backdropcms.org/presskit#mascot (the second one - the one where Drop is lying down). We could use that as a horizontal banner image for the initial front page.

@sutibun
Copy link
Member

sutibun commented Sep 25, 2015

@klonos ah kk

@jenlampton
Copy link
Member Author

Yes. 👍 Yes 👍 Yes 👍 Please let's get a default home page layout in core. I love where this is going so far. Who wants to make us one? :)

@Graham-72
Copy link

I was having a look today at creating a single-column home page layout using an editable custom block so that the user can upload a banner image of their choice, but I got caught by the disappearing image problem referred to in issue #1385 Inline images disappear after a while. Are we hoping to fix this one?

@Graham-72
Copy link

Now I see that this is also raised as an issue and bug report at #1373 .

@jenlampton jenlampton added this to the 1.4.0 milestone Jan 28, 2016
@jenlampton jenlampton modified the milestones: 1.5.0, 1.4.0 May 15, 2016
@jenlampton
Copy link
Member Author

jenlampton commented Sep 12, 2016

I was having trouble with getting the old PR testing so I've made a new one: backdrop/backdrop#1539

edit: woohoo! passing tests!

@quicksketch
Copy link
Member

PR is looking really good! And passing tests too, great!

I left some feedback on the PR. I have a hangup with the way the "No promoted content" message is shown. Right now it will double-execute the view, which won't be acceptable. Although I see what you mean that it would be easy to remove the block with these links, this block would have no purpose at all on an existing site. You'd never want to place a block that said "No promoted content", and as it's written currently, if there were promoted content, the block wouldn't do anything at all.


From a chat in Gitter, @jenlampton suggested that we make a block that is just the create content links, which might be useful in an eventual dashboard, so the block would have some purpose. However to move this forward, we decided to just remove these links entirely and move this task to a follow-up. In the mean time we can just add the empty text to the View default configuration.

@jenlampton
Copy link
Member Author

Pushed an updated PR that addresses all the feedback left by @quicksketch .

@quicksketch
Copy link
Member

quicksketch commented Sep 12, 2016

Looks great now!

One more point of feedback and question though. Why is the path and name of this new layout "home"? Everywhere in Backdrop we refer to the front page as well, the "front" page. We don't call it the "home" page, so why would our layout be "home" instead of "front" in the out of box configuration? I'd love for this to go in ASAP, but this has been bothering me for a while now. As we won't be able to easily change this (well other than making all the same test changes over again), I'd like to make sure we use a reasonable name.

@jenlampton
Copy link
Member Author

jenlampton commented Sep 12, 2016

Why is the path and name of this new layout "home"?

Because that is what normal people call it. I have no idea why Drupal decided to call it the front page, but that's not terminology that the rest of the world uses. Since we had the opportunity to choose a name, I chose the one that was the most sensible.

Everywhere in Backdrop we refer to the front page as well, the "front" page.

I'd like to fix these too, eventually. But since change is hard and adding new things correctly is easy, I thought we should start here. The win over having something everyone understands outweighs the inconsistency in this case, imho.

@quicksketch
Copy link
Member

quicksketch commented Sep 12, 2016

Well, perhaps not scientific: https://www.google.com/trends/explore?date=today%2012-m&q=%22home%20page%22,%22front%20page%22 (home page is more popular)

It's worth noting that "home page" means multiple things, like a user's personal blog would be called their "home page", as would the default page loaded by a browser when you open a new window. So those trends might not be applicable to our actual problem here.

The internet at large seems to use these terms interchangeably. Drupal's documentation also uses them at the same time: https://www.drupal.org/node/265172

However, there's no doubt that this is intentionally introducing an inconsistency in our system that otherwise we don't have. Right now we use "home page" exclusively to reference a user's homepage when posting a comment to a node. There are a fair number of references to "home page" in code comments or tests, but never in the end-user interface (as far as I can find).

I'd like to fix these too, eventually.

In truth, I don't think we will ever change all usage of front page to home page. It'd be a ton of API change and string change. From a search, we have 273 references to "frontpage", "front page" or "<front>" in our code. Providing backwards compatibility for a string like this would be messy, so it'd likely have to be a clean break in 2.x. But if that's the case, we should keep consistency for now and do the entire rename all at once.

@jenlampton
Copy link
Member Author

jenlampton commented Sep 12, 2016

It's worth noting that "home page" means multiple things

I don't care about the many meanings. I do care what real life human beings call the front page of their site. They don't call it the "front page" of their site. They call it the "home page" of their site.

There are a fair number of references to "home page" in code comments or tests, but never in the end-user interface (as far as I can find).

Here are two:

menu

breadcrumb

Think about it this way: when you create a panel page that serves as the home page of a site, what do you call it? You call it a home page. That's exactly what we did here.

However, there's no doubt that this is intentionally introducing an inconsistency in our system that otherwise we don't have.

As I said before: The win over having something everyone understands outweighs the inconsistency in this case, imho.

@quicksketch
Copy link
Member

Well, doing a little research on sites that I know are running Drupal that I didn't build (though I may have helped on them later):

http://www.grammy.com/home
http://www.msnbc.com/home
https://www.tesla.com/home
https://www.syfy.com/home
https://www.harvard.org/home
https://www.drupal.org/home
http://www.telemundo.com/home

I turns out I couldn't find a single /front site of the sites I tried. Note almost all the above sites redirect from /home to just /. Visiting /front on all of them are 404s.

So it looks like this might be a "just me" concern. From the evidence of existing sites out there using Panels or custom callbacks, these sites all at least chose "home" with no prior guidance on what to name the path. So seems fine to me. 👍

@jenlampton
Copy link
Member Author

jenlampton commented Sep 12, 2016

I would be happy to change the text around the setting for Front page to Home page too, if that helps clear up inconsistency issues. Something like this:

screen shot 2016-09-12 at 1 28 17 am

alternate PR that includes this change at backdrop/backdrop#1543

@quicksketch
Copy link
Member

Yeah let's make that separate. I'm not sure we'd ever be able to clean up the inconsistencies. Let's move it to a new issue for bikeshedding.

@jenlampton
Copy link
Member Author

jenlampton commented Sep 12, 2016

bike-shed-4

located here: #2162

@quicksketch
Copy link
Member

I made yet another follow-up to help deal with the now-missing login block: #2163

@quicksketch
Copy link
Member

quicksketch commented Sep 12, 2016

Well, at least now I feel like we had the discussion on "home" vs. "front" so it's taken place and recorded.

With no further serious concerns, I've merged backdrop/backdrop#1539 into 1.x for 1.5.0. Thanks everyone for this 1.5 year journey! We still have work to do and a lot of follow-ups already in the queue, but this lays a tremendously important foundation for future work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants