An inside look into how we made Slidewise’s “Replace Colors” feature
Working on the Replace Colors feature was an interesting and challenging journey. It took a lot of work to get it done, but it was fun, and we're really happy with how it turned out. I’d like to walk you through a few highlights from the journey from the initial idea to the feature you see now.
Slidewise's existing color feature allowed users to view and navigate to colors, but not to replace them. The index showed a list of non-theme colors. Underneath each color, there was a list of associated types where the colors appeared in the presentation, for example, Shape fill and Text fill.
Our first step was to generate some ideas for how to add the new ‘Replace Colors’ functionality to the existing feature.
Design 1
Initially, we use Balsamiq to create rough mockups, like the one below, to explore how the Replace Colors feature might work best from a user's perspective. This early example shows a simple dialog with the option to replace multiple colors at once.
It had a major flaw though because it only allowed you to replace multiple source colors with a single replacement color. This approach was impractical because Slidewise needed to close and reopen for each color replacement, making it inconvenient if you had multiple colors you needed to change.
Design 2
This design focused on allowing users to configure multiple replacements at once. However, as you can see, it made the dialog much more complicated, and we really wanted to make sure our finished feature would be simple to use. 😵💫
The checkbox options for replacing colors also posed a problem. This approach, while common in other tools, requires the user to make a decision without enough information. For example, if they want to replace 2 blue source colors with Accent 1, they may not know that Blue color 1 is only used in Shape fills, while Blue color 2 is used only in Text fills. If they only select Shape fills, only one color will change because the other is only used in Text fills. The more source colors selected, the more complex and unpredictable the results.
Ultimately this led to our decision to move on from the design again.
Design 3
We reworked the designs to eliminate the checkboxes by grouping the colors by their type. This led us to the design below, which we felt checked many more boxes:
- See where source colors are used
- Change only the color types you intend to
- Make multiple color changes at once
- See which colors are duplicates of a theme palette color
- Replace colors with theme colors or directly-set colors
With this design, colors can appear more than once in the list, if they are used in for example, Text fills and Shape fills. However, it allows the user to make much more granular changes without fear of changing colors that they didn’t want to.
Build 1
Design 3 served as a blueprint for the feature and established our first development task, which was to reverse the color index. We needed to first group by type, bringing all of the shape fill colors together and then secondly by the colors. To do this, we had to modify the deep code responsible for scanning the presentation's colors and constructing the tree.
This is how colors looked in Slidewise for the same presentation, before and after the changes.
You might spot that the new index shows 1 additional color. This is because (69,85,95) is used in Shape fills and Text fills, so it now appears twice in the list.
Test 1
Restructuring the color index is a pretty fundamental change, which had the capacity to break lots of things that were previously working. So we had to extensively check the new version with all of our test files to make sure colors were still appearing correctly.
During testing, we fixed a pre-existing bug that had prevented Slidewise from indexing multiple instances of the same color within a single shape. For example, a shape with both orange text and an orange outline would previously only display the outline in the Slidewise index.
Build 2
The Replace colors feature is roughly made up of 2 separate components:
The UI element displays colors in the presentation and allows users to select color changes they want to make.
The engine component receives instructions from the UI and then modifies the underlying XML within the file.
We decided to prioritize the development of the core engine code responsible for interpreting UI instructions and modifying the PowerPoint XML. We wanted to make sure that if we discovered any limitations within the replacement code we would find them before starting on the UI. Building the user interface is time-consuming - so it’s ideal to avoid having to make too many changes once you’ve started.
Test 2
To ensure the Replace Colors functionality worked correctly, Andrew built a command-line tool we could use to control it before building the UI. This allowed us to test replacing colors on lots of files, which drove out a fair number of smaller issues that we were able to fix.
During testing, we encountered unexpected behavior when replacing colors in some charts with theme colors. This anomaly was due to color theme overrides on those specific charts, a feature Slidewise currently doesn't yet fully support. When you paste a chart and choose “Keep Source Formatting…” it creates a chart-specific color theme override.
The reorganization of the index and the subsequent restarting of all testing would have been too risky at this stage. As a result, we opted to move any chart colors in theme overrides into a separate node and disable the Replace Colors option for them, instead of adding them properly to our index.
Simple instructions on using PowerPoint to reset these charts to the main theme and remove overrides are available. We have also documented the chart overrides requirements and added them to our backlog for future development.
Thankfully, nothing we found caused any fundamental problems, and we could confidently move on to building the user interface.
Design 4
While we were working on the replacement code and testing, we had also gone through a few more design iterations. These design changes were aiming to:
Providing clearer instructions on what the user needs to do.
Removing noise from the design for faster understanding
Making it easier to remove configured choices
Extended to include color picker mock
Build 3
We now had designs and code that could accurately show and replace colors. It was time to build the user interface to connect the two.
We started building the dialog and you can see below how it builds up in layers. However, by screenshot no.3 we realised that it wasn’t possible to have independent rollovers on the two different color swatches in a single row. This made the UI quite confusing to use - as it wasn’t clear what could be clicked on in order to use the feature.
Design 5
Having more fully understood the constraints with the UI tools, we then took that learning back into design to rework it. Our solution was to display a "Select color" button in the replace with column when hovering over each row. The color options would then appear when the button was clicked.
We were really pleased that the limitations in the tools forced us to think again and come up with a better design. Picking a new color is clearer and easier now compared to the previous design.
We shared an early development build of the feature with a few customers and watched them as they used it. This identified a few areas for improvement in the UI. For example, our early ‘Select color’ buttons didn’t look enough like buttons, so they were often overlooked. After a fair bit more polishing, we improved the design still further to what you see today.
Auto-Match
The Auto-Match button was introduced to simplify the process of assigning theme colors. During testing, we found that many presentations included colors that perfectly matched theme colors (shown by a yellow dot). However, we found that manually configuring each of these colors was too time-consuming.
Later, we might expand this to include close matches in addition to exact matches.
I've spent the last 15 years working with a team that's truly passionate about creating high-quality software that has a positive impact. Sharing some insight into how we make those tools with the people using our software has been in our minds for a long time.
When Nolan Haims asked me "How do we do what we do" on The Presentation Podcast last year, it bothered me that I didn't have an easy answer. However, six months later, this blog post is my attempt to answer his question. 😉 So thank you Nolan for inspiring this behind-the-scenes look at our process!
We’d love to hear your feedback. Let us know in the comments or just drop me an email if you found this interesting, or if you have any follow-up questions.