#364 iOS Tips, NoMenuBar, Akinator, Snapguide, iLuv Inline Remote, CableJive dockStubz, Songza, Coding Accessible iOS Apps

Recording from a hotel with the Samsung Meteor Mic, and a lot of help from the NosillaCastaways! Rod Simmons of the Simple Mobile Review Podcast gives us some iOS tips. Ken Wolfe of the Manhattan Repertory Theatre in New York City reviews the free NoMenuBar from jeb.com.fr/en/nomenubar.shtml. Professor Albert reviews Akinator from Elokence.com. Mike McPeek reviews the iOS app Snapguide in the iTunes Store. Kirschen Seah FreeRangeCoder.com reviews the iLuv Inline Remote and the CableJive dockStubz. Kim Landwehr reviews Songza from songza.com. Timothy Gregoire reviews SiderOak from Spideroak.com. In Chit Chat Across the Pond, Donald Burr of Otaku No Podcast teaches us how to code accessible iOS apps – it’s not that hard!


Hi this is Allison Sheridan of the NosillaCast Mac Podcast, hosted at Podfeet.com, a technology geek podcast with an EVER so slight Macintosh bias. Today is Sunday April 29th, 2012 and this is show number 364. This has been one of the most challenging weeks of my life. As you heard last week, my mom had a stroke on Tuesday the 17th. She was in really bad shape, couldn’t move her right side, couldn’t eat or talk. Within two days though she was walking and eating, but had a lot of trouble communicating – both speaking and understanding.

On Thursday night of last week I moved her from the hospital to an acute rehab center for her to get 3 hours of rehab a day – occupational, physical and speech therapy.. She’s been there for 10 days now and with the exception of last weekend when my brother took over, I’ve been with her every day. My life is now work from 7-11am (so I keep getting paid for my day job), then 6-8 hours with mom, then back to the hotel room nearby for another 3-4 hours of work. That hasn’t been the challenging part though, mom was really really depressed and discouraged this week, even though she was improving. Imagine if I couldn’t talk – how discouraged and depressed I would be? Well I learned my gift of gab from my mom so it was really bad for her.

This isn’t a story of gloom though – the great news is that in the last couple of days she’s really snapped out of it. Her speech is improving at a dramatic rate and she’s finally understanding pretty much what’s happened to her. With any luck I’ll be able to spring her on Monday or Tuesday if she can prove she’s in good enough shape to go back to the assisted living program where she lives.

Your next logical question should be how in the heck am I recording a show? Well because of the kindness of the NosillaCastaways, I have a giant batch of recorded reviews for you. Rod Simmons, Professor Albert, Mike McPeek, Ken Wolfe, Kirschen Seah, Kim Landwehr, Timothy Gregoire, Caleb Fong and even Professor Albert all sent in fabulous reviews. Donald Burr worked with my challenging schedule and we managed to record a Chit Chat Across the Pond. Donald will be walking us through the steps to design an iOS app for accessibility. It’s fascinating and I think you’ll really like it.

Before we kick into the recordings though, I’d like to apologize to Marks everywhere. During the discussion of depth of field with Bart last week, I said that it was Mark Sheppard who took the awesome flower photo with the really deep depth of field, but it was actually Mark Pouley, aka @SwitcherMark. For some reason we have a lot of Marks involved in the plot – as many as four in the live show alone including Mark Greentree and Mark Dalton! We pretty much have an infestation of Marks! Apologies to all marks, especially Mark Pouley. Ok, that’s enough from me – let’s get into the listener reviews.

Rod on iOS Tips

< ---no shownotes available--->

I LOVE the keyboard shortcuts – I did one for my name and email address.

Ken Wolfe on NoMenuBar

Hi Allison, This is Ken Wolf from Manhattan Repertory Theatre in New York City with a Mac Application that I love, and if you are a Menubar Geek, you will love it too.

First off, let’s start with the problem that needs to be solved.

Now I’ m an OBSESSIVE menu bar Geek. I love Mac applications that have menubar items so that at any given moment I can access or look at whatever I need. In my menubar, I have Menumeters, Istat Menus, (yes I know that is overkill) I have Fantastical, Textexpander, Logmein, Temperature Monitor, Hazel, Growl, BusyCal, SnapRuler and Dropbox. Plus I display Spotlight, the time, battery life, WiFi, BlueTooth, Volume Control, and Time Machine. So I have a lot of menubar items up there in that little menu.

So here is the problem. Let’s say I want to see if my Dropbox is syncing and I am working in say Pages. I have so many menubar items, and Pages has its own menubar items, so the Dropbox menu item is not displayed up there. So I click on Finder, but Finder still has too many menubar items so I can’t get to my Dropbox menu item. Now for a Menubar Geek like me, this is so not fun.

Enter NoMenuBar from jeb.com.fr/en/nomenubar.shtml to the rescue. NoMenuBar is a wonderful little application with just one menu bar item way over to the left. That is all it is. This application does nothing at all. It is just blank application with one menu bar item – but I LOVE THIS APPLICATION. And I use it ALL THE TIME!

I simply place NoMenuBar in my dock and when I need to see ALL my menubar items I simply click on it and my menu bar is wide open so I can menubar geek out anytime I want.

NoMenuBar is created by Jean-Edouard Babin who can be found at jeb.com.fr and the good news is NoMenuBar is FREE, but if you are an Obsessive menubar geek like me, please send him a donation. NOMENUBAR is a Universal Binary and good for Mac OSX 10.1 and up. The link will be in the show notes.

Have fun, you Menubar Geeks!

Review – MacWorld: macworld.com/reviews/product/727622/review/nomenubar_1

Professor Albert on Akinator

Hello dis is is Professor Albert with an IOS application dat I love. But first, let’s start with dat very special problem that needs to be solved. Have you ever been at a party and its no fun dere – everyone kinda talking da chit chat but it is very dumb chit chat – nobody is having any fun – it is not wild and crazy and fun.

Well I have a very special IOS application for da IPad dere dat will make your party wild and crazy! Da Application is called Akinator the Genie from Elokence.com.

Now dis is a mind reading application. It reads the mind of anyone at the party when they’re thinking about a fictional character, or a real person, a celebrity – something like dat. This application will ask them questions and then tell them who dey are thinking about!

Ven the application opens up, you see this very handsome genie AKINATOR dere. You press play, then, there is a little sign that says: “Think about a real or fictional character and I will try and guess who it is.” Below, press on “let’s go” and den you vill see the magic GENIE AKINATOR and this time he says something like: “Does your character really exist?” You press Yes, Don’t Know, No, Probably, Probably Not. And this goes on – maybe 20 questions, maybe 15 questions, and then magically AKINATOR appears the picture of the person you’re thinking about!!!!

Dis is a truly amazing application dat iPad can read the minds your minds and the minds of people to the party, much much better than Pictionary or Charades or anything like that. So by activator it is only $1.99 in the Mac application store dere da iTunes application store. Buy it have some fun, and tell them that Prof. Albert sent you.


At work this week the big boss asked a bunch of us to do one of those online interview thingys where they figure out your personality traits and then make assessments based on the interview you do. I followed the attached instructions, and they were disastrous. First of all, it was in Powerpoint of all things, can you imagine? Second of all, they’d turned the Powerpoint into a PDF so the links and codes you had to enter were not clickable! The instructions were out of order, no screenshots of what to do, what a mess! I knew I was the first of about 20 of us to go through this so instead of sitting back happy that I’d gotten through it, I decided to save each of the 20 people about 10 minutes each by making a quick tutorial for them. I whipped open ScreenSteps and took a few screenshots, typed in the urls and told ScreenSteps to make them clickable urls, and put in the codes so people could copy and paste them instead of having to type in these long strings of characters. The whole thing took me about 10 minutes, I exported to PDF, and emailed it back to all of the others to save them time. I reach for ScreenSteps instinctively now – if you’d like to save people’s productivity like this, check out ScreenSteps Desktop from ScreenSteps.com. It’s only $40 for the Standard version – I saved 10 times that in this one use of ScreenSteps.

Mike McPeek Snapguide Review

Hello everyone, Mike McPeek here with an IOS review. Long time listeners of the Nosillacast knows Allison really loves Screensteps and Clarify from Bluemango Learning Software. They are both good ways to make computer documentation. But what about the place that has no monitor, you know, the real world. What is a person to do if you need instructions on how to bake a cake or put together a bike repair kit? You could ask someone. However what if there is no one available with knowledge of these things then what are you to do. That is whereby Snapguide comes in.

snapguide logo form iTunesSnapguide is a free IOS app that creates a knowledge community. When you open the app there are 5 buttons across the bottom, featured, explore, create, activity and me. The featured tab is for guides that the app has decided  to put in the spotlight. How this is arrived at I don’t know. Explore has 2 tabs, Popular and Recent. Activity is the social part of the app where you can see what has recently been posted, who has liked a particular guide and who has started following you. Me is where your personal information goes such as stats for how many guides you have done, who you are following, how many are following you, and how many  likes you have received. There is also a place for messages and saved drafts of guides you have started, which brings us to the giving back portion of the app.

The Create tab is where your guides are made. First you start by giving it a title that starts with “How to …”. You fill in the rest with a description of  what it is your going to demonstrate, keeping it under 50 characters. Next you will go to the editor that will have a thumbnail for every page you create that can be clicked on to edit or delete. In the editor there is a page to list the supplies you may need to use for the project. When you are using a guide the list  can be brought up from the bottom with a flick of the finger. After you listed your supplies, f any, you can start adding new pages to the editor. There are 3 kinds, photo with a comment area at the bottom, video and a text page for instructions. The pages can be edited and arranged as necessary. After you are happy with your arrangement you click next where you will be taken to  your title page where you can add a cover photo if you wish. After that you hit the publish button so your guide can be sent to the internet for all to see.

While this may not rival the Library of Alexandria for depth of knowledge, this might just be the place if you want to know how to make cheesy beer potato soup or get a bike ready for spring riding. Now let’s see if there is a guide on what to do if a large number of birthday candles set of the fire alarms. Until later good luck and God bless.

Mike McPeek as an About.Me page that links to all his important stuff – about.me/mikemcpeek. He also has a blog where he combines pictures with all his little pearls of wisdom at mmcpeek.blogspot.com.

Kirschen Seah on the iLuv Inline Remote and

Hi this is Kirschen Seah from FreeRangeCoder.com and I have a couple of reviews for you. It’s hardware this time for a change.

iLuv Inline Remote

The first item is the iLuv Inline Remote, also known as the iPod Remote with Third-party Headphones Adapter for VoiceOver.

Ever been in this situation before? You’re listening to a podcast on your iOS device through speakers connected to your headphone jack and you need to pause it. You hit the home button twice and then tap on the pause button on the display. Wouldn’t it be nice if your speakers came with the same remote as on the iPhone headphones?

So here’s the solution to that problem – the iLuv inline remote. This is a simple little device which has an iPhone four conductor 1/8″ plug on one end and a 1/8″ jack on the other. In the middle there’s a three button remote similar to that on the iPod Shuffle (the one without the buttons). The buttons control the volume and provide play / pause functionality. Double clicking on the centre play / pause button skips to the next track, triple clicking skips to the previous track, much like the Apple inline remote.

You plug your regular speakers or headset into the jack and then plug in the iLuv into the iDevice. And voila! You have a remote control!

The iLuv remote is available in either black or white. You can get it for under $10 from Amazon, I’d recommend you use Allison’s link on her web page.

Advantages: it’s short in length, about 6 inches, and does not appreciably extend the length of the speaker cable. It also works with any speaker – powered or non powered – or headset. My one issue is that it doesn’t have a microphone, but for that price, I’m more than happy.

The iLuv remote sits quietly in between your iDevice and audio outputs and lets you control volume and play or pause the audio. Now I don’t have to turn on the iPhone just to pause a podcast.

CableJive dockStubz

The second item is the CableJive dockStubz Charge Converter and 30-pin Pass Through Adapter. Here are the problems to be solved…

You’ve got an iPhone safely wrapped up in a case and you like to plug it into a video output adapter. But wait, the connector is just slightly larger then the standard dock connector. You sigh loudly as you remove the case for the umpteenth time to plug in the video connector.

Or perhaps you have a dock connector in your car. It used to charge your old iPod but does not charge your brand new iPhone 4S at all. That’s because the iPhone now uses USB versus FireWire. You can play music but your iPhone will be discharging.

Here’s a third common issue – you have an iPad and want to use the VGA adapter but your battery is low. There’s no time to recharge before the important presentation.

Three problems – one solution. The CableJive dockStubz – it’s three things in one: a pass through dock connector, a charge converter, and an external charge adapter.

In the first scenario, you plug the oversized dock connector into the socket at one end of the dockStubz and plug the dockStubz’s standard size dock connector into your encased iPhone. It fits all cases as it is exactly the same size as the standard Apple dock connector. You can even plug it into the connector in Apple’s iPod dock and plug your iPhone into that.

For the second situation, the dockStubz contains circuitry to convert the FireWire power voltage to USB levels. You simply plug the dockStubz into the automotive dock connector and the iPhone into the dockStubz. It’s really that easy.

And in the case of the last scenario, the dockStubz has a micro-B USB receptacle on the side through which you can supply additional power. Since the Apple VGA adapter does not come with a dock connector power socket, as in the HDMI adapter, the dockStubz comes in handy to power your iPad while using the VGA adapter.

The dockStubz is available from Amazon and other retailers. It costs just a little more than $20. You’ll find that it’s such a handy little device to keep in your bag of device adapters. One thing I found amiss was that CableJive could have included a USB-A to Micro-B connector but alas, that was not the case. Fortunately my travel kit bag is equipped with that cable so I’m all set. Once again, I’m Kirschen Seah from FreeRangeCoder.com – and I’ll see you in the bitstream.


Well Kirschen – I immediately went to Amazon and bought the dockStubz,and it came in the mail this week but I wasn’t home to open it! Steve brought it down to me but I haven’t even opened the box. Looking forward to it though!

Kim Landwehr on Songza

< ---No text available-->
iPhone or Android app and a website that lets you create playlists. Kim’s info: Podcast is Remembrances Back in the Day (about growing up in 60’s and 70’s in NJ suburb), twitter is twitter.com/klandwehr, email is kim.landwehr@gmail.com, Facebook is http://www.facebook.com/kimlandwehr

Timothy Gregoire on Spideroak

Hi Allison,
This is Timothy Gregoire of The Church Tech Geeks Podcast, with another review. This week i’m going to talk about spider oak, but before I get to that, let’s start with a problem to be solved. Well, for a while now i’ve been trying to find a reliable cloud backup provider that works for me. Both Crashplan and DollyDrive have failed for me, so I wanted to try a new approach.

So, I tried spider oak. Spideroak is designed to be a competitor to dropbox, but with some major differences. First off, you don’t have to have a central folder where you store everything, there is no Spideroak folder. Instead, you select the folders that you would like to upload by checking the boxes in a filesystem view. You don’t have to move anything around on your system, which is a huge plus for me.

So heres my current situation: I currently have a 22.75 gb free Dropbox account, that I store all of my documents and other assorted files in for backup and access on the go. The problem is that the pro plans are way more expensive than spider oak and I need a place to store my iTunes library, my 50gb aperture library, and some other assorted files. There are also some security concerns associated with dropbox.

Spideroak has a zero knowledge policy. They claim that they have no access to your files. The files are encrypted before they ever leave your computer. Spideroak can’t recover your password without erasing all of your data, so make sure you don’t forget your password! Ive never heard a story about Spideroak getting hacked. To set up your backup, go to the backup tab and select the files that you want to back you.

You can also view files from all of the other computers in your spider oak network from the view tab. Spideroak does not limit you to one computer on your account. You can backup as many computers as you want as long as you have purchased enough storage to hold all of the files. Next is sync. Spideroak can sync files between computers and drives across your Spideroak network. It works very well to pull files across and to create an extra layer of redundancy of your backups.

It works across windows, mac and linux. Sharing is very similar to dropbox, its very easy to use. To share files, you create a share room and give the people that you want to share the files with the share room ID and password. Spideroak pricing is very easy to understand. Space is sold in 100gb increments for $10.

Spideroak is a free application and gives you a free 2gb account which can go to 10gb with their refer a friend program. Spideroak can be found at Spideroak.com. You can find me at thechurchtechgeeks.com, or you can search for The Church Tech Geeks in iTunes. I’m also @timothygregoire on twitter. Thanks Allison for the great show!

Chit Chat Across the Pond

Main Topic – How to Make Accessible Apps

When the iPhone first came out, people assumed that the blind wouldn’t be able to use it because it’s a touchscreen device with only 4 buttons. Apple proved them wrong. They have embraced accessibility in a BIG way. The iOS platform is the industry leader in mobile accessibility. Android, Windows Mobile, Blackberry, etc. don’t even come close. That’s why I’m a Mac/iOS user – my vision has fortunately remained stable, but I am always afraid that things might take a turn for the worse… but if they do I am ready for it

When talking accessibility, what are we talking about?

Primarily will be talking about accessibility for the visually impaired, because that’s the one that requires the most effort from developers. There are some considerations for other disabilities which I will briefly touch on later.

Basically each thingie on screen (button, text field, label, icon, etc.) has certain attributes that the Accessbility API’s need:

  • Is it an accessibility element? (Should VoiceOver be able to “see” it and recognize its existence?) (isAccessibilityElement)
  • What is it? (accessibilityLabeland accessibilityHint)
  • What are its traits? (accessibilityTraits)
  • Type of item (static text, button, image, adjustable control, etc.)
  • Is it clickable (can you interact with it)?
  • If it’s a selectable object, is it currently selected?
  • Does clicking on it start some sort of media playback (audio/video)?
  • If it’s an adjustable control, what is its current value? (accessibilityValue)
  • What are its on-screen coordinates? How big is it? (accessibilityFrame)
  • Here’s the good news: Apple makes it really easy to make your apps accessible. They provide a very rich set of tools and APIs that help with this. Which means you have absolutely positively NO excuse not to! In most cases, all it invokes is literally just a few extra lines of code, and poof, instant accessibility. In some cases, no coding is required at all.

    Standard UI elements:

    • One of the great things about developing for iOS is Interface Builder – you can piece together your program’s UI by dragging and dropping from a large palette of UI widgets (text labels, buttons, sliders, etc.)
    • If you use these standard interface elements – guess what – the system automatically makes them accessible. Since Interface Builder knows what it is you’re putting on screen, it automatically fills in the necessary accessibility information.
    • Works best if your UI has obviously titled elements (i.e. a button titled “Play” that starts playing something).
    • Beware ambiguous labels (or controls that don’t have a label)!
    • Example: In the Otaku no Podcast app, in the Podcasts screen (first tab), there are entries for “Latest Audio Podcast” and “Latest Video Podcast.” Beside each is a “Play” button. It’s obvious to a sighted user what each Play button does; however, for a VoiceOver user, all they would hear if they tapped it is “Play” — play what??!
    • Example 2: In the Otaku no Podcast app, look at the Audio Player screen. The “play button” at the lower left uses the “play” graphic – no text label. In this case, since VoiceOver doesn’t have a text label to fall back on, it uses the filename of the image that the button is using. So you’ll hear something like “playbtn dot PNG” which is even worse!
    • In cases like this, we need to give iOS some more specific information.
    • In Xcode, highlight your UI element, then go to the Identity Inspector. There you will find a section on “Accessibility.”
    • “Enabled” – whether this item should respond to VoiceOver (You’ll almost always want this)
    • “Label” – What you want it to say (Example: for the “Audio Podcast -> Play” button I put “Play the latest audio podcast”; for the “play graphic” button I put “Play”)
    • “Hint” – This text is spoken after a short delay after the “label” is spoken. Useful to give the user additional information about this particular UI element. (Example: for the Refresh button, the button’s Label is “Refresh”, and its Hint is “Tap to check for new episodes…” – it gives the user some additional information if he/she is confused.)
    • “Traits” – Most of these options are very specialized, and you don’t want to go turning them on willy-nilly. Here are the important ones:
    • “Button” – is this a button?
    • “User interaction enabled” – can you “do” something with it? (I.e. tap a button, enter text into a text field, etc.)
  • You can still manipulate these values in code if you want (handy if e.g. you need to change your UI to respond to conditions when your app is running).
  • Some actual examples from the Otaku no Podcast app: https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
    Look at “OnP main screen – play latest button,” “OnP main screen – refresh button,” and “OnP player screen – graphical play button”
  • Custom UI elements

    • Sometimes the standard controls aren’t enough (you need more/different functionality); also sometimes you may use standard controls, but want to create and manipulate them in code (rather than using Interface Builder). In these cases, you will need to use code to set up all the necessary accessibility information.
    • All accessibility information can be set in code.
    • Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “adding to code 1” and “adding to code 2”

    Accessibility Containers

    • Sometimes you may have an object that is subdivided into multiple sub-objects. You need to provide accessibility information for those sub-objects.
    • Example: the Convention Calendar tab in the Otaku no Podcast app. The entire calendar view is a single object; each individual day is a sub-object. Unfortunately this is one area where I still need work; it is completely inaccessible. I’m using an open source calendar library that isn’t yet accessible. I’m working with the developer to add accessibility to it. For an example of this done right, take a look at the iPhone’s Calendar app, in Month view.
    • In this case, we use a series of “accessibility containers.”
    • Each container provides a full set of accessibility information to the OS (description/label, value, hint, etc.), as well as the bounds (the physical location/dimensions of the area where this accessibility information is attached to).
    • These elements are stored in an array (an ordered collection of objects). You need to provide three pieces of information to the Accessibility API’s: the number of items in this array, a way of retrieving a given item #, and a way of testing if a given item is part of the array. (In 99% of the cases, these will be trivial one-liners.)
    • Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “container code 1” and “container code 2”
      Another good (more real life) example can be found in the Use Your Loaf TaskTimer project (see below); look at theUYLCounterView.m file

    Accessibility Actions

    • If you are creating a custom adjustable control, you need to give VoiceOver information on how to manipulate its value.
    • VoiceOver has two standard gestures: swipe up (increases the value of something) or swipe down (decreases it).
    • So when coding your custom control, you need to create special “increment” and “decrement” code that VoiceOver can use to change its value.
    • A good example of this is the page turner in iBooks (the little dotted line with the box at the bottom that lets you quickly page through a book).
    • A third type of gesture is “scroll.” This is meant for a control that scrolls to a different part of your UI. Example: moving between home screens, or scrolling between cities in the Weather app.
    • Example:https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “action code 1” and “action code 2”

    UI Changes

    • The iOS user interface is very dynamic. Things are moving around, morphing, swooping in and out, etc. Obviously blind users can’t see this. So iOS provides a way for developers to let the user know that “something happened” using VoiceOver.
    • There are three types of UI change notifications.
    • Screen changes: when your UI changes dramatically. Usually when a user moves into a different part of your app (navigates to a different screen). VoiceOver notifies the user with a tone, and it clears its caches and does other preparations to deal with a new set of accessibility data.
    • UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, nil);
  • Layout changes: if some part of your UI changes, but the user hasn’t necessarily jumped to an entirely different part of your app. (Example: in the iTunes Store app, tapping on the price label ($0.99, etc.) next to a song changes it to a “Buy” button.) This notification tells VoiceOver to re-read the current state of all accessible items that are on-screen, and by doing this it figures out what has changed and informs the user of those changes.
    • UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, nil);
  • Dynamic changes: if a part of your user interface is dealing with some dynamically changing information (state changes, data changes, etc.). This notification tells VoiceOver to read it out to the user. Example: in the Compass app, the compass value is constantly changing as the user moves his/her device in space. The Compass app sends a dynamic changes notification that tells VoiceOver to read out your current heading. Also useful for communicating any sort of significant status change in your app (“Loading complete,” “Connected to server,” etc.) You may only want to do this when a significant change in data has occurred, otherwise it can get real annoying. (for example, Compass only notifies when the compass value has changed by 5 degrees I believe.)
    • UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, @”Loading complete.”);

    VoiceOver-specific API

    • Sometimes it is useful to determine whether or not VoiceOver is running, and to do different things depending on whether it is or not.
    • A program can, at any time, test to see whether VoiceOver is enabled or not.
    • if (UIAccessibilityIsVoiceOverRunning()) {
      // VoiceOver is active; do something different
      }else {
      // VoiceOver is NOT active; do the usual thing (whatever that may be)
  • Also, programs can sign up for the system to notify them whenever the VoiceOver status changes.
    • [[NSNotificationCenter defaultCenter]addObserver:self selector:@selector(handleVoiceOverStateChange:) name:UIAccessibilityVoiceOverStatusChanged object:nil];
  • Your program can also tell where VoiceOver’s “focus” (the object that it’s dealing with) is, and when “focus” enters or leaves any given object.
    • accessibilityElementIsFocused
    • accessibilityElementDidBecomeFocused
    • accessibilityElementDidLoseFocus
  • A good use for this is, when a user is running VoiceOver, to present a more simplified UI to them, or otherwise change your UI to make it easier for VoiceOver users to interact with. Example: In the Photos app, the photo controls normally disappear after a few seconds to let you view the full image. This could be confusing to VoiceOver users; so if Photos detects that VoiceOver is in use, it prevents this auto-hiding behavior.
  • Testing Accessibility

    • Naturally, like any other aspect of software development, you’ll want to test your accessibility code.
    • In the iOS simulator
    • The iOS Simulator has a built-in Accessibility Inspector. It displays all the accessibility data of any given object on screen (just click on it).
    • Access it by pressing the virtual Home button, launching the Settings app (you might have to swipe right to get there), tapping on General, then Accessibility, then turn on the Accessibility Inspector.
    • Example: https://www.dropbox.com/gallery/169813/1/iOS%20Accessibility?h=1f050c
      Look at “Accessibility inspector”
  • On real devices
    • Unfortunately the accessibility inspector doesn’t support certain actions (notably the swipe gestures that let you change values of controls). Also it doesn’t really give you a “feel” for how an actual blind user would interact with your app. For this you really need to test on real hardware.
    • To enable accessibility – Settings -> General -> Accessibility -> VoiceOver -> turn it ON.
    • A shortcut is to set up the triple-click home button shortcut: Settings -> General -> Accessiblity -> Triple-click Home -> set it to VoiceOver
    • If you’re feeling really brave, you can enable Screen Curtain (completely turns off the screen, the closest thing to actually turning yourself into a blind person, and much more comfortable than a blindfold (or poking your eyes out)). Just activate VoiceOver then triple tap using three fingers. Repeat to turn off screen curtain.
  • Of course, doing your own testing is fine (and indeed is essential), but you really should be sending your app out to others to test.
  • Miscellany

    • If you localize your app, you also need to localize your VoiceOver prompts! (VoiceOver is available in 30 languages)
    • If you’re not localizing, you really ought to. The App Store is global, why shut out a potentially huge user base? Getting translators is easy and relatively inexpensive (try Craigslist).
    • Remember that localization doesn’t just mean translating words and letters; some countries have different ways of expressing date/time, currency, etc. iOS has code that helps in these conversions.
  • It’s always good to think outside the box.
    • With clever use of the accessibility tools, you can make things accessible that you wouldn’t think were possible.
    • A good example is the Stocks app. You’d think that there is no way that the graph at the bottom could be made accessible. You would be wrong.
    • They used accessibility areas to slice up the graph. For each slice, it tells you a representative date within that period, and the stock price for that date.
  • Less is more.
    • Keep your labels short. Users are going to be scrolling through these dozens of times.
    • If you want to provide additional information, use an accessibility hint. (That way users only get the additional information if they actually need it)
  • The more buttons, interactive elements, etc. on a screen, the harder it is for a VoiceOver user to navigate it.
    • If you really want the fancy UI, check to see if VoiceOver is in use; if it is then present a simplified UI.
  • Do not include an object’s type (“button,” “slider,” etc.) in its accessibility label. iOS will automatically read out the item’s type itself, so there’s no need for you to do so also (besides it makes your app look amateurish).
  • Remember that there are other disabilities besides blindness.
    • Physical Disabilities:Try not to make your UI teeny tiny. Of course this makes it more difficult for sighted people to use your app. But it becomes orders of magnitude worse when you throw physical disabilities into the mix(motor control difficulties, CP/MS, or people who use a head-mounted pointer, etc.) It also makes it harder for visually impaired (but not completely blind) users to see your app as well. IMHO this might be a compelling argument for a larger-screened iPhone (more space to spread out your UI in).
    • Deaf/Hard of Hearing: Some programs use sounds to indicate that something happened. It’s always a good idea to also include some sort of visual feedback as well, for those who are deaf/HOH.
  • Use standard controls (text entry fields, buttons, etc.) whenever possible. Not only is this good for usability (users know what an iOS text box/button/on-screen keyboard/etc. look like, they may not be able to instantly recognize your weird nonstandard UI); but using standard UI elements also gives you the highest level of compatibility with alternative input devices (head pointers,braille displays/keyboards, etc.). (Bad example of this is Mac OS Ken’s Secret Crypto Wonder Badge. Totally nonstandard keyboard.)
  • Resources

    The obligatory plugs section

    • Check out my iOS apps!
  • My portal site – links to everything I do, as well as houses my blog. http://DonaldBurr.com/
  • I’m on twitter as http://twitter.com/dburr/
  • And finally, if you are at all interested in Japanese animation (Anime), comics (Manga), food, travel, culture, etc., check out my podcast, Otaku no Podcast. http://otakunopodcast.com/
  • That’s going to wind this up for this week, many thanks to our sponsor for helping to pay the bills, Blue Mango Learning at bluemangolearning.com makers of ScreenSteps and Clarify. Don’t forget to send in your Dumb Questions, comments and suggestions by emailing me at allison@podfeet.com, follow me on twitter at @podfeet. I contribute a fair amount over on Google Plus nowadays so just search for me by name if you want to circle me up. If you want to join in the fun of the live show, head on over to podfeet.com/live on Sunday nights at 5pm Pacific Time and join the friendly and enthusiastic NosillaCastaways. Thanks for listening, and stay subscribed.

    2 thoughts on “#364 iOS Tips, NoMenuBar, Akinator, Snapguide, iLuv Inline Remote, CableJive dockStubz, Songza, Coding Accessible iOS Apps

    1. Coder Blog - May 3, 2012

      […] here’s the review on NosillaCast #364 No […]

    2. Coder Blog - May 3, 2012

      […] to the NosillaCast #364 review No […]

    Leave a Reply

    Your email address will not be published.

    Scroll to top