Icons overlapping idea title.

[asvinb]

Bug Description

When the browser is resized to 960px, upon hovering an idea, the icons are displayed on top of the idea name.

Steps to reproduce

1. Go to Site Kit dashboard
2. Scroll down to Idea Hub widget
3. Resize browser to 960px
4. Hover a suggested idea.
5. See error

Screenshots

Additional Context

• Browser: Chrome

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• For viewports where the Idea Hub widget appears in a narrow state (even if this viewport is technically not "mobile"), the buttons on each idea should appear below the idea rather than on the right of the idea, similar to how it is in the current mobile layout.

Implementation Brief

Using assets/js/modules/idea-hub/components/dashboard/DashboardIdeasWidget/Idea.js and assets/sass/components/idea-hub/_googlesitekit-idea-hub-dashboard-ideas-widget.scss:

• Replace the grid layout with normal divs:
  • Replace the <Grid> and <Cell> with <div>s with the same className attributes (.googlesitekit-idea-hub__idea--actions and .googlesitekit-idea-hub__idea--details respectively).
  • The <Row> can be replaced with a div with a suitable className (div.googlesitekit-idea-hub__idea--wrapper for example).
  • Remove any mdc-layout-grid-* CSS that is now redundant.
• Refactor the layout CSS:
  • For viewports below $bp-xlarge (1280), use a display: block-based layout, such that the .googlesitekit-idea-hub__idea--actions wraps underneath the .googlesitekit-idea-hub__idea--details.
  • For viewports above $bp-xlarge, switch to a flex-based layout, such that the two divs are inline
  • The media query which adds a display: none rule to the .googlesitekit-idea-hub__actions--delete, .googlesitekit-idea-hub__actions--pin and .googlesitekit-idea-hub__actions--unpin should be updated so that it applies to viewports above $bp-xlarge. This means that the action buttons are all visible when they wrap.
  • Similarly, the media query that applies justify-content: flex-end; to .googlesitekit-idea-hub__actions should be updated to apply to viewports above $bp-xlarge, so that the action buttons are left-aligned when they wrap.

Here is a gist:

	// Replace grid layout with normal divs
	return (
		<div className="googlesitekit-idea-hub__idea--single">
			<div className="example-css">
				<div className="googlesitekit-idea-hub__idea--details"> ... </div>
				<div className="googlesitekit-idea-hub__idea--actions"> ... </p>
			</div>
		</div>

@media (min-width: $bp-xlarge) {
	/* Use a flex layout above 1200 */
	.example-css {
		display: flex;
		padding: 12px 24px; /* use variables, this is just to illustrate */
		justify-content: space-between;
	}

	/* The following action buttons are hidden above 1200 */
	.googlesitekit-idea-hub__actions--delete,
	.googlesitekit-idea-hub__actions--pin,
	.googlesitekit-idea-hub__actions--unpin {
			display: none;
	}

	/* The  actions are right-aligned */
	.googlesitekit-idea-hub__idea--actions {
		justify-content: flex-end;
	}
}

And an example screenshot:

Below 1200	Above 1200

Test Coverage

• No new tests required.

Visual Regression Changes

• Images dealing with the Idea Hub Dashboard widget might need to be updated.

QA Brief

• Check that the icons in the Idea Hub dashboard widget does not overlap the text content across all breakpoints.

Changelog entry

• Ensure the icon buttons in the Idea Hub widget do not overlap idea labels.

[johnPhillips]

For viewports where the Idea Hub widget appears in a narrow state (even if this viewport is technically not "mobile"), the buttons on each idea should appear the same way as in the current mobile layout, below the idea rather than on the right of the idea.

@felixarntz The current layout uses MDC grid, which is based on media queries (as far as I can make out). In a sense, media queries are a bit redundant, because the widget can be 'mobile width' on a desktop viewport under the circumstances described (if alongside another widget).

So we need a way to activate the mobile layout based on the width of the widget rather than the viewport. The only way I can think of to do this is to scrap the MDC grid and get the content to overflow and wrap as the container shrinks? So the layout issue can be solved this way, with the buttons tucking under the idea content as the width decreases.

However, we have additional styles that kick in on mobile media queries that would be impossible to replicate in this way, for example the buttons are all visible on smaller viewports, whereas on desktop they are hidden unless you hover over them. I can't think of a way to have buttons hidden when they are inline but visible when they overflow. If only @container queries were available.

TD;DR I'm pretty sure we would need to make the buttons visible across all device widths to make this work. That's a pretty significant change to the design though, so I wanted to flag it to you before writing the IB.

In the example below I've tried to demo this, just for clarity.

• The first item is how it might look inside a wider widget, with everything on one line
• The second item is what it might look like when the widget gets narrower and wraps
• Note that the buttons are visible throughout because without media queries we can't have the buttons hidden on desktop and visible on mobile; they need to be visible all the time.

Worth checking with @asvinb too as his CSS skills are mightier than mine. Am I right in saying this?

[felixarntz]

@johnPhillips Thanks for the detailed insights - I may have phrased the ACs overly broadly, the main thing we should accomplish is indeed for the buttons to appear in their own line below the idea for these viewport sizes. They don't need to 100% match the exact styles used on mobile, the goal is to prevent the overlap.

[johnPhillips]

Just to explain the consensus I arrived at with @asvinb, @aaemnnosttv and @eugene-manuilov in a slack conversation:

• We should wrap the action buttons at a suitable breakpoint (Asvin suggested 1200)
• The action buttons should only be hidden when inline, as they look a bit strange if they are hidden when wrapped (see second idea in screenshot below):

I have updated the IB accordingly.

[tofumatt]

This works for me—thanks for the detailed discussion and reasoning behind the approach in the comments, it helped a lot! 👍🏻

IB ✅

[felixarntz]

@marrrmarrr @alex-moulin I pinged you on the PR for this #3920, can you share your thoughts there?

[eclarke1]

@felixarntz for this one, both @marrrmarrr and @alex-moulin have responded on #3920
@johnPhillips could this one potentially come back to you for Execution as Asvin is now away please? (To implement the suggestion from Alex?)

[aaemnnosttv]

@eclarke1 I don't think we can implement the suggested changes without more definition. Ideally we should establish some secondary ACs and design to work from in which case it might make more sense to address in a follow up issue. Cc: @felixarntz

[johnPhillips]

I've created a little demo of @alex-moulin's idea hidden menu idea here.

https://google.github.io/site-kit-wp/storybook/pull/3966/?path=/story/modules-idea-hub-widgets-dashboardideaswidget--ready

Smaller screen	Larger screen

Notes:

• Context: the original conversation was on this PR: Wrap icons when there is not enough space. #3920
• This is just to aid discussion and deals with the piece about hiding the menu. I think there is further discussion to be had around what happens when a create / pin / unpin etc operation takes place (see https://app.asana.com/0/1185360131189553/1200879239497113/f)
• I've disabled the actions for the sake of time, so clicking the buttons won't have any effect.

[felixarntz]

@johnPhillips Thanks, this works for me. Paging @marrrmarrr @alex-moulin to share their thoughts. It's somewhat urgent to make a decision here, is the above good to proceed? It's a rather drastic UI change of course, so I want to make sure we're all aligned.

[alex-moulin]

@johnPhillips @felixarntz this mock-up looks good to me.
If I could be picky then I would suggest we add a label next to each action on this menu as we got the space so users know exactly what's available to them.
cc. @marrrmarrr

[felixarntz]

@johnPhillips @alex-moulin After reviewing again with @marrrmarrr, we've decided to go back to the original scope of the issue here and not change the design significantly at this point - the small menu also has some issues, e.g. it requires extra clicks to access, and a menu of vertical icons feels odd, e.g. since there is now an additional icon among them to just close the menu.

At this point, something like the solution from #3839 (comment) is what we should go with.

In other words, let's now follow the original ACs on the issue and create a PR for that. @johnPhillips It's okay to remove the hover state for now so that the icons always show for both mobile and desktop. When the PR is testable / previewable (e.g. on Storybook), we can make a final decision (i.e. make sure to request review by @marrrmarrr and myself), but it seems to me that removing the hover effect is the appropriate solution here, also since it will unblock #3907.

[felixarntz]

@johnPhillips Actually 🤦 I forgot there already was a PR for this one. #3920 actually looks good to me as is when focused on purely the issue here. IMO we can move forward with that, unless there were outstanding problems? I know we still have the challenge of the hover state complicating #3907, but if it's for that, then we should discuss that part further in #3907 and keep it out of this issue here.

[felixarntz]

That escalated quickly! PR is merged 😆

[wpdarren]

QA Update: ✅

Verified that the icons in the Idea Hub dashboard widget does not overlap the text content across all breakpoints.

ih-1.mp4