Using Subform to Improve Subform: Part 1 - Box Model UI

#1

In my opinion, there's no better way to learn/improve a tool than by using it for that exact purpose

That is what I intend to do throughout this early-release process.

In this post: Improving the user-interface for managing box model properties

Proposition: How might we improve the current user interface for managing box model properties such that we:

  • Maintain all current functionality
  • Minimize screen real estate where possible without sacrificing usability
  • Maximize hit-target size for all form elements
  • Minimize cognitive load through proper use of CRAP (consistency, repetition, alignment and proximity)
  • Maximize design pattern reuse throughout application

Big reveal: before and after of 'Margin' property manager (mocked-up in Sketch)

In defense of this new design

  • All current functionality is maintained: 4 direct inputs and three toggle switches
  • Screen real estate has nearly been cut in half
  • Hit-target size of toggle switches has increased, and by separating them, the margin for error in selecting the wrong toggle has been greatly reduced
  • Elements including the lock and link icons - and the functional use of Subform's blueish purple color - help connect this UI component with neighboring components, and removes the need for position labels (e.g. top, bottom, left, right) due to functional alignment of the lines to the input fields.
  • This UI is designed in such a way that it could work unchanged for padding and border (at least border-width)...like so:

Mock-up re-created in Subform

subform-screencap.png1366x768 89.8 KB

Subform document provided for exploration

Subform Box Model UI Design Concept

Plenty more to come

I plan to write about:

  • The joys and frustrations I experienced while building this and other mock-ups in Subform
  • Other ideas for how to successfully build upon the potentially ground-breaking capabilities currently presented in the early versions of Subform

Cheers,
rmion

#2

This is awesome! Thanks for taking the time to write this up and share some ideas.
In particular I like that you were explicit with your goals for the design (maximizing hit-size, etc.).

I recall talking w/ Ryan about doing something similar w/ colored borders to indicate the position the input corresponds to, but I think we decided it was too difficult to parse at a glance compared to physically arranging the inputs.
(Not that we actually tested it with anyone, though --- it very well could be that 90% of people immediately "get" this design too.)

Two questions:

  • Any reason you used both the lock icon and the little chain icons? If I understand the design, both are being used to indicate that some inputs are constrained to have the same values, so why not just use multiple instances of the same icon?

  • What happens to the top/bottom left/right constraints when the lock is enabled or disabled? On the borders example, the lock seems to be enabled but the little chains aren't enabled, and everything has a different value, so I'm not sure what's happening.

Finally, before you get too carried away with the margin/padding controls I should let you know that we're looking into getting rid of those as independent properties and rolling them into a broader layout engine semantics and control UI.
We don't have any visual designs yet, but I'd love if you could take a look at my thoughts on layout and chime in there too.