https://redmine.gc.cuny.edu/https://redmine.gc.cuny.edu/favicon.ico2017-11-10T16:47:24ZCUNY Graduate Center - Project Tracking SystemCUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=344322017-11-10T16:47:24ZChris Steincstein@bmcc.cuny.edu
<ul><li><strong>Tracker</strong> changed from <i>Bug</i> to <i>Feature</i></li></ul> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=393632018-09-27T21:27:52ZBoone Gorgesboone@gorg.es
<ul><li><strong>Target version</strong> changed from <i>1.14</i> to <i>1.15</i></li></ul> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=393712018-09-27T21:30:55ZBoone Gorgesboone@gorg.es
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-4 priority-4 priority-default" href="/issues/1544">Feature #1544</a>: Group Filtering and Sorting</i> added</li></ul> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=425042019-03-01T19:41:38ZBoone Gorgesboone@gorg.es
<ul><li><strong>Target version</strong> changed from <i>1.15</i> to <i>1.16</i></li></ul><p>As we begin to have more info about sites and groups (like Primary Purpose; see <a class="issue tracker-2 status-5 priority-4 priority-default closed parent" title="Feature: Site/group creation portal (Resolved)" href="https://redmine.gc.cuny.edu/issues/10987">#10987</a>), it makes sense to think more generally about this.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=450922019-09-06T19:55:52ZBoone Gorgesboone@gorg.es
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-4 priority-default closed" href="/issues/11298">Feature #11298</a>: Explore Ways to Make the "Courses" tab More Interesting</i> added</li></ul> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=450942019-09-06T19:56:16ZBoone Gorgesboone@gorg.es
<ul><li><strong>Assignee</strong> changed from <i>Chris Stein</i> to <i>Sonja Leix</i></li></ul><p>Looks like our initial implementation may focus on Courses filters. See <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Explore Ways to Make the "Courses" tab More Interesting (Resolved)" href="https://redmine.gc.cuny.edu/issues/11298">#11298</a>.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=450992019-09-06T19:58:21ZBoone Gorgesboone@gorg.es
<ul><li><strong>Related to</strong> <i><a class="issue tracker-15 status-5 priority-4 priority-default closed" href="/issues/11395">Design/UX #11395</a>: Design consistent directory filter UI pattern</i> added</li></ul> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=457562019-10-08T20:31:59ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/12684">8897-courses-filtering-v10A.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/12684/8897-courses-filtering-v10A.pdf">8897-courses-filtering-v10A.pdf</a> added</li><li><strong>File</strong> <a href="/attachments/12685">8897-courses-filtering-v10B.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/12685/8897-courses-filtering-v10B.pdf">8897-courses-filtering-v10B.pdf</a> added</li><li><strong>File</strong> <a href="/attachments/12686">8897-courses-filtering-v10C.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/12686/8897-courses-filtering-v10C.pdf">8897-courses-filtering-v10C.pdf</a> added</li></ul><p>Matt and Colin, <br />Continuing work on just the search/filter interface of the Courses tab here, since <a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Explore Ways to Make the "Courses" tab More Interesting (Resolved)" href="https://redmine.gc.cuny.edu/issues/11298">#11298</a> is approved. But for seeing discussions around this element, please see the other ticket (<a class="issue tracker-2 status-5 priority-4 priority-default closed" title="Feature: Explore Ways to Make the "Courses" tab More Interesting (Resolved)" href="https://redmine.gc.cuny.edu/issues/11298">#11298</a>).<br />Attached are the three versions we discussed earlier: <br />A: Iteration of v9 > adding arrows to filter dropdowns to indicate interaction<br />B: Iteratioin of A > adding arrows to filter dropdowns to indicate interaction and distinguishing dropdowns visually more from the search field by adding a different background color<br />C: Is in essence the search/filter interface of v7 and updating the rest of the design to v9</p>
<p>Please review internally and share feedback and pick a direction ASAP.</p>
<p>Boone, let us know if you have a final design approval deadline in mind. Thanks.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=457612019-10-09T02:21:00ZMatt Goldmattgold@gmail.com
<ul></ul><p>Hi Sonja,</p>
<p>Thanks so much for your work on this. V10B ( <a class="external" href="https://redmine.gc.cuny.edu/attachments/download/12685/8897-courses-filtering-v10B.pdf">https://redmine.gc.cuny.edu/attachments/download/12685/8897-courses-filtering-v10B.pdf</a> ) 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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=457652019-10-09T16:46:20ZColin McDonald
<ul></ul><p>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?</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=457692019-10-09T17:54:56ZBoone Gorgesboone@gorg.es
<ul></ul><p>v10B addresses my concerns too. Thanks for bearing with us, Sonja.</p>
<p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=466222019-11-14T16:19:42ZBoone Gorgesboone@gorg.es
<ul><li><strong>Target version</strong> changed from <i>1.16</i> to <i>1.17.0</i></li></ul><p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=466342019-11-14T17:29:12ZSonja Leix
<ul></ul><p>Boone Gorges wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=529262020-07-14T17:16:09ZBoone Gorgesboone@gorg.es
<ul><li><strong>Target version</strong> changed from <i>1.17.0</i> to <i>1.18.0</i></li></ul> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=535632020-08-06T15:50:33ZColin McDonald
<ul></ul><p>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).</p>
<p>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?</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=541422020-08-26T19:35:29ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/15512">8897-filter-interface-v1.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/15512/8897-filter-interface-v1.pdf">8897-filter-interface-v1.pdf</a> added</li></ul><p>Hi team, <br />I took at stab at this aligning with the UI patterns around search and filters established for the Courses tab. Please review the attached wireframes and share your feedback. Thanks.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=541532020-08-27T02:19:56ZMatt Goldmattgold@gmail.com
<ul></ul><p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=542162020-08-31T19:23:41ZSonja Leix
<ul></ul><p>Matt Gold wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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? <br />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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=542312020-09-01T02:55:18ZBoone Gorgesboone@gorg.es
<ul></ul><p>I agree it's too much, and I think it's a good idea to convert pagination to bottom-only.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=542462020-09-01T16:26:31ZColin McDonald
<ul></ul><p>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.</p>
<p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=542472020-09-01T16:54:12ZSonja Leix
<ul></ul><p>Talked about "Academic Interest" on the People page on today's dev call.<br />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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=546092020-09-12T01:11:11ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/15741">8897-filter-interface-v2.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/15741/8897-filter-interface-v2.pdf">8897-filter-interface-v2.pdf</a> added</li></ul><p>I thought I've posted these updates already, but here they are. <br />I've explored adding an "Academic Interest" field both inline and hidden within an "Advanced" option and frankly it's confusing. I'd like for us to seriously consider how we can write these search terms into the general search algorithm to surface results by those terms. I'd love to hear Boone's further thoughts on this.</p>
<p>Please share your feedback on the updated/condensed designs attached (doesn't include "academic interest" option).</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=546172020-09-14T14:46:30ZBoone Gorgesboone@gorg.es
<ul></ul><p>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:</p>
<p>1. One named Karen English<br />2. One who has listed '19th century English poetry' in the Academic Interests field<br />3. One who is an Assistant Professor in an English department</p>
<p>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 <strong>should</strong> be matched, how we weight the results.</p>
<p>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 <strong>why</strong> there was a match. This is already the case with Academic Interests, but perhaps not as clearly in the case of Role and Campus.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=546502020-09-15T15:47:12ZColin McDonald
<ul></ul><p>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.</p>
<p>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?</p>
<p>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.</p>
<p>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:</p>
<p>Brief Descriptor<br />About You</p>
<p>(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?)</p>
<p>Free Entry<br />Academic Interests<br />Education<br />Publications<br />Positions</p>
<p>(These don't seem to have a privacy toggle)</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=546522020-09-15T15:53:37ZSonja Leix
<ul></ul><p>Thanks Boone, I agree with all your suggestions and course of action in regards to determining the search algorithm rules.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p>
<p>In response to Colin:</p>
<blockquote>
<p>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?</p>
</blockquote>
<p>Yes, I can add those to Groups and Sites.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=546902020-09-15T21:05:41ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/15785">8897-filter-interface-v3.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/15785/8897-filter-interface-v3.pdf">8897-filter-interface-v3.pdf</a> added</li></ul><p>I've added the Campus and Purpose selectors for Groups and Sites.<br />If you could share some direction around what content might be missing for the search results before EOD tomorrow, I can update the mockups once more before the Friday meeting.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=548842020-09-22T14:52:10ZColin McDonald
<ul></ul><p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=549252020-09-23T14:30:39ZBoone Gorgesboone@gorg.es
<ul><li><strong>File</strong> <a href="/attachments/15876">Screenshot_2020-09-23_09-22-43.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/15876/Screenshot_2020-09-23_09-22-43.png">Screenshot_2020-09-23_09-22-43.png</a> added</li></ul><p>As Colin notes, there's a couple of issues regarding search (field priority in determining the order of results, and the surfacing of matched fields in the directory) that need clarifying. The two issues are somewhat interlinked and it may be helpful for me to give a brief overview of how things currently work.</p>
<p>When you search the Members directory (search field at top left) - let's use 'English' as an example keyword - the following fields are matched: user_login, user_nicename, any xProfile fields. On the Commons, there are many xProfile fields:</p>
<pre>
| Full Name |
| College |
| Title |
| Academic Interests |
| Email Address |
| Phone |
| Skype ID |
| IM |
| Website |
| Blog |
| Twitter |
| Delicious ID |
| Facebook Profile Link |
| YouTube ID |
| Flickr ID |
| LinkedIn Profile Link |
| Role |
| academia.edu Profile URL |
| Brief Descriptor |
| About You |
| Publications |
| Education |
| Github |
| Vimeo |
| ORCID ID |
| Google Scholar |
</pre>
<p>Query results are then displayed in the directory with the following fields: Display name, last activity update (if available), Positions (if available; otherwise College and Title are shown), Academic Interests. See screenshot.</p>
<p>There are a couple of oddities in this setup, some of which we may decide to fix as part of this ticket:<br />a. Search matches all of the listed xProfile fields, some of which may not be appropriate to search. For example, what's the benefit of matching the academia.edu profile URL?<br />b. Search matches all xProfile fields, regardless of their visibility status (Logged-in users, Friends, etc). This is a longstanding BuddyPress issue that is hard to work around and probably is not solvable for this release, but it may be worth investing time into down the road <a class="external" href="https://buddypress.trac.wordpress.org/ticket/6211">https://buddypress.trac.wordpress.org/ticket/6211</a><br />c. We match all of the fields above, but we don't show all of them in search results, so there are cases where you don't know why a field was returned.</p>
<p>Sonja had some ideas about how to approach c, and it sounds like she was going to incorporate them into the next set of designs. As for a: Since we have to do some work to set field priority anyway, I'd suggest we take the opportunity to stop matching all fields. Specifically, I think that keyword searches should match the following fields, in roughly the following order of priority:<br />1. Full Name<br />2. Brief Descriptor + About You<br />3. Academic Interests<br />4. College, Title, Positions<br />5. Publications, Education</p>
<p>All other fields would <strong>not</strong> be matched by keyword searches.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=549422020-09-23T18:31:02ZColin McDonald
<ul></ul><p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=549562020-09-23T21:15:18ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/15883">8897-filter-interface-v4.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/15883/8897-filter-interface-v4.pdf">8897-filter-interface-v4.pdf</a> added</li></ul><p>Thanks Boone and Colin, <br />I agree with this approach for a.</p>
<p>For c, I've been working on new wireframes which now indicate when there is a match in a field that isn't displayed in the search results. To make it easier to spot, I've added a pink dot to the left of those search results on the pages that have search results based on a search term – in the mockups I've used the search term "English". We could also bold the related search term in the text that is displayed in the search result, see page 2 for an example of that.</p>
<p>If there's any type of content we're missing within the search result item display, please let me know and we can add it in there. Alternatively to naming e.g. "Contains: English in Publications" we could also list the publications (or the relevant content) for those results – this might mean the search results items could get quite lengthy though.</p>
<p>I decided against using the "expand" feature we established for the new Groups Library. The reason for that is, that it doesn't make sense to only collapse the relevant search info since it's inconsistent in its display. There is certainly an option to collapse all info besides the most relevant info (e.g. group/site title or person's name, and activity status as well as the primary CTA button).</p>
<p>Looking forward to your thoughts and feedback!</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=549772020-09-24T15:24:10ZBoone Gorgesboone@gorg.es
<ul></ul><p>I think that the "Contains [keyword] in [field]" is a pretty good convention - it's succinct and clear.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=551172020-09-29T16:12:24ZColin McDonald
<ul></ul><p>Thanks for this, Sonja. I agree with Boone that the "Contains" convention is good, but I had a couple of followup questions.</p>
<p>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?</p>
<p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=551242020-09-29T16:33:27ZBoone Gorgesboone@gorg.es
<ul></ul><blockquote>
<p>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?</p>
</blockquote>
<p>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.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=551562020-09-30T16:44:46ZSonja Leix
<ul></ul><p>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.</p>
<p>Here are my suggestions for each:</p>
<p><strong>Groups</strong><br />Always show: Title, description <em>(currently truncated at 212 characters ?)</em>, activity, action buttons, meta data (public/private, number of members)<br />Conditionally show: quick link</p>
<p><strong>Sites</strong><br />Always show: Site title, activity, action buttons, latest post<br />Conditionally show: site tagline</p>
<p><strong>People</strong><br />Always show: Name, brief descriptor, college, position (truncate), activity, action buttons<br />Conditionally show: about you (truncate), update(s) (i found an example where this was displayed in a search result), quick link</p>
<p>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.</p>
<p>Once we've agreed on those I can update the mockups if needed.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=551582020-09-30T17:02:26ZBoone Gorgesboone@gorg.es
<ul></ul><p>Sonja, thank you so much for spelling this out in such precise detail.</p>
<p>~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 <strong>and</strong> 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 [...]")</p>
<p>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.</p>
<p>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 <strong>not</strong> 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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=551622020-09-30T17:35:01ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/15972">Screen Shot 2020-09-30 at 11.32.25 AM.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/15972/Screen%20Shot%202020-09-30%20at%2011.32.25%20AM.png">Screen Shot 2020-09-30 at 11.32.25 AM.png</a> added</li></ul><p>Boone Gorges wrote:</p>
<blockquote>
<p>Sonja, thank you so much for spelling this out in such precise detail.</p>
<p>~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 <strong>and</strong> 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 [...]")</p>
</blockquote>
<p>Yes, that sounds good to me. Once I hear from Colin or someone else on the team, I can update the mockups.</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Quicklinks were just a suggestion, they might not make a ton of sense.</p>
<blockquote>
<p>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 <strong>not</strong> 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.</p>
</blockquote>
<p>Thanks for this reflection. I agree it probably doesn't make sense to include this in the search term matching. I only included it in the list because I saw it on a search result and had to investigate where the copy came from (see screenshot). Happy to not show it at all if the team agrees.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=552672020-10-05T22:57:59ZColin McDonald
<ul></ul><p>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.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=555592020-10-13T18:48:51ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/16116">8897-filter-interface-v6.pdf</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/16116/8897-filter-interface-v6.pdf">8897-filter-interface-v6.pdf</a> added</li></ul><p>Colin McDonald wrote:</p>
<blockquote>
<p>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.</p>
</blockquote>
<p>Thanks Colin, <br />As discuss today during our call, attached is the updated mockup. Based on Boone's feedback, there was only one small update to be made on the last page, where I've included an instance of showing a search result based on the term being in the About Me section. There you can see the example of the term being in the middle of it and the content being truncated at the beginning and end to show the term: [...] lipsum <strong>English</strong> dolor [...]</p>
<p>Please let me know if there are any other revisions that need to be implemented. Thanks.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=555742020-10-13T21:29:36ZColin McDonald
<ul></ul><p>Thanks, Sonja. This is looking ok to me. Boone, let us know what you think.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=555752020-10-13T21:36:35ZBoone Gorgesboone@gorg.es
<ul><li><strong>Assignee</strong> changed from <i>Sonja Leix</i> to <i>Boone Gorges</i></li></ul><p>Thanks! I think this should be enough to get started.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=557802020-10-21T16:11:39ZBoone Gorgesboone@gorg.es
<ul><li><strong>File</strong> <a href="/attachments/16241">Peek 2020-10-21 10-43.gif</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/16241/Peek%202020-10-21%2010-43.gif">Peek 2020-10-21 10-43.gif</a> added</li></ul><p>Hi all - I've made a first pass at implementing these features.</p>
<p>The Groups and Sites directory front-end changes were fairly straightforward. I had to do some icky things to add meta_query support to blog queries, and I'll advocate for upstream improvements in BuddyPress that allow us to pull out this ickiness int he future.</p>
<p>The Members directory rewrite was much more extensive and required some mods from the behavior discussed above.</p>
<a name="Fields-displayed-for-each-member"></a>
<h3 >Fields displayed for each member<a href="#Fields-displayed-for-each-member" class="wiki-anchor">¶</a></h3>
<p>In <a class="external" href="https://redmine.gc.cuny.edu/issues/8897#note-34">https://redmine.gc.cuny.edu/issues/8897#note-34</a> and the follow-up comments, we talked about some user fields that should always show, and others that should show only when matched by a keyword search. As I built using a subset of actual user data, though, I ran into some issues.</p>
<p>Brief Descriptor and Positions: We discussed always showing Brief Descriptor, which we don't currently do on the Commons. I really like this idea, because it's a field that the user has direct control over. IMO it's the best single piece of info we've got to display in directories, where you want an at-a-glance sense of what a given user is all about. However, in the vast majority of cases, the Brief Descriptor is at least partly redundant with Positions. (Often it's pretty much exactly the same thing.) So, IMO, it doesn't make sense to show Positions if we're showing Brief Descriptor.</p>
<p>For related reasons, I'm not showing College, which is almost always redundant with Brief Descriptor.</p>
<a name="Keyword-behavior"></a>
<h3 >Keyword behavior<a href="#Keyword-behavior" class="wiki-anchor">¶</a></h3>
<p>We discussed several different improvements to the behavior of keyword searches:</p>
<p>1. Search results should be ordered by relevance, which is to say that (for example) a 'Name' match should appear higher in results than an 'Academic Interests' match.<br />2. Keyword parsing should be smarter. Instead of treating keywords like a single, quoted phrase, a search like <code>Matthew Gold</code> should return results that match both <code>Matthew</code> and <code>Gold</code>, but not necessarily together; you would add quotes to narrow down to exact matches. We would also add some basic support for stopwords (ignoring 'a', 'the', etc) and basic boolean logic ('AND', 'OR', etc).</p>
<p>It turns out that it's not feasible to do both of these things at the same time without the use of an external search appliance. As such, I'm dropping item 2 and going only with 1.</p>
<p>Relevance sorting, which I'm calling 'Best Match' in the user-facing interface, introduces a couple of UX problems. Our default sort options are 'Last Active', 'Alphabetical', 'Newest Registered'. When searching, most users will presumably want to see results sorted by relevance, but we don't want them to lose access to the other sorts. At the same time, simply adding 'Best Match' to the list doesn't make any sense in contexts when you're not searching by keyword. So I've done the following:</p>
<p>a. When you begin a keyword search - ie, when you're moving from a view of the directory that does not include a keyword filter (like the default view, or when you're filtering only by Campus) to one that does include a keyword filter - Best Match will appear in the 'Order by' dropdown after the page refreshes, and it is selected by default.<br />b. Users can then select a different option from 'Order By'. All existing filters (keyword and otherwise) will be maintained after this re-sort.<br />c. As described in the designs, if the keyword search matches a profile field other than 'Name' or 'Brief Descriptor', those fields will be shown in the results. In these cases, the keyword is in boldface text. Text is excerpted as necessary.<br />d. It added a great deal of technical complexity to match Positions by keyword. As described above, Positions is almost always redundant with other fields: the 'College' filter <strong>does</strong> match Positions, and keywords do match 'Brief Descriptor'. For these reasons, I chose not to match Positions with keyword. I don't think this takes away from the usefulness of keyword search, for the reasons given here.</p>
<p>The changes will be up on cdev momentarily for testing.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=558712020-10-26T21:25:59ZSonja Leix
<ul><li><strong>File</strong> <a href="/attachments/16271">8897-filter-interface-v7 mobile.png</a> <a class="icon-only icon-download" title="Download" href="/attachments/download/16271/8897-filter-interface-v7%20mobile.png">8897-filter-interface-v7 mobile.png</a> added</li></ul><p>Attached is the mobile design for the filter interface. It should be consistent in styles with the mobile experience on the Courses page.</p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=559222020-10-27T16:08:41ZBoone Gorgesboone@gorg.es
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>Testing Required</i></li></ul><p>Thanks, Sonja. I've implemented the mobile designs. <a class="external" href="https://github.com/cuny-academic-commons/cac/commit/d47d4d0335c2833114283e620076470bcea4fe2d">https://github.com/cuny-academic-commons/cac/commit/d47d4d0335c2833114283e620076470bcea4fe2d</a></p> CUNY Academic Commons - Feature #8897: Redesign Filter Interfacehttps://redmine.gc.cuny.edu/issues/8897?journal_id=568912020-12-08T16:32:14ZBoone Gorgesboone@gorg.es
<ul><li><strong>Status</strong> changed from <i>Testing Required</i> to <i>Resolved</i></li></ul>