search

MozillaFoundation / foundation.mozilla.org

Mozilla Foundation website
https://foundation.mozilla.org
Mozilla Public License 2.0
388 stars 153 forks source link

Featured post on /blog #3693

Closed kristinashu closed 4 years ago

kristinashu commented 5 years ago

Add the ability to feature two blog posts at the top of /blog.

Comp: blog w featured copy@2x

Style of the thumbnail should be the same as on https://foundation.mozilla.org/

image

Which blogs to feature should be selected on the /blog cms page:

image
alanmoo commented 4 years ago

@kristinashu The most straightforward implementation of this would impact all pages that use the "index" template; is that ok?

kristinashu commented 4 years ago

@alanmoo which other pages uses the "index" template?

alanmoo commented 4 years ago

Looks like it might just be/campaigns right now, which we don't actually make much use of. So I suspect this is fine. But I also suspect there will be a point at which we want to use the index template for other things too.

kristinashu commented 4 years ago

Ok got it. That sounds good, any page that is just a bunch of cards would benefit from a way to highlight a couple of the most important ones.

Pomax commented 4 years ago

After investigating, it turns out that it's really hard to add something that lets you pick (one or more) "child page(s)" for an IndexPage (which is what we'd want to be able to do here) because in order to add a Page Chooser (like we have for the homepage's featured blogs, for instance) the IndexPages would have to know "the" type of all its children, but there is no such thing: those could be blogs, or campaigns, or any other page type that we don't know before hand, because the IndexPage was designed specifically to work even though it had no knowledge of what child types were involved, as long as they have tags/categories.

Some options:

  1. Set a list of permitted page types that can be featured by an IndexPage. This would allow a Page Chooser in the cms, but you could pick to feature a campaign page on the blog index that way. This feels like a trivial problem ("don't pick a a campaign page when you're trying to feature a blog page") but it's something to bear in mind.
  2. Give every page model a featured option that can be toggled, and have the index page pick two of its children that have that flag set. This feels far less clean, because there's no simple UI in place for making sure only two child pages have that flag set. It would be quite the chore to make sure that the right number of pages have that option checked off.
  3. Rather than explicitly feature posts, we always render "the more recent X children" and render the rest in the normal paginated fashion. Depending on what the motivation for featuring is, this option might very well not even be an option at all.
  4. We make the IndexPage an abstract concept, with concrete BlogIndexPage, CampaignIndexPage, etc. subclasses. Then we'd be able to fairly cleanly add Page Choosing to each IndexPage "flavour", but this would certainly be the most work to get right, and would require swapping the new page model for the old page model in the CMS (so that rather than an IndexPage, the blog index would be a BlogIndexPage). In its defense, this would probably be the cleanest and most future-proof approach.
mmmavis commented 4 years ago
  1. We make the IndexPage an abstract concept, with concrete BlogIndexPage, CampaignIndexPage, etc. subclasses. Then we'd be able to fairly cleanly add Page Choosing to each IndexPage "flavour", but this would certainly be the most work to get right, and would require swapping the new page model for the old page model in the CMS (so that rather than an IndexPage, the blog index would be a BlogIndexPage). In its defense, this would probably be the cleanest and most future-proof approach.

I would vote for option 4 for better UX and cleaner implementation.

kristinashu commented 4 years ago

Yes, sounds like option 4 is the way to go. I think it's worth noting that I don't foresee us using Index pages anywhere other than /blog.

xmatthewx commented 4 years ago

@kristinashu - just to clarify, this would be useful for blog category index pages too, true? Like mozfest or /blog/category/advocacy/

Option 4 sounds like the better option. I'm curious how big a lift iingt would be (know we just need this for the blog index template). A single sprint engineering-wise? One engineer or two?

Option 2 isn't ideal, but it sounds much easier to build. It offers less control since Jen/Kevin would mark a post as featured, and the template would just grab the most recent featured, with no chance for Jen/Kevin to order them. But, I do wonder if most of the time that would match what they would pick anyhow. (Regarding the concern about having the right number, it seems like we could plan to display two, but have a fallback when there's only 1 or zero.)

kristinashu commented 4 years ago

@kristinashu - just to clarify, this would be useful for blog category index pages too, true? Like mozfest or /blog/category/advocacy/

Ah yes that's right, we would use it on /blog/category/[name] as well.

Option 4 sounds like the better option. I'm curious how big a lift iingt would be (know we just need this for the blog index template). A single sprint engineering-wise? One engineer or two?

Could estimate using our sprint values: 1: The simplest change. A string update, fix a color, etc 2: Up to an hour of work. More than a quick string change. Maybe some tests updated too 3: Around half a day of work 5: Takes a day of work 8: About 2 days of work 13: More than 2-5 days of work 21: More than a week, open separate tickets 40: A sprint, open separate tickets

Pomax commented 4 years ago

realistically, 8 should be the upper limit for single issues. 13 should be a signal to file separate tickets, too.

kristinashu commented 4 years ago

realistically, 8 should be the upper limit for single issues. 13 should be a signal to file separate tickets, too.

Ok, I've added "(consider opening separate tickets)" after 13 in our sprint planning doc.

@Pomax did you add the 3 estimate to this ticket? If so then @mmmavis do you agree? If if so then I think we should go ahead with Option 4!

mmmavis commented 4 years ago

@kristinashu I think Alan estimated this ticket to be 3 but he did it months ago.

This looks like a multi-step ticket to me. If I'm the person doing it, it would be closer to a 13 ticket since I don't have much experience with Django and will have to dedicate time reading docs & trials and errors 😂 .

Pomax commented 4 years ago

I did not - I'd put option 4 between an 8 and 13 though, but closer to an 8 if we want this done properly since we're likely to have 2 people working on it at the same time, expediting the work.

kristinashu commented 4 years ago

Ah ok got it! Could one of you please open up the necessary ticket(s) and then close this one?

Pomax commented 4 years ago

I'll split this up into specific implementation issues first thing tomorrow.

Pomax commented 4 years ago

I've filed implementation issues https://github.com/mozilla/foundation.mozilla.org/issues/4232, https://github.com/mozilla/foundation.mozilla.org/issues/4233, and https://github.com/mozilla/foundation.mozilla.org/issues/4234

kristinashu commented 4 years ago

I believe @Pomax has done all the prep work for this and now the page is ready for the front-end work needed to be able to show featured posts at the top of /blog.

I'm going to re-open this ticket for that work but please a new ticket or multiple tickets if needed.

cadecairos commented 4 years ago

@kristinashu now that the Abstract model work landed, can we close and refile this issue with the specifics for implementing the featured posts?

kristinashu commented 4 years ago

Yup. It will be the same as the first comment in this issue, is that enough?

kristinashu commented 4 years ago

Opened here https://github.com/mozilla/foundation.mozilla.org/issues/4624