Front end design review and discussion

Remember that the primary audience we are looking at initially are site builders and those new to Drupal who are looking to add functionality to a Drupal site. The advanced filtering will be geared more to those that need to do more specific searches.

As one of the maintainers of the Drupal Design System and Designer of Claro I can provide some review regarding integrity with those two things. Just hit me up once you'll need/want to have my input.

Project page display
#3246223: [Suggestion] Add two more action buttons to the project detail page for "Issues" and "File an issue about this project" actions

Here is what I am proposing for Phase I in the MVP (see #3247441):

FILTERS
I think in terms of filters down the left-hand column, it should just be categories. 54 is a lot, but nonetheless that list will always be kind of big, so we should consider whether or not we want that to be a single-select, or more like facets like it is now. Also, on mobile, what will it be? If it's a dropdown to start then maybe that helps with mobile.

Also, something to consider - the way search API works w/ facets is that we can hide categories for which no modules meet the existing search filter criteria (and even show the number of results after it, like "Education (56)"). This is useful for example with the default filter set of "recommended" or whatever - because then we don't want to show them a category which will bring them 0 results by clicking it.

THUMBAIL
Been calling this the "card" display (see #3240318), though I think it's not unreasonable to have a "list view" in MVP, as that's probably light work. For this we are suggestion just image (the first image that comes back from d.o; but need to decide on a default image/display for if a project has 0 images), title (linked to Drupal.org for phase 1), short description (truncated first sentence-ish of description from d.o), a shield icon if is covered by Drupal security team, and then a "download" or "install" button based on whether or not that module is already in the codebase. There's also a third possibility that the module's already been installed - which would do what? (grey button that just says "INSTALLED" ?)

I personally don't think we need to clutter the card with a status about "actively maintained" or whatever as long as we can show that in the criteria under the search (so they know it's an active filter). One reason I think for this is that that status is just defined by the maintainer, so I'm not 100% sure it's _super_ trustworthy. I also don't want to go down the rabbit hole of "everything that's filterable must now appear on the card," as it may then just keep adding clutter to the card.

PROJECT PAGE
I think we push this to phase 2. Part of what we'll want to look at, especially in site builder subcommittee, is the layout of the drupal.org page. We have an opportunity to look at these two things together.

SORTING
I think we should definitely have an exposed sort (see #3239477), and it will need a default, that is _maybe_ number of installs, but I do think we should have one. The ones I think we need are (and this includes some feedback from SBS), is popularity (number of active installs), relevance to the search keyword (if they search by keyword, those should necessarily be scored by keyword), alpha a-z (I am not sure if this is really useful, but it is probably expected?), and date of last release (I question this one also but it does appear on current d.o searches for projects).

RATING
definitely for phase 2.

ADVANCED FILTERING
Where I still have much confusion is how we're thinking about the "top" projects (or "recommended" or whatever), which is basically a predefined set of filters, and the advanced search. Previous UI had this on two separate tabs, but as it's just pre-selected filters (really) then maybe we want to just maybe literally have that display when you initially come to the page? I am having a hard time moving from one paradigm to the other, or understanding it in terms of the current mockups. I probably just need some clarification, or maybe we need to remove some things. (see #3240314 for info on what should be the recommended filter-set)

Since we don't think we can include core modules in MVP phase 1, we should have copy that explains that somewhere.

Another thought - it's possible that there could be two compatible releases for a particular project. Should we do two different cards show up and show the version, or should we show the two versions later? Should the Composer instructions mention that there are two versions (knowing this info dynamically) and providing two sets of instructions? If we're doing a real download and not instructions, which one would it pick, or how would you choose?

While we'll always need to continue to iterate on the design, we're past the high level of this issue and into more smaller tickets of specific usability improvements. Thanks everyone for their input!