CUNY Academic Commons

This all sounds good to me. I just thought I'd mention #12157 and #11298 where we built an interface for showing featured courses on the Courses page (i.e. the slideshow there). See this note in particular:

https://redmine.gc.cuny.edu/issues/11298#note-60

I'm not sure if what we built here might help Jeremy with what we need for this project, or if there's any sense in trying to bring this "featuring" workflow into a wider workflow we're building (because admittedly, the featured courses aren't getting changed as much as they should and having everything in as few places as possible can help). But if this is too tall an order to bridge together, we can also better manage the different workflows once they're in place.

Thanks for the reminder about that interface. For Jeremy's information, I've attached a screenshot from Dashboard > Courses > Featured. Obviously this interface is bare-bones - I did the minimum necessary to make it functional. What I've suggested in this ticket is that we add some more polish, so that you don't have to do the ID lookup. For ease of maintenance, it's reasonable that we'd want to keep all "featured" maintenance on a single dashboard panel, which means that Groups and Sites would be manageable in one place. Once we have it built, let's port the Courses "featuring" tool over to the new interface, and put it on the same page as Groups and Sites. But this can be handled as a separate enhancement.

Sure thing, Boone. Seems like this is going to be a good setup all around. Not sure I saw the screenshot btw, in case you want to follow up with that.

Thanks for flagging this, Colin. I think you're right that we probably need a separate field for this. The field's default value can be the group's description or the site's blogdescription, but it will have to be editable by the admin.

Okay, I've thought through this a couple ways and I think we can make a pretty useful UI to managed featured groups/sites (maybe courses one day). I think we can account for all flagging and title/description overriding in the interface itself without much trouble.

Some clarifications / questions:

• It's easy enough to change this in the future, but: are there other things that be included as part of "home page curation" on this page?
• Should this stand on its own as a new cac-featured-something plugin or is it better placed as part of the bp-nelo theme?
• I'm guessing it should not be possible (right away) to edit a site/group's featured status anywhere else than in this interface.

It's easy enough to change this in the future, but: are there other things that be included as part of "home page curation" on this page?

Only thing that comes to mind is "shortcut" management. For now I think these will be hardcoded, but if we have an admin UI for it in the future, it'll have to go somewhere. If you're steering in the direction of a "home page curation" admin page (rather than focusing on "featured") then I think you're onto something.

Should this stand on its own as a new cac-featured-something plugin or is it better placed as part of the bp-nelo theme?

Probably doesn't matter too much. I guess I'd say: let's put the data schema and admin stuff into a new plugin, and when we integrate into the homepage itself, we'll put function calls right into the theme template.

I'm guessing it should not be possible (right away) to edit a site/group's featured status anywhere else than in this interface.

Correct. We can add other tools (like when you're viewing a single group as a super-admin) sometime down the road if there's a call for it.

General scope list¶

The featured sites and featured groups interfaces are effectively the same, listed one after the other on a settings page available in the admin of the main site. I think we can use custom REST API endpoints (rather than admin-ajax) to manage updates to the lists and to individual sites/groups. This should provide some flexibility in the future if this interface becomes block based.

• Create a new plugin - cuny-home-curation / cuny-curation / preferences?
• Add a new settings page to the main site, accessible to editors and admins.
• Input field to search as you type for public sites across the network.
• Add site on enter or on button click.
• Existing featured sites are listed below the input field with title, description, and URL information.
  • An edit link here surfaces a modal to edit the description.
  • Description is pulled from site description originally, but can be overridden and stored as a new piece of site meta.
• New featured sites are appended to the bottom of the existing list.
• Featured sites have a remove link to remove their featured status.
• (Optional, pending ordering) Add drag/drop interface to modify the order.
  • It seems like it would be cool to have control over the ordering when curating home page items.

Individual sites / groups¶

• Add a field to edit secondary (featured?) description if the site or group description has been overridden for the home page.

(New) Home page¶

• Retrieve featured sites and groups via meta query OR via the function used to populate the list of featured sites/groups when the admin page is loaded.

Questions¶

It's possible the answer to these comes up during development, but it may be good to think through them now as well.

• What field(s) should the autocomplete use for sites and groups?
  • I'm guessing title and URL for sites, same for groups?
• What order should the sites/groups use?
  • We could track time added to the list.
  • We could maintain order data as additional meta
  • We could output in alphabetical / last updated / some other site field.

Thanks for this, Jeremy. Regarding order in your ending list, I assume you mean the order we display items marked as featured on the front end, especially because there's only a couple of visible slots. Would it be possible to randomize items' appearance for each load, as a way of making the featured sections more fresh? We'll want to keep the featured lists pruned so we're not cycling through something that's been up there for a while, of course.

Thanks for this, Jeremy! Looking good to me.

I agree with Colin that custom ordering is probably not necessary. 'Featured' will create a pool of available items, and we'll be pulling randomly from that pool each time we render, so order shouldn't matter. That said, I don't see the harm in saving the timestamp when it was added to the list, as this might be useful to display (eg when pruning old items as a cleanup task). On the admin panel, I think it's fine to display either alphabetically or by date-added; alphabetically is probably best if we expect there to be a fair number of items (10+) in each list, so that you might need to find a specific one.

What field(s) should the autocomplete use for sites and groups?
I'm guessing title and URL for sites, same for groups?

Instead of URL, let's match 'slug' for groups and 'domain' for sites (or even just the subdomain portion if it's practical, though it's probably not). This'll help to avoid some 'commons.gc.cuny.edu' noise.

Okay! I've opened a PR against the 1.19.x branch with a good iteration of this: https://github.com/cuny-academic-commons/cac/pull/11

I still need to account for:

• Randomized results when queried on the front end.
• Polish some of the styling / autocomplete behavior a bit.

That aside, I think the interface is ready for testing and feedback.

Hi all --

First, Jeremy, this looks great!! Thanks so much

As for public/non-public, I think I agree that we should only show public sites/groups -- so long as they don't show up on the members homepage. I don't think they do.

My only concern about the UX for this is that I could imagine that we will compile a large number of featured groups/sites -- 15-20? -- if they are randomized on page load. I can't remember how we set this up -- ie, are we picking a small number of sites to be featured or a larger group of which some smaller set will be shown in random order. If a larger set, then the page could get a bit long, and there might be a rationale for clicking to expand to see details or something like that.

Just wanted to note here that on the call today we decided that we'll see how the UX works in practice with adding/removing sites/groups from the list that we curate. We'll see how fresh the public sections pulling in these choices feel as they rotate through, and how hard it is to manage on the time interval we choose from our side. We might aim for refreshing the list every semester to start.

I made a few changes to https://github.com/cuny-academic-commons/cac/pull/11 and now only public sites and groups should be available for selection in the curation interface. Similarly, if a site or group becomes private after selection, it will no longer display as featured.

I haven't yet accounted for associated images on groups/sites.

A couple related questions:

• Would images be valuable as part of the curation view?
• Should it be possible to override the image in the curation view?

Thanks, Jeremy!

Should it be possible to override the image in the curation view?

This feels like it would add a lot of technical complexity, doesn't it? Seems OK to me if we only show the default image (which is the group/site avatar) in all cases, but it would be good to hear from the rest of the team on this.

I agree that this seems like complexity we may not need, both on images in the backend and customizing them for the frontend. If someone's chosen an image we don't want to display for some reason, if anything we might reach out to them directly since it could appear elsewhere. But otherwise I'm thinking it should be up to them what's shown, or just a default image.

I can bring this up during our upcoming design meeting, though.

Thanks for getting this up, Boone. Is there a way for me to test the curation back-end on cdev?

Yes. Dashboard > Settings > Home Curation, or https://commons.gc.cuny.edu/wp-admin/options-general.php?page=cac-home-curation

I also wasn't sure if we'd implemented anything to control longer group/site descriptions manually, or if we might want to automatically truncate those in the homepage sections. Or maybe something like the attached isn't that imbalanced, and we likely won't see more of a disparity?

There's nothing manual at the moment. We kinda decided above that manual curation of description and/or avatar would be a lot of technical overhead. It's easy for me to introduce automatic truncation to a certain number of words if someone can tell me what length you want. If we decide that we need full control over descriptions for this space, it will take more work for me to rebuild parts of the tool.

Thanks, I'll keep this handy for the full testing process. Seems to me that truncation might make sense, at least as a safeguard in extreme cases, but we can kick the tires on this more soon.

Boone, I was just testing and looking back at this thread where you say there's "nothing manual" in the curation tool, but if I click Edit below any curated site/group's description it seems that I can manually alter it. Is that intended? Sorry if I missed this change before. It does seem like a nice feature, provided the default or pre-populated description is still being pulled through to use in the absence of something manual.

Boone, I was just testing and looking back at this thread where you say there's "nothing manual" in the curation tool, but if I click Edit below any curated site/group's description it seems that I can manually alter it. Is that intended? Sorry if I missed this change before. It does seem like a nice feature, provided the default or pre-populated description is still being pulled through to use in the absence of something manual.

Ha, you are correct. This feature lets you edit the description as shown on the home page.

Great, works for me!

I just noticed on the homepage that we query for three Featured Sites and three Featured Groups. However only two are displayed when viewing on a desktop. At smaller widths (599px and below), it is possible to view all three with the sidescroll function.

Is this intentional?

I see what you mean Ray, good question. Perhaps Boone can weigh in here, or we can ask Sara during the dev call tomorrow.

The design comps show the following:

a. On desktop, show two, with no scrolling
b. On mobile, allow sidescrolling

For b, the number wasn't specified, so I made it 3.

https://www.figma.com/proto/3DMoVZ5ZG79AcwZOmYH7nn/CUNY-Homepage-design---Development-Handoff?node-id=725%3A4945&scaling=min-zoom&page-id=725%3A4467

Adding Sara to this ticket in case that makes it easier for her to chime in and/or call this up during the dev call shortly.

Just noting here that during the dev call yesterday we agreed, with Sara's input, that we'll continue to display two results on desktop and three on mobile even though we always query three. The three only make sense for the mobile sidescroll, where only scrolling two would be a bit weird in the available space.