Closed kristinashu closed 4 years ago
@kristinashu The most straightforward implementation of this would impact all pages that use the "index" template; is that ok?
@alanmoo which other pages uses the "index" template?
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.
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.
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:
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.
- 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.
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.
@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 - 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
realistically, 8 should be the upper limit for single issues. 13 should be a signal to file separate tickets, too.
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!
@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 😂 .
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.
Ah ok got it! Could one of you please open up the necessary ticket(s) and then close this one?
I'll split this up into specific implementation issues first thing tomorrow.
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.
@kristinashu now that the Abstract model work landed, can we close and refile this issue with the specifics for implementing the featured posts?
Yup. It will be the same as the first comment in this issue, is that enough?
Add the ability to feature two blog posts at the top of /blog.
Comp:
Style of the thumbnail should be the same as on https://foundation.mozilla.org/
Which blogs to feature should be selected on the /blog cms page: