How would you approach implementing a layout like ...

# compose-android

[Mikołaj Karwowski]

How would you approach implementing a layout like that?

I mean the text button that in the design is just a text. The UI designer didn't take into account the ButtonDefaults.MinWidth
From my experience it is a common scenario where the designs don't care about how it's done on our side

I don't feel like removing that minimum width/height as it is there for a reason

I can create a composable that takes in expected padding from text and calculates the real/remaining padding to apply to the button
Or straight up implement it using a Layout composable, but...
I feel like there should be an easier way to implement it, no?
Or is the best solution to force the designer to start taking our minimum button heights/widths and paddings into account when creating those designs?

The best I've found so far is to create a rectangle in Figma for example and match the centers of it with the center of the text, but then the margins become weird (6/23dp) and it smells like introducing own fantasy into layouts when we - as devs - are supposed to realize them 1:1 as they are given.

[Aditya Bhaskar]

The designer probably used a text instead of a text button because they designed it visually, not with interaction in mind. I don't see why you can't use a text button here. I'd even make it the same width as the filled button above it. It will visually match the designer's requirement, but also match the minimum touch surface constraints.
I'm not sure whether it'll match min heights though.

[Aditya Bhaskar]

Regarding the wider issue, we regularly feedback the UX and platform requirements to the designers. Most of our designers now know them by heart, or know to look them up. New designers often need the same feedback to bring them onboard.

[Mikołaj Karwowski]

I absolutely can use a TextButton and did so, I just usually feel uneasy making my own decisions in how UI looks like - for example deciding how big the hitbox should be. It allows some back and forth with clients/designers after coding the app and performing the demos because 'can we make that hitbox smaller'?

Or making non-obvious decisions in code - in Figma the paddings are 16 top, but in code it's 2. Why? Either javaDoc it and explain how I calculated it, or allow the disparity between code and Figma making devs not question that code and fertilizing the ground for tech debt

I think the UX feedbacks and making the platform requirements known to designers are the only sound solutions to that

[Mikołaj Karwowski]

Thanks 🙂

[Jonathan]

I'm a little confused on what you're having issues with? If you're wondering how to build the orange button. I recommend centering a Text in a Box and either take the padding defined in Figma and apply it to the modifier passed to the parent Box or many set the height specified in the design on the Box directly. Using a height modifier is my preferred choice if you want to make sure the bounds of the button matches Figma regardless of the text scaling. The clock listener should be added to the Box directly so that it's entire area (hitbox) is clickable; which is what a user would expect.