Create a dashboard block to provide prompts for new users

Why point number 2 to restrict to local recipes only?

This is an interesting idea and wouldn’t restrict it. Thanks for adding this issue 👍

I also don't know the value in putting it during install, since I think a lot of infrastructure needs to be installed to pick it up, I wonder if it's technically an interstitial between install and visiting the site.

I think it's a small distinction but important.

Why point number 2 to restrict to local recipes only?

The idea is to give starshot a chance to control the initial user experience before handing off to project browser.

I agree they don't need to be local, just curated.

Ah I see now, that then makes more sense, if you're restricting it to strictly Starshot / curated recipes then running them during the install step can be more accurately tested and that would probably be a better experience overall.

Moving this to the Starshot project. I don't think core can provide a solution for this before Starshot and Starshot needs it fast :D

I also don't know the value in putting it during install, since I think a lot of infrastructure needs to be installed to allow recipes to work, I wonder if it's technically an interstitial between install and visiting the site.

I think it's a small distinction but important.

Yeah I think when we are talking about "Installation" we mean exactly this interstitial, where you can add more stuff after the basics are installed, before you go to your site. @catch put in lots of work to make Drupal install-less but hit lots of problems. His concept for doing project browser / recipe installation in the installer was also to add it at the end of the installer, when the infrastructure is all built up.

I think the MVP of Starshot may be that there is no vertical selector (Magazine site, Community site site, etc) at the start of Starshot but one CMS recipe is installed (you already did the persona selection on the d.o page where you picked CMS over core framework). But the additional recipes would show in the Starshot UI as a simplified Project browser UI.

I think we are talking about this UI screen:

BTW while I moved this to the Starshot project, I think it would be ultimately solved in Project Browser and Starshot itself would only need to modify the installer flow to inject the Project Browser experience. So the main solution I think for this will lie in Project Browser, something like these items

• A way is needed to tell which component recipes should be offered here, initial MVP could be hardcoded
• A simplified UI should be built that offers those recipes and installs them when you continue on this screen

When this came up on my RSS feeds I thought it was a change record 😀

Will starshot have a custom install.php?

The governance around what will be added as recommended/curated recipes in the list will be super important obviously. Probably already discussed elsewhere but the recipes tagging/taxonomy is also super important to get right.

Starshot trying to insert project browser in the installer seems like a lot of potentially a lot of work which would then have to be discarded again once core handles it. Maybe it could work as an extra screen after filling in the site information form, but that's adding even more steps to the installer then. It's also starshot-specific custom code which overall would be good to avoid.

What I think could work is replacing the 'Welcome, you installed Drupal' front page with project browser + recipes. This implies no choices presented during the installer itself but as @Gabor said you've already made a choice if you install starshot. However as I'm writing this, there are two problems with that - replacing the default front page won't work if starshot ships with an actual front page that works differently, and even if it doesn't do that, as soon as there is one, the UI would disappear.

So... I think the first thing would be to build the UX in the wireframes at a dedicated route, which can be under extend or wherever and should be easily accessible from the navigation bar, and then figure out how to get people to it as early as possible during/after an install and making it clear they can get back there later too. Maybe a redirect to that page after install instead of the front page is worth a look?

Great feedback… as long as the UX is clear and intuitive then I agree it could be linked to.

I feel strongly the home page should be something visually compelling that displays the power of Drupal with content components. Part of the message on the home page could explain how easy it is to explore for more features and link to the feature (recipes) browser. Not sure it makes sense to call them recipes to the end user though.

I propose renaming the issue something like "[META] Add routed landing page that offers recommended recipes and next steps". As catch said it should get some wireframes with the goal to build in layout builder(?). I think there should be a subtask for each clear deliverable, hence [META].

* Welcome message
* Promote (and install?) optional recipes
* CTA to project browser
* CTA to... ?

The wireframe PDF shows an example of what we think the user should see after installation, and it's a dashboard, *not* the site homepage.

I agree the home page should showcase cool stuff but I think we should focus on making it a good homepage for the site you're building, and that will be super difficult if we're also trying to guide the builder journey from there.

The idea also being that the dashboard would be the page you always see when logging in (vs currently where you see /user) and we can add some prompts at the top if it's a fresh install or certain steps have not yet been taken.

Adding the wireframe PDF.

Awesome thanks! I agree it's not the home page.

I have changed the scope this within #3448172: [META] Finish your site, after installation → . I could see this moving to project browser project.

I think the title might need a little work.

The discussion seems to be moving this towards managing the recipe install after the actual install process since there are complications with putting it in the actual install process.

However, I think the intent still is to make it seem like it's part of the site configuration, and the title maybe keep that clear.

The discussion seems to be moving this towards managing the recipe install after the actual install process since there are complications with putting it in the actual install process.

That is what this ticket is about. The parent META ticket talks about a post-install landing page "Finalise your site". This issue is about what can be on taht page to helps the user install recommended recipes (ie. recipes that ship with starshot but not installed by default).

An alterative for this issue is it is just a content CTA "hey have a look at these other Starshot recipes" which takes the user to the project browser, but the goal either way is to hand select some additional starshot recipes before diving into 5000 options in the project browser.

the goal either way is to hand select some additional starshot recipes before diving into 5000 options in the project browser.

Yeah, exactly. Currently, the prototype adds blog, event and page by default. This functionality would enable us to change blog and event to be optional add ons rather than defaults, for example. (The specifics of the 'recommended recipes' are obviously not relevant to this discussion!)

I don't understand how "block plugin" related to the topic of this issue. Also I think #12 is the screen that would be provided by Project Browser and I thought based on the title that was meant to be covered by this issue. For #20 I think first a dashboard like thing should be available in Starshot, then project browser can expose a block for that dashboard. I think the #12 and #20 screens are quite separate, and in total at least 3 or 4 issues.

1. Project browser should have a "mini" screen that can be plugged into the end of the installer.
2. Either project browser itself should plug it into the end of the installer or Starshot should inject it there. I think PB would be a fine place.
3. Starshot should have an admin dashboard.
4. PB should have a dashboard block to offer additional things to install.

I think (1) and (2) of these are MVP, not sure if (3) and (4) are.

Agree that #12 and #20 are totally separate, I just added it because there was some discussion here of the user journey and specifically the home page, which is currently the place you land after install but ideally won't be in Starshot. Whether that's MVP or not, we shall see!

It is tricky to talk only about each screen independently, because I think that what happens before or after is often very relevant! Although I guess maybe the journey/flow discussion could or should happen elsewhere.

> then project browser can expose a block for that dashboard.

That's technically a block plugin correct? That's why i could see this issue moving to Project Browser project. Unless it's content block but then it would just belong to a recipe?

Retitled for that then. I think we can keep one issue here and one with the project browser? But the implementation would be in project browser IMHO.

Wondering if this could be a . It could be a default dashboard that the user is invited to delete when they are done. →

Yes I think it can use that. I don't personally have enough experience with the existing dashboard solutions for Drupal to say specifically :) I think this can be prototyped in the prototype with PRs though :) I am not sure about inviting to delete later, but parts of it should become less relevant indeed. Not sure how to handle that yet, but in the early stage you would be more interested in extending the site, while later you would value stability and not installing random stuff :)

One thing with the recipes, especially the recommended ones, it would be good if we could see an example of whatever you are getting. For example, if you are adding an events recipe, then having a link to see what an event looks like out of the box with dummy content would be so useful. Obviously not all things will have an easy visual representation but there are many that will. If the recipes browser plugin could optionally have a link to that representation, then someone could take a quick look at it to see if they might want to add the recipe.

I've been looking at some WordPress plugins, specifically to see what features the popular event plugins offer. It looks like there are some sophisticated capabilities available, including event registration (potentially paid), the ability to send notifications / reminders to registrants (by email or SMS), and more. It is worth noting that for WP the use of some of the more advanced features require upgrading to a paid version of a plugin. I'm not sure what the use experience is like for a site owner who decided to upgrade.

We could certainly build a very sophisticated event recipe to provide every capability imaginable, but I would be concerned that this could be brittle and hard to maintain, in addition to being overkill for sites that just need an easy way to list events.

The reason I bring this up in this thread, is that I wonder if it would be useful, as part of this "finish your site" step, to allow the site builder to choose what features they want to include. If they only need a simple system, they could uncheck the more advanced features, and if those additional features would be provided by other recipes, those could be added later, if needed.

That is my understanding of how it will work. There will be many recipes to choose from that are all [?] optional from my understanding. Also there was a discussion of allowing the uninstall of recipes if you haven’t changed any of the configuration for them.

There will be many recipes to choose from that are all [?] optional from my understanding. Also there was a discussion of allowing the uninstall of recipes after installing and playing around with them if you haven’t changed any of the configuration for them.

As a pendantic recipe system maintainer, I would like to clarify something here, purely for the record: there's no such thing as a "required" recipe. You don't ever have to use one. It's not like an install profile, which (until quite recently), you had to use when installing Drupal.

Another thing to be clear on is that "install" and "uninstall" aren't really words that apply to recipes, conceptually. When you apply a recipe, it's like a mindless little robot that makes some changes to your site, and then disappears into oblivion. Drupal doesn't know that you applied a recipe (you could have done all the same stuff just by clicking around in the UI), or which recipe you applied. So a recipe isn't really something you "uninstall" either -- although some work has gone into (and will continue to go into) the ability to revert a recipe if you don't like what it did to your site.

This is really just me being pedantic, to be honest; I just want to try and keep the terminology separate, if possible, because I don't want folks in the wider community to confuse the purpose and design of recipes with the way extensions (modules and themes) work. They're completely different concepts built on a completely different set of assumptions.

We could certainly build a very sophisticated event recipe to provide every capability imaginable, but I would be concerned that this could be brittle and hard to maintain, in addition to being overkill for sites that just need an easy way to list events.

I agree that this isn't something we'd want to build as one single recipe. We'd probably want to build, instead, a constellation of event-related recipes that set up various facets of useful functionality for events. Much less brittle, much more useful for different use cases. The recipe system is designed to facilitate that sort of composability.

> Also there was a discussion of allowing the uninstall of recipes after installing and playing around with them if you haven’t changed any of the configuration for them.

Yeah, "apply a recipe" is the language - I note that the Drush command has this language. Obviously "unapplying a recipe" is a compelling idea but being able to save a snapshot of the site (eg using workspaces suggested here) before you applied a bunch of recipes is IMO how starshot could be looking at it.

We'd probably want to build, instead, a constellation of event-related recipes that set up various facets of useful functionality for events. Much less brittle, much more useful for different use cases. The recipe system is designed to facilitate that sort of composability.

I agree, so I think we should consider what would be the best site builder experience. Could there be an extra step in the process of applying an event recipe, where the site builder can choose which available features they want to include? (registration, notifications, etc)

Could there be an extra step in the process of applying an event recipe, where the site builder can choose which available features they want to include? (registration, notifications, etc)

Yes and no. That's not "features of a recipe"; we don't want to have recipes make decisions like this. IMHO those "features" should be recipes unto themselves. So you'd apply several recipes to build up the functionality (event_content_type, event_registration, event_notifications).

That said, maybe we could (in contrib?) create something which gives the same experience as "choosing features" -- perhaps you check some boxes and behind the scenes it compiles a quick, temporary recipe that enables all those other component recipes that you want, then applies that temporary recipe and immediately deletes it.

Good point on the uninstall vs revert... though for a site builder who doesn't know what's going on behind the scene we may want to still standardize the language to be the same between modules vs recipes? Good one for the UX and documentation experts :)

As for picking bits and pieces of a recipe, that sounds potentially problematic to me.

This discussion got a bit side tracked I think! Updating the title because I don't think we will be prompting users only to apply recipes. I also don't think that 'Finish your site' is a realistic title for this, considering what would be required to actually 'finish' a site from here.

What we are really doing is providing some suggestions (next steps?) for what to do now that you have installed Drupal.

Thinking of a few things we could prompt, not in any particular order and not at all exhaustive:

1. Create an event / blog / landing page (based on the available content types)
2. Add a new content type (this could be applying a recipe OR creating one from scratch?)
3. Browse module add-ons (not the correct wording but this would take you to Project Browser)
4. Move to hosting (if this is a browser trial)
5. Collaborate with your team (add a user, but this only makes sense if it is on hosting already)

This will be covered by the dashboard track, so I'm going to close these issues to avoid confusion. We should have updated wireframes very soon!