Closed jeffchew closed 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:
—
List item text style is disabled-02
with info
tooltip on the left.
List item text style is disabled-02
with info
tooltip on the far-right, note the edge alignment.
List item text style is disabled-02
with info
tooltip on the right, slightly different position than above.
Both the text style and area is disabled
with no info
icon or tooltip.
Both the text style and area is disabled
but with a tooltip.
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.
On Aug 08, Wonil-Suh1 commented: One comment about the type scales, I wonder if this makes more sense:
Because the actions are pretty self evident at this point.
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.
If we look at the initial modal it also opens up with a prompt:
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.
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.
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.
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?
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.
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.
On Aug 08, Wonil-Suh1 commented: @james-dow interesting idea. will the two lists scroll together or are they two separate scrolling lists?
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.
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.
On Aug 12, larahanlon commented: Feedback from Friday 9 discussion (Wonil, Olivia, Lara)
32px
between the edge of modal and left-aligned text, 16px
between the edge of modal and card.link
for languages
in the list.Search
should be inset 32px
from the edge. Position above the list items.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.
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.
3.
The search
field is inset at 32px and aligns with all text and dividers.
— — —
I think option 1 is visually the most successful. I think our hover states can still hang 16px from the divider lines:
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.
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.
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.
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:
The other option could look like this, which is arguably neater but lacks some depth:
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.
On Aug 13, larahanlon commented:
👆I'd like to still vote for this option – option 1 with added 8px spacer and inset dividers – for the following reasons:
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
Brand Center
In our new masthead we inset
the dropdown divider lines but allow the hover to fill the width of the component:
L0 dropdown
Brand Center do the same (see above).
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
What if I'm trying to select Search
here but accidentally click the country-language behind the field?
Oops
Adding 8px and the drop shadow clearly separates the two clickable fields IMO:
—
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.
And the same applies to the rules - this is way closer to tables than dropdown menu.
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.
On Aug 16, hahnrob commented: Included in the Aug 16, 2019 sprint review meeting. Can be closed.
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