CUNY Academic Commons

Hi Sonja,

Thanks so much for your work on this. V10B ( https://redmine.gc.cuny.edu/attachments/download/12685/8897-courses-filtering-v10B.pdf ) resolves most of my concerns while keeping the menu all on the same line. I will still check in with a few people on this, but I think this can work, as it is much more clear visually. Thank you for your work on this.

This one's for Boone or Ray, I think -- looking at Sonja's new A/B/C options, the question arose about whether a keyword search for a professor's name will surface courses taught by that professor in the results. I think we discussed this before, but I wanted to confirm how this would work. We do have that Instructor field on the current Courses page -- will that be indexed for the new search?

v10B addresses my concerns too. Thanks for bearing with us, Sonja.

Colin - this has not been specified, but yes, I think it makes sense for search to match the following fields: group name, site name, instructor name. "College" is a question mark - feels redundant since it's a filter. But it doesn't make a huge technical difference.

Boone Gorges wrote:

I'm going to bump this ticket to the next release, so that we can consider whether the UI used for the new filters in the Courses directory can/should also be extended to Sites, Groups, and Members directories.

Thanks Boone. It will be good to gather some data and user feedback once released for courses to make sure it's solid before we consider extending it to Sites, Groups and Members directories.

Hello, resurfacing this ticket, perhaps to Sonja at first to see what she thinks now about extending the Courses filtering interface work to other areas, namely the tabs for Groups, Sites, and People (which is the only other tab with any filtering right now, just in the sidebar).

The Courses interface is much more slick of course, but we'd have to think about how to adapt it given those other tabs wouldn't have dropdowns for Semester or Cluster but probably could for Keyword and Campus. And People has the "Role" data that could be used -- are there others for Sites and Groups that could be swapped in?

Thanks, Sonja. I think it's looking good. I do think there are a lot of options there. Is there any thing we can simplify? One thought that occurs to me is whether the "Order by" option, which currently appears in its own line, might be integrated into the pagination options below -- but maybe that's a bad idea.

Matt Gold wrote:

Thanks, Sonja. I think it's looking good. I do think there are a lot of options there. Is there any thing we can simplify? One thought that occurs to me is whether the "Order by" option, which currently appears in its own line, might be integrated into the pagination options below -- but maybe that's a bad idea.

Hi Matt, I see what you're saying. We have a lot of options on these types of pages. Would you be open to only have the numbered navigation at the bottom of the page, so we have space to move the "order by" dropdown in its place at the top?
Boone might have some opinions about this, but I think it's too much to squeeze the three items (directory pagination message "Viewing 1 - 20 of 1,372 groups", the pagination AND the order by dropdown) all in one line. That also gets tricky on smaller devices then too.

I agree it's too much, and I think it's a good idea to convert pagination to bottom-only.

This is looking good to me as well, Sonja. I'm all for the simplification of pages at the bottom. I wonder whether we need that full line "Viewing 1 - 20 of 1,372 groups" at the top. the "1,372" or whatever results number is already there in the filter buttons at the top, and the less important 1-20 viewing range can be communicated next to the pages lower down. So perhaps we focus on fitting Order By as smoothly as we can at the top, and the rest goes to the bottom.

Should we also talk about adding Campus and Purpose filter drop-downs for the Sites and Groups pages? We ask for that metadata now in the new creation flow for both. I'm not sure if it's an issue that you could select Teaching purpose in the Sites search filter, and then you'd basically be searching Courses, in which case you might as well be on the Courses tab where you'd have more filter options (semester, etc). Perhaps we could tooltip or note that.

Talked about "Academic Interest" on the People page on today's dev call.
The interests are a way to find people by interest that is otherwise hard to distill. We'll need to explore how we can possibly better elevate these terms within the search (let's discuss more here), but we'll also explore how we can add this filter option within the new filter UI.

I like the simplicity of removing the standalone 'academic interest' UI. From a technical point of view, it's easy to include Academic Interests in a general 'keyword' search. The main question is how to ensure that search-result ordering works in a way that makes sense for most use cases. Say you have the following users:

1. One named Karen English
2. One who has listed '19th century English poetry' in the Academic Interests field
3. One who is an Assistant Professor in an English department

When searching for 'English', what would you expect to find? Presumably (a) all of these would appear in the list. And I would suggest that (b) they should appear in the 1-2-3 order suggested here. That is, 'name' is the most salient field, and Academic Interests is perhaps next, followed by others. It may be helpful to look at all the fields that users can currently fill in and decide, first, which of it should not be matched by keyword search at all (like a personal website URL, probably), and second, of those items that should be matched, how we weight the results.

Related, we should probably ensure that any fields matched by keyword searches (or other filters) are listed on the search results page. If I search 'English' and match user 2 above, the user's Academic Interests - or a sufficient portion thereof - ought to appear on the search results page, so that I know why there was a match. This is already the case with Academic Interests, but perhaps not as clearly in the case of Role and Campus.

Thanks for this new version, Sonja. I think that moving the "Create" buttons for Groups and Sites to the top and the page numbers to the bottom has decluttered things a lot.

Did we talk about putting Campus and Purpose filters in the top bars for Groups and Sites, since we've been collecting that metadata? Perhaps those would just fit in there, maybe if the search keyword bar was a little less wide?

I agree about removing the separate Academic Interests search and focusing on the universal search and how to prioritize terms in different areas. Boone's hierarchy seems about right to me. I tried to compile the different relevant fields we might want to allow for searching. I wonder if we might give weight to the first two, Descriptor and About, because they're more prominent in the interface and more likely to be filled out. The other fields seem roughly equal.

I definitely agree too that search results should surface a keyword you've searched, and perhaps highlight or bold it, in the excerpt for each individual result item. Here are the terms we have, other than Campus and Role, which I assume we'll keep separate from the keyword search:

Brief Descriptor
About You

(One issue with these two fields is that you can specify who sees them -- Everyone, Only Me, All Members, My Friends. Perhaps search only crawls them if it's set to Everyone?)

Free Entry
Academic Interests
Education
Publications
Positions

(These don't seem to have a privacy toggle)

Thanks Boone, I agree with all your suggestions and course of action in regards to determining the search algorithm rules.

Related, we should probably ensure that any fields matched by keyword searches (or other filters) are listed on the search results page. If I search 'English' and match user 2 above, the user's Academic Interests - or a sufficient portion thereof - ought to appear on the search results page, so that I know why there was a match. This is already the case with Academic Interests, but perhaps not as clearly in the case of Role and Campus.

And you're absolutely right, we should surface that information in the results so the user understands how the result relates to their search terms/options. For this it would be good to understand which information we surface by default and if it differs from what we might surface conditionally based on terms. Let's discuss during our call today.

In response to Colin:

Did we talk about putting Campus and Purpose filters in the top bars for Groups and Sites, since we've been collecting that metadata? Perhaps those would just fit in there, maybe if the search keyword bar was a little less wide?

Yes, I can add those to Groups and Sites.

Sonja, the latest mockup for this went over very well in the Friday meeting. I have no change/improvement feedback to pass along. Let's finalize with Boone the hierarchy and handling (including excerpt/highlighting of search terms) of search results, and we should be able to finalize from there.

Stopping the matching of all fields sounds right to me. I pasted all of the xProfile fields into a text doc and eliminated the ones that seemed extraneous to me for searching, and I got the same final list as Boone. I think it would be great to move ahead with that, for the multiple reasons mentioned on efficiency and relevance, with Sonja's revised design direction.

I think that the "Contains [keyword] in [field]" is a pretty good convention - it's succinct and clear.

Thanks for this, Sonja. I agree with Boone that the "Contains" convention is good, but I had a couple of followup questions.

What happens when searching multiple words in the keyword box? Does that convention get complicated? I'm not sure about our standard Boolean search parameters. So if I search 'english 101 mcdonald' will the results run through the "Contains" convention for each of those three words? Maybe prioritize results that have the most instances of those words, especially in combination? If I put "english 101" in quotes to define that phrase that would change things too, right?

Also, what are we showing by default in search results, and what are we showing when you search a keyword(s)? Are we always showing the group/site/person Name and "Brief Descriptor + About You" if they exist? Then we'll bold any keywords that appear in those two parts, and for other fields, show the bolded term in the Contains convention? I agree with avoiding the extra expand/collapse functionality if we can show enough clearly by default.

So if I search 'english 101 mcdonald' will the results run through the "Contains" convention for each of those three words? Maybe prioritize results that have the most instances of those words, especially in combination? If I put "english 101" in quotes to define that phrase that would change things too, right?

We currently don't really do any of this. Results are ordered by "recently active" in pretty much all cases. I can introduce support for quoted phrases ("english 101"), and I can do weighting for certain fields, but it's beyond our resources to do a more robust "order by relevance" tool like you'd find in a full-fledged search engine.

Also, what are we showing by default in search results, and what are we showing when you search a keyword(s)? Are we always showing the group/site/person Name and "Brief Descriptor + About You" if they exist? Then we'll bold any keywords that appear in those two parts, and for other fields, show the bolded term in the Contains convention? I agree with avoiding the extra expand/collapse functionality if we can show enough clearly by default.

Yes, I think this needs to be defined. Name + Brief Descriptor seems OK to me, though Brief Descriptor doesn't seem to be shown currently. "About You" is likely too long to put on the results page and should be treated like the other "contains" fields.

As discussed during the meeting yesterday, we need to define which fields/content we'll surface for search results for each of the content types "groups, sites, people" (and I'd argue we should replicate this in the list view) and in addition, which fields we'd like to show conditionally if it matches the search terms.

Here are my suggestions for each:

Groups
Always show: Title, description (currently truncated at 212 characters ?), activity, action buttons, meta data (public/private, number of members)
Conditionally show: quick link

Sites
Always show: Site title, activity, action buttons, latest post
Conditionally show: site tagline

People
Always show: Name, brief descriptor, college, position (truncate), activity, action buttons
Conditionally show: about you (truncate), update(s) (i found an example where this was displayed in a search result), quick link

Boone, if you could correct any of the names of these fields for me to make sure we're displayed the correct ones on a technical level. And please indicate if there are reasonable character limits or where you would recommend we truncate it. Let's agree on a character limit.

Once we've agreed on those I can update the mockups if needed.

Sonja, thank you so much for spelling this out in such precise detail.

~200 character limit seems reasonable for most of these (with the caveat that I will try to break only on word endings). In the case where we're matching a term in a conditional field that is then truncated - such as 'About You' - presumably we would truncate the beginning and the end of the field value, so that the matched term appears in the excerpt. Does that seem right to you? If so, let's be sure to include an instance of this in the mockups. (might look like "About You: [...] lorem ipsum [...]")

You've listed 'quick link' as a conditional field, which suggests that we should show 'quick link' only if it's matched by a keyword search. But should we really be matching quick link in search? This doesn't seem like the kind of thing that anyone would search for.

Regarding People > Update: The idea behind this feature is to show the latest update from a given user, kinda like "latest status" or whatever like Facebook used to have (maybe still does? I'm not sure). IMO this suggests that it's not great as a conditional field. For one thing, I think it should not be matched by keyword searches - it's not relevant to searching for people, and it's potentially too noisy. I think we should either show it whenever it's available, or never show it at all. I lean toward never showing it at all, but this would probably also mean removing the 'What's up, [username]' field from the top of member profile > Commons Profile > Activity.

This all sounds good to me, on both the search term matching and what we'll be showing. I'd say go ahead and update the mockups Sonja, and then we can get moving on the development.

Thanks, Sonja. This is looking ok to me. Boone, let us know what you think.