-
-
Notifications
You must be signed in to change notification settings - Fork 662
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
Tweak UI: Change some parts of UI for mention-unsubscribed warning. #4488
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, @Gautam-Arora24! See a few comments below.
src/common/ZulipButton.js
Outdated
@@ -103,6 +104,7 @@ type Props = $ReadOnly<{| | |||
text: LocalizableText, | |||
secondary: boolean, | |||
onPress: () => void | Promise<void>, | |||
hitSlop?: EdgeInsetsProp, // The EdgeInsets class specifies offsets in terms of visual edges, left, top, right, and bottom |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ZulipButton
's interface here is to accept a prop named hitSlop
that works just like View
's hitSlop
prop, right? In particular, ZulipButton
just takes hitSlop
and passes it directly to a View
.
I think it'd make a bit more sense to make that more explicit in this type, sort of like how we do with style
. If it's quite clear that a prop like hitSlop
is used just like View
's hitSlop
prop, then we don't need a code comment like this; people will naturally check the upstream doc for what it means. (And then, if the doc is unclear or misleading, we can add our own comments about that. But I don't think that's really the case here.)
Specifically, I'm thinking about something like this:
+ hitSlop?: $PropertyType<ElementConfig<typeof View>, 'hitSlop'>,
That's a way to say "hitSlop
, when present, should have the same type as View
's hitSlop
prop". 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done :)
@@ -54,6 +54,12 @@ const styles = createStyleSheet({ | |||
buttonText: { | |||
color: 'black', | |||
}, | |||
hitSlop: { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This doesn't belong in styles
; it isn't used for a View
's style
prop, but rather a View
's hitSlop
prop.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done :)
top: 6, | ||
right: 0, | ||
bottom: 6, | ||
left: 0, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How did you calculate what numbers to use here? 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see the commit message says the touch target now extends to 48px after setting the top and bottom hitSlop
to 6px. But let's describe the starting point, so we can be sure 6px is right. 🙂 Let's also include a link to the doc that gives the 48 x 48 px guideline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here is the link to the docs that suggests 48 x 48 px
guideline -> https://support.google.com/accessibility/android/answer/7101858?hl=en
@@ -67,7 +67,12 @@ class MentionedUserNotSubscribed extends PureComponent<Props> { | |||
const { user, onDismiss } = this.props; | |||
onDismiss(user); | |||
}; | |||
|
|||
componentDidMount() { | |||
LayoutAnimation.configureNext({ ...LayoutAnimation.Presets.easeInEaseOut, duration: 100 }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that these slide in and out now! I see something a bit odd, though—it looks like the warnings are sliding between the compose box's background and the compose box's inputs, in the z-direction. Can we fix that? 🙂
I think it might look better if it slid in and out from under the compose box entirely, i.e., not above its background.
Ah, also—the WebView jumps up and down a bit when these warnings enter and exit. Can we fix that? I think it'd probably be OK here to overlay the warnings above the WebView in the z-direction, instead of stacking them in the y-direction. Unlike the unread banner—see some recent discussion on that—these warnings can always be dismissed to see what's under them, without changing the state of the message list.
Here's a video with the animation slowed down so these things are easier to see:
mention-warning-animation.mp4
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done :) Now the Webview doesn't jump up and down and the warning overlay in the z-direction.
7829567
to
b903ada
Compare
@chrisbobbe This PR is ready for a re-review. Kindly have a look 🙂 |
Use a nice animation for this component. Use LayoutAnimation API to animate the component. Make use of componentDidMount and componentWillMount to make the component animate in both mount and unmount state. Make use of absolute positioning to make sure that the warning message does not move the Webview up and down. Also, now the warning message overlay on existing message in the z-direction. Discussion of this in CZO [1] [1] https://chat.zulip.org/#narrow/stream/48-mobile/topic/UI.20tweaks Fixes part of zulip#4224
b903ada
to
54c3d4b
Compare
Made the use of hitSlop prop and passed it from MentionedUserNotSubscribed to ZulipButton. Touch target now extends to 48px by specifying top and bottom properties of hitSlop prop to 6px each. Since the height of the button is 32, so adding the hitSlop to 6 at both top and bottom sums it up to 48. Link to the doc - https://support.google.com/accessibility/android/answer/7101858?hl=en Discussion of this in CZO [1] [1] https://chat.zulip.org/#narrow/stream/48-mobile/topic/UI.20tweaks Fixes part of zulip#4224
54c3d4b
to
1501c6b
Compare
This PR is intended to solve left-out parts of issue #4224.
This is how it looks
Screen.Recording.2021-04-10.at.8.49.00.PM.mov