Many developers feel frustration with Auto Layout.
I think a major part of this frustration is with the tools themselves. The concept and math behind Auto Layout make sense, but the tools that we use to achieve the desired results often result in many hours (or even days) being wasted. See http://openradar.appspot.com/25173433 for an example.
Here are a few issues developers have while working with auto layout in Interface Builder:
• The design tool uses static frame rectangles for layout, but these frames are dynamic within the app.
• Editing views and their constraints involves a lot of navigation: a developer is constantly moving between the view’s detail panel and the constraint’s detail.
• It’s hard to tell which view a constraint affects.
• Views constantly get misplaced.
• Keyboard focus is never where you want it: there’s a lot of clicking between the panels and the storyboard view.
These are just off the top of my head, but the point of this Radar is not specific examples. Rather it’s a suggestion to rethink the needs of developers and designers alike.
The following idea occurred to me as I was trying to work around an issue with Interface Builder: I was editing a .storyboard file in BBEdit. It’s just XML and every developer knows how to deal with that text. The elements and attributes in this text are also easy to understand: you can see the views and their attributes clearly.
So why doesn’t Interface Builder just become a viewer for this textual markup? Something like the browser for HTML and CSS code: save the file and refresh to see the results. This way of working suits both developers and designers: look at any website you admire to see the effectiveness of this combination. It’s not interactive, and everyone loves it that way.
Auto Layout also has a textual representation for its constraints. These could also be used in an “auto layout text editor” — the main function of the editor then becomes the management of the view hierarchy. The designer and developer can focus on just the important part: constraints.
Thanks for your time in considering this proposal. Please let me know if you have any questions or comments. Thanks!
Description
Many developers feel frustration with Auto Layout.
I think a major part of this frustration is with the tools themselves. The concept and math behind Auto Layout make sense, but the tools that we use to achieve the desired results often result in many hours (or even days) being wasted. See http://openradar.appspot.com/25173433 for an example.
Here are a few issues developers have while working with auto layout in Interface Builder:
• The design tool uses static frame rectangles for layout, but these frames are dynamic within the app. • Editing views and their constraints involves a lot of navigation: a developer is constantly moving between the view’s detail panel and the constraint’s detail. • It’s hard to tell which view a constraint affects. • Views constantly get misplaced. • Keyboard focus is never where you want it: there’s a lot of clicking between the panels and the storyboard view.
These are just off the top of my head, but the point of this Radar is not specific examples. Rather it’s a suggestion to rethink the needs of developers and designers alike.
The following idea occurred to me as I was trying to work around an issue with Interface Builder: I was editing a .storyboard file in BBEdit. It’s just XML and every developer knows how to deal with that text. The elements and attributes in this text are also easy to understand: you can see the views and their attributes clearly.
So why doesn’t Interface Builder just become a viewer for this textual markup? Something like the browser for HTML and CSS code: save the file and refresh to see the results. This way of working suits both developers and designers: look at any website you admire to see the effectiveness of this combination. It’s not interactive, and everyone loves it that way.
Auto Layout also has a textual representation for its constraints. These could also be used in an “auto layout text editor” — the main function of the editor then becomes the management of the view hierarchy. The designer and developer can focus on just the important part: constraints.
Thanks for your time in considering this proposal. Please let me know if you have any questions or comments. Thanks!
Product Version: Xcode 7.2.1 (7C1002) Created: 2016-03-16T17:40:09.464270 Originated: 2016-03-16T10:39:00 Open Radar Link: http://www.openradar.me/25195388