Ad Builder - Settings Panel
Ad Builder - Settings Panel
In the old edit page, the app did not communicate it’s state clearly. This resulted in the user finding it difficult to know what object or layer was currently selected and what they were effecting when they updated settings or edited an animation.
Additionally, the inputs for updating the canvas or layers were spread across several floating accordion menus. The user would toggle open each of the menus, one section at a time, which had little logical ordering to assist them. This was found to be tedious and hard to establish a mental model for finding the settings they needed.
Wireframe recreation of the old edit page UI - an artboard and its accordian menus
Firstly, we wanted the menus to be docked in a permanent position, seeing the ability to alter the layout by dragging menus as counter productive. It was decided to try a panel fixed to the right of the page that could be known as the go-to place for all settings. This could help the user better form a mental modal and spend less time recalling where the settings were.
Early wireframes of the Settings Panel
Mocking up different input layouts
The Style section of a layers settings includes required styles like position and size, but also optional styles like rotation and opacity. If included by default, these optional styles would make the section very long and waste space displaying un-edited inputs. At this I decided to have the optional styles accessible via an inline form - which would have to be quite compact due to the limited space.
Early design of a compact Add Style form
After a some more elaborate inline form attempts, I settled on the humble select box. Selecting an option from the list directly added it to an optional styles section below it. In this way there was no need for a Submit button which kept the form small, while it also visually matched the other inputs around it.
Final design - adding optional styles
So the panel was to be the main place to find settings, but with so many configurable options across the canvas and layers, there clearly wouldn’t be space to display every setting at once. The user would not want to waste energy scrolling a long list of options. This would be as unintuitive as hiding them behind collapsed menus. This is how it was decided to make the panel only show settings relevant to the current selection. In this way it was now contextual and the amount of information displayed would not be overwhelming.
Contextual Settings Panel demo
Since there was now this fixed panel, it was a great place to display app state to solve not knowing the currently selection. This selection preview ranged from an icon to a small preview of the asset used in the layer, then additionally, its name and layer type.
Selection preview demo
With all the settings kept in the same place, users found what they needed faster, with nothing to filter or lists of irrelevant items to scroll through.
The selection preview was appreciated as a useful reminder of the current selection, since the user could be editing a layer that was only partially visible on the artboard, due to animation or screen space. They could now work assured the options they were editing would have the intended effects.
An area that needs further work has to do with layer groups. Users described issues with not knowing if the current layer was inside a group and how to exit that group. This app state information would fit well next to the layers details in the selection preview section at the top of the panel. Below are some iterations of different ideas for displaying group information.
Iterations of possible group indicators and navigation
The demos above also show how the settings were further sorted into tabs, rather than using a single scrollable list. The main reason for this was the optional layer styles which, if many were added, would have made the list quite long. I think this decision to use tabs decreased the usability for small readability improvements and a slightly less cluttered UI. I overestimated the amount users would explore the interface and I would have liked to spend more time experimenting with a single list, which might have been better.