Project

General

Profile

Feature #14180

Design/UX #13998: Homepage Redesign

"Featured" flag tool for groups and sites

Added by Boone Gorges 6 months ago. Updated 19 days ago.

Status:
Assigned
Priority name:
Normal
Assignee:
Category name:
Home Page
Target version:
Start date:
2021-03-16
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)

Description

The 1.19 homepage design introduces new 'Featured Sites' and 'Featured Groups' areas. See latest wireframes linked from https://redmine.gc.cuny.edu/issues/13999#note-21.

The old version of the homepage uses the cac-featured-content plugin, which creates a widget where the admin can select a single item to feature, and can also provide custom markup, descriptions, etc for the widget.

The new version will allow us to retire cac-featured-content. Instead, we will have "pools" of sites and groups that have been flagged as Featured. Items in the 'Featured Sites' and 'Featured Groups' areas on the homepage will then be pulled randomly from these pools.

As such, we'll need a new interface that allows the CAC team to specify which groups and sites are in the "pool". This will require a couple of things.

First, we'll need some mechanism for storing the "featured" status. Probably a simple flag in groupmeta and sitemeta will work. We'll also need CRUD tools for toggling the flag. (If we use meta, then we can simply use meta_query to pull up the list when we build the homepage itself, and we shouldn't need additional "fetch" wrappers.)

Next, we'll need a UX where the CAC team can managed the "pools". Given the fact that the interface for managing Sites in Network Admin is very different from that for managing Groups, I think we probably can't easily integrate into those existing UIs, and should build a new one instead. On that interface, we need:
1. The ability to see a list of all items that are currently Featured
2. The ability to remove existing items from the Featured list
3. The ability to add new items. I imagine this could be an autocomplete that matches names or slugs/URLs.

I think we want to make the interface accessible to anyone who is an Editor on the main site, since we have so few Super Admins and we don't want to create a curation bottleneck.

Jeremy, I'm tentatively assigning this to you. Given this rough spec, can you envision a workable UI? This is a tool that will be used only by the CAC team, so it doesn't need to be extremely beautiful, but it should be easy to read and to use. I think it's OK to make it require JS, and you should feel free to use whatever library you want (thinking here specifically of the autocomplete tool - jquery-ui, select2, or something more modern). No need to use a full JS framework unless it's easier to do so.

Screenshot_2021-03-22_15-04-58.png (11 KB) Screenshot_2021-03-22_15-04-58.png Boone Gorges, 2021-03-23 01:44 PM
featured-area.png (34.8 KB) featured-area.png Colin McDonald, 2021-03-30 12:29 PM
Peek 2021-07-29 11-21.gif (250 KB) Peek 2021-07-29 11-21.gif Boone Gorges, 2021-07-29 12:22 PM

Subtasks

Feature #14179: Featured Sites and Groups for Home Page RedesignNew

History

#1 Updated by Colin McDonald 6 months ago

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.

#2 Updated by Boone Gorges 6 months ago

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.

#3 Updated by Colin McDonald 6 months ago

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.

#4 Updated by Boone Gorges 6 months ago

Sorry about that - trying again

#5 Updated by Colin McDonald 6 months ago

I wanted to mention the "description" field in the design for featured items -- unlike Courses, where I think we're just pulling some metadata lines, is this description field going to be something editable by our team? Or will we rely on the description as entered when the item was set up? Could that introduce problems if there is not description, if it's really short/long, if it's not useful for a wide audience, etc? See attached.

#6 Updated by Boone Gorges 6 months ago

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.

#7 Updated by Jeremy Felt 5 months ago

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.

#8 Updated by Boone Gorges 5 months ago

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.

#9 Updated by Jeremy Felt 4 months ago

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.

#10 Updated by Colin McDonald 4 months ago

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.

#11 Updated by Boone Gorges 4 months ago

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.

#12 Updated by Jeremy Felt about 2 months ago

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.

#13 Updated by Boone Gorges about 2 months ago

Thanks, Jeremy! I've had a first look at the admin UI and it seems great so far. I've attached a brief gif for those who want to have a look.

One thing that jumped out at me was this: it seems like non-public sites/groups are being returned by the autocomplete. This is likely because the default behavior of the REST endpoints is to return groups (and probably sites? though I didn't look) that the current user has access to; and if the current user is a super admin, they have access to everything. For the Featured tool, I think we want to limit to groups/sites that are public - or at least not hidden - right? This may also be a question for Colin and Matt.

#14 Updated by Matt Gold about 2 months ago

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.

#15 Updated by Colin McDonald about 1 month ago

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.

#16 Updated by Jeremy Felt 24 days ago

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.

#17 Updated by Jeremy Felt 24 days ago

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?

#18 Updated by Boone Gorges 23 days ago

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.

#19 Updated by Colin McDonald 19 days ago

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.

Also available in: Atom PDF