$x = 'morning'; include 'local-greeting.php'; print $x; project browser community! Who needs what? Say hi and let us know you're here. I may be pinging individual names here for clarity on some things.| fjgarlin | hi there :wave: fjgarlin |
| bsnodgrass (he/him) | Greetings from St Charles IL, western burbs of Chicago. Catching up... had a conflict earlier |
| chrisfromredfin | I have the current MR spun up here if anyone wants to take a look through the UI - https://8080-shaal-drupalpod-zsfcdkp58zf.ws-us46.gitpod.io/ |
| Divya Mangadu | I have some ideas that I mentioned in the thread before, but I'm a little confused about what these recommended modules look like. To clarify, are the recommended modules the ones that are covered by the security team, actively maintained, etc? |
| chrisfromredfin | After all this time with no additional comment, we have thus decided the following criteria for the "recommended" (default) tab will be thus:* must have a release compatible with this version of drupal* must have security coverage* must have a supported and recommended release (that is compatible)* maintenance status: actively or minimally maintained, or seeking co-maintainers* development status: actively developed or maintenance fixes only |
| chrisfromredfin | So two of those are "automatic" (the compatible release) and the "supported and recommended release"... so from a UI perspective, it's choosing:security coverage = coveredmaintenance status = active or minimally or seeking codevelopment status: actively developed or maintenance only |
| chrisfromredfin | Now @drumm has mentioned that one of those, I believe "development status" is often overlooked, so I'm not sure if we want to (a) include it, and make people start paying attention to it (b) not use it in PB at all, and potentially remove it from d.o entirely? (c) something else? |
| chrisfromredfin | ALSO, there is discussion happening here: #3281218: Restrict the plugin's ability to control which filters are available#comment-14535346 - and in the comments below, which might also change the front-end UI quite a bit. Also curious your thoughts on this. |
| chrisfromredfin | ^ Basically, the above wonders about converting those filters to booleans or on/off radios, and letting the backend decide which statuses mean which front-end status |
| chrisfromredfin | @fjgarlin pinging you on the above ^ |
| fjgarlin | thanks for the tag. I’ve been kinda waiting for conversations on other issues and progress to be made that was somehow related to this.I’m currently working on the project_usage and core_compatibility migration from D7 to D9 as those are quite complex cases and need some thinking.Having said that, this issue is probably the next on my priority list and I’ll start working on a draft/proposal tomorrow or the day after, so expect some updates soon. |
| chrisfromredfin | OK that's good, I was hoping we could get some feedback on this somewhat major approach anyway first, from some UI/UX people. @timplunkett (he/him) you still like the idea of abstracting the Drupalisms out of the PB front-end yes? |
| timplunkett (he/him) | Yes, I'm in support of that idea |
| fjgarlin | I’d love that too. If we have a clear view of what we want and all parties (UI/UX, devs, DA…) are happy I can try to code everything more confidently.I’m happy to start as soon as tomorrow or wait a bit longer if anybody else wants to chip in. happy either way |
| chrisfromredfin | I'm comfortable saying that if there's no additional feedback and if we three are in agreement, then it's the best way forward and we should do it. I just want to make sure @leslieg knows about it. I think it simplifies the UI in a good way, that makes the whole thing easier to understand and use and gets rid of drupalisms, so ... |
| timplunkett (he/him) | Do we have a concrete proposal for how to do this? or are we just agreeing on the intention |
| chrisfromredfin | No, only thinking about it from the UI side. So I think the frontend API call simply passes a bool, and the plugin on the backend is responsible for fetching and saying what adheres to that criteria. I would assume this would involve updating the front-end->Drupal contract, but not necessarily anything with the Drupal backend; just updates to the plugin(s) |
| timplunkett (he/him) | Sorry, I meant "how to present this in the UI". Agreed not worried about the backend implementation |
| chrisfromredfin | oh oh. No, no input from a UX person. My personal believe is radio buttons with either( o ) Well Maintained ( ) show all |
| chrisfromredfin | tho all that verbage could be a bit of a usability debate |
| timplunkett (he/him) | okay we'll leave that to the experts. +1 to the general idea though |
| chrisfromredfin | because then how it shows on the tags in the "currently selected" |
| fjgarlin | I’ll try to suggest something (code) based on ^^ and the info in the issue specially and coordinate with you @timplunkett (he/him) (and all really) to see if you like the approach.--UX wise, I think that checkboxes make the most sense with the options here: #3281218: Restrict the plugin's ability to control which filters are available#comment-14535346as you can choose as needed. if we do radios we’d need to do another extra one to select all. also, keeping checkboxes would not mess up with current UI. but again, happy with any suggestion in any case, just giving my opinion. (edited) |
| fjgarlin | changing it to radio / checkbox won’t be the complex part here so I’m not too worried about it :slightly_smiling_face: |
| chrisfromredfin | Yeah while checkboxes make sense I think people need to understand the either/or decision, so I'm still pushing for radios. Happy to be overruled,though, especially by someone with more experitse :slightly_smiling_face: |
| leslieg | @chrisfromredfin it’s not clear what changes are being proposed in this thread in terms of UX. There are several outstanding tickets dealing with defining the default criteria: as a sitebuilder or someone new to Drupal I have no idea what “covered” means, changing the advanced filter icon with a button, adding a way to return to the default filter display, etc. How do those tickets tie in here? |
| timplunkett (he/him) | the proposal here is to hide all of those Drupalisms behind bigger "buckets" |
| timplunkett (he/him) | present fewer options on the front-end, have them correlate to all the key things on the backend |
| chrisfromredfin | Basically in the "advanced filters" box @leslieg we're talking about removing all the Drupal statuses, and making it an either or... so under "Maintenance status" instead of showing all five, we just show "Well maintained" and "show all" -- same for development status and security coverage (which is already a yes/no) |
| fjgarlin | so, will your suggestions be the following then?- Security: ( o ) Covered by a security policy / ( ) Show all - Maintenance: ( o ) Well-Maintained / ( ) Show all - Development: ( o ) Active / ( ) Show all |
| leslieg | So the initial statuses displayed will be well maintained and covered by security (with yes option as the default for both)? Will the advanced search also just have these or will the D.o statuses of actively maintained, minimally maintained, etc be options? |
| chrisfromredfin | no we get rid of the d.o statuses entirely. They're merged in the backend so that the ones we chose are the ones represented by the "well maintained" version |
| Jillian Chueka | Where in the UI is this located? In the advanced filters? |
| leslieg | So if they are only displayed in advanced filters, the default is to show no filters relating to maintenance, security and possibly development status? Sorry for all the questions, just trying to understand from a user perspective |
| timplunkett (he/him) | currently, everything is hidden in advanced filters. and when you open it, you get 11 checkboxes. 4 for dev status, 5 for maintenance, 2 for security |
| fjgarlin | Default filters will be preselected, same as they are now. |
| timplunkett (he/him) | proposal is to have 1 checkbox (or 2 radio buttons) for each |
| leslieg | ok thanks and some way for users to know what the filters mean? |
| fjgarlin | I think there was an issue for that. can’t remember which now tho. |
| fjgarlin | #3282163: Improve iconography usability by adding a legend |
| chrisfromredfin | Yes, I think still having a legend or whatever is good. |
| Divya Mangadu | Re: radio buttons vs check boxes, I don't think there's a need for a "show all" option; since it's a filter, it's usually assumed UX wise that no options checked = everything is seen. So a checkbox makes sense to me. I could also see someone thinking that "show all" means "show all filters" (I thought that at first too).I'm worried that "well maintained" is a bit too broad, but a tool-tip/legend could help. Does "actively maintained" fit what it's filtering out? |
| chrisfromredfin | Oh, I see. So a filter in the affirmative .. I was thinking the checkbox would be "show all" which didn't make sense to my lizard brain. I got it now. So there's a checkbox to restrict to like "Actively Maintained" only, but it is checked by default (because we do want that to be our recommendation) |
| Divya Mangadu | Yeah, that's what I' m thinking. I also think some copy at the top of the filters explaining why they're pre-selected would be helpful.In terms of the OG reset button question, since there aren't many filters now and because it seems like we want to steer users towards using the recommended modules, I think just having a "reset" button that goes to the pre-selected filters is a good solution here (with a explanation of some sort). I think having a "reset to recommended modules" as a button alone might be confusing without knowing what a recommended module is. |
| Divya Mangadu | Just a quick mock since I know I'm more visual - what do you think @Jillian Chueka? |
| fjgarlin | what is “top modules”? isn’t that determined by the sorting? |
| timplunkett (he/him) | "collections" was something we removed from MVP |
| fjgarlin | and I think we were going to abstract “development status” as well to a more simple approach right? |
| chrisfromredfin | correct. should be all of those. |
| timplunkett (he/him) | right, but TBD on the terminology. the idea is the same, +1 divya |
| fjgarlin | it’d be great to update the issue with the above info and kind of a confirmation / agreement on the options within scope for the issue. |
| Jillian Chueka | Agree, spot on Divya. Alerting the user why those filters are preselected is a good choice. For terminology, I agree with a simplified approach. |
| chrisfromredfin | Love it. Also there is an open issue re: having a "Legend" to describe this. This may resolve this one. I think @leslieg has some input from user interviews. |
| leslieg | @Divya Mangadu yes, the text explaining the options was going to be replaced with a legend. Listening sessions showed that users were not reading the text and if they did, it was too technical for them to understand. . |
| Jillian Chueka | Ah interesting. So it is definitely worth it to simplify the language |
| drumm | - Maintenance: ( o ) Well-Maintained / ( ) Show allWhat we currently have is really “could be well-maintained” / “explicitly not well-maintained”. We can never really promise something is “well-maintained” since it is so subjective. We do give maintainers ways to say they aren’t maintaining something. |
| chrisfromredfin | We should understand the caveat that the data is all user-selected. But I think there's not a ton to do about this at this point. If we want to hedge, I might just get rid of "Well-" and do "Maintained" / "Show All" |
| drumm | That’s a good simplification. Now I’ve looked at the word “maintained” too much and I’m wondering if it makes sense on its own to a broad number of users with varying English/Drupal proficiency. Probably over-thinking it. |
| drumm | One edge case - “maintenance fixes only” - in my mind, that’s “maintained.” Could be a simple project that doesn’t need new functionality. Does that sound right? |
| chrisfromredfin | yes, maintenance fixes only we actually did specify should register under 'maintained' :smile: |
| chrisfromredfin | but it's nice when people independently comes to the same conclusions |
| fjgarlin | Nearly there :slightly_smiling_face: |
| leslieg | That’s correct @chrisfromredfin we are looking for a non-technical short description of 200 characters or less to be displayed on the cards for the projects. There are child issues created for the top 100 modules if folks want to chip in to help create these. See threads 3 and 5 from yesterday’s Site Builder Subcommittee meeting (edited) |
:3: good point, Leslie! There are lots of non-contributions to be made to this initiative to help make the top 100 modules very project-browser-friendly. Those issues can be found here. https://www.drupal.org/project/issues/project_browser?text=&status=Open&...
| chrisfromredfin | I'm guessing that's been here since the @grasmash days. That code hasn't been touched too much. ? |
| bnjmnm | That's helpful and lines up with the Git history :+1: |
| chrisfromredfin | Looking through ProjectBrowser.svelte where it's set as a prop (hardcoded) ... I just don't see why it's needed currently. It may have been a forward-thinking thing like if we wanted to make the Pagination component re-usable for some other purpose; but I don't think even the blue sky mockups have a second set of pagers |
| chrisfromredfin | So I vote trash it if that's what you were thinking |
| bnjmnm | Glad to get the +1, I'm refactoring some components to make pager accessibility easier, and it seemed silly to move an essentially-unused prop to a new component |
| chrisfromredfin | excellent. |
| timplunkett (he/him) | I rarely fill in past the first few parts. Happy to slim it down |
| chrisfromredfin | Yeah I went to review this issue and while the code looks good I don't even know the problem it's solving :wink: #3282692: Redundant image alt text for VBO/Pathauto etc. |
| chrisfromredfin | ping @hj (they/them) or @narendraR if you want to fill in a description so I know what I'm testing :slightly_smiling_face: |
| chrisfromredfin | Here's my current pitch:Problem/MotivationSteps to reproduce
|
| chrisfromredfin | Open MR probably isn't even needed since so much of this represents the normal status. Like if it has an MR it would go to needs review. So maybe even ditch that. I think I just want to know that it's been reviewed for x y and z. |
| chrisfromredfin | So maybe:
|
| hj (they/them) | I’ll be honest I don’t really know what’s supposed to be tested either, I just filed all of them so we had existing d.o. issues for them but I think @bnjmnm might know as well |
| timplunkett (he/him) | Yeah that's from #3282265: Conduct an Accessibility review of the module (Late May 2022)#comment-14538549 |
| chrisfromredfin | I figured as much. I just didn't know what a duplicate alt attribute was or meant, or mattered :slightly_smiling_face: |
| timplunkett (he/him) | if it doesn't give any additional context, it should be rewritten or removed. since we can't rewrite them... |
| bnjmnm | My assumption for #3282692: Redundant image alt text for VBO/Pathauto etc. was that the alt text included the word "image of" or "photo of", but I haven't confirmed Many of the recent A11y issues filed have needed a little refining which I figured I'd get around to. I'm not used to a project moving this quickly so I probably need to hop to that or postpone some of them |
| bnjmnm | And BTW nothing wrong with anyone writing or working on the issues. Accessibility is kind of under-documented compared to pretty much everything else we work with |
| timplunkett (he/him) | the MR is checking if the alt === the project title. instead of returning empty string, we could prepend "image of " :thinking_face: |
| chrisfromredfin | I'm inclined to say we should make sure that as we're adding images to the top 100 modules we present them with an option for the alt, and try and get that data from Drupal (and/or "the backend") and leave blanks... that is, if my understanding of how it works now is correct, then it's probably fine? |
| bnjmnm | "image of" in alt text is a :-1:. It's already implicit that it's an image |
| bnjmnm | Do the module images ever include information that isn't already apparent in the module name/description/metadata? |
| timplunkett (he/him) | so Metatag's image alt is "Metatag config interface on Drupal 8." |
| chrisfromredfin | ^ which, for that image, may make sense |
| timplunkett (he/him) | Fieldgroup's is "fieldgroup_03.png" |
| chrisfromredfin | and webform's is their logo and the alt is "webform logo" |
| chrisfromredfin | garbage in, garbage out - I think the SBS initiative to push "having good data" could include the alt.. ?since we'll be approaching maintainers with logos and saying "here, make this your first image - with alt of 'some good alt here'" |
| bnjmnm | Given that inconsistency, I think it's better to mark the images as decorative |
| bnjmnm | alt="" |
| timplunkett (he/him) | great, that's what the MR does |
| bnjmnm | Nice! |
| bnjmnm | At least in the context of project browser, I don't think the image adds any new/relevant info. |
| timplunkett (he/him) | Oh I mispoke, we only mark it as "" when it matches the project title. if it's different, we pull it in |
| bnjmnm | Based on the examples you shared, it sounds like none of the alt values are particularly useful |
| timplunkett (he/him) | yeah in the ideal case, every project would have a decorative icon/logo that we'd have |
| timplunkett (he/him) | so if we want to pretend that they already all do, just going always with alt="" seems best |
| bnjmnm | There miiiight be contexts where someone is deprived information because its only available in the image, but I think it's worth waiting for evidence of that before trying to address it as it doesn't seem likely and it makes things more complicated |
| chrisfromredfin | agree |
| leslieg | I agree with the decorative thinking. The issues for logos for the top 100 modules did not include anything about specifying alt text. |
Participants:
chrisfromredfin, zebruh_divs, fjgarlin, tim.plunkett, leslieg, bostonjillian, drumm, bnjmnm, hildog
Comments
Comment #10
leslieg commentedComment #11
leslieg commented