Tag Archives: #idevblogaday

This is my last #idevblogaday post for now, and unfortunately I’ve completely run out of time for this week’s post and I can honestly say I don’t have any ideas for it either. How about that!?

Despite it now being a bi-weekly submission, it’s still hard to keep going with new ideas every two weeks :)

But I’d like to thank everyone who’s been reading my previous blog posts and please do check back again in the future. I’ll probably enlist myself in the queue again and try to write some blog posts in the meantime if I come up with some ideas :)

Accessibility on iOS provides visually impaired iOS users the ability to use an awesome touch screen platform to its full extent. It’s your job as an iOS developer to ensure your app works wonderfully with Accessibility on iOS.

When considering adding features or optimizing your app for Accessibility, don’t assume we’re just talking users who are completely blind. And despite being all iOS being full touch screen devices, there are lots of visually impaired users outthere, ranging from users who are blind, hard at seeing or colour blind, for example.

Apps, such as Mail, numerous Twitter clients and more include the possibility of changing text on the screen to a larger font size. Matt Rix‘ Trainyard includes an option for players who are colour blind. These are just a few examples of improving apps for Accessibility.

Also consider interaction. While a scroll requires just a flick with one finger for regular use, having VoiceOver enabled scrolling is done with a three finger swipe, and moves the UIScrollView (and any NSObjects that inherit from UIScrollView) a page at a time. So while a pull-to-refresh is awesome, for user with VoiceOver enabled, it might not be as apparent or ease to use.

In this post, I will focus a bit on optimizing your app for VoiceOver. Before continuing with this post, check the video below where a blind user shows off VoiceOver and demonstrates how to use it.

I also recommend enabling VoiceOver on your own device and playing around with it for a while, just to get familiar with it. One thing is to know about it and use it with the Accessibility debugger turned on in Simulator, another thing is to experience it for yourself!

While most of UIKit works fairly well out of the box with VoiceOver, there are plenty of things you can do to improve how your app works with VoiceOver. If you’re doing any custom UI (especially drawing) VoiceOver will most likely not work, or it may speak out the names of the object. So if you call a custom UIButton “createNewTaskButton,” that’s what it will say. Instead, it should probably say “Create New Task”.

Consider your own app(s) and what use visually impaired users may have of it. I made a transit app, so it was only natural to optimize it for visually impaired users and add custom and improved VoiceOver support. With VoiceOver enabled, users can tap the time until the next transit vehicle arrives and the device speaks out in plain English “Next TTC vehicles arrives in 5 minutes and 32 seconds. Tap again to hear updated time.” If I had not customized it, it would have just said “5:32.”

Underneath are subsequent vehicle arrival times. As you can see from the Simulator screenshot, without VoiceOver optimization, the device would just say “20 min bullet 25 min bullet 26 min.” With Voice Over optimization, it says “Subsequent TTC vehicles arrive in 15 minutes (pause) 20 minutes (pause) and 25 minutes. Tap again to hear updated times” Notice the (pause) and look at the screenshot. VoiceOver speaks pretty fast, so if you would like a bit of a pause, just insert a period, and it will pause a bit between the words. This is a great way to split up important information.

Also notice how it will say “and” for the last arrival time. If there are more or less times, it would only say it for the last item. Remember attention to detail in these cases. If someone was to tell you the information for what you touched on the screen, how would you best understand it? There’s a huge different between spoken language and UI. Keep this in mind!

For the buttons with which users can change a route, the label would look like this “506 • Carlton.” In this case, the literal VoiceOver sentence would be “506 bullet Carlton.” So I went ahead and customized this to “506 Carlton,” so it wouldn’t speak the “bullet” part of it. For the custom UIButton where the user can add or delete a route/stop selection to their Favourites, I added “This is a favourite. Double tap to remove from your favourites” and if the selection is not a favourite it would say “Not a favourite. Double tap to add to your favourites.”

If you’re doing any custom drawing, for example as I have done in the example on the right, you will need to pay extra attention to VoiceOver optimizations.

For flat, drawn views, VoiceOver cannot access any of the text or other information on screen. In this example, I draw each cell, so there are no UILabels or UIImageViews for VoiceOver to recognize and speak.

I therefore set the accessibilityLabel property on each cell which then provides VoiceOver with information about what to say. As you can see from the example, according to Accessibility Inspector, VoiceOver will say the route number and name, and because the item is a current selection, I also made sure VoiceOver lets the user know about this by saying “Current selection” after the route number and name.

For non-VoiceOver users, the checkmark is a great visual marker for the item being a current selection. But for VoiceOver users, this would have not been the case. Especially since it’s a custom drawn view, VoiceOver has no clue about the checkmark. In your Accessibility optimization, not only consider what VoiceOver would say, but also consider the UI and what VoiceOver can see, or should see that is related to the item the user it touching.The user may not know about a certain UI object or visual marker without VoiceOver telling them.

Accessibility Inspector in iOS Simulator is a great tool to help optimize your app for full VoiceOver support. Tapping the X button disables the Inspector and hides most of its UI. This enables you to see the app without VoiceOver enabled to quickly get to the content you’re currently debugging for VoiceOver, or since VoiceOver scrolling requires three fingers, it will allow you to scroll when you disable it temporarily.

While Accessibility Inspector shows what VoiceOver will say, you should again test on an actual device with VoiceOver enabled. As mentioned, one thing is how something looks and “sounds” when it’s written, another is how it sounds when VoiceOver speaks it.

So these were a few of the consideration I made for one of my apps in optimizing it for full VoiceOver support. For more on the subject, I urge you to read Apple’s Accessibility Programming Guide for iOS, which gives a more detailed overview of the possibilities as well as more in depth examples and usage guides.

Furthermore, Matt Gemmell has written a great post on it as well with more details on Accessibility properties, among other things, and it’s totally worth checking out.

What a week. Yesterday I returned from a fantastic week in San Francisco attending WWDC and related parties and events. I met some incredibly talented, incredibly interesting and incredibly fun people throughout the week from all over the world. While it’s stressful and tiring, I wish I had more time to meet even more awesome people. Thanks to everyone who were part of making my second WWDC attendance a blast!

Days have been packed full of amazing and interesting sessions and evenings running to dinner, parties and bar hopping. For this reason, I haven’t managed to prepare anything great for this week’s #idevblogaday post. But I took some pictures throughout the WWDC week, so I thought it would be fun to make a small “WWDC in Pictures” post. The photos are all taken with my phone, so don’t expect amazing shots. But I’ve tried to include various shots of things you don’t necessarily see in the press for example.

Enjoy.

Sunday registration

Snack tables were always a big hit. Probably the only thing at WWDC without line-ups, surprisingly!

Typical line-ups for a session. And I was in the front of the line. In the background is another line-up coming towards us.

View going up an escalator of one of the many WWDC banners

Always busy and buzzing in the lobby of Moscone

Line-up for one of the more popular sessions in Presidio

Waiting for a session to begin

Drinks at The Chieftain. Loren Brichter is in this shot.

T-shirts were a big thing this year. Here's an awesome one I got from Mike Piontek (@robotspacer)

TestFlightApp.com's t-shirt. If you wore one in the Keynote line-up you got free breakfast. Awesome marketing.

Great line on the WWDC Bash wristband

Random WWDC Bash photo. Lots of food and drinks!

As Michael Franti & The Spearhead entered the stage everyone was like "Who?". I personally hadn't heard of them but enjoyed the music way more than OK GO. Rock just doesn't do well live if you don't know the songs.

I love this guy. Seriously. He's my hero.

Beach balls!!!

Everybody enjoying the Bash

Line-up for the men's wash room. Worse line of the week - I had had four beers at that point. They even started letting guys into the women's wash room.

Waiting for Wednesday's lunch presentation to start.

Buzz Aldrin's presentation was followed by a Q&A. Notice the patriotic lighting.

Stump the Expert is always a blast.

My last WWDC beer Friday evening at Jillian's watching Canucks beats Bruins with my new German friends from iosphere GmbH. What a week.

I just returned from vacation, so this won’t be a huge blog post. I’m making a pretty sweet offer at the bottom of the post, so be sure to check it out at the bottom!

In this post I will address how you can use simple techniques to create a sense of depth on a flat touch screen device and a “visual tactility” to your app – and without going completely overboard with textures. While I like to create unique examples, I’ll be using examples from existing apps and talk about what effects are used, what’s good about them and why you should stay away from some of them.

What’s too much?

You might be familiar with the Game Center app. While the design is great and I can appreciate they were going for a pool table-look or poker-table look with wood grain navigation and tab bar, and a green fabric background, but I personally think it’s all too much.

Gloss on top of wood (navigation and tab bar) just doesn’t work, and it really makes it look more fake than real. The horrible font and it’s weird shadow are also not working. And the shadow is depressed into the background as well? Weird. Furthermore, notice how some items in the main view are raised from the background, while others appear to be depressed into the green background. And why is there a shadow coming from the navigation bar only and not the tab bar? The navigation bar is raised from the background, yet the identical looking (texture-wise) tab bar is on the same plane as the background.

Needless to say, this is a great example of what’s too much.

Textures that work

Notice how this app uses lots of textures, yet they make the app more appealing, and when you view it on your iPhone it really looks and feels great. Groceries also uses a wood grain texture for the navigation bar and tool bar. The background (more visible on first launch of the app) is a cork board texture, which matches the two bars. The table resembles a piece of note paper stuck to the board, with the top edges torn and casting a soft shadow on the background.

Now, while both Game Center and Groceries share some major similarities, why does it work for Groceries and not for Game Center? As I mentioned earlier, gloss on wood doesn’t work. In Groceries, Sophia uses a soft white-to-transparent gradient that helps fake a soft light from the top, making the bars seem 3-dimensional. The colours of the text match in the bars the wood grain much better compared to the Game Center app. Both the navigation bar and tool bar cast a soft shadow on the background and paper creating a nice depth in the UI.

Groceries is a great example of how extensive, yet careful use of textures in your app’s UI can compliment your app’s content and not desperately steal away attention from it like in Game Center.

Shadows create depth

Using shadows, you can easily create a 3-dimensional effect. As seen above, you can protrude and depress views when using shadow effects on views and texts.
For UILabel, see the properties shadowOffset and shadowColor. I suggest you use these for most text in your app. As a general note, do not use it with longer text, such as in a UITextView or where not approrpriate, such as in a UITextField. I briefly talked about how to appropriately use colours and offset in this post: http://runmad.com/blog/2010/11/random-tips/ (Tip #4). Have a look at the above screenshots and see how shadowOffset is used.

Some points from this post:

Don’t go crazy with textures. Subtle is key and more is never the answer!

Use textures and colours that compliment each other.

While you want to go for real-world look and feel, creating completely “realistic” interfaces often never works. It’s all about finding an in-between state, where it’s appropriate for a non-tactile, touch screen device, yet still has a 3-dimensional depth to it.

I was expecting this blog post to be about something completely different, but I’m still out of the country and have come down with a bad cold, so it’ll be a bit of a short and simple.

I’ve decided just to a few coding tips, I have come across and though might be useful for other devs, especially if you haven’t worked much with UIKit before in your development, or perhaps just these areas below. (At the bottom of this post is an Xcode project file which includes examples of the tips below).

Tip #1: Check for URL scheme and open correct app from your ownYou’ll probably run into having to link to another app, for example your company’s Twitter account. Instead of just linking to the Twitter website, you can do a quick check in code and open the Twitter app instead. You can also do it with other Twitter client apps as well, however, not all have URL schemes setup (that I could find), and most users will probably be using the official one anyway. Regardless, the code is good to do the same check for other apps, or if Twitter.app doesn’t exists on the user’s device, you can try another Twitter client app, or use a UIAlertView to ask the user what else they’d like to use (depending on which ones are possible to open using the URL scheme).

Basically, all you have to do is ask whether UIApplication responds to the URL:

Tip #2: Getting a free UINavigationController in your UIViewControllerI have seen some apps that use a UIToolbar as a navigation bar, and this just doesn’t work. If you compare the two, they’re actually a bit different, and this really shows when put in the wrong place.

If you’ve got a UIViewController, turning it into a UINavigationController is really easy:

Tip #3: Getting a free UIToolbar in your UINavigationControllerThis one I only just recently found out (thanks to @auibrian). UINavigationController actually comes with a UIToolbar. It’s property is set to hidden:YES by default, so all you have to do is override this property when you load the view.

[self.navigationController setToolbarHidden:NO];

Note: I have seen some weird behaviour when pushing view controllers onto the screen (buttons not getting a pushing animation, just appearing in the toolbar in place). Also, you will need to hide the toolbar if you’re popping or pushing to a view controller that you do not want to show the toolbar (because with pushing you’re reusing the same navigation controller). In my opinion it’s not a very good way, I wish the view controllers were more separate for this.

Tip #4: Use shadowColor and shadowOffset appropriately when faking text indention
One thing that bugs me are improper use of a UILabel’s shadowColor and shadowOffset. When using these, one has to pay attention to the colour of the background as well as the text colour. In the below example (when we’re going for the look where text looks carved into the display, used by Apple across the entire UI), we’ll see that when using darker text, use a lighter colour for the shadow and a positive value for the offset.

When displaying lighter coloured text, use a darker shadow colour and a negative value for the offset, which in both cases create the proper indented or “carved” effect.

Using the wrong combination doesn’t create this effect and makes the text appear raised from the rest of your UI, which is most likely not what you should be going for in most cases ;)

I’ve made a small Xcode project you can download here, which has the code examples from tips 1, 2 and 3 and I suppose #4 as well, since navigationItem.title is using text indention.

Again, apologies for a bit of a short and simple post due to being under the weather and traveling.

This will be my first #idevblogaday post, so I’ll just briefly introduce myself and then get on with my post. Follow me on Twitter: @runmad, by the way :)

I’m writing this on a flight from Toronto to Copenhagen on an iPad so hopefully it’ll turn out alright. I was afraid my turn for #idevblogaday was going to be exactly when I was going away on vacation, and sure enough @mysterycoconut tweeted @ me the day I was leaving that I’m up, so here we go.

I’ve done development for about 1.5 years now, Objective-C is the only programming language I know. I have a degree in marketing and management communication and years of experience in graphic design. I love experience marketing and sensory branding. I got into iOS development because I loved how (then) iPhone OS brought to life an amazing UX through great hardware, UI and functionality. A great iPhone app is a mix of marketing, design, experiences, sensory triggers and of course, code. So I started learning the coding part and have found that knowing all the rest really does help and benefit you!

I work for online retailer and I have built an iPhone app that allows you to browse our products, purchase them, check orders, etc. You can check it out here.

Your app sold a few hundred copies (or thousands, congrats) after first releasing it and has since then steadily not sold very well. Should you care to do actively pursue further development and thereby bring more features and goodness to your customers who already paid for your app? Let me try and convince you to do just that.

I’ve read a bunch of posts on IAP and how this has revitalized sales for a game. Noel Llopis’ (@snappytouch) Games From Within blog to read a few posts on his experiences with using IAP to boost sales for his game Flower Garden. IAPs are definitely awesome, and I guess this post will be more of a idea that would compliment IAP in certain instances (depending on what kind of app you have).

I had no Internet connection while writing this, so I have no links for facts and figures but go by general knowledge and my perception of scenarios. Trust me, it’ll be awesome anyway, facts are hugely overrated, right?! You might not agree with me, but feel free to leave a comment and we’ll talk ;)

Joking aside, let’s have a look at why I think you should create and submit meaningful app updates, somewhat regularly.

We all know that App Store customers are greedy. You give them a free app, they want an arm. You sell your game for less than a buck and they complain about there only being 150 levels which meant they finished it in a day because it’s so good (telling you they’ll reward the last, fifth star when you release an update with a billion levels).

Let’s stick with that dollar. How much are you as a developer, as the seller, willing to put into your work after it’s out of the door and the first point updates are released to fix those nasty bugs? I know developers generally hate when customers complain about a one dollar app in a review, but look it this way: They paid you money. They bought something from with their money. They feel entitled as your customers. I bet many indie developers didn’t expect to have to deal with customers when they started iOS development, and are unfortunately surprised by it. It might just be a buck, but this dollar can lead to much more money if you take care of your customers. Give them more than what they came for and they’ll help your sales grow by spreading the love through word of mouth.

The dilemma you have is whether, once a customer has paid for an app, should they receive more? Sure, you can sell level bundles or other objects related to a game with IAP, but perhaps you could also just give this to your customers for free… Or if you have a non-game app, it’s not easy to sell app features as IAP, and I’ve never personally been a fan of apps that have a “Pro” version.

Spreading the loveWhen was the last time you told your friends not to miss out on a dinner at that restaurant where the waiter treated you like shit? And how many times have you been back to that awesome bar where they tend to free-pour rather generously?

Let’s look at free-pouring. Angry Birds. I would say it’s probably the most popular app ever. It rival sales numbers (not profits mind you) of major console franchises and why wouldn’t it, it’s a buck! Buying this game is a no-brainer for most people, even the greedy ones. You get so many levels it’ll take you days if not weeks to finish. Once you’ve finished they throw more free levels at you in a free update for that one dollar you spent two months ago. They’re clearly insane, right?!

In my opinion (even if this isn’t their intention) it’s a quite clever marketing move. Every single time Rovio releases an update to Angry Birds you’ll tap open that game while riding the subway with hundreds of other people seeing you play this game. You’ll remember how much you love that game and be sure to tell your friends with iPhones (and now other platforms) to download it. You haven’t left a review yet, but feel that now is the time to do so. You’ve had so much fun playing this game – and still do with new levels! – that they deserve that quick 5 star review.

App update sales multiplier
Let’s say Angry Birds has sold 1,000,000 copies (it’s sold a lot more but let’s stick with a nice, huge, round number). Of this 1m downloads, 95% still have it installed and have played it within the last two months. (It’s my belief that a paid app actually stays on a users home screen way more permanently than a free app. It’s like throwing out a dollar and it doesn’t take up any physical space in your life even if you don’t use it. Apps that stay on the device (not just iTunes) are way more likely to receive attention when updated in the App Store.) Angry Birds gets an update with fixes but, more importantly, a new world and 30 new levels or so. Of these 950,000 active customers, let’s say most will update at some point. 10% of these people will tell their friends. On average these 10% tell two friends about the game. Of these 190k people who now know about Angry Birds, just over half will go to the App Store and download Angry Birds for a dollar (it’s a no-brainer price).

So now, from a free update, Angry Birds just made another $100,000 (before a 30% cut) on top of that 1 million copies already sold. Of course I was using the highest grossing game, but I still believe it this ripple effect holds true for your apps. If you reward your customers and exceed their expectations, trust me, they will reward you back by word of mouth, which lead to more sales.

You’ll always have those vocal, annoying customers with horrible reviews and ridiculous expectations, but don’t forget the people who often are the least vocal to you are often really vocal about your app/game to their friends. Who do you trust most for advice on awesome apps, people who are clearly idiots from app reviews or your real life friends or people you follow on Twitter? My guess is the latter two. Just like the restaurant example earlier. You’re probably more likely to visit a restaurant based on a great review from a friend who recently went there compared to a review in a newspaper.

Active developmentYou may not be selling millions of copies of your app like above, but it doesn’t mean you shouldn’t pursue active development if your app has something going for it. Updates will remind your customers about your app. They’ll revisit the app and it’ll be first in their mind been their friends asks what new stuff they’re using on their iPhone, or which apps they should get within X category.

I know this comparison may sound insane, but it’s rather valid: Coca-Cola technically doesn’t need to advertise. It’s not like we don’t know what it is, where to buy, how it tastes and how it makes you feel, right? True, but when Coca-Cola spends millions and millions of dollars to advertise, they’re reminding you of the brand over and over and over. If you hadn’t just read the first part of this paragraph, I would bet money that you would have said “Coca-Cola” if I asked you to name a soda brand. This is because you have seen so many Coca-Cola advertisements and heard the brand name so many times over the years that it’s imprinted in your brain!

Same goes for your app. Remind customers about your app and be the first thing to come to mind when they think of awesome apps within your apps category/core functionality.

With all this said, don’t just release meaningless “bug fix” updates. People will see straight through this after several of seemingly pointless updates and only get annoyed that your app apparently is full of bugs. As @Jury said in a tweet the other day:

Obviously, if you have a severe bug in your app, get it fixed asap, so your customers won’t grow resentful of the fact your app doesn’t work as expected.

So in review:
– Free updates help increase awareness about app.
– Awareness leads to re-discovery which helps keep your app “immediate” for users.
– Think of users as customers. You’re not doing them a favour by releasing an app. They’re doing you one by giving you money in return.
– Give your customers more than they expect and they’ll return the favour with a review or other kinds of word of mouth.
– Updates help provide value and helps your app exceed your customers expectations, regardless of the cost of your app.

Note:
– “Bug fixes” are not directly seen as value for your customers. Sure you fixed bugs, but what value does this bring other than just fix something that should have been working in the first place?
– In my opinion, too many “bug fix”-only updates that talk about “improvements,” etc. just become annoying and doesn’t show customers that you (the developer; or seller) is focused on building new features.

I hope you enjoyed my first #idevblogaday post. I hope it was insightful and invoked some thoughts as to what you could do with your app, even if I didn’t provide a single line of code :)

I do hope I surprised some people with how marketing blends in with being an iOS developer and provided some insight into what kind of relationship you have with the users of your apps.