Buy Generic Alprazolam - No Prescription DrugStore

Designery nerdy things.

How to help your iOS dev in Xcode, as a designer.

by admin on December 10, 2013, one comment

The first few seconds when you hold a beta of an app you've been working on in your hand, is this awesome feeling of delight, mixed with a little bit of narcissism (ya, I did that). The next several seconds, you start to notice all the tiny designery things that the developer didn't get quiiiiite right. Move this up 5px, change that font to bold, add a 1px stroke around that box, etc. The developer I work with calls it having a "Jenni Session," where we sit down together and tweak all the tiny visual things that are bothering me. I'm glad that he cares enough to let me do that, but it would save so much time if I could just do it myself. I've heard about designers that work in Xcode with their developers, and I've tried taking a tutorial or two to get more familiar with it. I've been surrounded by developers all my life, a developer father, brother and now a developer husband. I often joke that I feel like a kid that grew up with code as a second language; where I can read and understand code but can't write it myself except for some basic things. Sometimes I kick myself for being so stubborn on NOT trying to learn code when I had so many opportunities growing up, but I was insistent on being the artsy one in my family and didn't want to be like them. I'm still a bit stubborn, but I know it would be smart for me to be more involved. Then I saw a post on Medium from Julius Tarng, the designer at Potluck. The title itself pulled me in, "Designers: you can Objective-C, too! How you can help your iOS engineer by getting into production storyboards and Objective-C — if they let you." This looked exactly what I was looking for. A way to get more involved with the pixel perfection in Xcode, but doing minimal damage to the actual code. There's a couple of things with storyboards that didn't make sense in my design mind: The Navigation Controller is screen-shaped, looks exactly-like-but-sits-in-front-of the View Controller (the screen you're actually mocking up), but you can't put any visuals on it. But if you want to apply certain characteristics to that screen, it has to be applied to the Navigation Controller, not the View Controller. Or how you can easily tell a screen to respond as a modal, yet there's not an equally as easy way to make a close button to get out of that modal. For anyone that wants a good hint at making that close button, check out my friend, Bryan Clark's, stuff on Github that he put together to help me with this. Go Fork with it. heh. Just a day or so later, Meng To wrote another equally helpful article, "Learning Xcode 5 As a Designer," that went a little bit deeper on Storyboards through a tutorial with files attached so you could mess around with it yourself and see how it was built. By the end of the day I had my own working prototype in Xcode. I rebuilt some existing screens of my job's current app since I already had the layout and slices done. It's pretty easy to figure out the basics of Storyboards and feels a little bit like keynote. The best part was, I didn't get least bit frustrated, I was actually getting kinda giddy. That same excitement of seeing something that I actually built, in my hand. There were a couple of things I got stuck on, but I just went back and forth between the two articles and found some other things online. The dev at work was more than happy to help explain things to me, and was even more excited at the idea of working like this on the future iteration of the app. Later in the week, Meng To released another article/tutorial with attached file examples about his new product, Canvas, which allow you to animate in Xcode without code. This is what I'm playing with now, but I haven't quite mastered it yet. So anyone that is a mobile designer, I encourage to you at least play with the tutorials that Meng provided. It feels good to learn something new and it might actually help you understand what you're making a little better.

One thought on “How to help your iOS dev in Xcode, as a designer.

  1. Great article! As a developer, we want to execute your vision as closely as we can.

    The reason for the minor faults between designer and dev basically boil down to two things in my experience.

    1. Things we overlook, such as a drop shadow or other detail that is subtle but important to the design. I chalk this up to a left brain vs right brain thing.

    2. “Impedance mismatch” between the tools (Photoshop vs Interface Builder in Xcode). A common problem of this sort is vertical line spacing, something that is apparently customizable in Photoshop but not in IB – it has to be done with code.

    I like the idea of designers tweaking in Xcode, as it helps you understand our side of the fence!

    Other things designers can do to help developers better execute on your visions:

    1. Give us a “style guide” that lists all the fonts and point sizes in the app, each with a unique name (“Heavy Titles”) or a code (“F1″.) Then tag the mockups with these codes. This eliminates us having to guess what the font is, or the point size.

    2. When giving us colors, we need them in RGB values. These can also be part of the style guide so we can set up a category on UIColor with all the customized colors the app needs. This eliminates us having to try and eyedrop the color from a screenshot (which is sometimes off in significant ways) or use a hex->RGB converter on the web somewhere.

    3. Clearly tag the spacing between elements and between screen edges, in pixels. This again prevents us from eyeballing it and making a mess of the design.

Comments are closed.