-
Notifications
You must be signed in to change notification settings - Fork 40
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
Comments
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. |
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. |
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
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. |
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. |
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. |
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. |
@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. |
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 |
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. |
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. |
Yay. This thread got mentioned in the design meeting even if briefly. Just two thoughts.
|
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 think this may be a good idea as well, these pages are sorely neglected. Let's make a new issue for this.
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)? |
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
We can all argue some more for the other key blocks or how to implement it. |
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. |
@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. 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. And because they're tasteful and subtle, we could add them both on the header and footer and get away with it. |
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. |
@klonos ah kk |
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? :) |
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? |
Now I see that this is also raised as an issue and bug report at #1373 . |
I was having trouble with getting the old PR testing so I've made a new one: backdrop/backdrop#1539 edit: woohoo! passing tests! |
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. |
Pushed an updated PR that addresses all the feedback left by @quicksketch . |
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. |
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.
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. |
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).
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 " |
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.
Here are two: 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.
As I said before: |
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 I turns out I couldn't find a single 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. 👍 |
I would be happy to change the text around the setting for alternate PR that includes this change at backdrop/backdrop#1543 |
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. |
located here: #2162 |
I made yet another follow-up to help deal with the now-missing login block: #2163 |
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! |
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:
YES
YES
NO
YES
YES in 2.x See #2114
YES.
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
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#1500PR from @jenlampton at backdrop/backdrop#1539
The text was updated successfully, but these errors were encountered: