The panelists talk about prototyping with Jay Thrash.

 

Give me one second!

I can’t. Time is non-transferrable.

Hey everybody and welcome to episode 85 of the iPhreaks Show. This week on our panel we have Jaim Zuber.

Hello, from Minneapolis.

Pete Hodgson.

Hello from still-wet San Francisco.

I’m Charles Max Wood from DevChat.tv and this week we have a special guest, Jay Thrash.

Hello, from North Carolina.

Still in North Carolina, huh?

Yes, yes I am.

We had you on about a month ago, but do you want to introduce yourself anyway?

Sure. I’m here in North Carolina; I live near the Research Triangle area. I’ve been here for quite a while, working amongst my fellow technologists, and for the past three or four years, I’ve been very involved with iOS development and really enjoying it.

Awesome. We brought you on today to talk about prototyping, and this is something that I’ve been interested in. I have some apps that I want to build, but I would like to build some prototypes and show them to people before I actually go build them. Is that the kind of prototyping we’re talking about?

There are actually I guess two mediums of prototypes that I like to deal with, and it all comes down to whether we’re going to talk about paper versus pixel prototypes. I think that both forms have quite a bit of value when it comes to building successful applications in a fairly reasonable amount of time.

Basically what you’re saying is you can do it with a pen and paper, or you can do it with an application.

Exactly. When I’m working on ideas for a new app, or even if I’m working through ideas for a feature for an existing app, a lot of times I like to start with paper prototypes.

Initially, it’s probably just a lot of rough sketching, and I like to think of these as my unit tests for my ideas. With pen and paper, it’s very easy to sketch out a lot of ideas and work my way through a

user interface or a workflow in a way that allows me to catch maybe dead ends or missing steps that I might not have realized that I needed before I started sketching out those ideas.

Do you find that there’s any more or less impedance using a whiteboard or something as opposed to pen and paper?

I guess it depends on the setting. I feel like I’m more productive when it comes to sketching when I use pen and paper, but if it’s more of a group setting, I could see how whiteboards would be useful.

I also like to do a lot of the sketching on paper because it’s easier to retain and show it again later, whereas whiteboards, you don’t want to sketch out some great idea and then have the “Do not erase” on it for the next three months while you worked through it.

There are some techniques that I’ve used with some of the teams that I’ve worked with. We have what we call sketch boards where we sketch out ideas and put them on this big piece of craft paper, and then at any point, we can roll that big craft paper up and move the collection of prototypes around if we need to.

That makes sense. It’s kind of like doing them on sticky notes and being able to move them around.

Right, right, but at a little bit of a larger scale I guess.

Yeah.

Do you ever take those prototypes and take them to a coffee shop and grab random people and ask them what they think of them?

Not so much with the paper prototypes. I think that when it comes to getting feedback from people outside of the team, I found that what I call the pixel-based prototypes – prototypes that are running on the device – are a bit easier to test in those environments.

For the paper prototyping, that’s usually taking place – at least for me in my experience – amongst the team that I’m working with. I find that it allows you to, in a sense, externalize your thinking, so rather than – if I’m talking to you about a feature and I’m just describing it verbally, at the end of that discussion, you and I might have somewhat different understandings of how that feature might actually work.

But if I sketch something out, even if it’s in a rough form, we now have this shared visual understanding of what it might look like and we’re both much closer in that overall understanding.

I’ve definitely had that experience not just with UI-based stuff, but even software stuff, like talking through something and we’re like, “Okay, great. We’re on the same page here” and then we go to draw an outline and like, “Wait, wait, hold on.”

Right, and it’s a lot better if you work out all of those inconsistencies and misunderstandings as early in the development process as you can. You certainly don’t want to be discovering that stuff when you’re a couple of weeks away from shipping or something like that.

Are there any tips that you have for drawing it on paper, certain things you want to make sure you get or don’t miss?

I think probably the first tip and the thing that I think is most important is just to do it, just to try it. I know early on, I was very reluctant to do it because I’m not an artist – I work all day by typing on keyboards. I’m not using my hands to draw really nice things, but I had to get over that misunderstanding that I’m sketching out my ideas; I’m not drawing my ideas.

Sketches can be very rough and lightweight and just practicing and getting through that will allow you to understand how much value I think that there is in sketching out your prototypes or your UI designs.

Part of me wants to get those markers – the dry erase markers – that write on dark surfaces, and then vandalize my iPhone. Or just something about the same size, anyway.

You can get those notepads or you can just draw around your iPhone.

Right. I found when I’m sketching out something that I want to be about the size of an iPhone screen – well, I guess this won’t work anymore now that we’ve got the iPhone 6 and 6 Plus – but something the size of a business card or a credit card, if you just put one of those down on a piece of paper and trace around it, you’ve got a rectangle that is pretty close in size to the iPhone 5 screen size was. That’s a quick and easy way to sketch out those screen sizes. You might draw ten of them across a page and then use those to work through a series of screens.

Is there a concept of dealing with different screen sizes, or if you’re prototyping an app, do you just prototype out the iPhone app and then go back to the drawing board, so to speak? Or I guess, literally, this time for the iPad or whatever?

Yes. I think that for those different screen sizes, because it’s just pen and paper, it’s pretty easy to go back and re-sketch things for what it might look like, given the different dimensions of the screen sizes. You can certainly compose the larger screen based on some of the individual components you have on the iPhone screen.

I know these days, what they call card-based UIs are very popular. What you might do is design what an individual card looks like in your UI and then perhaps on the iPhones sketch, all the cards are laid out vertically, but in the iPad sketch they’re laid out in a grid fashion.

And then you could use other really lo-fi techniques like sketching things out on sticky notes, and then you can move them around. You could say, “Okay, this is what it looks like when it’s on the iPhone screen, but if I take it and move it over to this other sketch, this is how they’re going to lay out on the iPad’ and you could move things around and show where things go when they get deleted or reorganized into folders. It all depends on what kind of UI you’re trying to put together.

I find it surprising how much adding a physical element helps people brainstorm through that stuff collaboratively, like having things on stickies and standing at a wall or a whiteboard or a table or whatever and saying, “What if we do this thing before that thing?” or “What if we put this thing inside of that other thing?” and having that conversation, moving pieces at the background. It’s really surprising how much more engaged people get in the conversation; you draw people into that conversation like that.

Right. I know in some of the environments that I’ve worked in, we like to keep those sketch collections up on a wall so people can have access to them whenever they want to and reflect back to them as inspiration. You might be in a phase of the app when you’re actually implementing the UI and you might not remember, “Okay, why are we doing it a specific way?” If you’ve got all these original sketches and things around, you might be able to spark a memory that makes you understand, “Oh yeah, that was why we decided to do it this way, because some other thing we had to avoid, some pitfall in a previous design.”

I’m wondering – I’m a freelancer; I know Jaim is as well, and Pete works for a consulting company. Are clients usually pretty open to the hand-drawn things, or do they want something with a little more polish that's done with pixels?

Well, I think that that’s going to depend on the client; it’s going to be different for everyone. Based on your interactions with them, it might be kind of a larger client that is expecting more refined mockups for you, or it might be somebody who’s a small project that your helping someone get their first app in the App Store and they’re okay with low fidelity sketches.

I think that certainly internally, just as you’re trying to get a lot of ideas out of your head and collect it on paper – that’s where I think the real value in these lie. And then once you’ve refined that idea and maybe laid out potentially a majority of what the app interface might be, then you can maybe change focus and start working with some of the more pixel-based prototyping tools, and then that could be the things that you share externally with people.

That’s true. I guess you have to communicate with your client just to find out what they expect.

Right.

I think for some people, it actually really helps to make it look not finished because it a) communicates that there’s still a bunch of work to do. You don’t get that problem of “Oh, you’re done, look at that! The Photoshop looks great! Let’s ship it” and it leaves it more open, again, to collaboration. If people see it’s a sketchy thing, ideally, if they’re standing next to you while you’re sketching it, then again, they can get drawn into collaborating on it rather than feeling “Ooh, graphic design – I’m not qualified to do that [inaudible 12:42]” or “I don’t know how to use Photoshop so I can’t contribute to this discussion.”

There are even a lot of app prototyping tools out there that intentionally use that rough, handdrawn look because they want to reinforce the fact that these are just prototypes; these are not finished products. So it helps [crosstalk 13:02] prevent that misunderstanding with the people that you’re sharing it with.

I was working on a web app and I disagreed with the idea in general, but that client wanted to do the design, do the fit and finish of the CSS later and just wanted to get the information architecture out. I didn’t want to get hung up on the work progress UI, so I did all of the fonts in Comic Sans just to make it really clear that that wasn’t the final UI. But I’m not sure that actually worked out that well; I think the client got really annoyed at me for using Comic Sans.

I had a similar issue come up with one of the designers I work with where he said that he had a client that actually commended him on his selection of Comic Sans because they felt like it really captured the look that they were going for even though he was just using it as a pure placeholder font.

That sounds like a very high-risk situation [chuckling].

Yeah [chuckles], exactly.

Yeah, but I’ve had that where I sent a client the .psd – I just exported it to a .png, sent it over to him and they emailed me back, “Wow! You got that done fast!” I was like, “Well, that’s just the design” and they’re like, “Well, when are you going to launch it?” They thought that I had finished the app and taken the screenshot. The low fidelity does help with that.

All I have to do is code!

That’s right! That’s it! [Laughs]

Yeah, a simple matter of coding.

It’s just typing.

Yeah. “I’m almost done, just give me a few weeks!” And with the hand-drawn, I mean it’s usually pretty obvious that it’s hand-drawn, unless you’re extremely talented and spending way too much time on it.

That’s one thing that I’ve seen with a lot of these tools like Balsamiq Mockups and things is that their prototypes are drawn lines. It looks like it was hand-drawn almost, so it’s pretty obvious that you’re not going to go with that as the final design; it really is just a prototype, and it shows.

Right. While we’re still on the topic of paper prototypes, one technique that I’ve found very useful is the idea of what’s called speed sketching sessions – I think it’s what some people on the Internet refer to it as, where you timebox yourself in a session where you’re going to sit down for maybe five or no more than ten minutes.

This works great in a team setting where you have a specific component or maybe a workflow within an application, and for the next five or ten minutes, everyone’s going to sit down and come up with as many variations on that idea as they can. It’s not about refining it; it’s all about divergent in exploration design. And then at the end of that time, everyone presents their ideas and they can defend the decisions they made and then everyone can pull the best ideas from all of those sketches and then use them in future sketching sessions.

The next session will be based on ideas that came out of the first one and then you refine it and refine it further until you come up with your final design.

That sounds a lot like the idea of these design charrettes, which, according to Wikipedia, the origin of the word charrette is French for “cart” or “chariot.” The design charrettes is a very similar idea where you just get a bunch of people together. I think it’s pretty much the exact same thing you described where you just brainstorm by building a bunch of wacky ideas and presenting it to each other.

Right. But I think the real value comes out of them when you constrain yourself as much as reasonably possible. You say, “Okay, for the next five minutes, sketch as many ideas as you can for this particular thing” as opposed to just come up with whatever pops into your head.

Let’s start talking about some of the pixel options that are out there. You’ve got an article here form thoughtbot on animating with Keynote, and I’ve actually purchased some Keynote – I don’t even know what to call them, like little slide doohickeys that you just stick on there and they represent something that’s in your webpage or in your app. So you get buttons or whatever and then you can actually make it so that button goes to a different slide, so if somebody clicks it, it acts like the app.

Have you used tools like that before in the past? Jay, [crosstalk 17:29]?

Oh, absolutely. I’ve definitely used Keynote. Keynote is one of my favorite pixel prototyping tools right now. It’s pretty amazing how powerful the drawing tools are within Keynote. Now that we have Keynote on iOS, it has the added benefit of actually being able to access these prototypes on the final device, which is hugely valuable when it comes to getting feedback on those prototypes.

There was a collection of templates that I remember using called – I think it was Keynote Kung-Fu. It might be at keynotekungfu.com. It’s a collection of both web and mobile control widgets so that you can very quickly compose a screen on these UI elements that’ll look like UI elements on the actual device.

Yeah, those look pretty nice. I’m trying to remember which ones I’ve picked up. It might have been this; it might have been something else. It’s nice because if you open up keynote – I’ve done demos with this kind of thing too, and it’s high enough fidelity too to where people think that you’ve finished the app. But if you make it pretty apparent that it’s in Keynote and so it’s a slide that’s just a little more interactive, then a lot of times you can get away with having a higher fidelity prototype and have them still understand, “Look, this isn’t an actual thing you can stick on your phone.”

Right. There was a really great session at WWDC this year; I believe it was Session 23 and it has the awesome title of Fake It Till You Make It. It was a presentation by three people in the Apple prototyping team, talking about the processes that they go through when it comes to prototyping and designing applications within Apple.

They talk about how using Keynote is a vital part of that prototyping process for them because it lets them build out screens and take those screens out into the world, so to speak, and share them with fellow Apple co-workers and gain feedback from those co-workers on how they feel that that particular prototype, whether it’s accomplishing the goals that they set out.

Yeah, it makes sense. I think the one I bought was Keynotopia.

Yes, I’ve heard of that one. That one also has, I believe, collections of widgets for other presentation apps like PowerPoint, so if you’re on a non-Mac or iOS platform, then there are other options for you out there with – what was it? Keynotopia?

Yeah, I’ll put a link in the show notes. The Keynote Kung-Fu also looks really nice. [Crosstalk 20:12] The good thing is you have shapes in Keynote, so you can just put a square in there and tell people it’s a button.

Exactly, right. One thing I like to do is go on some of these websites like UXArchive and Mobile Patterns and some of these other sites where they curate great designs for mobile applications. If I see a screen layout that I think has some great elements to it, I’ll take that screenshot, pull it into Keynote, and then use that as the basis for how I’m going to sketch out where various UI elements are going to be laid out on the screen. So I’ll take that screenshot, crank the opacity down so that it’s very minimal, and then lay my elements out and then delete that screenshot.

Yeah, that makes sense. I want to point out real quick, Keynotopia is for web – there is a flat UI mobile template, but I don’t think it’s this fully whatever is Keynote Kung-Fu.

Okay.

Just to throw that in there. Have you used some of the other tools? I’m trying to remember, I tried one a while back; it’s like a full-on prototyping template deal.

Well the other prototyping tools that I’ve spent the most time using are Quartz Composer with the Origami plugin from the Facebook design team. More recently, there’s been a Quartz Composer competitor called Form, and that is by RelativeWave. You can find that at relativewave.com. I believe they were just acquired by Google. This Form app used to be somewhere around 80 bucks, but after they got acquired I believe they re-released it for free, which is great.

Both of these tools are great when you’re trying to prototype specific interactions within your app. I wouldn’t recommend you using these to prototype the entire navigational structure of an app. You might have a particular screen that’s got a unique interaction on it, something that brings some character to your application and you really want to get that animation or that interaction nailed down, Quartz Composer with Origami as well as Form work great for that. You can really tweak those animations and get them to the point where you feel like they’ve got the right feel to them before you sit down and try to code them up.

That makes sense. I think the one that I was thinking of was Briefs.

Yeah, that was the one I was going to mention.

Right, the one from MartianCraft – that one’s great too. That one is really good when you are needing to share those designs with clients, so I think that one works best for companies that are doing work for other people because the briefs that pass that client app that other people install, then you can share those prototypes with them so they can access them remotely.

I have a question about this, and that’s mainly that – I’ve been playing with the idea of doing some prototyping with one of these tools, but at the same time, it seems like it’s as complicated as Interface Builder. Since Interface Builder is going to be the tool I use to build the interface anyway, is there a reason for me to use some of these tools?

It’s going to come down to each individual application that you’re working on. If you’ve got an app that has a fairly standard UI, a very standard navigational flow, then you may not find a lot of value in using some of these more high fidelity prototyping tools, because you’re going to be wiring up a typical Table View navigation stack or something like that.

People, I think, already have a really good understanding of those built-in, system-level behaviors. It’s when you’re working on things, I think, that are unique to your application, something that’s new and different, that you gain value in prototyping them with these tools before you implement them in code.

A lot of times, the more that you implement things in code, the more that you’re boxing yourself into a particular solution and you may not have the opportunity to fully explore that idea and find its best version of it, so to speak.

You also get into that sunk cost fallacy of “I’ve already built some of it in Objective-C or Swift or whatever, so I’ve got to reuse this stuff for my production code” and then you get unnecessarily constrained to keep what you’ve got rather than throwing it away and starting from scratch.

I think it’s really good to be able to wear different hats when you’re doing different things. If you’re exploring an idea, you should be able to just hack a bunch of stuff together and play with it and move stuff around and have things be really fluid, but once you get down to actually building the thing, you need to go on a different path and start making good quality code, not just throw-it-away code. I think it’s okay to do throw-it-away code; it’s just not okay to keep throw-it-away code around when you should be throwing it away.

I’m glad that you’ve mentioned Xcode and Interface Builder because even though that’s the application we will be using to actually build the application or mobile apps, Interface Builder’s actually a somewhat powerful tool that you can use for prototyping. You might simply put together a series of screens in a storyboard and instead of those screens being composed of actual UI controls like Table Views or Collection Views or something like that, the screens could simply be screenshots from a tool like Photoshop or Sketch, right? And then you’re just wiring them up using segues, and now you’ve got a real application that you can run on the device, but it’s just letting you jump through what will be the eventual real user interface. I’ve seen some people use that technique very successfully for prototyping applications on the device.

On one hand, that’s a good balance for people that already know how to wire up a storyboard and navigation and all that stuff pretty quickly. On the other hand, they get this really down the path of “Hey, this is done, isn’t it? Everything works; it looks like it should work.

Right.

On your phone, even.

Yeah.

I touch it and it moves to the next screen.

Yeah, it’s a delicate balance, because the best kind of feedback you’re going to collect is when people are interacting with your prototypes on the actual device. If you’ve got a series of screens that someone’s clicking through with a mouse or something like that, they might give you some valuable feedback, but I think that until it’s on the actual device, you’re not going to get the real insights that you’re looking for when it comes to working through the designs with prototypes.

As long as you provide as many disclaimers as you can upfront to let people know that these are just mocked up screens; we’re going to walk through it on the device. Hopefully, you’re not going to mislead anyone into thinking that something is final or that that functionality has actually been implemented.

Having dealt with enough clients? There’s no way to do that [chuckling]. [Crosstalk 27:31] touch this and they will still come back and say, “Hey, this doesn’t work!”

Yeah, you can put it in 60-pt font: This is not done! [Chuckling]

Not even Comic Sans will save you.

Nope.

Right. How about Marker Felt?

I’ve tried that one, too!

Is there an electric shock kit?

[Chuckling] There you go. That’s right. “So it’s ready to ship!”

I’m wondering, how do you pick the right tool? Let’s say I’m starting up a new application, what questions do I need to be asking myself in order to say, “Okay well I should sketch this out on paper” or “I should be using Briefs” or “I should be using Quartz Composer” or “I should go straight to Interface Builder or maybe Keynote”? What are the right things to consider when you’re picking one?

That’s a good question. I think, for me, when I’m starting out, I always like to start with paper because I feel like it’s such a low barrier to entry that just sketching out ideas upfront before I touch anything that uses a keyboard and a mouse, I’m always going to gain additional insight and ideas from that simple act of sketching stuff out.

Once I’m ready to move to actual pixels, it really depends on what kind of application I’m building. If I feel like it’s something where it’s a workflow-based app where the user – in order to get a good idea of how you’re using the app, you really have to go through a series of screens. At that point, I’m going to be prototyping a navigational structure. I think Keynote works really well for that.

But if it’s an app that’s very focused in its interaction, say, it’s something like a mockup for something like Instagram where it’s basically just “I’ve got a list of photos, I can take a picture, I can post a picture,” I’ve got a very limited set of interactions there. In that case, I might want to use something like Origami or Form to prototype some really interesting interactions with what happens when I take that picture and then I manipulate the filters or do something like that.

It’s hard to say that there’s a specific tool that’s always going to work in every situation. I think it differs from situation from situation, but it really comes down to whatever you feel most comfortable using. If you use Keynote all the time to make presentations, then Keynote is something that you could use to do all of your prototyping.

I saw a really great post the other day from – was it thoughtbot? I’ll have to look this link up and we’ll put it in the show notes. He did a great video of some interaction prototypes that he built and he built them all in Screenflow, which is what most people use when they’re doing screencasts and things like that. Screenflow has drawing tools in it and he actually uses screen flow to create the animations, and then exported that movie into animated .gifs that he could share with his team.

That’s really interesting.

One option for building these interactive prototypes, which I’ve heard at least one mobile developer advocate for is using a web technology to build something that’s roughly interactive but not super polished. I’m suing that as an alternative to building out an interactive prototype and prototyping a specific thing.

Using something like Ionic, for example, to just build the rough idea of the UI, and then getting people to play with it and giving you feedback. I’m wondering if any of you folks have heard of that before and what are your opinions on that?

I’m not sure I completely follow. You’re using Ionic to do your prototyping?

Yeah, so building out a simple version of the app, a throw-away version of the app, using Ionic, which is for those of you who don’t know, it’s like an Angular-backed thing for building mobile web applications. You build it in HTML and CSS, build it in JavaScript maybe, and it’s click through-able and it’ll give you some idea for the information architecture and the high-level flows, but you’re not going to necessarily going to take a bunch of time polishing the look and feel. It’s still that sketchy, unfinished idea, but using web-based tools, I guess.

It sounded like a really wacky idea, but this person said he had great success with it. I guess not necessarily a prototype; I guess it’s more in the realm of an MVP, like “Let me build this and see if people are actually interested or if it actually engages people.” Maybe it’s like a level up from just a pure prototype that you’d never put in the hands of any end users.

Yeah, I know people who have built full-on apps with Ionic.

Yeah, I’m sure the folks at Ionic will be quite upset because they thought that I was suggesting you only use Ionic for throw-away stuff and not a real thing. They obviously want people to be building their entire product in Ionic, but it does seem like – I guess particularly if you’re the folks who are coming up with the prototypes aren’t necessarily super fluent in iOS but they are more comfortable more in the web-based world.

48] in Angular, for example, but they’ll prototype ideas in Angular and play with them and just put them in front of people to see how people react to the idea rather than build the final product.

I could see that for market testing where you actually have something that’s functional that they can work through, but I’m not sure it will save you any work as opposed to doing something in Interface Builder where you just build in the segues and tap-tap-tap, go-go-go.

Yeah, I guess the thing I’m describing isn’t really a prototype; it’s more like an MVP, just like the bare minimum to see if anyone actually can use the thing and get value out of it.

I think it is valuable in the sense that you get a functional prototype. It actually has the backend code to do the work, and if you are more familiar with the web technology, I can see that as a faster way to get something out the door, and then you can evaluate whether or not you have the tradeoffs that make it worth switching over to Swift or Objective-C, or whether or not people are just happy with the way it is and it doesn’t have any of the issues that some of the other apps that really shouldn’t be written as hybrid apps get written as hybrid apps.

But yeah, I don’t like it for the MVP idea. I don’t know if it’s a great idea for prototyping or not.

Yeah, I personally haven’t tried any of those web-based tools, a lot of them that are based on JavaScript. I’ve talked to people who use Framer.js to do a lot of prototyping, but I’m not the best JavaScript programmer in the world, so I feel like going into that realm – for me, at least – would slow me down a bit because I would have a lot of baggage that I would need to learn ahead of time before I felt like I’d be productive using some of those tools.

I think you just gave me a JavaScript Jabber episode [chuckling]. But we’ve talked to the Famous.js and Ionic folks on JavaScript Jabber; I have never seen this Framer.js where it’s actually animating your app for you. That’s really interesting.

Yeah. A few months ago, I guess this was back over the summer, we had a new, local meetup group called Intent which was for UI and UX designers. Even though I’m not a UI or UX guy, I like to play one on TV, so I like to go to these meetups just to get ideas.

One of their first meetups was a survey of all these different tools that people can use to do prototyping, and Framer.js was one of the tools that was presented. It was a great meeting because what they did was they had the same kind of app prototype, and each person had to implement that prototype using one of these four or five different tools, so you got a really good understanding of what the strengths and limitations were for these various prototyping tools.

Because some of them, you could get all of the screens laid out and wired up really quickly, but the animations between the screens was really bad. Whereas others, you could do nice fade and bouncing animations and things, but wiring up multiple screens was complicated difficult.

I really like it. One thing that I am wondering about here is that it appears to – you take the image and you stick it in your application, and then it animates through the images. What I’m wondering is, can you put demo apps in the App Store? They’re not actually functional but you put up there, “This is a demo app for this kind of app.”

For example, if I wanted to build apps for – I always use the example of plumbers. I wanted to build an app that’s ABC Plumbing app, and then XYZ Plumbing can also have an app just like ABC Plumbing’s app. Can you put the demo apps up there that just show them what they could get, or do they actually have to do something?

That’s an interesting question. I know I’ve never tried to post an app like that; I don’t even know if it would get through the approval process. I know that you can’t – any kind of keywords you might use in an app name or description that might imply that it’s a beta or a test app a lot of time will get you rejected during the app approval process.

Interesting. Alright, one last question then we get to picks. If I wanted to go and put a demo out on Kickstarter to build an app, would you recommend that I do a high fidelity one or do you think a sketch on Keynote or something would work?

For something like that, I would think that you’d want – if you could do a high fidelity, I think that would work best because that’s going to put the best foot forward. Especially for people who are coming in to viewing this project or whatever it is for the first time and don’t have a lot of the background or the history of working on the project, the first impression is always going to be the most valuable one.

And a lot of times, those demos that you see are typically created in something like After Effects so that they are really pan tooled animations to make the app look the best that it can.

Yup. Alright, well, some of us have a hard stop coming up, so we’ll go ahead and jump over to picks. Pete, do you want to start us off with picks?

Surely, surely. My first pick is self-serving – The ThoughtWorks Technology Radar just came out today. Today recording day, not today the day you’re listening to this because I don’t know what day you’re listening to this, dear listener.

The ThoughtWorks Tech Radar is our opinionated opinions on what things we think are interesting for technology organizations to look at, things that we think we would make fun of people if they weren’t using them, all the way through to things that we would make other people who are using them.

We do it about two or three times a year, I think, and it’s just been released. If you’re interested in the world of technology and want to see what’s up and coming, then take a look.

My second pick is – I feel like someone might have picked this before – the Dash app. It’s really, really awesome for keeping all your API documentation stuff easily accessible and offline. If you’re trying to write software on a plane and the plane doesn’t have Wi-Fi, then you can look up the documentation for any programming language or framework that you can really think of. They have a dock set in the Dash app.

29] if you ask me.

My last pick is a book, Thinking, Fast and Slow. This is a book about the way our brains work and the way that our subconscious biases can affect the choices we make in life and the way our subconscious biases can affect how we communicate with each other. I think this is really useful; it’s particularly useful for those of you who are consultants or contractors. It’s just really interesting in general to – it’s got lots of really funny scientific studies about how bad our brains our when it comes to some kind of biases.

There's a really interesting one about guessing people’s – how old Gandhi was when he died and how much you can affect people’s guesses by making them spin roulette wheels and funny things like that. I really enjoyed this book, so I think you should read it. Those are my picks.

Awesome! Jaim, what are your picks?

I’ve got one pick and this is a book from Mike Monteiro who is more known probably for using Goodfella’s quotes to get our clients to procure payment and teach us how to encourage them along those lines, but he’s also been writing some books lately. This is a guy who understands a lot about dealing with clients and most [inaudible 40:41] about doing design, but it really translates well to a developer. If you are a consultant, a freelancer – whatever you want to call it – he’s got a book out that came out maybe a month ago called You’re My Favorite Client.

This is meant for a designer to buy for their client, but it does a great job of talking about the relationship with people that are doing the work and people that want to benefit from the work. I thought that was a great read. Mike Monteiro, You’re My Favorite Client.

Alright. I’ve got a couple of picks. One is something that I’m just starting to play with now. It’s an email system. I’ve used Ontraport, Aweber, Mailchimp in the past; not a huge fan of Ontraport’s email stuff, it’s just kind of clunky. Aweber and Mailchimp do most of what I like or need, but they just didn’t seem to quite have it. And so I’ve been playing with Drip – you can find it at getdrip.com. Anyway, it’s a really cool system and I’m really looking forward to some of the things that I can do with it.

The other pick that I have is, I found some iPhone design notepads on Amazon. They’re not that expensive; they’re like five bucks and they have some in the iPhone 4s size and some others that I’m not sure quite what size these are. If you need that, I guess that frame around what you’re working on so that you can see what you’re drawing in an iPhone, then check that out. I’m more of the school where I’ll just Dropbox and then fill it in, but some people need that so they can see it in context. Those are my picks. Jay, what are your picks?

Alright. Sticking with the theme of the show, I’ve got a couple of lo-fi picks. When it comes to paper prototyping, I typically stick to just using pencils and sharpies, but whenever I want to highlight something or provide depth or shadows, I always pull out my Copic markers, especially a C6 or a C2. There these light gray markers that don’t cover up what you’re doing and allow you to provide shadows and things and make you’re sketches really pop when you’re showing them off.

And then for storing my markers, I got these great pouches from Nock – it’s called the Nock Chimneytop, and it’s a little zipper pouch that was actually started as a Kickstarter project. They had a collection of pen and drawing pouches, others, to store your sketch notepad and things in, and they’re really well-constructed and tough and they hold. They’re very small but they hold a surprisingly large amount of pens and pencils and erasers and things like that.

And then a new tool that just came into existence within the past week or so is an app called Zeplin, which is a plugin for Sketch. It allows you to create your style guides very quickly from images that you’ve composed in sketch. You can maybe design a UI in sketch and then using Zeplin, you can export that and extract information like what’s the color palette? What fonts are being used? What’s the spacing between all of the onscreen elements? Zeplin is a great tool for automating a lot of that.

Awesome. Well, thanks for coming, Jay. It was fun to talk and I’ve got a ton of ideas now for different things that I can use to prototype out some apps.

Great! I was glad I could jump on the podcast again. I had a great time last time and this time was no different.

Alright! Well, we’ll wrap up the show. We’ll catch you all next week!