Pushing The
Arrow’s Buttons

creating multi-state buttons

Ben Watanabe

Published in

A First Project With PaintCode

8 min readMar 14, 2015

A First Project With PaintCode

& the story of Look Up’s arrow

- Part 3 -

One of the first demos of PaintCode are buttons, so that’s where the Look Up arrow will go first. The example is of a basic button with two states, regular & click/tap. The button in this example is used to email the app store link for Look Up.

As is the case with most apps, there are buttons everywhere including other social buttons for sharing. I couldn’t find a good source for these in PaintCode, so adapted @Kevin’s that were created for Sketch. The social buttons recreated in PaintCode are also included in the supporting file that is linked below.

The Big Picture:

As with the symbols we created in the Part-1, the first step is importing the SVG from Sketch.

Shapes vs Beziers

Now it’s time to break a rule from Part 1. We’re going to recreate the rounded rectangle base of the button. The reason behind recreating the base being that all imported paths are converted to beziers on import. Beziers aren’t as easy to work with as shapes, as can be seen in the image below there are twice as many points in the bezier as the shape.

not to mention the handles that effect the angle of the rounded corners

In part 4 when we talk about creating dynamic shapes using PaintCode’s awesome struts the difference in beziers and shapes becomes especially important. Even now though, if you decide to resize the rounded rectangle it’s nice not to have to worry about elongating the corners.

Colors Continued

I only created the unclicked state in Sketch, so I’m going to add the clicked state by creating colors off of the base color of the button. This step also highlights a reason to still import the button from Sketch and that the gradient of the button is also imported.

Next the base button is going to be copied into a new canvas and the original gradient replaced with a darker version.

Now that we have two buttons the style that we like to use for Look Up for multi-state buttons is having one image to call, so next the symbols of the two buttons are combined into a single canvas below.

What’s happening with the third button’s arrow is covered in the Nitty Gritty Notes

This method is nice because once we add the variable for it being clicked we can see how it feels transitioning from a regular button state to clicked, and how one’s brain might recreate the frames between the two states. In one instance when the two buttons were separate it looked fine, but when combined and animated it seemed to be illuminated rather than depressed.

In order to be able to smoothly test the animation though and to make both buttons accessible to the developer two variables are necessary.

selected: a boolean variable
notSelected: an expression as follows

!selected

There’s no need to make additional expressions, or complicate the notSelected one, to adjust the opacity of the layers as PaintCode has the great Visible If… drop down menu…

So just set the buttonSelected symbol to Visible if Selected and… well hopefully you get the idea if you’ve made it this far.

One more thing, make sure that the selected variable is set as a parameter. The developer will not be able to access the selected state if the selected variable is not set as a parameter.

local variables are only available on your end I believe

Q: Why not start by creating the buttons in one canvas?
A: Because then you also can’t compare them side by side and it’s harder to keep track/visualize all the assets and their states.

Localizable & Reusable

Finally if the button is a generic button to be used in multiple instances from say submitting something to saving or the app will be localized into multiple languages the button’s text is best to be made accessible.

In Look Up’s case this button will need to be localized into Japanese. The steps to create a button with editable text are:

Create a Text variable
Set it as a parameter
Link the variable to the text in both canvases that are the symbols

Now here is where my method of recreating the canvases within a combined layer has a weakness.

4. Linking the variable to the text field of the symbols’ origin canvas you’ll also have to link it again to the variable spaces that are now available within the symbol.

If you didn’t do the combined method that I proposed this last step won’t be necessary, but the good outweighs the bad in my opinion.

Where The Magic Happens:

We can extend this idea to provide an additional state for a button (mouse down). In the example below we use the StyleKit method provided with a parameter for ‘selected’. Then we set the menu item’s image and alternateImage properties.

self.menuItem.image = [StyleKit imageOfRestEyeWithSelected:NO];self.menuItem.alternateImage = [StyleKit imageOfRestEyeWithSelected:YES];

It really is just as easy as it looks. You pass in if you would like the button image selected or not, magic happens, and then you pass the code to the button.

It won’t always be the case that there will be a single API call with a parameter; it may be two separate methods. It just depends on how the designer decides to organise the PaintCode file. This is exactly the same thing for when designing an API as a designer. There is not necessarily a right or wrong way to do this (I happen to prefer working with parameters); the important thing is to be consistent.

Sidenote: When creating a button like this for OS X, you need to change a bunch of properties so that it will display properly. Categories are great for this sort of thing. You can find the one we used on BitBucket.

Nitty Gritty Notes:

Symbol Inception

Symbols are great, but they can get a bit funky when you have a symbol within a symbol. As is the case here, with the *arrowGlass* being used as a symbol within the button, and then the shareButtonSelected being used as a symbol within the shareButton…

It’s easy to see the arrowGlass isn’t showing up correctly, but time shouldn’t be wasted trying to fix this. It’s purely a graphical error that happens within PaintCode, and is not replicated when the asset (shareButton) is used within an app.

Don’t Go Crazy Simplifying Colors

We talked about linking the gradient to existing colors in the start of this post, but don’t go crazy with it. You may not want to use White everywhere and actually have duplicate unnested whites that are called shareButtonColor. Splitting up the colors in this way allows an element’s color to be changed without changing all instances of that color…

One time after getting overzealous with my first ever chance to use the word refactoring and having just a few colors I decided I didn’t like the color of one piece of text, so changed it from white to orange. Orange was not an appropriate color for the entirety of the app, so I had to keep one general color labeled white and one goalTextColor color variable.

Nested Colors:

The great part of using nested colors is that if later I want to change the color of the button only the base color has to be changed and the nested colors will proportionately adjust.

!notSelected Variable Over Optimizing?

It may seem like having a !notSelected is over optimizing, since if we just layer the selected state on top the button in this example would be fine. However, if we were to with current design trends and follow material design standards that button may have a drop shadow in it’s unselected state. In this case the unselected button does actually have to be hidden.

Changes At Compile Time

As mentioned in the previous article, one of the nice things about working with PaintCode as a developer is that it just becomes like working with one more API. One advantage this gives is the compile time errors when the API you are using changes. Instead of back and forth between the designer, you get compile time errors which in most cases can be fixed by Xcode’s code complete.

In the case of more drastic changes, you might want to reach for the repository change log to show you what happened. Maybe the method you were using no longer exists. No problems here, just look at your designer’s commit log and you will probably see a method removed and a method added close by.