Project

General

Profile

Actions

Feature #14180

closed

Design/UX #13998: Homepage Redesign

"Featured" flag tool for groups and sites

Added by Boone Gorges over 3 years ago. Updated almost 3 years ago.

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

100%

Estimated time:
(Total: 0.00 h)
Deployment actions:

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.


Files

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
Screen Shot 2021-10-27 at 4.28.41 PM.png (563 KB) Screen Shot 2021-10-27 at 4.28.41 PM.png Colin McDonald, 2021-10-27 04:28 PM

Subtasks 1 (0 open1 closed)

Feature #14179: Featured Sites and Groups for Home Page RedesignResolvedColin McDonald2021-03-16

Actions
Actions #1

Updated by Colin McDonald over 3 years 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.

Actions #2

Updated by Boone Gorges over 3 years 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.

Actions #3

Updated by Colin McDonald over 3 years 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.

Actions #4

Updated by Boone Gorges over 3 years ago

Sorry about that - trying again

Actions #5

Updated by Colin McDonald over 3 years 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.

Actions #6

Updated by Boone Gorges over 3 years 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.

Actions #7

Updated by Jeremy Felt over 3 years 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.
Actions #8

Updated by Boone Gorges over 3 years 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.

Actions #9

Updated by Jeremy Felt over 3 years 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.
Actions #10

Updated by Colin McDonald over 3 years 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.

Actions #11

Updated by Boone Gorges over 3 years 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.

Actions #12

Updated by Jeremy Felt over 3 years 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.

Actions #13

Updated by Boone Gorges over 3 years 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.

Actions #14

Updated by Matt Gold over 3 years 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.

Actions #15

Updated by Colin McDonald about 3 years 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.

Actions #16

Updated by Jeremy Felt about 3 years 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.

Actions #17

Updated by Jeremy Felt about 3 years 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?
Actions #18

Updated by Boone Gorges about 3 years 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.

Actions #19

Updated by Colin McDonald about 3 years 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.

Actions #20

Updated by Boone Gorges about 3 years ago

  • Assignee changed from Jeremy Felt to Boone Gorges

Reassigning to myself for integration into the new home page.

Actions #21

Updated by Boone Gorges about 3 years ago

  • Status changed from Assigned to Testing Required

I've finished the integration with the home page. I made a couple of minor changes to cac-home-curation in the process, including adding a caching layer so that a given query would only happen once every five minutes.

When it comes time to launch, we will have to ship the cac-home-curation plugin at least a little bit before launch, so that we can input the initial featured groups/sites.

Actions #22

Updated by Colin McDonald about 3 years ago

Thanks for getting this up, Boone. Is there a way for me to test the curation back-end on cdev? 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?

Actions #23

Updated by Boone Gorges about 3 years ago

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.

Actions #24

Updated by Colin McDonald about 3 years ago

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.

Actions #25

Updated by Colin McDonald almost 3 years ago

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.

Actions #26

Updated by Boone Gorges almost 3 years ago

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.

Actions #27

Updated by Colin McDonald almost 3 years ago

Great, works for me!

Actions #28

Updated by Raymond Hoh almost 3 years ago

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?

Actions #29

Updated by Colin McDonald almost 3 years ago

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

Actions #30

Updated by Boone Gorges almost 3 years ago

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

Actions #31

Updated by Colin McDonald almost 3 years ago

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.

Actions #32

Updated by Colin McDonald almost 3 years ago

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.

Actions #33

Updated by Boone Gorges almost 3 years ago

  • Status changed from Testing Required to Staged for Production Release
Actions #34

Updated by Boone Gorges almost 3 years ago

  • Status changed from Staged for Production Release to Resolved
Actions

Also available in: Atom PDF