Page MenuHomePhabricator

Compare the contents: Adjust scrollable and sticky areas
Closed, ResolvedPublic

Description

As part of the "Compare the contents before translating" step (T241589) of the Section Translation workflow, a sticky header lets the user scroll through the contents while the options to switch between source and target can be used:

Compare contents - Sticky header.png (768×1 px, 192 KB)

Currently, when testing an example translation on the test servers the tabs for source and target contents get hidden when scrolling:

Screenshot 2020-08-03 at 12.39.37.png (1×993 px, 250 KB)

Event Timeline

Pginer-WMF triaged this task as Medium priority.
Pginer-WMF created this task.

Change 623620 had a related patch set uploaded (by Nik Gkountas; owner: Nik Gkountas):
[mediawiki/extensions/ContentTranslation@master] SXContentComparator: Make content header sticky on scroll

https://gerrit.wikimedia.org/r/623620

Change 623620 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] SXContentComparator: Make content header sticky on scroll

https://gerrit.wikimedia.org/r/623620

I've noticed some discrepancies with the spec:

  • The two rows of the sticky header appear in reverse order. In the spec, title appears on top and the tabs appear below. In the implementation, the tabs appear on top.
  • The style of the tab component needs adjustments. The spec uses elements left aligned with some padding around them and blue is not used (more details below). If this adjustment requires significant effort, a separate ticket can be created.
SpecImplementation
Compare contents - Sticky header.png (492×375 px, 85 KB)
Screenshot 2020-09-18 at 11.04.14.png (813×566 px, 260 KB)

Source and target selector:

Compare contents - Source and Target.png (768×1 px, 105 KB)
Compare contents - Source and Target Dimensions.png (768×1 px, 65 KB)

Change 630381 had a related patch set uploaded (by Nik Gkountas; owner: Nik Gkountas):
[mediawiki/extensions/ContentTranslation@master] SXContentComparator: Fix source/target selector button UI glitches

https://gerrit.wikimedia.org/r/630381

@Pginer-WMF About the style for this tabs, do you see this as a tab UI component pattern or a new UI pattern? In dashboard, we have similar tabs(suggestions, published, in draft). Do you think those tabs and this should use different styling and UX? Asking this because, the Vue component need to be designed for that pattern. The way @ngkountas attempted to solve this is by reimplementing the tab component just for this screen. Is there a logic behind using #222 for highlighting pattern deviating from OOUI style

image.png (77×505 px, 6 KB)
image.png (47×209 px, 1 KB)

@Pginer-WMF About the style for this tabs, do you see this as a tab UI component pattern or a new UI pattern?

I see this as a tab UI component. In this case the tabs are shown inside a grey panel to emphasize the separation of the contents (the general content on top from the affected by the tab at the bottom).

In dashboard, we have similar tabs(suggestions, published, in draft). Do you think those tabs and this should use different styling and UX?

Well, I don't see those int he dashboard as tabs. The proposal for the dashboard is to have a navigation bar (at the bottom) on mobile and toggle buttons (same as we have now) on desktop. The tab component may not work well for cases where there is more than one list (suggestions + for later, for example).

Is there a logic behind using #222 for highlighting pattern deviating from OOUI style

The tab component has not been standardized in the styleguide yet. One drawback of the OOUI implementation is that blue is often used for elements you can click on, so it seems to suggest that you can click on the active tab while not on the others (while tabs work exactly the opposite way).

What I proposed is more aligned with the tabs for advanced editing created recently on mobile, which I think they align better with the style guide principles (see "article" and "talk" tabs below):

Screenshot 2020-09-28 at 11.27.20.png (641×500 px, 114 KB)

We use blue for both accent and interaction. These behaviors are often aligned and using the same color keeps things simple, but tabs are an exception where the element needing the accent is different from those providing the action to switch.

Got it. So can't this be solved if the default UI of tab in our vue UI library follow grey underlines instead of following OOUI style? @ngkountas If we do that, then we don't need customizations right? The tabs we have in desktop dashboard will also follow the grey underline style.

Got it. So can't this be solved if the default UI of tab in our vue UI library follow grey underlines instead of following OOUI style? @ngkountas If we do that, then we don't need customizations right? The tabs we have in desktop dashboard will also follow the grey underline style.

@santhosh I think that there are three important differences between our current tab UI component and the desired one (at least for this case):

  1. The color that you have already discussed
  2. Text alignment: current implementation aligns text in center while specifications require left alignment for these elements.
  3. Width of active indicator (highlighting line of active tab)

I'm not sure how we can overcome these discrepancies too and if it's ok to set these styles as defaults in our vue UI library component, as well.

Got it. So can't this be solved if the default UI of tab in our vue UI library follow grey underlines instead of following OOUI style? @ngkountas If we do that, then we don't need customizations right? The tabs we have in desktop dashboard will also follow the grey underline style.

@santhosh I think that there are three important differences between our current tab UI component and the desired one (at least for this case):

Our library component should match this design.

  1. The color that you have already discussed

Let us change the tab hightlight color in UI library as that is supposed to match design spec.

  1. Text alignment: current implementation aligns text in center while specifications require left alignment for these elements.

Let us change the alignment to left

  1. Width of active indicator (highlighting line of active tab)

Let us change the width of tab hightlight color in UI library

I'm not sure how we can overcome these discrepancies too and if it's ok to set these styles as defaults in our vue UI library component, as well.

Meanwhile, any help in documenting this UX pattern in design guide is highly appreciated @Pginer-WMF, may be as part of T260239: Finalize Design Style Guide's “Components” section

Change 635006 had a related patch set uploaded (by Nik Gkountas; owner: Nik Gkountas):
[mediawiki/extensions/ContentTranslation@master] SX Content Comparator: Fix sticky header elements order

https://gerrit.wikimedia.org/r/635006

Change 635006 merged by jenkins-bot:
[mediawiki/extensions/ContentTranslation@master] SX Content Comparator: Fix sticky header elements order

https://gerrit.wikimedia.org/r/635006