De-dupe Featured Projects

[gvn]

We need to determine a de-duping strategy for the Projects page.

A couple possibilities:

1. Solve at the administrative level by not featuring projects under multiple issues (or change the order of the featured items).

2. Write code to de-dupe and backfill the results in network.

I'd prefer to solve this at the root level with approach 1. Approach 2 is difficult to make bulletproof and is a bit hacky IMO.

[alanmoo]

I'm a bit confused as to what's broken that we're trying to solve in point 1. The way the pulse API works currently is that entries (projects) are the main model, and they can be featured or not featured. Similarly, they can apply to one or many Internet Health Issues. Therefore, fetching featured entries by issue behaves as expected. Are you suggesting that we disallow selecting multiple issues for an entry?

[gvn]

I'm suggesting we don't add a bunch of extra business logic as middleware on network when we should look at returning/fetching data in a way that precludes it.

[hannahkane]

I agree with @alanmoo that it sounds like this is the expected behavior; it's important that we're able to associate entries with multiple issues, for discoverability and tracking reasons.

I understand why @gvn would want to solve this within Pulse, though, rather than on the Network site.

Is it possible that the best solution is actually a design solution? Should we reconsider how we're presenting projects on the Network site? Could it be more like the featured projects on the Pulse homepage, with a different treatment for presenting the issues?

[gvn]

To be clear, I'm not saying that the API is "broken". This is absolutely expected behavior.

However, aside from requiring a hacky implementation, option 2 makes it unclear to an administrator what projects will actually show up in Network (and under which issue). They'll have to follow a flow chart versus having a clear correlation between their choice and what is shown.

Are we OK with projects falling arbitrarily under an issue on Network? I would imagine not.

[gvn]

Possibility 3: If we can set the order of the projects under each issue in the CMS, then we can remove the "featured" flag from the query and there will be a clear order to the items shown in Network.

That would look like this in Network:

And this is Pulse:

As you can see, there's a clear correlation.

[alanmoo]

As we realized on the stand today, this still doesn't quite solve the problem, especially if we deploy when a new entry has recently been submitted with all issues checked.

Pulse's API was designed to be very minimally curated; users and admins can categorize content while admins can "feature" certain entries. That's it. Everything in the API is related to showing entries based on filtering of the data.

That being said, @gvn, it seems like you're coming at this from a "the content on the Network site is curated" approach. For this specific case, I'm not sure it's the right approach. In fact, I think the ideal situation for this page would be if the Pulse entries were pulled dynamically from the API, instead of only on build (or at least cached and updated somewhat frequently). However, I don't think the project order should be specifically set, as the more work someone has to do to mange the site the more likely it is the content goes stale.

I do still feel like the best option is 2, as it would result in the most dynamic content for visitors and least work for admins.

[hannahkane]

I'd like to re-raise my design question from above. Is there a reason we're creating different layouts for the Pulse homepage and for the Projects page on the Network site? It seems to me the added value we get from the Projects layout if we have space to explain what the five issue areas are, but couldn't we solve that problem in another way?

[alanmoo]

I believe the design reasons revolve around the purpose of the page, which feels to me like "here are our five issues in one spot" as a primary purpose, and "some associated projects" as a secondary. On Pulse, it's more about "find projects related to this issue" and you have to toggle between the issues to see everything.

[xmatthewx]

Thanks all for the discussion, and for moving forward with the implementation despite incomplete information.

In the future, we will have a dedicated Editor-in-Chief of site content. This person might want A) explicit control over projects featured on the network site's project page. If that's the case, we'll want them to specify IDs of specific projects in the CMS. The Editor might not want that. They might instead want B) the latest fresh content, anything identified as featured in Pulse by a dozen staff and community people. We don't have that Editor-in-Chief today. Right now, I think we benefit more from fresh content than from tight control.

To wrap things up for now, I think we should add some basic intelligence on the site before rendering, even if it's a little spit and duct tape. Abbreviated pseudo code: (note.... I'm not saying this is the correct approach, just sharing to help clarify) retrieve 2 featured open innovation projects, render and remember IDs. retrieve 4 featured digital inclusion projects, render and remember the first two that aren't already displayed. ... retrieve 10 featured web literacy projects, render the first two that aren't already displayed.

Is there a reason we're creating different layouts for the Pulse homepage and for the Projects page on the Network site?

The site and pulse have overlapping between different user stories. The site needs to be a friendly orientation to people new to the idea of our network, and/or our issues, and/or the fact that we have collaborative projects. We assume this audience has limited prior knowledge. On Pulse, if a visitor likes the simple intro statement, we can focus on discovery of projects without extra context.

Does this makes sense?

[gvn]

The desired functionality makes sense.

I'm still against adding hacks, but will do so if we can't/won't solve this at the API level. My ask is that we create a follow-on ticket to refactor this properly in the future.

[xmatthewx]

At the API level, I guess the solution would be ?issue=sampler-plate 🍽. As we merge backends, I don't have a strong opinion of where we put the logic.

[xmatthewx]

💥 thanks for the speedy work on this.