Page MenuHomePhabricator

Visual changes to add descriptions
Closed, ResolvedPublic

Description

Add description(s) flow

👉 Visual changes to add descriptions | T217169 on Zeplin

  • Bases almost completely on the “Translate description(s)“ flow (T217170)
  • Does not display a language dropdown to switch languages (also if multiple languages have been set in the app). It always uses the app’s primary language.
  • Derived from T194327 @cooltey:
  • To help users in deciding to add a description for a specific card, don’t show the placeholder image when there’s no “real“ article image. Instead, show more of the article text.
  • Slight variations in labelling:
    • “Add translation in %language%“ --> Add description
    • “Translated by you“ --> “Added by you“
  • Landscape: Check out the design on Zeplin. When there’s no article image, the available space should be used to display the extract.

Event Timeline

Charlotte renamed this task from Visual changes to add descriptions flow to Visual changes to add descriptions.Feb 26 2019, 6:48 PM

Derived from T194327 @cooltey:
To help users in deciding to add/translate a description for a specific card, please remove the placeholder image from this screen when there’s no “real“ article image. Instead, show more of the article text.

scblr updated the task description. (Show Details)

Hi @schoenbaechler. I have questions about the undo and redo buttons that besides the dice button.

Do they appear only after the action of adding description was done? Could you please describe in detail about how the flow goes, thank you!

What I understand now from the flow chart shows below, please correct me if I am wrong.

  1. Pick an article to add a description, for example United States
  2. After completing the action of adding a description to the United States, the user will see a new card, for example, Taiwan. In the meantime, the undo button will appear.
  3. Press on the undo button, will bring the user back to the United States card. In the meantime, the redo button will appear and the undo button disappeared.
  4. Press on the redo button, will bring the user to the Taiwan card, and the undo button will appear, and has the same steps on 2.
  5. Press on the dice button, will show a new card, for example, Japan, and the undo, redo buttons disappeared.

You got it almost right @cooltey. Think of the buttons more as back and forward rather than undo and redo. But let’s simplify the concept even further and align with the “Randomizer“ feature that is already existing in the app.

  • Remove the forward button completely from the interface
  • The back button is always visible
    • When it’s disabled (not tappable), it’s deemphasized in #000000 12% opacity.
    • When it’s active (tappabble), its color changes to #000000 38% opacity.
  • Tapping the shuffle button (dice) presents a new, random card that is missing a description

Further clarifications:

Let’s say you enter the “Add descriptions“ feed for the first time today. You’ll see the United States card. You don’t want to add a description to that card, so you’ll press the shuffle button. A new card is presented (Taiwan). That’s when the back button becomes active and changes to #000000 38% opacity.

You still see the Taiwan card, but then you change your mind. Now you want to add a description to card that has been shown before (United States). You’ll press the back button and you’ll see the United States card again. That’s when the back button changes to disabled state and #000000 12% opacity. Tapping the dice or swiping the card left in this situation would show you the Taiwan card again.

Ok, now you’re adding a description to the United States card. After you successfully added a description to the card. You get back to the “Add description“ feed. Since you have been navigating through the card stack before, the card you’ll see now is the foremost - the Taiwan card. If, let’s say you decide to add a description to the Taiwan card and you successfully do that, you’ll see a new random card in the feed.

Updated the screens to reflect these changes. Happy to jump on a call tonight to discuss it.


To answer your question:

Do they appear only after the action of adding description was done? Could you please describe in detail about how the flow goes, thank you!

No, the back button also appears when you shuffle the card stack for the first time.

Thanks for such detailed information, @schoenbaechler! Will follow the new design and flows you've mentioned. :)

Hi @schoenbaechler, could you please provide the SVG file of the icon in the snackbar (the little circle one), thanks!
https://app.zeplin.io/project/57a120b91998d8977642a238/screen/5c77d80a7c9eb3bc84b26d91

Hey @cooltey, you should be able to export the SVG from that Zeplin screen now.

Hi @schoenbaechler, I should have check this earlier, my bad.

When working on the work of adding the icon into the Snackbar, I checked the material design Snackbar page and looks like it does not recommend to add an icon into the Snackbar.

From the page:

Don’t place icons in Snackbars. If your message needs an icon, consider using an alert.

Also, the native Snackbar component does not allow to add an icon. If we really want to do it, we will need to create a custom layout and replace the original layout, which is not recommended.

BTW, the new style of a Snackbar will contain margins and also with rounded corners.

Screenshot_1552428998.png (2×1 px, 288 KB)

Good catch @cooltey. I agree with you, let’s go with the recommendation and not use an icon. Updated the screens on Zeplin and Overflow to represent this.

BTW, the new style of a Snackbar will contain margins and also with rounded corners.

Ok, I feel like we’re not hip anymore if we don’t go with it 😂 So there’s no choice, let’s go all in with rounded!

Thanks @cooltey, it feels great to just tap the card to add a description!

Below the issues I experienced:


Add descriptions screen

01 Article text is cut off sometimes:

Screenshot_20190325-133337.png (2×1 px, 438 KB)
Screenshot_20190325-154012.png (2×1 px, 947 KB)

02 According to T217444#5023826 and design specs, please remove the preview of the next card:

Screenshot_20190325-133624.png (2×1 px, 1 MB)

03 Remove the language dropdown, according to this task’s description:

Does not display a language dropdown to switch languages (also if multiple languages have been set in the app). It always uses the app’s primary language.

Screenshot_20190325-133828.png (2×1 px, 179 KB)

04 Incorrect article title line-height. Correct definitions: font-size: 24px; line-height: 32px; respectively line-height: 1.333333em;

Screenshot_20190325-140558.png (2×1 px, 177 KB)
.

05 Remove image border-bottom:

Screenshot_20190325-142057.png (2×1 px, 284 KB)

06 Different margins and line-heights than specified, see screenshot (design vs implementation) for comparison:

image.png (1×2 px, 2 MB)

07 Show more of the article’s text when available (such as in this example):

Screenshot_20190325-143757.png (2×1 px, 155 KB)

08 UI does not adapt in landscape mode, here’s a screenshot from “Randomizer“, as reference:

Screenshot_20190325-144425.png (1×2 px, 735 KB)

09 RTL – the card’s content should be right aligned, e.g. when the app language is set to Arabic (check the T217170 | RTL flow screens on Zeplin for reference)

Screenshot_20190325-144936.png (2×1 px, 646 KB)

10 Space from card to dice should be 48dp (it’s currently ~ 62dp)

image.png (388×902 px, 46 KB)


Add description screen

11 Copy should say “Add description“ not “Add title description“

Screenshot_20190325-144813.png (2×1 px, 83 KB)

12 RTL: Article content and interface elements should be right aligned, see demo screen on Zeplin:

Screenshot_20190325-145750.png (2×1 px, 81 KB)

13 Input field needs to be active so the keyboard is shown when users arrive on this screen to accelerate the editing flow. Plus, caps should be on when users start typing:

Screenshot_20190325-150225.png (2×1 px, 170 KB)

14 Can we show more text and less images here? (--> Reference screen on Zeplin)

Screenshot_20190325-150559.png (2×1 px, 533 KB)

15 Whole element needs to be tappable (not only “read")

Screenshot_20190325-150203.png (2×1 px, 148 KB)

16 Remove placeholder image and left align article title

Screenshot_20190325-145750.png (2×1 px, 131 KB)

17 Use correct font-definitions (font-family: 'Droid Serif'; font-size: 14px; line-height: 20px;) in bottom sheet:

Screenshot_20190325-144813.png (2×1 px, 122 KB)

18 Use Roboto 12px Medium instead of Regular here:

Screenshot_20190325-152029.png (2×1 px, 125 KB)

19 Minor spacing issues, see design vs implementation comparison:

image.png (484×2 px, 165 KB)

20 Can we use material_theme_secondary_color for "READ", I noticed it’s too prominent and needs to be de-emphasized:

Screenshot_20190325-153340.png (2×1 px, 160 KB)


Is the format like this ok @cooltey? Would you rather prefer a different “issue report“ style?

CC: @Sharvaniharan

Thanks for the review, @schoenbaechler, and Yes, the format looks great to me!

08 UI does not adapt in landscape mode, here’s a screenshot from “Randomizer“, as reference:

I remember that we are not focusing the landscape mode at this time, or should I unlock it? cc @Charlotte

The landscape should have a different layout due to the language bar (From: and To:), and it will affect the entire screen that does need a design to rearrange the rest of the items.

Thanks @cooltey, just FYI, that screen is currently the only one within the “Suggested edits“ feature that has landscape mode disabled in the Alpha.

@schoenbaechler

07 Show more of the article’s text when available (such as in this example):

The app gets the article's summary text from the Page Summary API, which means that we cannot control the length (amount) of the text, and that's why some articles might have less text than others.

14 Can we show more text and less images here? (--> Reference screen on Zeplin)

Same from the comments above, but we still can setup a parameter to disable images from the screen. Just a reminder that we use this standard preview dialog everywhere in the app.

@cooltey:

The app gets the article's summary text from the Page Summary API, which means that we cannot control the length (amount) of the text, and that's why some articles might have less text than others.

Ok, @Sharvaniharan just mentioned this to me as well. The current situation ...

Screenshot_20190325-143757.png (2×1 px, 155 KB)

... is far from ideal. Is there any way to retrieve longer article extracts? If not for version 1, maybe for version 2?

If it’s not possible in version 1, we probably have to make the cards adaptable in height and vertically centered again. Plus set a max-height in case we have an image and a longer extract.

Same from the comments above, but we still can setup a parameter to disable images from the screen. Just a reminder that we use this standard preview dialog everywhere in the app.

If it’s not possible to show longer extracts in version 1, I think it’s fine to show the images here.

Quick update: @cooltey and I discussed this yesterday. There’s currently no option to retrieve longer article extracts. To avoid unpleasant situations like this, we’re going to make some adjustments to the designs for V1. Cards have a min-height and max-height and are fluid in between. Ideally min-height is defined as 3/4 of the card’s width (device’s viewport width) to maintain a 4:3 aspect ratio. Examples:

Image and longer extractNo image and short extract
image-long-text.png (1×720 px, 653 KB)
eaf-11-no-img-less-txt.png (1×720 px, 129 KB)
same specs as beforemin-height with 4:3 aspect ratio

I added an additional screen to Zeplin that demonstrate the behavior. This affects @Sharvaniharan’s work in T217170 as well.


This is not an ideal solution, but straightforward for V1. In regards to V2 @bearND @Mholloway: is there any way to retrieve longer article extracts? The length of the extracts varies quite a bit, even though some articles have more content than they’d output within that extract. We’d love to have the possibility to show more article content in the cards. In case you don’t know what I’m referring to:

eaf-11.png (1×720 px, 657 KB)

Thanks for the feedback!

I see, thanks @schoenbaechler! I have an additional question:

08 UI does not adapt in landscape mode, here’s a screenshot from “Randomizer“, as reference:

We don't have a UI design for landscape mode now. Where should the language bar (used in translate description screen LINK) show in the landscape mode?

The ideal way of handling this is to keep the original card item view and have the other views (language bar, dice...etc) changed.

Hey @cooltey, sorry for the delay in commenting on this. As discussed earlier, I added an example landscape design to Zeplin:

When there’s no article image, the available space should be used to display the extract. Added it to the task’s description as well.

@schoenbaechler The PR got merged today and it is ready for design signoff

Thanks @cooltey and great work! Love the smooth animation when navigating through the cards!

01 Text is still cut off at the bottom of the card:

Screenshot_20190403-182414.png (2×1 px, 890 KB)

02 Apply edit_improve_tag_selected_drawable color from Android theme guidelines to both plus icon and label. It’s currently failing color contrast AA standards in dark and black mode:

Screenshot_20190403-162955.png (2×1 px, 984 KB)

03 Spacing on “Add description“ screen is incorrect. Can we align with the designs? Input field text also collides with info icon because of that. On the left you can see the specified design, the right side is a screenshot from the app

image.png (1×2 px, 566 KB)

04 4:3 minimum height of cards is not applied (makes the experience more consistent). See screenshots below:

Screenshot_20190403-164858.png (2×1 px, 73 KB)
Screenshot_20190403-164946.png (2×1 px, 89 KB)
Screenshot_20190403-165104.png (2×1 px, 103 KB)

Spec from an earlier comment (T217169#5057349):

Cards have a min-height and max-height and are fluid in between. Ideally min-height is defined as 3/4 of the card’s width (device’s viewport width) to maintain a 4:3 aspect ratio.

Example: If the cards width is 344px on a 360px viewport. The cards height would be 258px

05 Line height is better than before but still off, see image below (original designs in red). The font-size needs to be 24px and line-height 32px (1.333333em) (see Zeplin). Type is positioned on a 4px baseline grid.

image.png (678×1 px, 214 KB)

06 Noticed that cards have a darker shadow on the right when swiping from the left to right. It’s disappearing as soon as the card is in place. Is that intentional? Could we remove the darker shadow and align with the same one as when swiping from right to left? To illustrate:

Left to right swipeRight to left swipe
Screenshot_20190403-164117.png (2×1 px, 838 KB)
Screenshot_20190403-164345.png (2×1 px, 774 KB)
Darker right shadowLighter right shadow

07 Apply material_theme_secondary_color instead of material_theme_de_emphasised_color here:

Screenshot_20190403-174611.png (2×1 px, 141 KB)

08 Sometimes there’s too much additional space between label and article text (maybe edge case when extract has line breaks):

Screenshot_20190403-174549.png (2×1 px, 119 KB)

09 Use material_theme_secondary_color instead of material_theme_de_emphasised_color for info icon and character counter:

Screenshot_20190403-182902.png (2×1 px, 182 KB)

10 Blinking cursor/focus on input but no keyboard? Can we remove the focus on the input when the keyboard is collapsed?

Screenshot_20190403-184112.png (2×1 px, 174 KB)

11 Shouldn’t this label right aligned when the app is set to an RTL language? The input field below (Arabic description) is fine since it depends on the system’s language.

Screenshot_20190403-185421.png (2×1 px, 156 KB)


I think 1-3 should be prioritized since they’re limiting the current experience. The rest would be good to have too but only if it’s not threatening the release date. Thanks!

@schoenbaechler

Regarding the talks on Slack, I've made changes to most of the findings. Now you can update to the latest version of the alpha apk to see the changes.

10 Blinking cursor/focus on input but no keyboard? Can we remove the focus on the input when the keyboard is collapsed?

That's the one I did not resolve yet, will try to fix it.

Wow, I’m impressed @cooltey, you catched them all! 🙏

Please feel free to move it to QA signoff if you were able to fix the the blinking cursor (T217169#5083065).

Cheers!

(moving it to “Did not pass QA“ to clean up the “Design signoff“ column)

Hi @schoenbaechler
Regarding the opinions from engineers, we think it would be better if it keeps the default behavior of the input field instead of overriding it. Would it be okay for you?

Thanks @cooltey. It’s kind of a weird behavior since at least to me, a blinking cursor indicates an active/focused field that’s ready to receive keyboard input. But you are right, I checked some other Android apps and I think it‘s fine. Let’s blame Google! 😉

I think I verified all of the changes @schoenbaechler added. Looks good for me on 2.7.276-alpha-2019-04-04