Create a "mini-browser" UI

Are we referring to the mockups from this Starshot issue: #3449347: [META] Recipes, Package Manager and Project Browser improvements needed for Drupal Starshot → ?

Yup! The first one is for the "site template" version and the second is for the "feature-based" one - and we're prioritizing the "feature-based" one first.

Hi @Ravi Kant,
Thanks for considering this project. We are going to maintain the theme, so currently, we don't need new maintainers for this theme.

yash.rode → made their first commit to this issue’s fork.

Gave this a quick manual test. It worked, but there were a few things I noticed:

• The styling is virtually nonexistent (see screenshot). It can probably be deferred to a follow-up, but it's ugly the way it currently is.
• There's no text or anything that indicates what this little list of projects is, or what to do with it. Ideally, we'd add a configuration option to the block which allowed us to set some preamble text.
• If you click to a project's detail page, "back to browse" takes you back to the main project browser, rather than where you were. That's jarring.
• There's no indication that a project browser is loading in the block's spot. This is something we'd ideally fix for all project browsers; it'd be good to have some sort of throbber there while it loads.

I think these are all follow-up material, though.

Let me preface this comment by saying that nothing I am about to say is meant to impugn any work that was done by Yash, myself, or anyone else who worked on this. My problems here are with the management, not the technical side.

Having said that...what are we doing here?

When I manually tested this issue, I saw a small project browser displayed in a block, exactly as promised. So it does what it sets out to do...but how is it useful? What problem is this mini-browser solving?

I am hard-pressed to figure out what a non-technical user is supposed to make of this thing. They will see several icons, and some words that are most likely meaningless to them. One of those things will be freaking Chaos tools, which should never be seen by a non-technical person under any circumstances.

I think this was implemented without a clear idea of who it was meant for, or how it would be used, or what the benefit to end users would be. We need to take this back to the drawing board and figure out what we're trying to achieve. This is a case, I think, of incomplete wireframes (Drupal CMS's, to be precise) dictating the implementation, rather than a fully thought-out user experience being brought to life.

Postponing until we have more info from the UX team.

Agree this should be postponed for now. We may have a need for something along these lines to expose local recipes post-install, but we are best off waiting for wireframes before we continue.

The main reason for this issue's existence was to support the Starshot wireframes Dries presented, which showed a way to apply recipes during the installer. Since that was abandoned in favor of a post-install recipe-chooser, and that was largely handled in ✨ Expose each source plugin at its own dedicated route Active , can this issue be closed? I don't think there's a need for this specifically; or, at best, we re-scope this issue for whatever the next logical choice is for the post-install thing. However, I think that might be handled in Recipes initiative and not here in PB.