Moderation - Unable to update content within /explore

[thisandagain]

As we are starting to drive more traffic to /explore (formerly known as the gallery) we have a need to keep that content regularly updated. The existing content on that page hasn't been updated in quite some time and after talking with @keyboardkat and @cadecairos it looks like part of the problem is that the architecture of that page and the features available within the MakeAPI admin cause some serious friction.

Couple options for resolution:

• @cadecairos has a prototype called Gallery Maker that could be used to create galleries using the MakeAPIs list API. The model is a little strange as the list feature is user-centric (lists are connected to a specific user) and in that it's not a perfect fit for our needs, but seems like a good way to resolve the problem quickly.
• Another option could be to simply add a isFeatured flag to items within the MakeAPI and modify the /explore view to render items chronologically where isFeatured === true. This is my preference in the long-term as we move to having many people from the team featuring makes as to keep content constantly (ideal -> hourly) updated. With that we'd need to think about adding a way to feature content within Webmaker itself visible to staff / admins.

Looking for more suggestions.

/cc @keyboardkat @cadecairos @simonwex

[cadecairos]

Another option could be to simply add a isFeatured flag to items within the MakeAPI and modify the /explore view to render items chronologically where isFeatured === true. This is my preference in the long-term as we move to having many people from the team featuring makes as to keep content constantly (ideal -> hourly) updated. With that we'd need to think about adding a way to feature content within Webmaker itself visible to staff / admins.

This feels like the path of least resistance. One thing we still lack is a solid tool for admins to find and feature makes.

[thisandagain]

Wondering if we could even do that with an IRC bot. Have a bot post new makes to a channel and have a whitelist of users that can tell the bot to feature a make by id.

[keyboardkat]

Hi @cadecairos @thisandagain @simonwex, here are initial user needs/requirements for the moderation dashboard. I took these from several old bugs, and updated them based on current status:

1. The ability to easily find new makes (was quite hard in the MakeAPI admin.) See Bug 938245.
2. The ability to preview moderated makes before they are published (i.e., not having to just reload webmaker.org over and over) See Bug 997282.
3. The ability to moderate more than the first 12 makes (currently, we can only control the top 12. The rest fill in randomly. Could be fixed by adding pagination, each page with a new set of 12 makes);
4. The possibility to have one moderation dashboard for all parts of webmaker.org that need to be moderated. i.e., both /explore AND /teach - web lit textbook. See Bug 997282.
5. A easy-to-follow taxonomy for moderation of the 12 makes to be featured, specified in a public read-me file. (I put the old editorial taxonomy here, but it isn't the best place)
6. The ability to moderate without having to use code (i.e., not having to learn this kind of JSON).
7. The ability to easily add tags to makes, whether you want to tag 12 at a time, or 1. See Bug 938252.

@cadecairos, let me know if you'd like these to be framed differently? Thank you! :poop::poop::poop:

[cadecairos]

The ability to easily find new makes (was quite hard in the MakeAPI admin.) See Bug 938245

I agree, we need simple, powerful search features that don't over complicate the interface. I think date based searching would be helpful (i.e. "show me makes created yesterday/last week/between x and y). Are there any specific types of queries you might find useful?

The ability to preview moderated makes before they are published (i.e., not having to just reload webmaker.org over and over) See Bug 997282

Can you clarify what a "moderated" make is? Does that mean it's been featured (in whatever manner we end up going with)?

I have ideas how previewing can be made to work using the list API, but some of the mechanisms to make it happen don't exist and will require some engineering across apps.

The ability to moderate more than the first 12 makes (currently, we can only control the top 12. The rest fill in randomly. Perhaps this could be fixed by implementing pagination so each page only has 12 makes on it);

Using the tag-based featuring mechanism will turn this into a nightmare - If I understand the current process correctly, featuring a make requires adding a tag "webmaker:featured-x" where you replace 'x' with the position of the featured make. The amount of work involved putting a make into the top slot of a 50 make list will ruin any person's day.

That is one of the reasons why make lists were created, since there's no hard upper limit to how many makes can be in a list, and makes can (with the right front end tool built on top of the API) be added, removed, and organized, since they're represented internally as an array, and not using tags.

With @thisandagain's proposal for a featured flag, we will lose the ability to order featured makes, as we'll be limited to using the default sorting mechanisms provided by the MakeAPI (i.e. created at date).

The possibility to have one moderation dashboard for all parts of webmaker.org that need to be moderated. i.e., both /explore AND /teach. See Bug 997282

Another problem that Make Lists can simplify. Since make lists have unique ID's, we can specify different lists to use for each moderated part of the site, and feed those id's into the moderation tool, so that you can select the list you want to moderate, and get the benefit of using the same tool to moderate every part of the site.

This might be out of scope for a single two week sprint.

A easy-to-follow taxonomy for moderation of the 12 makes to be featured, specified in a public read-me file. (I put the old editorial taxonomy here, but it isn't the best place)

I'm not entirely sure what this is. I feel like this is something that belongs on a wiki page?

The ability to moderate makes without having to go into code (i.e., JSON).

This will require some work to rewrite the pages that render content using hard coded json blobs.

The ability to easily add tags to makes, whether you want to tag 12 at a time, or 1. Bug 938252.

do-able, but needs design work

[keyboardkat]

Some answers to @cadecairos questions below, next to our names....

1) The ability to easily find new makes (was quite hard in the MakeAPI admin.) See Bug 938245

• @cadecairos: I agree, we need simple, powerful search features that don't over complicate the interface. I think date based searching would be helpful (i.e. "show me makes created yesterday/last week/between x and y). Are there any specific types of queries you might find useful?
• @keyboardkat: date would be great. also: # of views, # of remixes, top users.

2) The ability to preview moderated makes before they are published (i.e., not having to just reload webmaker.org over and over) See Bug 997282

• @cadecairos: Can you clarify what a "moderated" make is? Does that mean it's been featured (in whatever manner we end up going with)? I have ideas how previewing can be made to work using the list API, but some of the mechanisms to make it happen don't exist and will require engineering across apps.
• @keyboardkat: By moderated, I mean makes that have been chosen to be featured. @k88hudson started on a preview draft a while ago, but i'm not sure how far that got. worth asking her!

3) The ability to moderate more than the first 12 makes (currently, we can only control the top 12. The rest fill in randomly. Perhaps this could be fixed by implementing pagination so each page only has 12 makes on it);

• @cadecairos: Using the tag-based featuring mechanism will turn this into a nightmare - If I understand the current process correctly, featuring a make requires adding a tag "webmaker:featured-x" where you replace 'x' with the position of the featured make. The amount of work involved putting a make into the top slot of a 50 make list will ruin any person's day. That is one of the reasons why make lists were created, since there's no hard upper limit to how many makes can be in a list, and makes can (with the right front end tool built on top of the API) be added, removed, and organized, since they're represented internally as an array, and not using tags. With @thisandagain's proposal for a featured flag, we will lose the ability to order featured makes, as we'll be limited to using the default sorting mechanisms provided by the MakeAPI (i.e. created at date).
• @keyboardkat: If the list format allows any number of makes to be featured, that fulfills this user requirement nicely :)

4) The possibility to have one moderation dashboard for all parts of webmaker.org that need to be moderated. i.e., both /explore AND /teach. See Bug 997282

• @cadecairos: Another problem that Make Lists can simplify. Since make lists have unique ID's, we can specify different lists to use for each moderated part of the site, and feed those id's into the moderation tool, so that you can select the list you want to moderate, and get the benefit of using the same tool to moderate every part of the site. This might be out of scope for a single two week sprint.
• @keyboardkat: agreed. this is just something to keep in mind, especially while moderation is built into /teach and other sections, to ensure we keep taxonomies and formats consistent (and therefore easier for moderators in future).

5) A easy-to-follow taxonomy for moderation of the 12 makes to be featured, specified in a public read-me file. (I put the old editorial taxonomy here, but it isn't the best place)

• @cadecairos: I'm not entirely sure what this is. I feel like this is something that belongs on a wiki page?
• @keyboardkat: I said this because in the past, the taxonomies and editorial/moderation how-tos have been in a separate place than the moderation dashboard. Would be great to link them all together, whether via a Github read-me, a wiki or the dashboard itself. So, probably more of a top-level organizational task than a dev task in the end -- @thisandagain will likely have thoughts.

6) The ability to moderate makes without having to go into code (i.e., JSON).

• @cadecairos: This will require some work to rewrite the pages that render content using hard coded json blobs.
• @keyboardkat: yep. another thing for @thisandagain to keep in mind as he determines needs.

7) The ability to easily add tags to makes, whether you want to tag 12 at a time, or 1. Bug 938252.

• @cadecairos: do-able, but needs design work
• @keyboardkat: cheers :)

[cadecairos]

of views

@keyboardkat, might not be doable since that data isn't stored in the makeAPI. It might exist in GA, but I'm not sure how to piece together a list of urls from one DB and data bout the URLs from GA. maybe @adamlofting or @jdotpz can chime in on that one

of remixes

I think this sort is supported already.

top users

@keyboardkat what's a top user?

edited: GH markdown is the worst.

[keyboardkat]

@cadecairos top user: same as lead user, i presume. someone who creates more makes than the average user, or as we once defined it, someone whose makes are remixed more than others.

[cadecairos]

@keyboardkat Ah, okay. That might require crafting a special query based on the definition of a "top user"

[jdotpz]

Well, you can certainly get at data containing /explore urls.

**Asked by @thisandagain : Wondering if we could even do that with an IRC bot. Have a bot post new makes to a channel and have a whitelist of users that can tell the bot to feature a make by id. https://github.com/jdotpz/mofoircbot If we then write to sqs on a make, this bot can announce it. Maybe. I suck at it.

[cadecairos]

make creation generates an event on our event queues. from there it should be a no brainer dumping a url into an irc channel.

after that, we just need a bot to watch the channel for whitelisted users to trigger featuring.

[adamlofting]

We can programmatically query Google Analytics and pull page view data for individual makes, but if we want to do that I would suggest we make it a more systematic task at a MakeAPI level. Setting up something like a daily, or hourly script to update the numbers.

Having pageview metadata stored against makes could have lots of benefits across the site for gallery automation, giving users feedback and even the web literacy angle that comes with users understanding popularity and tracking.

[thisandagain]

Understanding the dynamic between productive / consumptive use of Webmaker at a per make level would be helpful for product planning as well. :+1: but outside of the scope of this sprint in my view.