Review initial Starshot wireframes

ckrina → credited lauriii → .

ckrina → credited pameeela → .

I wonder if we need two options in the download page.

I think that would serve to only confuse people. It is my understanding that moving forward the starshot set up is meant to be default. The only people that would want what is called core would be site architects or developers already familiar with Drupal

The truth is that as an architect I never go to the core download page, I just use composer create drupal/recommended-project:^10 anyway so I don't need the core option there at all. (I do need access to the issue queue still, but that is a separate question).

If we hit the target and Starshot is the most configurable option and as long as it's all recipes you can choose, why would I not want to use it even as an experienced developer?

Wireframe 1:

Question:

Where does the "Learn More" link on the Core CTA go? I am assuming it will go to the existing Download page (at a new URL) which features more granular, developer-level detail like the composer install command.

Observation

I wonder if there needs to be a little more content under the "Why Choose" section. Some content blocks from the homepage could be repeated here, but I would want to understand more about the potential journey if we expect this page to be as popular as the Homepage (which currently gives a nice broad overview of what Drupal is and how it can be used.

Wireframe 2:

I like this and would assume we can show up to six possible options to give a broader flavor of existing themes. Six (two rows of three for desktop) would be the limit I would suggest before the "More templates" action if none of the initial themes were a good fit for someone.

Wireframe 3:

I wonder if there needs to be a way to go back. This is a "wizard" workflow, and the ability to go back and change a previous selection based on the new options I am being presented would be good. Something on screen 4 might trigger me to think I made the wrong selection on a previous screen, and the ability to go back would be much better than starting over.

These options are likely well understand by most folks, but if we are trying to help new people lean what Drupal can do, these boxes need more context somehow. I would suggest a short statement, or if the detail needed will clutter this clean interface for those that don't need the extra context, an expanded Tooltip or Popover display would be useful for those that need more detail around what we mean by "Landing page" or "List Projects" (portfolio?)

Wireframe 4:

If the search box at the bottom of the Site Structure block is meant to find more admin controls, I would move that to be under the "Site Structure" headline instead of underneath the grid of items.

The first thing people will have to do is enter content. I wonder what tools we would have to help someone migrate their content? Do we suggest or assume they are coming from a well-known CMS that we have a migration module for (WordPress)? How can we help someone populate their new Drupal site quickly so they can really start to see how things work and look on the front end?

Wireframe 5:

Why are we confusing people (potentially) with "Extend" as the language in the menu but "Recipes" as the language on the page? Which one is it? If Recipes are a collection of modules that work well together, we need to introduce that concept more clearly. Will folks be able to install a Recipe OR a single Module? That to me means this is the Extend page and Recipes are a part of that, not the main event.

Wireframe 6:

It would be nice to take a cue from WordPress and reveal the number of installs for a Recipe/module and possibly a few additional stats like open issues, last updated, etc. It is not for the novice developer, but over time, it will become useful when evaluating Recipe options for novices and experienced devs.

@nicxvan That is probably related to: 🌱 [meta] Deprecate tarballs, because they are incompatible with Composer-managed dependencies, Automatic Updates, Project Browser, and release managers' health Active

I'm loving the progress on these @ckrina and thank you for presenting them on the superzoom

Two quick things I wanted to raise:

1. Since wireframe 3 is kind of a fine-grained way of asking the same question as wireframe 2, do we really need 2 at all? If I select on 3 that I want to publish news and (for example) "sell products", at that point in the install it's sort of implicitly a magazine-style site but also a store (which is of course possible and encouraged -- no need to pigeonhole the new site!). Wireframe 2 would make sense to me in the context of a theme, but with composable experience building being a target goal for Starshot I'd assume there would be less emphasis on themes as we tend to construe them in Drupal
2. When does a user leave the modal wizard experience and enter the kind of business-as-usual site interface? When a user gets to the home page, will there be some existing content to prime them on the editing experience, without having to click "Add block to section" which can be a cognitive load?

Not sure how directly valuable it would be for these wires in particular, but I've got a proof-of-concept Starshot-predecessor side project I'd love to briefly demo for you. Maybe some of the prior art there would be useful or inspiring.

@poker10, only tangentially.

My comment is why complicate the intial view with two options if the vast majority of people coming to that page will need one of them.

Or maybe it's more vertical so there is still a way to choose the Core option.

The thing is as a developer of sites, I'm not frequently going to d.o to get started, so I'm not sure the target audience for this page needs to know about core as an option.

I'd even consider making CMS full width then make a small mention below about core for people that want to dig further.

Even though the CMS is highly emphasized, it is still making someone visiting make a decision that they probably don't need to make.

I think it's more related to: 🌱 [Discussion] Recommendation for dropping version numbers for external marketing of Drupal Active

Wireframe 2: I feel like this could use some kind of help text/tooltip. E.g. what does the blank canvas give you? Is it no theme installed? Is it nothing related to ... Is it just a theme you select or is it more? Or is it no theme at all, and just the layout you choose.

Other things I've noticed have already been said by others.

Re #10 I could see a full width layout where Drupal CMS is the main option, with a much smaller 'Or get drupal/core' underneath. Agreed that experienced Drupal users never go to this page anyway. People who are experienced developers but new to Drupal probably wouldn't hurt to have starshot as their 'first ever Drupal install' too, and can have other entry points to getting only core - they'll know what sort of things to look for to find it (or just read down).

#8.1 I think I agree with this.

Is the issue that the 'full site templates/recipes' are mutually exclusive and you can only select one?

The 'blank slate' option looks on the face of it sounds like the minimal profile, but I don't think we would want that at all? I assume we'd want the 'starshot default admin experience' but with a very minimal set of recipes. So not really a blank slate but more like 'standard+'.

This could possibly still be combined into a single page with two steps:

[ Pick a site template [radio-style selection] or [mix and match]]

[Individual recipes to customize blah blah [checkbox style selection]]

'mix and match' is a no-op but makes it clear you only get what you checkboxed.

It also seems possible (even likely?) that we won't have multiple site profiles even for a 1.0 release, which would mean it's only really possible to do the second page anyway.

I also think that the landing page should feature Drupal CMS only, rather than having two options presented. As catch suggested, there could be a link to Drupal core.

And I agree that wireframes #2 and #3 are somewhat redundant. (When we initially worked on #3, #2 didn't exist and was added later.) I would expect if you choose a specific flavour, you wouldn't expect to see another screen with options. But perhaps we need #3 only if 'Blank slate' (name TBC) is selected, to prompt the user to install something?

I agree that wireframes #2 and #3 are somewhat redundant. (When we initially worked on #3, #2 didn't exist and was added later.) I would think if you choose a specific flavour, you wouldn't expect to see another screen with options. But perhaps we need #3 only if 'Blank slate' (name TBC) is selected, to prompt the user to install something?

The thought behind wireframe #2 and #3 was that user gets to select a site template that is closest to what they are trying to accomplish with the site. This would select a theme as well as decide which recipes to present for the user as featured recipes. For example, if the user selects magazine as the site template, it could show an article recipe, reactions recipe, and comments recipe. This would provide the user more flexibility but it's unclear if the target persona sees value in being able to customize the starting point on this level.

The 'blank slate' option looks on the face of it sounds like the minimal profile, but I don't think we would want that at all? I assume we'd want the 'starshot default admin experience' but with a very minimal set of recipes. So not really a blank slate but more like 'standard+'.

It was intended to be a starting point which provides defaults beyond Standard, just like you're describing. Blank canvas might not be the best term for that.

The thought behind wireframe #2 and #3 was that user gets to select a site template that is closest to what they are trying to accomplish with the site

I think this could be done with a two row layout for wireframe #3 using the states API too.

Have 'Pick my own', 'Blog', 'Brochure' options at the top.

Depending on what's selected at the top, highlight different recipes underneath.

The big difference with that is people would be able to see what the consequences of picking the 'site template' level options are by what happens to the changes underneath. Currently the installer doesn't provide a 'back' button so with two pages we don't have a lot of opportunity to let people change their minds.

I think we are painting ourselves into a really problematic hole by adding the label "CMS" and bifurcating our product even further. Additional thoughts here on the related post: https://www.drupal.org/project/starshot/issues/3452281#comment-15634164 →

I think this issue should be blocked until a real decision on the final product name is made.

If Starshot launches as "Drupal CMS" then we will have all of these:

• Drupal CMS
• Drupal Core
• Drupal 7
• Drupal 10.2 (and 9, and 8 ofcourse)
• Next iteration of Drupal 11

Adding "Drupal CMS" to the mix just causes additional confusion and we really should be simplifying as a product.

If Starshot launches as "Drupal" that uses "Drupal Core" and "Legacy Drupal" is Drupal 7, then the story becomes so much easier to tell.

@ivanstegic

As a counterpoint I think the suggestion is that this would make the non developer facing name just Drupal CMS. All of the other names you mentioned would be developer focused which we would still need to maintain since we need to know versions.

Someone new to Drupal landing on this page would only see the product Drupal CMS, then maybe a small link underneath with core, not a side by side choice. (assuming that direction is taken)

@nicxvan you said "Someone new to Drupal landing on this page would only see the product Drupal CMS" and I think it's herein that lies the problem.

Someone new to this page should be introduced to "Drupal" and not to "Drupal CMS"

The name is a separate question with a separate issue for discussion. Ultimately the page will display whatever the name is, I don’t think it’s a blocker to working out the page layout and user flow.

I also don’t think Drupal 7 is relevant, it is not currently promoted and will be EOL shortly after Starshot launches. Drupal 8 and 9 are already not supported so I don’t feel that these should be considered at all.

FYI, the name discussion is happening here: #3452281: Decide on Starshot's product name →

And then there is also a discussion about using versions in the name like Drupal 7, 8,... 🌱 [Discussion] Recommendation for dropping version numbers for external marketing of Drupal Active

I think this could be done with a two row layout for wireframe #3 using the states API too.

Forgot to say, I like this idea. Mainly, I think it needs to be revisited in the context of making a top-level choice. But I also think I recall that the 'flavour' selection was unlikely to be in MVP -- so maybe we need to resolve that first.

In #3095736: Create content for Drupal's initial "Getting started" page (after minimal or standard profile installation) → we added some friendly welcoming content to people's first experience with Drupal (at least if they install the Standard profile). And I think something like this could fit well into the new installer experience. For example maybe a welcome message ("Congratulations and welcome to the Drupal community!"), a CTA to "join the community" and a link to resources for finding more help and relevant documentation could be included in the landing page / dashboard in wireframe #4.

This could act as both a way to recruit people into the community. And, as a way to reinforce that Drupal is backed by a large community and that when you "buy" Drupal you get access to that as well.

Considering that the "Drupal Installer CMS" involves a series of steps, should we:

1. Add a progress bar at the top of the page.
2. Display the current step number to help users easily see where they are in the setup process and how many steps are left.
3. Include a call-to-action (CTA) button to go back to the previous screen or step.

Thank you.

Thanks to everyone for their feedback! I am closing this issue since we are moving into the next stage, where we will create updated wireframes.

Automatically closed - issue fixed for 2 weeks with no activity.