062 iPhreaks Show - Therapeutic Design with Cory Foy

00:00
Download MP3

Transcript

CORY: I’d like to figure that out. Because right now I write everything with code, but if I can figure out how to do apps with magic, that sounds [laughter].**[This episode of iPhreaks is brought to you, in part, by Postcards. Postcards is the simplest way to allow you to feedback from right inside your application. With just a simple gesture, anyone testing your app can send you a Postcard containing a screenshot of the app and some notes. It’s a great way to handle bug reports and feature requests from your clients. It takes 5 minutes to set up, and the first five postcards each month are free. Get started today by visiting www.postcard.es]****CHUCK: Hey everybody and welcome to episode 62 of the iPhreaks Show. This week on our panel we have Pete Hodgson. PETE: Good morning from Berkeley, California. CHUCK: Alondo Brewington. ALONDO: Hello, from North Carolina. CHUCK: Jaim Zuber. JAIM: Hello, from Minneapolis. CHUCK: I’m Charles Max Wood from DevChat.tv and we have a guest this week, Cory Foy. CORY: I hail from North Carolina, as well. CHUCK: You want to give us some background on you real quick, Cory? CORY: Sure. I have a pretty interesting story background on both the development and the process side. I’ve been in the development world for fifteen years and I’ve gotten to see a lot of interesting changes over that time period as we’ve seen more web adoption and mobile adoption. I’ve been working in the mobile space for well over ten years now. Lately, what I’ve been focused on is helping a set of therapists who work with severely disabled children, help figure out how they can incorporate technology into their day-to-day operations – that’s what’s the focus of our company has been in the apps that we’ve been building – or how can we kind of help them help their children use the technology that they have around them. CHUCK: That’s really interesting. Is that what you mean by Therapeutic App Design? CORY: It does, because what we found was – the apps that are out there right now – there are a lot of apps that are out there targeting autistic children or children that need help learning different things. But it’s a different game whenever you’re talking about therapist-led work. What we found was that the apps themselves – you had to think very hard about different pieces and parts of the app and how they operated, and also how they interacted between the therapist and the person that they were working with, whether that’s an adult or a child, and how the apps itself allow that interaction. A lot of our focus had been on saying, “Now that we’re using this for therapy where you can really mess people up if you get some things wrong, how do we make an app that allows for it to be used in that kind of an environment?” JAIM:  Are there some kind of used cases for this app you’re talking about? CORY: Well, the specific case that we’re building for –. Our company pretty collapsed. We launched because my aunt and a couple of her colleagues are speech language pathologists; they work within a public school system in Florida. What they ran into was that a lot of the materials that they had fell into three categories. One, they were very old paper-based materials. They had been around a long time and the therapist would have to carry these giant carts of materials from classroom to classroom that they worked in. The second was a lot of highly specialized hardware. Where they saw that was it would be effective, but parents would have to pay 5 or 6 or 7,000 dollars for a single device in order to work with their children through these devices. Then what we saw was the – of course, the iPad adoption, and suddenly people have a tablet and they can go spend 3 or 400 dollars on a tablet, and have this thing that was wonderful and was really portable. But a lot of the applications that were on there didn’t take into account that some of these kids were very severe. As an example of that, the first app that we released was called the Yes/No app. It literally teaches kids how to say “Yes” and “No” to things because they don’t know how to do that. We’re not talking about babies; these are school-age children who have severe disabilities who we need to teach the difference between being able to say “Yes” and being able to say “No”. That was the target market that we went after, saying, “How can we help therapists working with these kids to be really effective in a way that the parents can also be able to afford the equipment to work with them, and the therapist themselves, on public school teacher budget, can be able to afford these tools and not have to log around these giant carts of materials.” CHUCK: That’s very interesting. Is the Therapeutic App Design specific to these kinds of apps that are designed to help these kids or adults be better at functioning in the world, or can these concepts be applied to other apps that just anybody is going to use? CORY:**Well, I think it’s about – I think that there are some lessons that we can learn from the apps that we should all be taking into account with the apps that we build, regardless. It’s kind of similar to the idea of web accessibility. There was a time when you really had to remind people to put alt tags into their images, to be thinking about web screen readers and those kinds of things. As we’ve progressed, some of that stuff is becoming integrated into our tools. I think that as we look at building these mobile apps now, we have to consider that not everybody is touching the screen. As not as intuitive as that is, there are people who completely use apps using voice-over, who aren’t seeing the screen, who are relying on the screen being able to be read with them. Similar to what we did on the web world back in the late ‘90s where we said, “Take a day or a couple of days and try using it using a non – or text-based browser or voice-over browser or something”. We have this phenomenal toolkits built directly into the iOS framework around accessibility, and what we need to do is to be taking our apps and doing things like, “Hey let’s try our apps with voice-over and what happens”. An example is – there’s a guy in Twitter named Kevin Jones, who I met at the Madison Ruby Conference last year. He is blind, but he uses and writes about technology on his iPhone. Because he’s blind, he uses everything via voice-over. He talks about a situation where he used this app to determine when the next buses were coming. One day, it just stopped giving him this information, and he knew he could touch this one spot and it would stop giving him information. He talked to some people who could see what was going on, and the developers had released a new version of the app where they had replaced this button – this list of bus stops – with an interactive map to show where the buses were, and you could click on the pen of the bus to show where it was –if you could see the pen [chuckles] – which he could not, right? So, this app which was a phenomenal and useful thing suddenly became useless to him because he couldn’t visualize the information. I think from one aspect of it, it’s really important to be thinking about accessibility and therapeutic uses, and how people who aren’t just like us who are using the apps and thinking from it that way. But there’s also a second point, and I think that the second point is really where we made the decision to build our own framework and build our own apps – not our own accessibility framework. But where we really said, there’s a lot of things people don’t take into consideration that we needed to as part of a therapeutic model of application-building. As an example, a lot of apps out there, when you think about what we’re trying to do, especially those targeted towards kids, they tend to be fairly flashy; they want to keep the kids engaged. They know the kids tend to have a lower time before they go, “Ok, I’m not interested in this”. So, the apps do things like, as soon as you get the answer right, it flashes a big checkmark and it goes “Yeeey! You did it!” or says certain things, plays music and shoots fireworks, and then advances to the next thing. Well, what we ran into was that all of those things are completely awful when you’re trying to teach the kid – think about this first app that we built: Yes/No. You don’t want these flashy graphics because for some of the kids, it’s overwhelming. And you don’t want lots of noises because that can be distracting and upsetting. The worst part is you don’t want it to just auto-advance to the next thing, because then the teacher or the therapist is not having the ability to have what we call a teachable moment with the child. So, in the example of the app is we show a picture of a dog, and then we ask the question below: “Is this a picture of a dog?”, or “Is this a dog?”, and they would click on “Yes” or “No”. If they click on “No”, then the teacher would want to have a conversation with them about that rather than them just clicking “Yes” and then moving to the next screen. Even from that perspective – it’s funny even thinking about something as simple as that picture of a dog, we ran into the problem of needing to be very clear and very precise and unambiguous with the questions that we were asking and the pictures that we were showing. As an example, one of our questions is “Is this an eye?” – like an eyeball, right? And we have associated with it a picture that shows an actual zoomed-in picture of an eye. But we got feedback from some therapists that kids were getting confused when it was showing – when it was asking the question about the eye and showing the picture of the dog, because the dog has an eye on it. Some of those kids – they were getting confused. Or we would say, “Is this a pizza?”, and we would show a piece of pizza and the kids would say “No, it’s not a pizza. It’s a piece of pizza”. Or “No, those aren’t pants. Those are jeans”. So, there was a lot of work that we really had to go into; to think about how can people interpret, not only the questions that we’re asking, but the answers that they’re seeing to make sure that there’s never a question in their mind about what is showing up, especially because in our app itself, we randomize the questions in the pictures. It’s not like we’re setting out a timeline where we can ensure all of that. So part of the challenge from the development perspective was saying, “How can I build a randomized set of data and questions so that any answer will still be able to clearly make sense to somebody who’s struggling to even know the answers to Yes or No.”**ALONDO: So Cory, in finding out, sort of working through these issues and going through the user testing, is it a close relationship with a specific group of therapists that you work with that are the users or using some external sources for a testing? CORY: In our particular case, we are working with a close set of users. That’s been fantastic, because they’re working directly with kids in a school system and they have broader access to a larger pool of therapists and so we get a lot of feedback from them. But there’s actually a startup here in Riley called Learn Trials, and what they’re working on is the ability to take information like this, and apps like this, and run like you would run a clinical trial – run clinical trials with apps and the data from them. What we could do in that case is say, “We think that a Yes/No app will increase the ability of kids to recognize their – increase their abilities of being able to recognize Yes or No; increase it by 30%” and they have the ability to distribute that and run that in a clinical trial-type environment to give us that data back. We haven’t started using that, but I’ve been – I’ve talked with them, and I’m really interested in that, especially as you get more and more therapy apps where you’re saying – again, these are kids with challenges and problems and you want to make sure that you’re not causing harm. It’s kind of the Hippocratic Oath: “First, do no harm”. Same kind of thing from app design, whatever you’re targeting – helping children or helping adults – is we want to first do no harm. I like that movement towards saying that we’re moving beyond user-testing and qualitative-testing to actually saying “How can we quantify the impact that we’re having even with mobile apps that we’re building, that we threw together in a weekend?”. PETE: I know it’s really interesting because I’ve always been a bit skeptical of –. I’ve got a little boy, and surprisingly enough, he likes to play with my wife’s iPad. We have these kinds of educational games, and I’m doing educational # there. As you have no idea whether there’s any sign or any basis at all to whether these things are actually educational in any way – he likes playing with them because they’re kind of toy-like and they look like they’re teaching him something, but I’ve always wondered how much science actually goes on behind all these things. CORY: Right. It’s not even just saying, “Are they learning something”, it’s saying “Are they actually being harmed by some of this stuff?” There was the issue with Baby Einstein a couple of years ago where they said – it was this set of TV things where the kids would watch it and learn things supposedly from watching it. Then the recommendations came out that that actually was somewhat harmful to some of the kids, and they recommended that no child that was under 2 be watching TV for certain reasons. That’s really my bigger concern, is I want kids to enjoy it; not everything has to necessarily be a learning opportunity. But we absolutely don’t want to be harming children, especially when we’re talking about probably helping kids to learn and are we helping them learn in the right way. PETE: Are you aware of this same kind of actual science approach being done with educational – with apps that, I guess, targeting the more general population of educational things for kids versus therapeutic apps? CORY: I am not off-hand. As I said, the startup here in Riley, I’ve talked with them and I know that they’ve done some work around that with some companies, but I haven’t seen it. I think part of that is if we think about the majority of iOS developers that are out there, or mobile app developers, it kind of mirrors the idea of most business-owners in the states, which is that they’re small shops, so the idea of doing a clinical trial of your app to reach out is just overwhelming. I like the idea of saying, “I think that if we make that easier to reach out, more people would be willing to do that”. I’m a little fearful of saying this, but almost the idea of a certification process – to be able to say, “Hey, we’ve run trials and we can show that these has these kinds of impacts”. I think it would go a long way if we did both sides of that where we, as a community, said “If you are going to claim educational benefits, back that data up. And by the way, we have tools so that doesn’t cause you hundreds of thousands of dollars to go do that”. ALONDO: Are there other HIPAA compliance issues as well for a therapeutic app like this? CORY: That is a fantastic question. We have worked very hard to ensure that we don’t fall into any HIPAA rules. From our perspective, what we’ve done is we don’t capture any data about the children. We’ve talked to some districts about the idea of saying, “We want to give it to 30 students and let them practice, and we want to capture the results of that without running into HIPAA regulations”. I’ve worked a lot with HIPAA before, and the trick is just disassociating the data and the IDs. In those kinds of cases, what we’re doing is saying, “Ok, there’s a unique identifier and that’s the only thing that we know about, and we don’t know who the child is or anything else like that”. But certainly, you can run into that, where even something as simple as knowing that a child has the application can reveal certain pieces of information that you have to be careful of. I think that it’s a gray area, but I don’t think that it’s an insurmountable one with a little bit of thought process behind it. PETE: You mentioned at the start of the show that there was – in the pre-iPad or iOS world, there are lots of specialized devices that are used – therapeutic devices that you used. I’m kind of interested; can you give us some examples of what those kind of specialized devices are? Because I haven’t got any background, so, I’m naïve. CORY: You know, I can’t say that I do, but a lot of them look like portable computers that kids would use or they were –. I think that we haven’t seen as much of them lately since the tablet revolution has come about, because why would you spend 3,000 dollars on a specialized device whenever you can have an iPad. Now what’s interesting is that we are seeing some cases of apps that are fairly expensive in the couple hundred dollar range, that are therapeutic app which are HIPAA compliant and do all sorts of things as part of that, that people are able to buy for their iPads. But I think that that what we’re seeing right now is that the platform, as a whole, has enabled the innovation to focus not on these hardware devices, but on the innovation of just building a software and delivering it that way. JAIM: That’s pretty interesting. One thing that you talked about earlier – I’m kind of curious about – you’re talking about creating a multi-user app where the kid is not generally doing everything. There’s also a therapist involved – having a teachable moment. What lessons have you learned from trying to design for apps that are used by multiple people at the same time? That’s something that most of us don’t really deal with. CORY: I think what we’ve found by that was focusing on what the end-game was. I think in this case, the end-game was saying what is important in the app isn’t the app, but it’s the conversation and communication that happens between the therapist and the child or the therapist or their patient, because that’s what we’re really trying to enable. It goes back to that – I love that term of a teachable moment; that’s what it really comes down to. I know in my own classes when I teach organizations different topics, the power of it comes from those “Aha” moments. A lot of times those “Aha” moments aren’t in the tool that we’re using itself, but in something that happens that slips in our brain, or something that another person says or that the instructor says. We wanted to be able to maximize those, and to maximize those we found that we had to slow the process of the app down, which, again, that kind of runs counterintuitive to a lot of the game-ification effort that we take with applications of “Let’s keep things flashy. Let’s keep everybody going so we don’t lose their interest”. But in this case, it’s really saying that we’re going to be explicit about when they can move forward. As an example, on the app itself we made the decision that they can’t move forward until they get the answer correct. Further, the only way they can move forward is there’s a small arrow in the upper right hand corner that they have to click. It’s not this big “Press Here” to go next, but it’s really designed to say, “Ok, the upper right hand corner is where the therapist operates and the big buttons are where the child operates”, so that that way it creates the space to say, “Here’s where the therapist has some control over it, and here’s the work area for the kid”, and the two of them are segregated so that there are not a lot of accidental hits between the two areas. And that gives the control back to the therapist to make the decision to say, “Ok, now we’re ready to advance, and we’re advancing on my own cue”. As far as our theory, using it at the same time, typically the way that it works is that they’re sitting together. Primarily, the child is using it with a therapist operating with them – talking to them. Now, what we’ve been working on for the next release of the app is almost the term voice-over, but it uses voice commands as well with this, so that we can basically use it in an unintended mode, so that the child can hear when the app is saying, “Select the answer”, and then it can advance. We give both options to say, “Ok –”, and in one instance, the therapist has the control, but in another instance, we want it to autoplay so the child can interact with the application and play with it. JAIM:**That’s very cool. Do you have any other lessons learned when developing an app with side-by-side? Sometimes if I’m trying to demo an app and I have it pointing the other way or have it all off-centered and not directed in front of me, I try and press a button and I always miss. Are there – [chuckle] – did you ran across that? How do you handle that?**CORY: There’s not always great ways of handling that, unfortunately. We’ve worked with apps in industrial environments and in those cases we found that it was really handy to have the little styluses, so that way they felt like they were more – the teacher had a little more control over some of these stuff. In the industrial environments, we were building apps for people who were welding giant pipes and big oil rigs and things like that. In that case, they had gloves on so they can’t touch it. But we still found a lot of the same principles of making it easy; with the stylus, they have a lot easier time with it. But as far as the side-by-side, I think that the two biggest things that we learned out of building this were the one # which is the auto-advance and the not-flashy graphics; keeping the interactions to a minimum or allowing the interaction level to be set, so maybe make it exciting for some people, and being able to tone it down for others and control that. Then, the second thing is really the idea of – especially in therapy apps – making things very clear and very unambiguous so that there isn’t confusion on top of already having to try to teach the lesson, because that’s where people tend to get frustrated is when things aren’t clear and things are kind of confusing – they’re not sure about if they want to continue. They’re already learning; they’re already in a mindset of having this cognitive load on them about a child learning to say “Yes” or “No” – there’s a lot of cognitive work going on there. From both the child and the therapist, the last thing that you want to do is have a situation where any part of it that is confusing with them. So, we do a lot of testing with therapists in working situations, getting their feedback, and then immediately turning around and incorporating it. And the fact – I think that that’s one of the thing that I’ll say – one of the biggest rules that I have whenever I build applications – client applications – is that I want to be able to contact the user and explain to them how to solve the problem before they’ve contacted me that they have a problem. The idea of the application was we wanted to be able to very rapidly respond to therapists whenever they had questions. From that perspective, we made it very easy for them to know how to contact us, and when they contacted us, even though we’re a fairly small company, we responded as rapidly as we possibly could to them to say, “Yes, we’re got your information. Is this a workaround that’s going to work for you? If this is not a workaround that’s going to work for you, here’s when we would be able to incorporate it to bring it in” so that way they felt like we were on their side as well, because we take the idea – that this isn’t just a game, this is a therapy app – very, very seriously. CHUCK: I want to change tactics a little bit, because it seems like you guys have tackled a specific niche with a specific need. I’m curious – do you feel like that changes the conversation a little bit from people who are writing more generally – general interests, like games or task managementsor something like that on your phone? Do you have to have a deeper understanding of the industry that you’re getting into, or did you kind of figure that out as you went along? CORY: I think that there are some lessons that we learned which are specific to the niche that we’re in and that’s why we ended up where we were. But I think in general, some of the principles are applicable to other people who are writing apps, because if we think about a lot of the design aspects of this, there’s common sense that’s in here. The idea of clarity – the idea of doing what is necessary and making things very easy to use. There’s a great book called “Don’t Make Me Think” that was kind of a hallmark of web usability. I think that we need to remember those principles as we’re building out our applications. I think one of the great things about working on the iPhone platform as opposed to the Android platform is that we have a limited set of devices to operate from, and the idea of usability and the design of the app is so built-in to Apple’s way of doing things, that in fact, you can’t get your app accepted if you’re not following certain design guidelines. I think that that in itself has brought us a long way towards the idea of good design of applications and impacting how we do things from games to task managers. And then, the second part of that was what I was saying before – let’s remember that not all of our users are going to be like us. Some of them are going to be using it with limited capabilities of muscles, and some of them are going to be using it with voice-over. Taking that time to actually go through the iOS accessibility guidelines and thinking through with that is – I think that that’s a really important thing for so many of us to do. It doesn’t work for all of us, right? There are certain games – that’s not going to work; certain games rely on being able to see things. If your app doesn’t have to rely on that, thinking about how to provide options – like the bus-stop that I was talking about with Kevin’s idea, where they had a list of buses and then they change that to an interactive map – it’s having in your mindset of what happens whenever we change this design element; and we’re changing it for a reason. But what does that enable or disable for certain conditions? How does that change how people can interact with our app? It’s just having that awareness and that mindset and that context in there I think impacts a lot how we operate, not just in how we build our apps, but on how we interact with our users, as well. PETE: I think Apple have a lot of really good results out there around accessibility, as well. They have a really good WWDC talk. I’m guessing they do a good one every year, but I know for a couple of years ago they had a really good WWDC talk talking about accessibility and voice-over and all that kind of stuff. CORY:**Absolutely. And it’s great to see that we, just as developers, need to actually go listen to them [chuckles] and watch them and think about those kinds of things. I’ve spent some time over in India working with teams over there, and I get a lot of people ask me what is India like or what are other countries like. The thing that I tell them is that “I can explain certain things to you, but you don’t necessarily have the context to really understand what I’m saying”. And I think it’s the same kind of way with accessibility. We can talk about accessibility, but until you’ve actually turned the voice-over on for your app and tried to use it just with that and said “Am I able to get the key things out of my app that I would expect people to be able to use with voice-over using voice-over?” Until we actually try to do that, we miss that context of how important this is for people who are using it and how much people use our apps anyways, because they don’t necessarily have a choice, and they want to be able to use it so they work around some of the limitations. Just taking that context and trying to it on our own and understanding where we’re coming at will help, no matter what type of app that we’re building.**JAIM:**I think it’s an interesting exercise to be able to put on some blindfold and try to use your app. I know most of the apps I work on would’ve failed. [Chuckles]**CHUCK: Yeah, there was a terrific talk given at Mountain West JavaScript Conference by Ryan Florence. I’ll put the link into the show notes here. But anyway, he basically pulled up a website and then he set some CSS that was all effectively blank, and then he had the reader read the page and it was like, “How could anybody make any sense out of this – just based on this?” It’s really interesting, and I think it gives you that – just a little bit of empathy for – oh my goodness – somebody who can’t see this webpage couldn’t use this webpage because it’s just impossible. JAIM:**Definitely back in the day when things were basically text-driven, you could probably use magnet links and translate that into speech. But with a lot of newer websites, that doesn’t really play out. It’s so visually-driven. [Inaudible] empathy for other approaches.**CHUCK: They do have accessibility options for you; there’s ARIA and things like that. In fact, I’ll put a link to – we did a Ruby Rogues episode on accessibility as well, with somebody who is visually impaired, and again, it was just kind of that – it kind of wakes you up to the fact that how important it is and what kind of a difference it makes to these folks. I know that these are web-based things, but as Cory pointed out, Apple has a ton of tools for accessibility, so you should definitely go check those out, as well. CORY: And really, honestly, we – even back in the late ‘90s and early 2000 – I worked for government. And in government, we were required by law to provide our apps as accessible. I would say that I have not seen a giant leap forward from the more static sites of the late ‘90s to the dynamic ones we have today. I haven’t seen those giant leaps forward in usability, but at least people are thinking about it more, and more of our frameworks and toolkits are building it in. I think that in iOS, they make it so dog-easy to do it that just simply turning it on and simply thinking about it and giving a little bit of thought process to it helps everybody, not just blind people or people who are disabled, it helps everybody because you’re thinking about the design and usability of your application, which is – that can be just a big win regardless. PETE: It is really surprising how much you get for free from Apple and it’s almost like – I guess this is what you’re saying is just if you turn it on and see – you’ll see that you’re 80% of the way there, and you just need to make a few little changes and it’s not like –. Most of the timem it’s not huge structural changes to the UI. It’s just like, “Oh, this is an image that says OK,” and the accessibility framework has no idea that this is OK, so I need to add a little tick – a little accessibility identifier – that it says that’s it’s a bus and it says OK; then the screen reader will work, then voice-over will work. It’s normally not a huge chunk of effort to do. CORY: An interesting thing is, in the web, a lot of how we do automated testing relies on accessibility in the browser. By making controls and making things accessible, you make them easier for some of these automated tests. And I think that we’re going to see the same thing – we do see some of that same thing in the mobile world where we’re going to start seeing a lot about our support around automated testing of things, and it’s going to rely very heavily on having these accessibility elements in, because they’re in anyways, and so for free, we can inspect and walk the app using those accessibility APIs. PETE: That’s absolutely true. As someone who built one of those tools, it’s true. All of the testing tools out there use accessibility identifier as their primary way of understanding the semantics and the application, because if you think about it, an automated testing tool needs to understand what’s in the UI, so the machine can read it just like voice-over needs to understand what’s in the UIs, so our machine can read it. There is a very interesting analog there. CHUCK: Do you know how these accessibility features stack up against other platforms like Android or Windows? PETE: I know that better than Android, not because I’m Android bashing, I just know that Apple is very focused on this and have applied a really systematic approach to giving you most of it for free. There’s definitely equivalence in Android world – from what I’ve heard, not from first-hand experience – there’s a little bit more effort to get it working. CORY:**I worked for Microsoft in a former life, and there was a big focus around accessibility, because if you think about at that level in Apple as well, they’re doing government contracts and government contracts require accessibility to be built-in and part of the platform. I haven’t worked with the latest versions of Windows phone, but I know that during my time there, accessibility was a very important thing throughout the whole Windows ecosystem. I’d imagined that they have done a lot of work to that, but I think, again, one of your challenges between the three platforms are – Android has this amazing market share, but it also has this amazing number of devices that are different screen sizes and different resolutions that are a little trickier to support from certain elements. So, the idea of – and I’m not familiar with the accessibility ecosystem there – but the idea of accessibility there seems like it would only help as you’re trying to do some other designs across different devices, because you’re thinking about non-standard stuff anyways, it should end up being a lot more adaptable to certain screen sizes and frame rates and things like that. But I’m not an Android expert so [laughter] don’t take that from me.**ALONDO: Is anybody really, at this point? CORY:**Can I pass on that question, is that ok? [Laughter]**ALONDO: Sure. JAIM:**Global mute button. [Chuckle]PETE: Tumbleweed. CHUCK: Alright, well, Pete do you want to start with the picks? PETE: My picks are short this week. I’m going to pick a really dated article. It’s actually all the way from 2010, but it’s really good. It’s good enough that Apple apparently used to link to it when talking to people about accessibility. A guy called Matt Gemmell, or Gemmell – I don’t know how to pronounce his last name – very smart Scottish guy who wrote an article about accessibility for iPhone and iPad. It’s just a really good intro article on how this stuff works, and also why it’s important. It’s a really good read. Maybe some stuff is a little bit outdated by now, but most of the fundamental stuff will be the same. So, that’s a good place to get started if you kind of want to start educating yourself around all the accessibility stuff we were just talking about. My next pick is going to be a plug. A friend of mine just started working at a startup in San Francisco called Partender, and they are looking for iOS devs. So, if you are an iOS dev in the San Francisco bay area, or possibly even outside the San Francisco bay area – I don’t know – and you want to work in a cool app, then get in touch with them. Go to angel.co/partender/jobs and there’ll be a link in the show notes. CHUCK: Awesome. Alondo, what are your picks? ALONDO: Ok. I have a couple of picks that are actually – one is a video, and it is Matt Thompson’s presentation from the recent AltConf in San Francisco, and I think it’s apropos just because there’s a lot of changes right now in the iOS development environment, as well as the – as we we’re talking about the accessibility – wanting to incorporate these things. Basically the topic is about “Being a Beginner Again”. It’s very short, but I thought it was a very good presentation and just talks about the mindset of being a beginner – we all have an opportunity right now with Swift and a lot of the new APIs. It’s a great way to encourage people to really think about the opportunity there and just framing their minds for starting something new. Along with that, there’s a podcast by Scott Hanselman called HanselMinutes. The topic is “What it really means to be Junior Developer”. It struck me just because in certain ways, with a new language or with new APIs, you are a junior again in certain aspects, and it talks a lot about the mindset there how to treat other people, as well who are truly junior developers, whether it’s in development as a whole or on a platform. I think those are two great listens. And my third pick is a triple-style golden ale that I find just absolutely delicious. It’s called La Fin Du Monde and it is from Unibrouem, which is a Canadian brewery. If you are a beer drinker, I recommend it. CHUCK: Alright. Jaim, what are your picks? JAIM: Ok, I’m going to have one pick. So I was up on North Shore, Lake Superior last year; we went to this farm that makes maple syrup. And while we were there, we stopped – we found out about a Grade B Maple syrup, which I did not know existed, but it is fantastic. Most of the maple syrup that you’re going to buy, like the pure maple syrup is Grade A, which is a little bit lighter, and Grade B – they kind of label for cooking and stuff like that. But if you actually like maple syrup and this is more of what you like about it – it’s kind of a dark rich flavor – take a look for it. If you can find a Grade B maple syrup, it’s fantastic. CHUCK: Alright. I’ve got a couple of picks. The first one I’m going to pick is the talk by Ryan Florence that I mentioned before. Another pick that I have is Trello, which is kind of a project management tool. It’s a kanban board – if you’re familiar with the term. If not, just go check it out. But it’s really simple and that’s why I like it and I could use it. And I found a few features on it that are really like – such as being able to email stories onto a board. And that’s all I’ve got this week. Cory, what are your picks? CORY: I have four. The first one – Matt actually has an updated article. He calls it “iOS Accessibility Heroes and Villains” and he shows some examples of different apps and the challenges in voice-over with that. The second one is the trial – Learn Trials – that was the company that I was talking about trying to enable clinical trial-type management for apps and for some other things. The third one is our company – prettycoolapps.com. That’s our actual company, so I figured I’m safe to do that. And the fourth one – since I heard a funny one earlier – is a game I’ve been spending a lot of time on called Goat Simulator. They just released it for OSX as well, so it’s available on Steam. You basically cause lots of chaos as a goat, so it’s a pretty good way of killing some time and releasing some stress. CHUCK: That sounds like too much fun. CORY:[Chuckles]**JAIM:**I like to eat grass and head-butt people, so this should be cool. [Laughter]**CORY:It’s a perfect game for you. [Laughter]CHUCK: Alright well, thanks for coming Cory. I really appreciate you taking the time and hopefully, we’ll get some people to go check out the accessibility stuff in iOS. CORY: Yeah, and from your listeners’ perspective, if they have questions, feel free to have them contact me. I’m pretty easy to find on the Interwebs. I’m always happy to answer questions or point people to different resources, as well. CHUCK: Alright, great! Thanks for coming. We’ll catch you on next week. [Hosting and bandwidth provided by the Blue Box Group. Check them out at bluebox.net.]**[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]**[Would you like to join the conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]alondo**

Sign up for the Newsletter

Join our newsletter and get updates in your inbox. We won’t spam you and we respect your privacy.