carbon-design-system / carbon-for-ibm-dotcom

Carbon for IBM.com is based on the Carbon Design System for IBM
https://www.ibm.com/standards/carbon/
Apache License 2.0
269 stars 156 forks source link

Locale selector: Finalize design & obtain approval #279

Closed jeffchew closed 5 years ago

jeffchew commented 5 years ago

Wonil-Suh1 created the following on Jul 15:

This issue is for the approval process for the locale selector final design.

Acceptance criteria

Original issue: https://github.ibm.com/webstandards/digital-design/issues/1230

jeffchew commented 5 years ago

On Aug 08, larahanlon commented: Making some suggestions for locale selector behaviors/motion. @james-dow this is just to get started. Please take a look at this PDF for notes.

Sketch file is here.

jeffchew commented 5 years ago

On Aug 08, larahanlon commented: Hey @Wonil-Suh1 @Olivia-Flory @james-dow

I'm looking for your feedback on these explorations for country-language pages that are unavailable. Which do you think is most successful, considering user interaction + layout + component usage:

  1. List item text style is disabled-02 with info tooltip on the left.

    disabled-1-left-tooltip
  2. List item text style is disabled-02 with info tooltip on the far-right, note the edge alignment.

    disabled-2-right-tooltip
  3. List item text style is disabled-02 with info tooltip on the right, slightly different position than above.

    disabled-3-right2
  4. Both the text style and area is disabled with no info icon or tooltip.

    disabled-4-disabled
  5. Both the text style and area is disabled but with a tooltip.

    disabled-5-disabled-tooltip
jeffchew commented 5 years ago

On Aug 08, Wonil-Suh1 commented: Thank you @larahanlon. Should the icons be gray as well, and turn dark on hover?

I lean towards the last option where there is no icon, I feel that it has a fairly good affordance.

jeffchew commented 5 years ago

On Aug 08, Wonil-Suh1 commented: One comment about the type scales, I wonder if this makes more sense:

  1. The region is the top heading
  2. "Choose your language" is smaller and secondary text color

Because the actions are pretty self evident at this point.

  1. The call to action and the search field is attached to the list

screen shot 2019-08-08 at 11 05 25 am

jeffchew commented 5 years ago

On Aug 08, larahanlon commented: Cool thanks @Wonil-Suh1 I agree with the disabled + tooltip option.

RE: type scales. I considered this in earlier studies but after exploring I don't think it makes logical sense in the overall flow: In the region selector step, the large text prompts an action. If we change the text scale in the following screen then the larger text becomes a label/title rather than a prompt.

screen shot 2019-08-08 at 11 17 55 am

If we look at the initial modal it also opens up with a prompt:

screen shot 2019-08-08 at 11 24 24 am

Although connecting Choose your country-language and Search field makes a lot of sense, my thought is to keep the type scales consistent with the purpose of the message.

jeffchew commented 5 years ago

On Aug 08, Wonil-Suh1 commented: Yep, I understood why you designed that way. But another way to look at this is that "Europe" is the region you selected - it directly corresponds to the prompt on the first screen. I'm not sure if presenting "Europe" as a small heading makes sense.

jeffchew commented 5 years ago

On Aug 08, james-dow commented: Is there a reason we aren't just hiding the ones we don't have translations for? Or maybe if we still want to show them group at the bottom of everything with a label "unavailable" or something. I like the cleanliness of not having the info icon, but I can see the tooltip getting on my nerves as I scroll and try to read things.

jeffchew commented 5 years ago

On Aug 08, Wonil-Suh1 commented: @james-dow that's a good point - the tooltip popping up on every unavailable entry will be annoying. then how about grayed out info icon that turns darker on hover?

jeffchew commented 5 years ago

On Aug 08, larahanlon commented: Yep you're right @james-dow it would be so annoying. My understanding is that we need to show the country-language even if the page is unavailable (because there may be other pages in that country-language). Grouping them at the bottom is a good suggestion. The grayed-out icon may also help to solve.

I'd like to do an A/B test of the locale selector in general (there are many alternative solutions for similar moments) so we could include two options for the disabled view in that.

jeffchew commented 5 years ago

On Aug 08, james-dow commented: Quickly threw this together in reference to the grouping comment above. Just another way to think about it. Also, we might could explore in the future having a link to request an unavailable translation.

image

jeffchew commented 5 years ago

On Aug 08, Wonil-Suh1 commented: @james-dow interesting idea. will the two lists scroll together or are they two separate scrolling lists?

jeffchew commented 5 years ago

On Aug 08, james-dow commented: Oh, I would think a single scroll. Two probably would be way too much. The list of unavailable grouped at the bottom would be getting them out of the way so people can quickly select from what's available, and yet still find the list of unavailable if necessary.

jeffchew commented 5 years ago

On Aug 08, Olivia-Flory commented: You could consider only showing the tooltip upon hover of the icon vs the entire country name, I think people are pretty used to having to hover over the info icon.

I also prefer options 2 and 3 where the icon is on the left and doesn't alter the alignment of the type, I feel option 1 is more difficult to scan because the icon is left aligned and indents the disabled fields.

Did you consider moving the info icon to the right of either the country or language? I had left the info icon at 16px for tooltip in our theme because it is a secondary/functional item.

jeffchew commented 5 years ago

On Aug 12, larahanlon commented: Feedback from Friday 9 discussion (Wonil, Olivia, Lara)

jeffchew commented 5 years ago

On Aug 12, larahanlon commented: @Wonil-Suh1 @Olivia-Flory

Question about alignment of search and country-language list. Which of the following looks better / fits with our overall system approach?

1. The search field hangs 16px over left and right. The search icon aligns with the rest of the text in the modal. The horizontal dividers between country-language is inset at 32px and aligns with the text.

screen shot 2019-08-12 at 3 27 36 pm

2. The search field hangs 16px over left and right. The search icon aligns with the rest of the text in the modal. The horizontal dividers between country-language also hang 16px left and right and does not align with the text.

screen shot 2019-08-12 at 3 28 02 pm

3. The search field is inset at 32px and aligns with all text and dividers.

screen shot 2019-08-12 at 3 27 47 pm

— — —

I think option 1 is visually the most successful. I think our hover states can still hang 16px from the divider lines:

screen shot 2019-08-12 at 3 28 15 pm
jeffchew commented 5 years ago

On Aug 12, Olivia-Flory commented: Initially, I lean towards 3 because we talked about search+icon being inset with the rest of the content. But I think 1 could work too, and Carbon seems to overhang search on their icon library page. I tried to find examples on Wake of aligning to the columns vs overhang and couldn't find much.

Something about 2 feels a bit off, for whatever reason the horizontal rules feel too tight.

jeffchew commented 5 years ago

On Aug 13, Wonil-Suh1 commented: Hmmm, in 3, the search field feels small - i know it's an optical illusion, but it does impact the overall visual balance to me. For that reason I lean towards 1 or 2. One potential issue with 1 might be that as the list scrolls, that the inset rules do not align with the search field may become visible, and for this reason I lean towards option 2. The hover state in 1 and 3 feels awkward.

All things considered, option 2 feel the right way to go.

jeffchew commented 5 years ago

On Aug 13, Wonil-Suh1 commented: One thing - i feel that the space between the top row and the search field should not be there - repeating 48px through out may simplify the layout further.

screen shot 2019-08-12 at 9 26 30 pm

jeffchew commented 5 years ago

On Aug 13, larahanlon commented: Thanks! @Wonil-Suh1 @Olivia-Flory

@Wonil-Suh1 that extra 8px space below the search was intentional to show one way that we could visualize the scroll-behind:

screen shot 2019-08-12 at 9 30 12 pm

The other option could look like this, which is arguably neater but lacks some depth:

screen shot 2019-08-12 at 9 30 27 pm
jeffchew commented 5 years ago

On Aug 13, Wonil-Suh1 commented: I lean towards the second option where the search touches the list — being essential. and that does create a bit of a delightful moment too, AND aligned very well with the concept of IBM.com as a platform.

jeffchew commented 5 years ago

On Aug 13, larahanlon commented:

screen shot 2019-08-13 at 5 30 03 pm

👆I'd like to still vote for this option – option 1 with added 8px spacer and inset dividers – for the following reasons:

1. 8px spacer is common across IDL/Carbon nav components.

So if we look at the left-nav panel, 8px (or 16px) is used to separate either different nav components or sub-menu items:

Carbon

screen shot 2019-08-13 at 5 24 37 pm

Brand Center

screen shot 2019-08-13 at 4 58 55 pm

2. Masthead alignment

In our new masthead we inset the dropdown divider lines but allow the hover to fill the width of the component:

L0 dropdown

screen shot 2019-08-13 at 5 04 11 pm

Brand Center do the same (see above).

3. Readability

I worry that there isn't enough delineation between the Search text field and the list item that could be scrolling behind. Maybe the drop shadow will be enough but I'm not 100% convinced:

Search and Botswana are competing here

screen shot 2019-08-13 at 5 02 01 pm

4. Interaction / safe zone

What if I'm trying to select Search here but accidentally click the country-language behind the field?

Oops

screen shot 2019-08-13 at 5 01 47 pm

Adding 8px and the drop shadow clearly separates the two clickable fields IMO:

screen shot 2019-08-13 at 5 02 27 pm

jeffchew commented 5 years ago

On Aug 13, Wonil-Suh1 commented: I see what you are talking about, but in this case I feel that it's very similar to data table UX model where the tool is attached to the content.

screen shot 2019-08-13 at 5 35 29 pm

And the same applies to the rules - this is way closer to tables than dropdown menu. screen shot 2019-08-13 at 5 40 23 pm

Also considering the impact on the overall layout, I feel that overhanging rules actually simplify the overall look and feel better than two different widths mixing with each other.

jeffchew commented 5 years ago

On Aug 16, hahnrob commented: Included in the Aug 16, 2019 sprint review meeting. Can be closed.