Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design Explorations: Block Details #9

Closed
melchoyce opened this issue May 24, 2019 · 24 comments

Comments

Projects
None yet
9 participants
@melchoyce
Copy link
Collaborator

commented May 24, 2019

How do we give people enough information about blocks to make informed decisions?

@karmatosed karmatosed referenced this issue May 24, 2019

Closed

Design explorations #2

5 of 5 tasks complete
@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented May 24, 2019

Details

I have three ideas here:

  1. wp-admin style plugins details modal
  2. https://wordpress.org/plugins/ style
  3. Stay inside the block library for details
  4. No details at all, go straight from search results to previewing in-context

Some questions:

  • The wp-admin version would be completely reusing the existing plugins architecture, so that's a plus — but it also kind of sucks compared to the details screens on .org, which feels much more modern and open and overall feels more organized and easier to scan. Which do we think is more important here, and if we went with the .org version, could we simultaneously update the core version? cc @tellyworth
  • Do we need to show the block banner, or is an icon sufficient?
  • Do we want to open details in a new modal at all, or keep everything in the block library?
  • Do we want to even show details?
@TimothyBJacobs

This comment has been minimized.

Copy link

commented May 29, 2019

Personally, I'm a fan of option 3. I'm not 100% sure why, but I think its because it'd encourage "simpler" details. I don't think a block should have the same level of details that an entire plugin would.

@mathetos

This comment has been minimized.

Copy link

commented May 29, 2019

Sorry in advance for the notification spam, but gotta give a shout out to "Rock your Blocks Off". Nicely done.

@boemedia

This comment has been minimized.

Copy link

commented May 29, 2019

I'd prefer to go for 2 or 3, since those have tags in them. It would be nice to be able to explore from there too. Although it's hard to guess what information one searching already has.
I also haven't been looking at what info is given in the cards that appear after search, so it kind of depends on that too.

@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented May 29, 2019

@TimothyBJacobs In your ideal world, what details would we restrict blocks to?

@boemedia:

It would be nice to be able to explore from there too. Although it's hard to guess what information one searching already has.

I think we can definitely explore that in future iterations on the block library.

I also haven't been looking at what info is given in the cards that appear after search, so it kind of depends on that too.

I'm envisioning the block cards would match plugin cards.

@kjellr

This comment has been minimized.

Copy link

commented May 29, 2019

I lean towards something more like 3 personally, as I frequently have to sort through way more information than I need on the WP.org plugin screens. I'm usually looking for two simple things:

  • Does this do what I want?
  • Does it have decent reviews and usage numbers?

For people who need more detailed information, it'd be cool to allow them to click into a more detailed screen from the small preview:

Screen Shot 2019-05-29 at 11 49 08 AM

@TimothyBJacobs

This comment has been minimized.

Copy link

commented May 29, 2019

@TimothyBJacobs In your ideal world, what details would we restrict blocks to?

I think a description, screenshots, author, rating and last updated. I think tags is probably duplicated by the keywords when registering a block. Maybe limiting the description length as well.

@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented May 31, 2019

Bunch of alternate ideas:

Details-2

@kjellr

This comment has been minimized.

Copy link

commented May 31, 2019

This one seems clear and well-organized to me:

Screen Shot 2019-05-31 at 3 36 11 PM

One minor suggestion: We could change "Last Updated: 2 weeks ago" to just "Updated 2 weeks ago" to save on a little space.

Also, would it make sense to put the buttons at the bottom of the view instead of the top?

@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented May 31, 2019

I was using existing strings:

image

We could try to update the string everywhere, though.

Only problem with that version is what happens if a block has a really long name/author:

image

Also, would it make sense to put the buttons at the bottom of the view instead of the top?

We've had issues previously putting actions on the bottom — people using keyboards would need to navigate through the description (which could scroll, because the library popover is a fixed height) to get to the actions. @bemdesign-er / @LukePettway could we get your thoughts on this?

@bemdesign-er

This comment has been minimized.

Copy link

commented Jun 1, 2019

I feel that the action buttons will need to occur after the description. Yes, it means users have to "tab" through to get there, but... I don't think that's too much of a problem - most users will want to read the description before installing the plugin. We can provide an affordance to keyboard/AT users who don't want/need to read the full description by a "skip-to-actions" link before the description. Yes it adds an additional "tab" stop - but it provides a quick way to move past the description area and into the "actions" for users who really don't need or want to read the full description. Let me know if that makes sense or if you have any other questions.

@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 1, 2019

Thanks @bemdesign-er! Would something like this end up being okay?

image

@bemdesign-er

This comment has been minimized.

Copy link

commented Jun 2, 2019

I think this is ok.

@sarahmonster

This comment has been minimized.

Copy link
Member

commented Jun 3, 2019

Definitely 3 feels like the right approach here. Some people will want more details prior to "committing" to a block, but the options for 1 and 2 feel super overwhelming. Nobody needs that much information.

Do we need to show the block banner, or is an icon sufficient?

A picture of the rendered block would probably be super helpful. If that's what a block banner would comprise, then yet. If it's just a shiny unrelated picture, then probably no.

Do we want to open details in a new modal at all, or keep everything in the block library?

The current design-leaning-toward (which I think is staying in the block library?) makes sense—it's all part of the same flow, and being able to navigate through this flow all from one view seems sensible, especially when you're providing back links and links to install directly. 👍

Do we want to even show details?
Yes! Some people will want them. But let's pare it down to the most useful and relevant details. Or wait, if you mean more details after this "more details" screen, then no. This is sufficient information to make a decision.

The layout with the star rating and update details below the author is the easiest to parse. (As a bonus, we can totally nix the "Description" heading unless it's helpful for accessibility reasons, which may not be required if we provide a skip-link? But I'm not exactly sure.)

@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 3, 2019

Thanks @bemdesign-er and @sarahmonster! I'll make these updates in the higher fidelity version I'm working on in Figma next: https://www.figma.com/file/QKhoOKXkBN2mHacqvrtdNuI6/Gutenberg-Block-Library-Installation?node-id=2%3A15

@bemdesign-er

This comment has been minimized.

Copy link

commented Jun 4, 2019

As far as the description header, I would keep it. Heading levels help denote different sections of content and help assistive technology users navigate through the content. Feel free to style the heading to be more like a bolder version of the description text if it makes sense for spacing or layout reasons. An <h3> doesn't have to "look" like an <h3>! All that being said, do be careful to not overdo it - if markup styling starts to depart too radically from expected norms, users can get confused.

@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 4, 2019

image

@LukePettway

This comment has been minimized.

Copy link

commented Jun 5, 2019

I agree with @bemdesign-er having them after is fine. If someone is using tab shift focus, assuming there are no focusable elements within the description, it shouldn't require much effort to get past the main content and to the action buttons.

@melchoyce

This comment has been minimized.

Copy link
Collaborator Author

commented Jun 7, 2019

@LukePettway @bemdesign-er:

Double-checking since I'm looking at rearranging the popover again — between these two options, is the second one better for keyboard users?

image

@afercia

This comment has been minimized.

Copy link

commented Jun 12, 2019

Thanks everyone for the explorations here 🙂 just a question: based on previous conversations, I thought it was decided to always have the primary button on the left. Recently, we also have moved some buttons from the right to the left to meet this (supposed) new, established, pattern.

Not arguing: whatever the decision is that will be fine. I'd just like to have consistency across the admin, where at the moment the primary button position is very inconsistent.

I'd greatly appreciate the design team to establish (and document) a pattern that from now on should be used everywhere: left or right, please let us know 🙂

References to previous tickets / discussions on this topic:
https://core.trac.wordpress.org/ticket/40822
https://core.trac.wordpress.org/ticket/40822#comment:9
https://core.trac.wordpress.org/ticket/40822#comment:10
https://wordpress.slack.com/archives/C02S78ZAL/p1554138401066300
https://core.trac.wordpress.org/ticket/46758
https://core.trac.wordpress.org/ticket/45972
https://core.trac.wordpress.org/ticket/43412
https://core.trac.wordpress.org/changeset/40655
https://core.trac.wordpress.org/ticket/9777

@LukePettway

This comment has been minimized.

Copy link

commented Jun 12, 2019

@melchoyce As far as keyboard accessibility is concerned, as long as the content itself is linearized, the button placement isn't going to really matter so either design is fine. Where it would be a problem is if a user had to go through the the content area before they could interact with the primary button.

@kjellr

This comment has been minimized.

Copy link

commented Jun 12, 2019

Just a question: based on previous conversations, I thought it was decided to always have the primary button on the left. Recently, we also have moved some buttons from the right to the left to meet this (supposed) new, established, pattern.

👋 Thanks for noting that, @afercia. I know Mel prepared a number of alternate positions for the buttons there. These are from the Figma doc:

Screen Shot 2019-06-12 at 6 32 37 AM

Because these buttons exist in a small, dialog-like overlay, I think it feels appropriate to follow the guidelines for modal buttons, which depict right-aligned buttons. In a smaller area like this, right-aligned buttons help guide the eye over the full content. That works well in this case, but wouldn't in the context of a WP-Admin page where the content spans the full width of the page (for example). In that case, the buttons end up being too far away from the content.

I'd like to see some guidelines too — this seems like something that could be added to the Button component documentation.

@sarahmonster

This comment has been minimized.

Copy link
Member

commented Jun 12, 2019

Since this button placement issue keeps coming up, I've opened a new ticket to discuss establishing clear guidelines for placement: WordPress/gutenberg#16123

@afercia

This comment has been minimized.

Copy link

commented Jun 12, 2019

@kjellr thanks for adding more details 🙂

However, I'm not referring to the position of the buttons group. As long as buttons are grouped, they can be placed on the left, center, right, depending on the context.

Instead, I'm referring to the position of the primary button (the primary action one) compared to the other buttons within the group.

A while ago, it was agreed (see references above) that the primary button should always come first within the group, that is: on the left in LTR and on the right on RTL 🙂 First.

Whatever the decision will be, I'm more interested in consistency and make a decision once and forever on the primary button position 🙂 After that, we should consolidate the pattern across all the admin. Thanks!

@melchoyce melchoyce closed this Jul 9, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.