Project Browser Initiative Meeting for November 23, 2022 [#3327739]

1️⃣ beta2's killer feature is installing via the UI, though there have been 63 commits since beta 1, so there's a lot fixed and new stuff. To this end, it would be good if folks who've not looked since beta1 to see how the new hotness looks.

fjgarlin

can’t wait to also have the jsonapi and layout changes issues merged, those two are big, tho one more visible than the other.but having the UI installing option is what most people have probably been waiting for during months, so that’s AWESOME

2️⃣ I would love to focus on #3240319: Prepare to switch to using (the future) Drupal 9 JSON:API endpoint - implement tests, etc. next. If I recall, there were tests being added to this. And it's in NR status. @fjgarlin can you succinctly say "what's next" on this?

chrisfromredfin	Ping to @drumm and @hestenet (he/him) (cc @fjgarlin) - is there any sense of timeline on when a production D9 "site" could be spun up for being a production endpoint? Or, is there anything else we can do to help advance that "hardware" side of it?
fjgarlin	Correct Chris.Tests were added, the plugin was moved to a test module for now, and that also means that it should be ready to merge into the main PB branch, as we are mocking the jsonapi result.as mentioned here #3240319: Prepare to switch to using (the future) Drupal 9 JSON:API endpoint - implement tests, etc.#comment-14782410, it’d be great to have @timplunkett (he/him) review as @narendraR, @bnjmnm and myself were actively working on the issue.once merged, it also means that tests will be running against the jsonapi plugin, which is a huge win for now, pending the server.
chrisfromredfin	Epic, so it's truly in NR and needs a code review. I'm not so savvy with testing stuff, but I'd be willing to take a look. OTOH if Tim wants to RTBC it I can merge it.
fjgarlin	correct, truly NR and super excited about it. the code is 90% mocking jsonapi results in json files, 5% the rest of the testing wiring and 5% the actual plugin :grin: , so you can actually focus on that last 10% for the review as the rest is just json files.

3️⃣ This issue needs some help, our current wording is a bit technical and needs to be made more user-friendly #3323354: Review all pop-up messages shown by the Svelte UI installer for user friendliness

rkoller	i still wonder if the success messages (point 11) are necessary at all in the form of an extra modal (ref #3318750: Remove the successful download/install modal from the Svelte UI for install controllers ). you have the installedlabel with a checkmark now in case a module is successfully installed and before that in case a module was successfully added a new button and label. the modal with the success message i’ve considered sort of unnecessary when testing
chrisfromredfin	FWIW, at NEDCamp we were discussing with @phenaproxima having a way for modules to tell PB "what's next?" after installing a module, and using the 'success modal' for that might make it make more sense. For example, some modules might specify "zero config""Installation successful. This module requires no configuration."or"Installation successful. Please go to [SomeModule config page] to set your API Key."or"Installation successful. Configure settings for [Rabbit Hole] on each entity type's edit page."
rkoller	with an actionable item the successful installation modal would make more sense i agree.
phenaproxima	+1 to that. If action is needed, that action should be facilitated as clearly and smoothly as possible.
timplunkett (he/him)	We'd need a mechanism for modules to self-identify those types of states
phenaproxima	Yeah, IMHO Project Browser might consider dispatching an event or invoking a hook in the module(s) that have just been installed.
phenaproxima	So they can either ignore it (zero configuration) or return some text or a render array
chrisfromredfin	I took a stab at this one.

4️⃣ next thing after that I think we need to think about is, since we have pushed a skeleton project detail page, is to really think about the usability of that page and what should be on it. I DO HAVE a very good "content hierarchy" for this (kind of the mobile version), https://projects.invisionapp.com/freehand/document/pwOhQ6IFC?zoomToItems...

chrisfromredfin	And actually, the screenshot that really matters is on this issue:#3322594: Update project detail page layout & elements
rkoller	the problem/motivation sentence looks like cut after the half and is missing something at the end?
chrisfromredfin	thanks, updated!
rkoller	one thought.
rkoller	we’ve outlined the hierarchy. but the used components are in a some cases still “pretty” flexible depending on the module maintainer and how much one will write about a module. i wonder if it would make sense to provide a bit more guidance. cuz i always have the webform module page in the front of my eye which is extensive and each and every other module page runs short. they are using unordered lists to display list of features and other design element no one else uses. and then there are other extremes with close to no content at all. if those module pages would be more consistent in their verbosity it would be helpful for people to navigate on those project pages.the quick description is good to get the gist of a module. the longer description component good to understand the scope of the module. but i think in regards of documentation and how tos it would be good to have a short how to to jump start with a module. and after that links to in depth tutorials and how tos could be provided. but to have a bare minimum how to how to get started with a module mandatory for each project page might be helpful.a good example https://www.drupal.org/project/depcalc has close to no description and it would be helpful to have a how to how to actually use the module.and if a module maintainer wants to go past the desired length of the longer description they could link to a dedicated docs page and so forth.
chrisfromredfin	Yes I was actually thinking of providing something more like a "mobile mockup" just to try and clarify what each thing means
chrisfromredfin	we're still going to have to work within the schema that d.o gives us, which is [body field] - be it the body field of webform, or the body field of depcalc
rkoller	the body field is the longer description component on the invisio page?
chrisfromredfin	yes
rkoller	ah ok wasnt sure anymore. then i would set editorial boundaries for the body field. that the gap between modules isnt too huge and pages look more or less consistent
chrisfromredfin	yes, and we have defined a template that people "should" follow, but we cannot necessarily enforce (yet)
rkoller	as soon as with some guard rails and recommendations for the body field that maintainers dont go off it should be good (edited)
rkoller	the body field and the jump start how to for documentation & how toare the only things. the rest looks good. would that need some more design input?
chrisfromredfin	#3230734: Improve project descriptions by using a template suggestion for the body field
chrisfromredfin	If anything, the actual template needs feedback ^
rkoller	ahhh THAT issue i completely forgot. hmmm in the context of the content hierarchy and if you revisit the hierarchy within the body field you’ve summed up in #7 (#3322594: Update project detail page layout & elements#comment-14799120)and instead of cropping the the long description down to the first 200 characters the quick description component might be used for the cards in grid view ( but not sure what the exact length of the quick description is). it looks just a bit off that the description on the module cards get concatenated right within sentences.i will write up some more thought in a comment tonight. have to think it a bit more through