Bummer! This is just a preview. You need to be signed in with a Pro account to view the entire video.
Dev Track: iOS Development: Designers + Developers - Rachel Parsons30:09 with Rachel Parsons
Rachel has been programming professionally since 2003, but has been heavily involved in computers since the mid-90s. She was building computers in middle school, embraced web development in high school, and got serious about object oriented programming in college. Initially, she thought she wanted to be a web designer, but she found web design wasn’t challenging enough and returned to programming. When she learned java, she finally realized how fun programming is. Currently, she's a principal software developer for an IT consulting firm, Cardinal Solutions. She works for a variety of clients on a variety of applications including mobile apps, BI dashboards, web applications, windows applications, services, APIs, and everything in betwee
[iOS Development: Designers + Developers - Rachel Parsons] 0:00 [Blend Conference 2013] 0:03 So I'm an iOS developer currently. Recovering .net developer, recovering Java developer. 0:04 Done my stint with Web application development, and now mobile is really where my passion is. 0:11 So what I kind of want to talk to you guys today about is 0:17 the mutualistic relationship between designers and developers, 0:20 specifically in the context of mobile development, 0:25 and a lot of my examples and kind of specific, concrete points are going to be geared towards iOS development. 0:29 But really, it applies to any kind of mobile development, 0:37 and I think we have a few designers arguing that it applies to all development these days that they are involved in. 0:41 So what is mutualism? 0:48 This is a biology term, and according to Wikipedia, it's the way two organisms of different species 0:51 exist in a relationship in which each individual benefits, 0:58 and I would argue that designers and developers are generally pretty different species. 1:02 We have different ways of thinking, different jobs, different ways of approaching a problem, 1:08 but we can figure out ways of working together because our jobs are more and more closely tied together. 1:14 So some examples of mutualism. 1:20 What am I talking about in biology? 1:24 Pollination is probably one of the easiest examples, bees going from flower to flower, 1:26 getting their nectar to make honey and at the same time pollinating flowers. 1:33 In the oceans we see this with clown fish and sea anemone. 1:39 Clown fish fight off the sea anemone's natural enemy, butterfly fish, 1:43 and the sea anemone are poisonous to most fish and thus protect the clown fish. 1:48 And then on land we see this with mammals even. 1:53 Mammals and some birds have a mutualistic relationship. 1:56 Rhinos and impalas like the one pictured get ticks and other parasites on them, 2:01 and the oxpeckers will actually eat those ticks and other parasites, 2:06 thus, you know, kind of doing a service for the impala. 2:10 So, do we really have a mutualistic relationship? 2:15 Are designers and developers really made for this? 2:20 Because I think this is sometimes how we see each other. 2:24 Developers—we see ourselves as these scientists. 2:26 We're curing cancer and solving the world's problems, and designers are creating these beautiful displays and wonderful shows, 2:30 and getting the applause, and we see each other very differently. 2:37 Designers may think that we're developers in our basement, we're kind of nerds, 2:42 always have our heads stuck in some hardware, 2:47 and we developers look at designers—ugh, take your finger paints and go make a pretty picture. 2:50 But I would argue that we're really 2 different pieces of the same puzzle, especially when it comes to software development. 2:56 Because without each other we don't really get a full picture. 3:04 We get some very disjointed things whenever we don't work together. 3:09 This is an example of what a developer might design, at least in the mid '90s or early 2000s. 3:13 This is what typically happened when developers would create UIs. 3:22 We are very logical. Some of us are really, really literal. 3:29 You need a check box that's on or off, and you need all 50 of them on the same screen. 3:33 Of course, because what user doesn't want all those options. 3:37 And what we really run into is that this isn't usable. 3:41 We would lose customers, we would write software that people wouldn't use, 3:46 and personally, that kind of sucks. 3:51 When I write all the software, I go through all this work, release a product, 3:55 and people are like, "Well this sucks, I'm not going to use it." 3:58 Even in businesses where it may even be important to their job. 4:01 But when we work together, this is the kind of thing we can build. 4:04 This is a converter—this is a conversion app that a couple of friends of mine built. 4:10 It's an iOS app, and a designer and developer collaborated on it 4:16 and built this really beautiful application, this beautiful UI. 4:21 And sure, I as a developer could easily throw up a couple of text boxes with a switch to switch the fields and a number pad, 4:26 but I think what you really get with a designer is the detail. 4:35 You know, it's the button—the to/from button, that toggle that will switch the 2 values of the fields. 4:41 It's the information button down at the bottom right. 4:48 It's those little details that designers really pay attention to. 4:55 They go out of their way to refine their designs and create something really beautiful, 4:59 and I as a developer can then take those designs and manifest them in a product. 5:04 So how do we do this? 5:11 We're changing the way that we work. 5:14 Designers are more and more a part of the software development team, 5:18 but we have to educate each other first. 5:22 We have to—developers and designers, it's really important for us to talk to each other, 5:25 to communicate, and to educate each other about our fields of specialty. 5:29 We also have to learn the user interface guidelines. 5:35 Mobile—it's a huge thing in mobile, especially with Apple and Android, and even Microsoft has followed suit with their platform. 5:38 So whether you're doing Web or any other technology, 5:46 if you're targeting a mobile device, you have to learn the interface guidelines, 5:49 and that goes for designers and developers. 5:53 And then designers and developers should collaborate on the implementation. 5:56 A designer can't just throw a designer over the wall and say, "Okay, go create it," 6:00 because maybe the designer created something that's going to take me weeks to implement. 6:05 If we had worked together, maybe we could have come up with a solution 6:14 that matched the timeline and our resource constraints and still met the need of the users. 6:17 So I'm going to talk about each of these three things in a little bit more depth starting with education. 6:24 So what do developers need to teach designers? 6:31 What can we do—what can I do to help my designer understand my process and get better? 6:35 One of the things that I think is most important is to explain clearly, 6:41 not to use any crazy—designers aren't stupid, but you don't necessarily need 6:46 to use the specific technical jargon of your chosen platform when you're explaining why you can't implement something. 6:52 My designer doesn't care that this complex algorithm is taking place under the cover 6:59 so we can't implement that design, 7:05 but she does care that hey, you know what, it's going to take me 3 weeks to get this working right 7:07 and then get it performing properly, and we may need to readjust. 7:12 We also need to develop the details. When a designer comes up with a detail, 7:16 comes up with a design, we need to make sure that we actually implement it. 7:21 There's no ignoring that drop shadow at the bottom of the rectangle, 7:25 like, oh, nobody will notice if that one pix of border that isn't there or if it's the wrong color— 7:30 that stuff does get noticed. 7:36 Users don't ever know that's what it is, but they know that looks off, that looks totally off, 7:37 I don't even know what that looks like. 7:43 And then the other thing that developers can really do to educate themselves is to learn about design. 7:47 Gone are the days when you can be ignorant of what users are using our apps, how they're using our apps, 7:53 and the things that they're expecting out of our apps. 8:00 We have to learn about good design. Read a blog or article, pick up the user interface guidelines and go through that, 8:03 or just look at what other people are doing. You know what works and what doesn't. 8:10 So pay attention to why. 8:14 And then designers. How can you educate us as developers and educate yourself as well? 8:18 When you have a design and you have a layout or something that you've done on purpose, you have a reason behind it, 8:23 and I as a developer come up and say, "I don't like that. I think that looks goofy," 8:31 well you have a reasoning, so don't just tell me to do it because you say so, 8:35 nobody likes to hear that. Didn't like hearing it from my parents, 8:39 didn't like hearing it from my teachers. Let's have a conversation. 8:42 Why is it important that a button should be in a certain place? 8:47 Why is it important that an icon be a certain shape or color? 8:50 And then it's your duty as well to learn what other people are doing, see what works, 8:55 look at other examples—I think that's a great way to come up with ideas when you're struggling through a problem, 9:01 building a form—you know it's really easy to take Web forms and convert them straight to mobile, 9:07 but that, ugh, that's never a good thing. 9:12 So how do other people do it? How have other people implemented solutions for those same problems? 9:15 And then learn a little bit about the technology. 9:22 As designers, it's really important for you to know the limits of a technology stack. 9:25 You don't have to know—again, you don't have to know the algorithms, you don't have to know how to write code for it, 9:31 but it's really helpful if you understand the performance differences between using an image 9:36 or using a poor drawing, hand drawing a line or something like that, 9:41 and that will come into play in the collaboration on implementation. 9:46 So, a little bit more about the UI guidelines. 9:51 You know, it's all of our responsibility, if you're on a mobile project of any kind, 9:56 again, Web or otherwise, every platform has its guidelines, 10:01 and those guidelines are generally a little different. 10:06 Android versus iOS versus Windows Phone versus whatever anybody else is doing— 10:08 Those guidelines are there not as a solid path. They don't say you have to do it this way, 10:14 but they do say it's recommended on an iOS device that the back button be in a certain place. 10:22 So they are there for all of our benefits. They help really just give us a path, 10:27 so read them, learn them, and love them because you'll be mired in that documentation a good bit as you're working with your design. 10:35 So, specifically, one of the UI guidelines is overarching in general is to be consistent, 10:46 and we're not just talking within your app because it's no longer 10:54 okay, the person is in my app, so I can put the buttons wherever I want. 10:59 You have to be consistent with the platform. 11:03 An example of what I am talking about—this is an alert box in iOS. 11:06 The OK button is on the right, and the cancel, the don't allow, the negative button is on the left. 11:12 That's a standard. In iOS it's opposite. In Windows Phone, I believe it's also opposite of iOS as well, 11:19 so this is one of those caveats that you have to know about, and you have to be consistent. 11:30 Because if your iOS users see the Android style, you may have some usability issues just because you didn't follow a UI guideline. 11:35 Next focus on the primary task. I don't know if you guys have ever used Clear, but this is a screen shot of it, 11:46 and it is a very simple task management app. 11:54 It's very straightforward, it's very clear, and it's focused. 11:59 The user isn't doing anything else, not managing his calendar and his task list, he's managing one thing, his tasks, 12:03 and that's all he's focused on. You don't need to overload a UI with a bunch of stuff just to get one thing done, 12:11 especially on a phone where you have limited resources or limited real estate. 12:20 And then be prepared for curve balls. 12:25 This is something else that the UI guidelines will tell you, this is in the Apple documentation. 12:28 What I'm referring to is the navigation bar, this bar at the top where All Contacts is, 12:33 that nav bar is 44 pixels high in portrait. As soon as you rotate it, it's 36 pixels high and the font size is different, 12:41 and the buttons inside are different, so if you've got custom images or a custom drawing or custom anything that is dependent 12:51 on that layout being a certain way in one orientation, reading the UI guidelines will help you figure out, okay, 12:58 now I'm going to support landscape, so I need to adjust, I need to make sure that my design is adjusted for that, 13:06 and I think that's something that designers would really benefit from reading the guidelines and learning them, 13:12 because as a developer I may overlook that. Ah, who cares. It's 8 pixels. 13:19 Just make sure that my layout lays out and that's it, but to a designer 8 pixels might as well be a mile for a lot of them. 13:25 And then go beyond the guidelines. Like I said, the guidelines aren't a strict "Here's how you do everything," 13:34 and that's because you kind of have to think outside that box, and you have some opportunity. 13:43 Specific example: This is a screenshot of an app I've worked on. 13:48 We had a form that the user had to fill out, and because it scrolled we decided to have a reset on there. 13:55 It's a little bit longer form. So, initial design was to put the reset on the left and search on the right 14:00 to follow that guideline that I talked about earlier, the positive, the OK, move forward action on the right 14:08 and the cancel, negative, destructive action on the left. 14:16 What I found was that we had a couple of users come back and say, "This is confusing. Can we switch the order of the buttons? 14:22 "Can we put search first and then reset?" 14:30 So I'm going back and forth with this client, just me, as a developer, with my client, 14:33 telling them about, well, that's not really the standard, and I think it will be confusing the other way, 14:39 and what I ended up doing was going back to the designer and chatting about it. 14:44 So I go back to the designer, and I'm actually looking for him to back me up, 14:49 and he says, "You know, let me ask you this. Why is the reset button so prominent? 14:53 "Is that even necessary"—that was actually the first question, "Is the reset button necessary?" 14:58 But then if it is, why is it at the same prominence as the search button? 15:04 What he suggested was brilliant. Demote the reset button to something that is way less of an option to click, and you've solved the problem. 15:11 We've eliminated any kind of discussion with the client—that's a really simple fix for me as a developer— 15:24 that's fine, move the order around, change the button style, and that's it. 15:31 So, that was just a really good example of where, me as a developer, I'm fighting this fight 15:34 and I think I know the answer, but my designer can come in and give me this perspective and a solution that solves all the problems. 15:40 Go back to the client, he's happy, I'm happy, everybody's happy, and it's usable. 15:47 So onto implementation. 15:51 Once you know the guidelines and you have kind of your framework, 15:55 you have to be able to talk with your designer or your developer about implementation. 16:00 you have to collaborate on that, the actual technology and the actual way—I'm going go write that code, I need to talk to my designer about that. 16:05 Then we need to know the tooling, and that's everybody. 16:13 That's the designers—anybody that's going to be involved in the software development, 16:16 I think it's really important for you to understand the tooling. 16:22 One of the cases is image slices versus core graphics. 16:25 So do we have any iOS developers in the house? Yeah, okay, we've got a few. 16:32 So you guys are familiar with core graphics. Even if you haven't done iOS development, 16:39 I'm sure most of you guys are familiar with having the ability to draw via code 16:43 whether it's with canvas in HTML5, with core graphics in iOS, you can do it with just about any language that has any kind of graphical interface. 16:52 But that requires code. Image slices, very traditional. 17:03 If you've done Web development, which I believe most of you, if not all of you, have, 17:08 it's just putting images together on a screen to create the illusion of a button when it's really just an image, 17:12 a gradient, or whatever. So having this conversation will really benefit you because 17:20 those 2 options have very different ramifications. 17:27 One is more performant than the other, but one may or may not be future-proof, 17:30 so when iOS 7 comes out, how are you going to be able to support—are you going to have to rewrite that section 17:37 where you implemented something that used image slices versus core graphics. 17:42 Are you going to have to re-implement a solution for a problem when a new version of the OS comes out. 17:48 So I'll show you an example of image slices and just show you kind of the line of thinking that we used. 17:54 I know it may be a little bit difficult to see this because it's so bright in here, 18:03 but this is, again, another app I've been working on, 18:08 and what we have here is—the designer came up with a stamp-looking detail section, 18:12 so there's a border all the way around that looks like a stamp, 18:20 there's a background that you totally lose on the presentation, 18:23 but there's a really subtle dotted pattern in the background, 18:27 and then of course you have all the elements with a dotted line separating the buttons. 18:33 So I call up my designer, I'm like I don't even know where to start because I can't draw this. 18:38 A stamp pad is a zigzag, and drawing that in code is just—that's not going to work at all. 18:44 So we talk through, does this need to be resizeable? 18:51 Yes, you know, I have addresses that will vary in height, I have multiple buttons that I may have to put on here, 18:54 if they have a website, I want to put additional sections in this view. 19:01 So how can we make it flexible enough without going through all the complexity of having to write all that code to draw it? 19:05 And this is what we came up with. We came up with 4 slices actually but with a pattern. 19:14 It's so subtle I can't even see it on my screen. 19:20 I just trusted that my designer put it in there and went with it, 19:23 but we came up with these 3 slices. Said, you know what, this isn't resizeable horizontally but it is vertically, 19:28 because I can stretch and repeat this middle image, but I still get the top, and I get the drop shadow at the bottom, 19:37 and I get that zigzag pattern all the way around. 19:43 This was, while it was not the prettiest code I've ever written, it was way better than trying to create these lines and these patterns in code. 19:47 It was just way more efficient to do it this way than with core graphics, 19:57 and probably a little bit more efficient from a view display performance perspective as well because it's very quick to throw an image up on a screen. 20:02 So an example of core drawing, core graphics that I'm referring to. 20:13 Same screen, except at the top, I've highlighted the top now, 20:19 the top section up here in the header, it's a gradient, consists of a gradient, linear, light gray to dark gray, 20:24 and then a really subtle border at the bottom, and then a drop shadow underneath that. 20:36 I said, you know what, we don't need an image for that. 20:41 It's going to actually probably take me more time to implement a stretchable image and try to do all that stuff. 20:46 I've got all the code to do a drop shadow, so I'll just implement it that way, 20:50 and it will be way more performant because it doesn't take any time for the device to draw those simple graphics. 20:55 So, I know you probably can't read this code, but this is the code to draw a gradient. 21:02 It consists of a couple of colors, you stick those colors together in an array, give them locations, 21:09 and then draw that in code, so this is all that was required, I don't know, 8 lines of code to draw the gradient. 21:18 This is the code to draw the inner shadow—that's what my designer called it. It was really just a black line with some opacity on it. 21:27 Yeah, this is a little bit more, we're still talking 8 or 9 lines of code, but like I said, it was almost nothing for me to throw this together. 21:35 It's a start point, it's an end point, my designer was able to give me the coordinates, give me the colors. 21:45 I just throw them into code because I already have this, I already know how to do this. 21:50 And then this last part is the drop shadow. Again, very simple, 5 or 6 lines of code. 21:54 It's very quick and efficient, so it is very simple to implement. 22:01 So that was just an example of the 2 different options and some of the ramifications of such. 22:08 A little bit more about core drawing, because—this is a specific example of where we did have a conversation, 22:15 should we do image slices? Does that make sense? 22:25 And in this case, with it being circular and there being probably a lot more trigonometry to laying out slices, 22:28 I suggested, you know, I can probably draw this pretty quickly using a tool 22:39 and get the gradients as long as we can agree on the gradients and actually a little bit of paired designing, kind of. 22:45 I had the tool up, and I wasn't quite sure what the gradient was supposed to look like, 22:53 so I call my designer over, "Hey, come here, is this right? Does this look how you intended it to look?" 22:57 So we tweaked it a little bit and were able to get this. This is actually a screen shot out of the app. 23:03 So the tool that I'm talking about is Paint Code. If you do any iOS development and you have to do any kind of core drawing, 23:11 I highly recommend this app. It's a great app by a company called App Code, 23:19 and basically I was able to draw this gradient, or series of gradients actually, 23:24 in, I don't know, maybe a couple of hours to get it exactly right, and that's just because I had just bought the app, 23:31 and I wasn't real familiar with it, and what it does is when you draw these shapes and sizes and gradients, 23:37 it actually generates the iOS code for you, which is really pretty cool because it gives you at least a foundation to start with. 23:44 I had to make this resizeable, which is the other reason that we used core drawing instead of images. 23:51 Any time you have a gradient you have to decide can you resize that gradient and maintain its gradientness. 23:57 So here, this is just a really great tool. I am actually advocating that designers get this tool and be able to use it, 24:05 because a designer could have easily done this in Paint Code versus Photoshop, 24:15 and gotten effectively a base code for me to start with without ever having to employ me. 24:22 So knowing the tools is a huge part of this, knowing what tools you have available and being able to use them is really important. 24:28 Designers need to learn source control, you need to learn how to interact with git and even subversion if you have to, 24:40 but you have to be able to commit your assets, images, and slices, 24:48 and I would contend it's even helpful if you know a little bit of code. 24:55 If you know how to edit points or colors, those things are really actually straightforward if you go and look at the code, 24:59 so knowing the tools—I highly recommend the designers download and install Xcode if possible, 25:08 and I've got a screen shot of that up here because I know some people haven't seen Xcode. 25:14 If you haven't seen it lately, it's got some really awesome features, 25:19 even now, and it's going to have even more awesome features next week when the new version is released. 25:24 My point in showing this specific screen shot is that it's very graphical. 25:30 It's still a very visual tool, and it's referred—this part of Xcode is called Interface Builder. 25:36 Of course you have the code and it looks like any other IDE, 25:44 but the actual UI development interface is called Interface Builder, and with storyboards, 25:49 which is another feature that your developers would have to be using of course, it actually lays out the flow of screens, 25:55 so a designer who maybe isn't familiar with iOS development could easily come in here and see 26:02 this is the start, this is where the user would go if they click on these buttons, 26:07 and here's where the user could diverge, and this is kind of what they're going to see. 26:12 Of course, it doesn't show everything that you're doing behind the scenes in code, 26:17 but at least gives you a starting point. 26:20 I actually pulled this screen shot specifically because it came off of a blog post from a guy who was advocating prototyping, 26:23 rapid prototyping in Xcode and iOS, which is something I haven't fully vetted yet because—there's some caveats to that— 26:33 but he had a whole template, and this is the template for anybody to really kind of start off that effort, 26:44 for a designer to come in and just kind of throw some elements on the screen 26:52 and get a flow together, and that's really helpful, because if a designer and developer can get into that prototyping cycle, 26:57 that's going to be way, way easier for both parties, and it will be more efficient. 27:04 We'll get out of this waterfall design, develop, design, develop—we'll get out of that cycle and get into a more collaborative environment. 27:10 So to wrap up, we need to educate each other. 27:20 Designers and developers—I think if anybody was in Adam's workshop yesterday morning, 27:26 he gave his opinion that designers and developers should be the best of friends, 27:31 and I wholeheartedly agree with that. I think that's a great idea because if you're not friends-ish, you're not going to be able to communicate, 27:36 and it's really important to communicate with each other, because that's how you're going to educate each other. 27:47 You can empathize with your designer, you can empathize with your developer the more that you get to know those people, 27:51 and you can educate each other on here's how I work, here's how that process works, et cetera. 27:58 And then learn, utilize, and go beyond the user interface guidelines. 28:05 Those are your buddies, you know, your other tools that you always have in your back pocket. 28:10 When a client is asking for something, I don't see the value in it, refer to the user interface guidelines 28:17 and then go beyond them when something isn't clear, when you're going round and round about some design decision, 28:23 go beyond it, think outside of that box, and developers, designers, collaborate on that. 28:30 Collaborate on implementation. Designers, when you're coming up with something, 28:36 send your developer an email or stick your head around the cube and say, "Hey, is this going to make sense? Can we do this?" 28:41 And then understand the tooling. Use the tooling. Your developer, I'm sure will—well, he should be happy—to help his designer to learn git 28:49 or learn Xcode or get Paint Code and that kind of thing, 28:58 because ultimately we can live in harmony, we can be friends, we don't have to be the nerdy developers and the finger painting artists. 29:04 We can be productive and bring that puzzle together into something really beautiful. 29:15 I pulled this image out of an article on Smashing magazine because I felt like it is— 29:21 it's a great image describing how integrated development, technology, code, and all that infrastructure is so important, 29:27 but without the skin of design, without the bones of copy and content and all those things that designers 29:39 and even other members of our team might bring, 29:46 without that stuff, what's our technology? Who cares? 29:50 Nobody will use my app if they don't see the value in it. 29:54 So, I encourage you, if you know a designer, be friends with him. 29:59 If you know a developer, be friends with him, and we can all get along and make beautiful, amazing things. 30:03
You need to sign up for Treehouse in order to download course files.Sign up