Project Browser Initiative Meeting for October 12, 2022 [#3328111]

1️⃣ @Jacob Morin and I made a great amount of progress on GitLab CI yesterday with Project Browser. Near as I can tell we dissected our mangling of code-commit-check.sh thoroughly and are going to open some child issues to port each piece of that functionality, and the PHPUnit testing functionality, over to separate jobs in GitLab CI. With @hestenet (he/him)’s base template we were able to get it to a working point (then a non-working point 🙂 ). So, just some more work there, but gratefully, an actual clear path forward. :smile:

leslieg	@irinaz presented a session on Drupal CI to GitLab CI at BADCamp last week. Recording is not available yet, I can try to get the slides
hestenet (he/him)	I'm honestly still surprised you got so far :sweat_smile: I have so much more I want to fix about the template
hestenet (he/him)	But on the upside - I can use all the examples of what you fixed to get it working to get a jumpstart
chrisfromredfin	something that works and is not ideal is far superior to something that doesn't work - so I agree, make small fixes then iterate!

2️⃣ Looks like there's been work as recently as yesterday on getting the Svelte UI installer piece going. Does anyone know where that one's at specifically? Are there still things that need to be addressed? #3312289: Svelte UI for install controllers

bnjmnm	It's not worth furthering the JS dev until the Composer Stager dependency of Project Browser supports file/directory exclusion. Until that happens, I need to rm -r node_modules after making any change otherwise the install will stop once the symlinks in there are found
bnjmnm	Stuff like test writing can still happen because it's not dependent on node_modules
chrisfromredfin	Ahh, the old symlinks issue rears its head again! I ran into that in a few places when testing out in Portland.
chrisfromredfin	@timplunkett (he/him) does it make sense to still wait on merging some of the smaller fixes, then? Alternatively, is there a way we can help out the "exclusions" issue for AU?
bnjmnm	This issue should not block other issues from going in
bnjmnm	It will likely be a while
chrisfromredfin	":thankful:
fjgarlin	currently 5 RTBC issues, all of them small-ish
timplunkett (he/him)	@chrisfromredfin go for it. I can help more this afternoon, AFK at the moment
chrisfromredfin	ok, great. I will look through!

3️⃣ The usability group has taken a swipe at our UX (h/t @rkoller) and issues are ... forthcoming? Already entered?

rkoller	i’ve added the list of issues to be created after writing up the draft for #3314350: [meta] Usability improvements for Project Browser . i wanted to wait until the recording of fridays meeting is up to revisit when creating those issue to catch all the details.
rkoller	or also others are free to open issue. but everything is tracked in the remaining tasks section.
chrisfromredfin	OK that's great.
rkoller	but i think best choice would be to wait until the recording is up. ihavent taken any notes or paied close attention memorizing. it is more productive when brain storming and finding issue to to focus on the screenshare and the discussion.

4️⃣ Categorization. Looks like we've had a few people take a swipe at this - so it may be time to look at and aggregate subjective results to hone for our next pass. @leslieg any additional feedback on categories that happened at BADCamp? I heard the contrib day was a bit of a bust there. (Or, there wasn't one. Or something.) (cc @rkoller) #3311475: Review Category Proposal

rkoller	i think even though the number of filled out questionnaires is small it might be enough for an initial honing and discussion round. and then the questionnaire as well as the categories would be improved for another maybe broader round of testing? would it make sense to have a video call. i guess a discussion is easier spoken than typed?
chrisfromredfin	Yes, that might be a good thing to plan for. Small group initially to hone, and then open up to a larger (ex.g. BoF-style meeting)? Or kind of an open-invite meeting straightaway?
rkoller	hmm maybe a smaller group for discussion the results of the questionnaires (ideally those people attending are familiar with the filled out questionnaires). and based on the level of changes and conclusions that came up during the meeting either run perhaps a remote bof during drupal south or do another round of questionnairs. or maybe both. and in regards of questionnaires i think instead of opening an issue and wait until people fill out personally approach people and gently ask and motivate. that way it would also be ensured that there is a certain diversity of people.
rkoller	when do think would it make sense to have the discussion? ideally before drupal south? (edited)
chrisfromredfin	Yes. @leslieg is mid-way through finishing her thoughts on the original one. So once she's done and uploaded hers we should plan something. When is DS?
rkoller	19th-21th of october: https://drupalsouth.org
rkoller	@chrisfromredfin i’ve created a spreadsheet file in numbers to easier compare the answers side by side. might help for discussions. one shee for the categories description one for module descriptions and one for the closed card sort answers. that might be the most insight- and helpful. and one idea in regards of the procedure. perhaps make the meeting with the people who filled out the questionnaire and discuss it in that round. then hone the categories for the next round of questionnaires. and again have the discussion at the end with the people participating. and i could attend as well but only listening and observing from this point on.
chrisfromredfin	meaning you've aggregated answers from the google docs? Can you share the sheet?
rkoller	bobs answers are missing or better have to be updated. he hasn’t sorted a module into a single category but instead put modules into two categories. that way it is difficult to compare with other questionnaires. i’ve already wrote him about and he will update his doc.and i guess the numbers spreadsheet might be moved to a google spreadsheet as well. that way others could access it as well. and one detail i am not sure yet how to present is apply a color coding to the closed card sort sheet. either give each module name a background color. that way it might be easier to visually grasp how consistently modules were sorted (either a horizontal line ideally or scattered across lines in the worst case). or the other option is to add a color scale. green for modules with six identical sorts and red with no to three identical sorts and yellow four to five. or something like that. but there are definitely a few points for the first discussion round i’Ve already noticed. in the results and answers.
rkoller	and i’ve sorted the modules as well as categories in the sheets alphabetically. thats easier to navigate.
rkoller	and one faux pas i’ve noticed. bobs username is bsnodgrass and not bobsnograss i’ve used by accident in the column headers in the numbers spreadsheet
chrisfromredfin	minor faux pas, I'm sure bob wouldn't mind. 🙂 This is wonderful tho! I would love to have time to digest this. @leslieg you should give it a quick read!
leslieg	Will do @chrisfromredfin

5️⃣ We need design input on #3310896: Improve UI of results count

timplunkett (he/him)	@Divya Mangadu @Jillian Chueka
chrisfromredfin	@Ruth L (tho she's at An Event Apart this week)
fjgarlin	ideally here too: #3313292: Change layout to make plugin-specific content more clear#comment-14738973
chrisfromredfin	I do like this layout functionally, I wish they somehow looked more like "Drupal Tabs" but that may be another issue. But I'd love to get some ideas around if this makes sense to a designer, yeah. https://www.drupal.org/files/issues/2022-10-12/Browse%20projects%20_%20p...
fjgarlin	that’s good feedback and perhaps could be addressed in that issue.
rkoller	yep i agree. at least for claro it could follow the drupal design system and be styled as tabs: (currently it looks more like buttons)
fjgarlin	should we even worry about seven admin theme anymore? #3084814: Deprecate Seven theme (edited)
chrisfromredfin	If that issue is closed/fixed, then I vote no.
rkoller	i think the following issue #3314210: Re-arrange radio-buttons for better usability might also need some design input. the styling of each radio button column isnt adjusted to the drupal design system yet (have to make a comment about that on the issue still). but the main point is another. i dont know any interface component in drupal with more than a single column for columns, checkboxes and alike. (edited)
rkoller	so some input might be useful in regards of the width of the gutter between columns?
chrisfromredfin	^ missing direct link to issue
timplunkett (he/him)	There's a lot of places where if we used the standard markup we'd benefit from the theme's styling. like using class="button" instead of rewriting cursor: pointer; in a bunch of places
Jillian Chueka	Is this the piece users could not find? The black text results count?I think adding the additional buttons is information overload for the user. "Results" should be in one place. Do users need clarifying breakdowns of results (i.e. module results vs. core results)?
Jillian Chueka	I wonder if moving the filter chips down a line so that results stands on it's own?
timplunkett (he/him)	right now the results are shown for each tab, and then repeated above for the active tab https://www.drupal.org/files/issues/2022-09-23/Screenshot%202022-09-23%2...
timplunkett (he/him)	"Drupal.org (mocked) 1900 resultsDrupal core 80 resultsRandom data 1 result"
Jillian Chueka	Ah I see. I wonder if vertical columns is the way to go here then. Maybe more like horizontal blocks of search results (kinda like this example)
chrisfromredfin	to your prev question, yes - they couldn't see the results count there (most testing was done with only one plugin enabled, so the other / tabs ones weren't there). Right now there's an MR that moved the results count below and out of the filters box, but the original thought I had was like you said, giving the resullts count its own line
rkoller	with the aforementioned patch it looks like that.
rkoller	one question i’ve asked in the issue. what is the benefit of showing the results count in each individual plugin source tab? is it a use case that someone is searching across all plugin source?
Jillian Chueka	Oh yeah that def looks better. ^ similarly, why break it out by Drupal core vs .org results? Is there a better way to show modules that are drupal core, either an icon or another signifier?
chrisfromredfin	technologically very hard (nay, impossible?) to mix data from two different sources on one tab. And, the idea is we want to have multiple sources so that organizations can provide their own libraries / curated lists, etc.
rkoller	i also like the results moved out of the filter component more. it is a separation of concern. and communicates things more clearly. i am just not sure if the result counts for each tab are necessary. you search in one context (source) and you are only interested in the result in that context. with that many results shown it is an overload as well. and in another issue those tabs for the plugin sources are moved above the filter component. then those result counts are even more confusing imho.
fjgarlin	part of the issue is that categories are per-plugin, and so are result counts
Jillian Chueka	Ah I see. So more of a back end constraint we need to design for.
rkoller	#3313292: Change layout to make plugin-specific content more clear that is the issue about moving the tabs.
fjgarlin	that ^^ 🙂
timplunkett (he/him)	yes, each different "source" handles its own filtering, and most relevant, it's paging (returning 12 results at a time)
rkoller	oh each source has a different filtering?
timplunkett (he/him)	we can't smush the various sources together, or we wouldn't know how to pick 12 from the 24, 36, etc results
fjgarlin	some of the filters are common, some are per-plugin :upside_down_face:
timplunkett (he/him)	but regardless, each source is responsible on its own for handling those filters, shared or otherwise
chrisfromredfin	For counts, I think I could argue for some functionality of showing it in the tabs (think of other faceted search interfaces) - or maybe it notifies you that "oh yeah I need to find this on that other tab") but I don't have strong opinions on it. Looking here at Amazon as an example, they're not showing counts(sorry we're having a couple of different discussions here)
fjgarlin	my first suggestion on the layout issue was trying to separate that.above the horizontal rule = commonbelow = per-plugin
rkoller	then i would heavily vote aginst displaying the result count in the those plugin source tabs? the impression as a user if you enter a search string is that those results are based on the same set of filters?
Jillian Chueka	The amazon result count is in the upper left corner
rkoller	one other issue might also need some design input i’ve totally forgotten about: #3300093: Improve the readability on individual module pages by limiting the line length its about the line length on the individual project pages. without the available patch things got up to line lengths of 390 characters (on a 38"display). but with the initial patch the readability improved tremendously but you get a lot of white unused space in return.

6️⃣ How to best ensure we have reliable test coverage when we switch to the JSON API DrupalOrg endpoint https://www.drupal.org/node/3240319

bnjmnm	We clearly can't hit that endpoint in tests, but that could mean our tests are not in sync with a resource that is very coupled to Project Browser.One (possibly too idealistic) option that came to mind after finding out the endpoint will be on Drupal 9. Could we make the JSON API modules endpoint available as something that could be installed during tests so we could have a local instance of it using an abbreviated dataset? This way, if there are changes to the endpoint, the Project Browser tests would catch it immediately, but without actually making requests to D.O. I have no idea if this is feasible at all
fjgarlin	that’d mean having the content types / fields, etc that www.drupal.org will have for projects, users, releases, paragraphs… so not sure that’s an option.
fjgarlin	there should be no changes to the endpoint (once it’s fully live) from the DA unless previously communicated, agreed, etc with PB/core as we know that’d break the endpoint.cc @drumm (edited)
drumm	Yeah, “just use jsonapi” isn’t an api design. A few static files is what’s normally done for mocking. That’s what core update module does with updates.drupal.org XML for example
bnjmnm	I had a feeling that was potentially an impractical request. I'm open to any suggestions regarding how we could implement a semi flexible mock, where it's at least as flexible as our current mock data, which automatically supports things like sorting / filtering
drumm	Of course, enough static files to cover some sorting/filtering use cases, full-text search too.
fjgarlin	once the endpoint is live, the results could actually be recreated as needed (as we do now every time we want to update the fixtures for example).currently you (Ben) have around 30 pages output worth of results with different queries, including sorting, pagination, filtering, so it’s not a problem to generate as many as we need and store them as fixtures in the module for the tests. (edited)
fjgarlin	relevant thread: https://drupal.slack.com/archives/C01UHB4QG12/p1664910285197359
bnjmnm	The part that concerns me (but I'm not presuming there's an alternate solution) is something like category filtering would only work for the specific scenarios we've mocked, despite the UI listing every category. We could limit the categories to those with mock support, but I'm worried about modifying the response contents to the point that a test is not accurate. I have the http intercept throwing an exception if a request is made for a query that isn't mocked, but still looking for a good way to get this info to the test output since it's requested by Svelte, not the test.
drumm	The tests just need to make sure one category page works? The categories will change over time, don’t need to test the same thing 30 times.
chrisfromredfin	I would think Drupal.org Mock API might actually stick around to be used as a test fixture locally (as random currently is). We would be responsible for updating Mock with changes that happen on the "real" api side. I also could see statically hosting .json files to use for fixtures.
drumm	As long as it’s hosted or otherwise retrieved from localhost. Anything that goes over the internet will cause random fails in automated testing. Guzzle/etc have their own testing, so don’t need to test any of that again. Do include handling for a failed request of course, since those will happen occasionally.