Inspector: Additive vs Always On (or the need for Progressive Disclosure)

Elements Feedback
1

The more I use the inspector the more I’m convinced an ‘additive’ approach to element properties will help to manage complexity far more than the ‘always on’ experience we have now.

Currently whenever you add an element and view its properties in the inspector you are presented with ALL possible properties and variations, even if you only need (or want) a couple. This puts the cognitive load on the user to process all of this input, and then attempt to focus on their own immediate needs while ignoring the added noise. Expanding and collapsing sections, while helpful, doesn’t really solve the problem, but creates an interesting game of 'Where’s the property?".

A better approach is one that Sketch uses with its Inspector. When adding an object or component you are presented with a basic collection of properties that are common to many objects; alignment, size, resize, spacing, corners, effects, filters, etc. — and everything else is additive (and subtractive) in accordance with the users’ needs.

In UX design this is commonly referred to as Progressive Disclosure.

If you want a border, simply add one. If you want another, add it also. Don’t want a fill. Delete it. Add a background colour. Add and position a background image, add and position another. Remove a gradient. etc. Change your mind on that second border? Remove it.

This also allows for some code/performance savings as well as currently it appears that every element exports every possible property setting even if it’s not being used. For instance, if I don’t want a :hover state on a button, I currently have to specify the same colour on :hover, instead of simply not adding that ‘state’ (and the associated properties) to the element.

Using an additive approach would not only reduce shipping unnecessary code and attributes, but also greatly improve the UX of the inspector panel.

1 Like
2

First I absolutely love this approach. Even when watching the last video, the “Where’s Waldo” game came to mind.

The simplicity of the UI is going to be the collision of complexity working it all out when developing this. A real juxtaposition indeed.

1 Like
3

Personally, I’d begin by looking at what properties are common (and often used) with the majority of elements. This will include properties such as width, height, margin, padding, alignment, layer/z-index, etc. Make these the primary properties within the inspector, and present them in a consistent and familiar manner.

For those properties used less often, make them optional properties that can be added (and removed) if the user wants them. (ie. backgrounds, borders, corners, etc)

Then look at what properties are truly unique to each element (spacing/gap, layout/flow/flex/grid, etc), and whether or not those properties are shared (or at least similar) to any other elements. Present these in a consistent manner in the components that require them, again making less used properties optional.

It’s not so much complex, as it is a lot of tedious, complicated work. The complexity we see currently is the result of treating each element as distinct and unique.

2 Likes