Foundation.mozilla.org: Enable homepage modification through admin

[alanmoo]

Right now, most of the homepage is automatically generated based off other data sets. We should move towards manual customization of the page via the Mezzanine admin. The initial goal is to enable manual selection of people profiles that appear on the homepage, though the "get involved" section can also benefit from this work, as well as possibly the featured news article.

As part of this work, we should begin the process of letting Mezzanine handle the generation of this page so that updates are served straight from it instead of being rebuilt by the static site generator. This can then be used by other pages in the future as we need to enable more editor-friendly customization of pages.

What are the steps we need in order to accomplish this task? Creating this as an epic so that we can bring in individual steps as other tickets.

Starting thoughts:

• Create homepage model in Django
• Import generated Jinja (post-Pug) homepage into Mezzanine
• Add template hooks for reading from the homepage model
• Change URL routing (cloudfront?) so that / points at heroku instead of AWS

[gvn]

I don't agree this is something we should necessarily do. The landing pages using this methodology are already painful to work with.

What is driving this request? Are we weighing the ROI on what'll be a significant amount of extra work for refactoring something that is already working?

At a minimum we should work toward a resolution on the consolidation of network and network-api before we look to tackle this.

[xmatthewx]

Outside of the engineering pros/cons on the approach, staff Editor needs capacity to...

• feature and sort content on the homepage independent of date posted and sorting on other pages
• quickly and easily feature content during high activity. for example, if Mozfest on Saturday generates two dozen new stories (on Medium and 3rd party) and many dozen projects and opportunities, Editor should be able to keep pace and update site throughout the day.

Short term, training can definitely compensate for clunky UI and _some_ UX quirks, but the capacity needs to be there. Long term, as we ramp up the pace of content, a single admin view with selectors for each feature spot is way more manageable than a feature toggle on each item across content types. Again, no opinions here how that functions under the hood, just sharing thoughts on the needs. cc @jessevondoom

[jessevondoom]

Yeah I'm chiming in with a vocal +1 of @xmatthewx's comments. Some clunk is okay and to be expected, but I think aiming for more centralized clunk is a fantastic first goal. Having to hit each section individually to affect change on the homepage will start to negatively affect the editor job function pretty quickly.

[gvn]

Once we deploy the latest version of the Network code the only thing on the homepage that will require a dev to update is the first news item (which I agree we should un-hardcode...see #328).

In general I want to clarify that I'm not against moving data into Mezzanine. I absolutely think that's what we should be doing as much as possible. My concern is with moving additional templates into Mezzanine just to make the editing experience is smoother (I agree that it isn't 100% ideal, but it does work).

Currently, the only Mezzanine enabled pages are the landing pages, which are fairly simple templates but still took a lot of effort to enable and are painful to work with. For them to work, the template has to be cross compiled from Pug into a Django template and pushed into the Network API.

The homepage is a much more complex template and will require a lot more effort to refactor to cross-compile.

I can go into more technical detail if anyone is interested, but the TL;DR is this: we have a CMS that is close to fully functional and comprehensive for a non-dev (albeit not 100% user friendly). In order to migrate more templates we'll almost certainly need to merge network and network-api and do a massive refactor of our template code. It's hard to say how long this will take, but it could be multiple sprints. My ask is that we move pragmatically on this and consider our ROI first. If we feel that improving the editor experience is higher priority than user-facing work, then let's do it. If not, let's consider living with our current system a bit longer while we tackle higher impact work first.

[alanmoo]

Disclaimer: I'm aware that we've detoured from talking specifically about this ticket, but it's important an conversation to have

Agreed that there's a fair amount of lift to accomplish this, and that we need to merge the repos first. It is important to make the publishing process smoother, and we have specifically identified that in the roadmap. August has "improve curation experience" and this is one of the items that falls in that category. We want to remove the pain from both developer and editor side, and it seems that the best way to accomplish this is to migrate to a pure Mezzanine approach for building the site, as it simplifies a lot of tasks and allows the CMS to behave as designed.

I'd like to explore the possibility of doing this work as we make changes to existing pages, as I don't think a massive refactor and singular redeploy is a prudent move. I understand that it may be more combined work to slowly transition the existing templates into Mezzanine, but some of the other work that is on its way to us can then be accomplished without having to do it twice, or being entirely blocked (mini sites and "collections of people" pages[1], for example.)

[1] - Think a better way to build pages like Network 50

[xmatthewx]

Here's the mockup I previously posted.

The drop-downs would get unwieldy eventually, but if the options are sorted reverse chronological, this simple UI can get us through the next couple months.

[gvn]

Assigning to @hannahkane to verify on staging (ping me if this is unclear!)

[hannahkane]

Verified!