johnpicozzi β credited artinruins β .
Great first steps. Here are my answers, thinking about it from a first-time user perspective:
- We should create a default newsletter title. Is there a Site Title that we can leverage to do this? Something simple like "[Site Title] Newsletter"
- "Yes, send occasional emails to me from this site." The block should be placed in the footer region.
- Confirmation message: "You are successfully subscribed to the [Site Title] Newsletter." Follow up question: Should we include a link to the Unsubscribe page in case someone signed up by mistake?
- Unsure how to answer this one. A new user likely is not thinking too much about various roles, and they are likely the sole owner/admin of a site. I would keep this ability on the Admin role unless it makes more sense to create a new role (but that feels more complicated than it needs to be)
Agree with the points above, especially the accessibility issues and overall size for desktop being too large. For mobile, the left and right margins are wildly inconsistent. Each section seems to have its own rules about how far away from the left and right viewport edges text content will be. The testimonial block is very narrow while others are wide and others are in between. More consistent spacing rules are needed.
A similar application of consistent top and bottom section padding should also be instituted. For example, under the Hero for mobile, the background pattern is not allowed to peek out, which looks like a mistake.
Thanks @ben.hamelin @jewelclark. From your sample code, I believe the contents of the alt tag are redundant. The title tag content on the button is descriptive enough that I don't think we need to describe the visual, which adds no additional information. Small thing, but let's not be overly verbose for the out-loud experience if we dont have to. Open to a conflicting view here.
@ben.hamelin I don't see anyone else mentioning this, but for an inclusive tooltip, it should use a button
element which inherently can have focus. A button does not indicate a new destination, which an anchor link does, so avoid the anchor approach.
The markup I would suggest would be along these lines: https://inclusive-components.design/tooltips-toggletips/#tooltipasprimar... but I am certainly open to ways in which the Drupal interface already approaches tooltip markup.
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.