Skip to content

Conversation

@cmonfortep
Copy link
Contributor

@cmonfortep cmonfortep commented Feb 15, 2020

Task/Issue URL: https://app.asana.com/0/0/1162132608576977/f
Tech Design URL:
CC: https://app.asana.com/0/0/1158941144031452/f

Description:
This PR is some preparation work that will be related (and be used) in a future task, where we will implement new Ctas with two buttons.
For context: To show our CTAs as Dax dialogs we will make use of a Dax dialog with two buttons. Usually, the secondary button will be used to dismiss the dialog.
Design can be found here: https://app.asana.com/0/0/1158941144031452/f

Within the scope of this PR, you will find the following changes:

  • Refactor current DaxDialog to handle a new secondary button
  • Decoupling view-highlighting related logic from simple Dax dialogs into a more concrete dialog.
  • Changes in UI according to new design
  • Enable sending pixels when the secondary button is clicked
  • Small improvement to avoid showing a dark status bar when the dialog appears

Steps to test this PR:
Currently, the new Dax dialog with two buttons is not used in any part of the project (but it will be). Testing the new dialog with 2 buttons will be included on a future PR once we have the experiment ready to be reviewed.

Then, do we need to test something? yes, ensure new changes don't affect how normal dialogs are shown. To testing that part:

  1. Hardcode variant mv
  2. Navigate to BrowserActivity
  3. Visit any site that triggers a Dax dialog
  4. Ensure that dialog appears and it's rendered as in previous versions (except for commented changes in the description).
    Example:

Possible triggers: a site with trackers, a site without trackers (wikipedia.org), a major entity (google).
To test different Ctas, you may need to perform a fresh install for each type, as showing some of them will disable showing others.


Internal references:

Software Engineering Expectations
Technical Design Template

Removing one layer of ConstraintLayout for one LinearLayout to simplify working with margins between buttons.
* Introduce new logic to show/hide a secondaryButton on DaxDialogs.
* Change DaxDialog creation logic inside Cta.
* Adapt BrowserTabFragment listener logic to new chanes.
</androidx.constraintlayout.widget.ConstraintLayout>
<com.google.android.material.button.MaterialButton
android:id="@+id/secondaryCta"
style="@style/Widget.AppCompat.Button.Borderless.Colored"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does it make sense to extract this to our own Button style?


fun onUserClickCtaSecondaryButton(cta: SecondaryButtonCta) {
cta.secondaryButtonPixel?.let {
pixel.fire(it, cta.pixelSecondaryButtonParameters())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this ok being launched in the main thread?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ApiBasedPixel:Pixel will excecute it in a background thread. So we are good here.

@malmstein
Copy link
Contributor

If this is not going to be used for now, does it make sense to merge into develop or to keep a feature branch where you add multiple PRs? Just wondering if something were to change before it's finished, we'd have to change code that is potentially released to Play Store but is not being used yet.

@cmonfortep
Copy link
Contributor Author

cmonfortep commented Feb 17, 2020

Thanks @malmstein for the review. About target branch on this PR, I'm happy with both approaches, I think both are valid but I will stick to the preferred one for the team. If it feels more natural creating a feature branch and merge everything there, I will move to that one and we can discuss this topic on our next mobile functional meeting.

@cmonfortep cmonfortep requested a review from malmstein February 17, 2020 09:25
@cmonfortep cmonfortep changed the base branch from develop to feature/cristian/fb_insert_cta_concept_test_exp2 February 17, 2020 09:36
@marcosholgado marcosholgado self-assigned this Feb 17, 2020
@marcosholgado
Copy link
Contributor

Assigning to myself to test all the cta scenarios since I know them very well but @malmstein and others, feel free to do your reviews as well, I just want to make sure all the ctas still work as expected :)

@subsymbolic
Copy link
Contributor

@cmonfortep yes, please don't merge items not ready for release into develop.

Copy link
Contributor

@marcosholgado marcosholgado left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, left a comment in case you want to think about naming :D

fun setDaxText(daxText: String)
fun setButtonText(buttonText: String)
fun setDialogAndStartAnimation()
fun onAnimationFinishedListener(onAnimationFinished: () -> Unit)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The onAnimationFinishedListener is specific to the typing animation and is triggered when it finishes. I would suggest to move it to another interface or make it specific to the TypewriteDaxDialog class but this would make DaxDialogHighlightView a bit messier.
The other option is to assume the DaxDialog always is going to have the typing animation (which it does for now) and maybe rename TypewriteDaxDialog to something more generic? Having TypewriteDaxDialog makes me think there is another version without the typing animation when in reality there isn't.
I don't think is massively important to stop the PR but it feels a very specific name for something that's always used like that.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, onAnimationFinishedListener can be moved into an interface and DaxDialogHighlightViewwill not be affected. The only part that will be affected is where we create those dialogs. But I liked that you commented on that. I think we can delay that change till we introduce a different Dax dialog, that is also the reason why I didn't segregate that interface into different ones.
As per the name, I'm fine changing the name or using this concrete one (because the interface takes the generic name), so I'm open to suggestions here. Tbh, I could come up with something else.

@cmonfortep cmonfortep merged commit a5f9839 into feature/cristian/fb_insert_cta_concept_test_exp2 Feb 19, 2020
@cmonfortep cmonfortep deleted the feature/cristian/two_buttons_dialog branch February 19, 2020 13:03
cmonfortep added a commit that referenced this pull request Feb 28, 2020
* Dax dialog with two buttons (#713)

* New variant: Showing DefaultBrowserCta and SearchWidgetCta as Dax dialogs (#714)

* Insert DefaultBrowser Cta and SearchWidget Cta as Dax dialog during Dax Journey (#716)

* New control group and changes on when to show search widget cta (#723)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants