3 ms·

One of the absolute worst things about iOS development is struggling with auto layout. Sure there are some things you can do with it that are hard to do in a bo

One of the absolute worst things about iOS development is struggling with auto layout. Sure there are some things you can do with it that are hard to do in a box layout method but 95% of the time it's just a massive headache to achieve something you could do with flexbox or even Bootstrap in a much more transparent way. In fact, one of the most appealing things about React Native is that it lets you do iOS layout with flexbox. So I'll pass on similar constraint-based approaches to HTML layout, thanks!

pavlov 11y ago
Agreed completely. Constraint-based layout solvers are very appealing to programmers because they seem intuitively like the "right" solution -- but that intuition is based on the programmer's mental model of user interfaces. Constraints don't match the way designers think and work, so they're not good as a non-programmer's interface. As often happens with solutions that are abstractly "right", constraint-based layout engines do a great job of fixing complex theoretical non-problems that nobody was asking to have fixed, while at the same time failing to address real-world issues that impede users' everyday workflows.
- kenferry 11y ago
  > appealing to programmers because they seem intuitively like the "right" solution … Constraints don't match the way designers work Interesting, I'd say almost the opposite. These constraints capture almost exactly the same thing as the orange guide lines you see in Keynote (or Powerpoint, or whatever). This is inset from the top right by 10, this button is the same width as the one above, the distance between these two buttons is eight. That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em.
  - paulojreis 11y ago
    > That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em. Yes, but that's because those designers were asked to specify the layout in engineer terms. :) That doesn't mean that that's the way they think and conceive the UI.
    - coldtea 11y ago
      Actually that's exactly the way they think. "These items should be aligned at their bottom ends", "this group of items should have space between them and take the whole width of the page" etc. And some designers tools also let them express it in exactly that way.
      - paulojreis 11y ago
        Yeah, that's the engineer perspective on it. Focusing on the details, on deconstruction, and not on the whole. It's true that rules such as "bottoms aligned" and "equal heights" exist frequently. And it's also true that there are tools to express these rules (align and arrange tools in Adobe software). However, those are the "implicit" parts, the minor details that one attends to while designing but without giving it much thought. Of course, for the technical guy who implements, those details are important. And that's why they're specified in design specs, so to speak. But the layout, the major composition, is thought (typically) out of a grid system. And that's what, I believe, a designer focus on. Not on individual element rules, but on the whole. Of course, if a engineer spends hours making a detail in the implementation look like the design, then he'll think that the designer gave it a proportional amount of attention. Typically, not true. :)
        coldtea 11y ago
        >But the layout, the major composition, is thought (typically) out of a grid system. And that's what, I believe, a designer focus on. Not on individual element rules, but on the whole. That might be true for print designers of yore, but we've moved beyond that in the last 10 years or so. Designers today know that it's not about some static composition on top of some grid. And they also know that individual elements are important (e.g. how a callout or a profile pic responds to a page resize). Heck, it's the same designers that had to suffer using floats for layout (and if there was ever a "engineering driven idea" and at odds with grids it was that). Compared to that constraints is designer heaven!
        paulojreis 11y ago
  - cageface 11y ago
    Designers almost always work in grid systems, not in collections of arbitrary measurements between screen elements. I suspect one of the reasons that Bootstrap has become so popular is that its grid system makes it fairly easy to implement the grid-based layouts that designers typically employ. Things like Bootstrap and flexbox make implementing grids easy. Constraint systems are at entirely too low a level of abstraction for this.
  - panic 11y ago
    Designers have to add these lines and numbers after the fact, and they don't always reflect the intent behind the layout. As screen sizes, typefaces and other layout details change, fixed numbers quickly become obsolete. The ideal is to encode that original intent behind the layout into your program. As far as I can tell, any set of constraints simple enough to solve efficiently will not be powerful enough to model your designer's intent. The design will eventually become complex enough that your layout will need to be represented as a procedure. Once that happens, the constraint system becomes just another pointless layer of abstraction.
coob 11y ago
You don't need to use React Native to use flexbox with iOS apps: https://github.com/robb/FLXView https://github.com/robb/FLXView https://github.com/joshaber/SwiftBox https://github.com/joshaber/SwiftBox
rimantas 11y ago
I'd say the percentages are reversed.
archagon 11y ago
Autolayout is really nice once you figure out what it's good for. And it's certainly not good for everything. Making a keyboard? Don't even bother. Too brittle, too slow. Making something with dynamically-loading views? Probably not a good idea. Too unpredictable. Trying to animate something fancy? Just change the frames directly. Doing it through an intermediary system is just too finnicky. But the other day, I was designing a toolbar for my app. I needed floating menu buttons all along the top of the screen. Whenever a menu opened, it would grow horizontally and vertically; any existing menu buttons along its edges had to slide out of the way accordingly, or shrink if they hit the edge of the screen (with the distance between menu buttons being paramount). The specifics of the menu's expanded dimensions were left to the menu controller itself, and they could change at any time. For this, autolayout was absolutely the perfect tool for the job. Whenever you have a small, finite set of static elements that can push each other around, autolayout makes things a lot simpler. (The programmatic interface is just awful, though, and the visual formatting language doesn't do enough.)

pavlov 11y ago

Agreed completely. Constraint-based layout solvers are very appealing to programmers because they seem intuitively like the "right" solution -- but that intuition is based on the programmer's mental model of user interfaces. Constraints don't match the way designers think and work, so they're not good as a non-programmer's interface. As often happens with solutions that are abstractly "right", constraint-based layout engines do a great job of fixing complex theoretical non-problems that nobody was asking to have fixed, while at the same time failing to address real-world issues that impede users' everyday workflows.

kenferry 11y ago
> appealing to programmers because they seem intuitively like the "right" solution … Constraints don't match the way designers work Interesting, I'd say almost the opposite. These constraints capture almost exactly the same thing as the orange guide lines you see in Keynote (or Powerpoint, or whatever). This is inset from the top right by 10, this button is the same width as the one above, the distance between these two buttons is eight. That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em.
- paulojreis 11y ago
  > That's almost exactly what designers' specs look like in my experience – screenshots annotated with lines with numbers on 'em. Yes, but that's because those designers were asked to specify the layout in engineer terms. :) That doesn't mean that that's the way they think and conceive the UI.
  - coldtea 11y ago
    Actually that's exactly the way they think. "These items should be aligned at their bottom ends", "this group of items should have space between them and take the whole width of the page" etc. And some designers tools also let them express it in exactly that way.
    - paulojreis 11y ago
      Yeah, that's the engineer perspective on it. Focusing on the details, on deconstruction, and not on the whole. It's true that rules such as "bottoms aligned" and "equal heights" exist frequently. And it's also true that there are tools to express these rules (align and arrange tools in Adobe software). However, those are the "implicit" parts, the minor details that one attends to while designing but without giving it much thought. Of course, for the technical guy who implements, those details are important. And that's why they're specified in design specs, so to speak. But the layout, the major composition, is thought (typically) out of a grid system. And that's what, I believe, a designer focus on. Not on individual element rules, but on the whole. Of course, if a engineer spends hours making a detail in the implementation look like the design, then he'll think that the designer gave it a proportional amount of attention. Typically, not true. :)
      - coldtea 11y ago
        >But the layout, the major composition, is thought (typically) out of a grid system. And that's what, I believe, a designer focus on. Not on individual element rules, but on the whole. That might be true for print designers of yore, but we've moved beyond that in the last 10 years or so. Designers today know that it's not about some static composition on top of some grid. And they also know that individual elements are important (e.g. how a callout or a profile pic responds to a page resize). Heck, it's the same designers that had to suffer using floats for layout (and if there was ever a "engineering driven idea" and at odds with grids it was that). Compared to that constraints is designer heaven!
        paulojreis 11y ago
- cageface 11y ago
  Designers almost always work in grid systems, not in collections of arbitrary measurements between screen elements. I suspect one of the reasons that Bootstrap has become so popular is that its grid system makes it fairly easy to implement the grid-based layouts that designers typically employ. Things like Bootstrap and flexbox make implementing grids easy. Constraint systems are at entirely too low a level of abstraction for this.
- panic 11y ago
  Designers have to add these lines and numbers after the fact, and they don't always reflect the intent behind the layout. As screen sizes, typefaces and other layout details change, fixed numbers quickly become obsolete. The ideal is to encode that original intent behind the layout into your program. As far as I can tell, any set of constraints simple enough to solve efficiently will not be powerful enough to model your designer's intent. The design will eventually become complex enough that your layout will need to be represented as a procedure. Once that happens, the constraint system becomes just another pointless layer of abstraction.

coob 11y ago

You don't need to use React Native to use flexbox with iOS apps: https://github.com/robb/FLXView https://github.com/robb/FLXView https://github.com/joshaber/SwiftBox https://github.com/joshaber/SwiftBox

rimantas 11y ago

I'd say the percentages are reversed.

archagon 11y ago

Autolayout is really nice once you figure out what it's good for. And it's certainly not good for everything. Making a keyboard? Don't even bother. Too brittle, too slow. Making something with dynamically-loading views? Probably not a good idea. Too unpredictable. Trying to animate something fancy? Just change the frames directly. Doing it through an intermediary system is just too finnicky. But the other day, I was designing a toolbar for my app. I needed floating menu buttons all along the top of the screen. Whenever a menu opened, it would grow horizontally and vertically; any existing menu buttons along its edges had to slide out of the way accordingly, or shrink if they hit the edge of the screen (with the distance between menu buttons being paramount). The specifics of the menu's expanded dimensions were left to the menu controller itself, and they could change at any time. For this, autolayout was absolutely the perfect tool for the job. Whenever you have a small, finite set of static elements that can push each other around, autolayout makes things a lot simpler. (The programmatic interface is just awful, though, and the visual formatting language doesn't do enough.)