Making Rounded Rectangles Look Great (with CSS)

Go directly to the project demo page.

Mike Rundle of flyosity.com recently posted an article, Making Rounded Rectangles Look Great, on designing rounded rectangles, some design techniques, etc. I recommend you to check out the post and download the PSDs for great inspiration!

I’ve recently worked extensively with re-engineering and re-designing the UX and UI for an online retailer, which involved a lot of paper, Photoshop and CSS (or Sass).

I thought it would be cool to create the buttons from Mike Rundle’s article in pure CSS, so I went ahead and did it. Before checking out the CSS buttons, be sure to check out Mike Rundle’s examples and PSDs for a comparison.

I tried as much as possible to stick with the same colours and transparencies as Mike Rundle’s examples, although there may be slight differences, depending your display and browser.

I’ve also added :hover and :active states to all the buttons, so they’re a bit more exciting. Unfortunately CSS doesn’t provide a simple way to create a masked gradient at an angle, so the Convex example is probably the least similar one. But it still looks great and I wanted to stick with all CSS – could have been achieved with an image mask or simple overlay.

You can check out the result on a separate page. Feel free to grab this .zip containing all the project files: Rectangles.zip.

Accessibility on iOS: Working with VoiceOver support

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 RixTrainyard 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.

Next TTC: Behind the scenes

Last week, I released Next TTC 2.0, a major update to my real-time arrival predictions utility app for Toronto’s streetcars (buses to be added by Toronto Transit Commission (TTC) soon).

Today, I’d like to discuss how I went about dealing with the data that is provided through the API and which UI/UX choices I made based on the data and how it would be used.

Bit of background

Data is provided for Toronto’s public streetcar transportation system through the nextbus.com API. Basically vehicles are outfitted with a GPS. Based on their location and proximity to a certain stop, the API provides arrival time predictions. So for example, if a streetcar is 1.2 km away from a XYZ stop, based on the average speed and time it takes from the streetcar to arrive at XYZ it will tell you that the streetcar is arriving in 4 minutes and 43 seconds. This can however change if the streetcar is backed up in traffic or suddenly able to travel at faster speeds, or make less stops en route to stop XYZ.

The data

TTC provides up to 5 arrival time predictions for the requested stop and/or route.

By requesting data for a stop only, you’re provided with all routes and their arrival times for that particular stop. Depending on the stop, this may be one or several routes at once. You’re also able to request stop and a specific route, which means the API just returns arrival time predictions for that route.

Furthermore, for TTC, some streetcars make short-turns. For example, route 501 westbound has two end destinations. The streetcars are on the same track for most of the way, but every few streetcars will stop at an earlier station. This means the API also returns predictions for each route-short-turn.

The data may appear as such:

  • Route 0
    • Destination 0
      • Prediction 0
      • Prediction 1
      • Prediction 2
      • Prediction 3
      • Prediction 4
  • Route 1
    • Destination 0
      • Prediction 0
      • Prediction 1
      • Prediction 2
      • Prediction 3
    • Destination 1
      • Prediction 0
      • Prediction 1
  • Route 2
    • Destination 0

In the above example we have requested data for a stop. This stop is serviced by 3 streetcar routes. Route 0 is currently in service and we are returned 5 arrival time predictions. Route 1 is also in service and has two destinations (or short-turns) for which we are returned results for both. Route 2 is currently not in service (some streetcar routes only run during rush hour) and we are not returned any arrival time predictions.

So as you can see, we are potentially dealing with a great deal of data.

Scope

Version 1 of the API provided less amount of data and details, so in Next TTC 2.0 I wanted to upgrade as well, while still retaining the basic user experience of the app.

The basic scope of the app is to launch the app and instantly get arrival time predictions for the stop nearest your current location. In essence this is pretty easy with Core Location. Once you have a user’s location, loop through all stops to find the nearest stop and request the data for that stop.

But how do you retain a simple user experience as required by the scope when you’re dealing with potentially lots of varied data?

UI/UX decisions

In Next TTC 1.x, if a stop had more than one route, I prompted the user to select the desired route – or telling them Route X and Route Y service this stop but only Route Y is currently running. While it was the only app allowing the user to view other routes at the same stop it was intrusive and quite annoying.

Alert prompt in Next TTC 1.x to select route for stop at user's current location

With version 2 of the API returning multiple destinations (short-turns) for one route there was more data to present.

My goal was to present all the data possible without any interruptions, while also making it extremely easy and quick to change between the desired data. So in 2.x I added the trust navigation bar (I also went from not having the status bar visible, to making it visible, so the user could see the current time), which allowed me to added a UISegmentedControl to quickly switch between routes for the stop at the user’s current location.

Next TTC 2.0 provides as easy way to switch between routes servicing the same stop in the navigation bar as well as switching between a route's short-turns

With a checkmark, I also visualize whether a route is running. While the returned data is a bit scrambled, I chose to sort the segments in an ascending order. Furthermore, the selection defaults to the first route in the segmented control that is in service, so the user isn’t initially presented with an empty result for a route they most likely wouldn’t care about, since they want to know when the next vehicle is arriving at their current location.

In the screenshot, you can also see another row of segments: All, Long Brand and Humber. These are the short-turns. As we saw earlier, the API would have returned two destination. I then present these two selections above the route button along with a combined set of predictions for both the short-turns sorted in an ascending order. In this case, 501 Queen is a long route, going from east of Toronto to west of Toronto. Both destination short-turns are quite far out of downtown, so if you’re going to a stop way before that, you wouldn’t care which one of the upcoming streetcars you can take, because you know you’re getting off before that. At the same time, if you’re going to Long Branch station, selecting Long Branch will provide you with upcoming arrival time predictions for that location, which could save you lots of time waiting or getting on the wrong streetcar (Long Branch is further than Humber. Unfortunately the API doesn’t sort the destination short-turns in order of proximity, so it’s not possible to present them in a sorted order at this time).

Example of a stop serviced by up to 5 different streetcar routes

While it’s recommended in the API documentation not to show seconds, I felt it was appropriate to show it because “1 minute” may be 1 minute and 20 seconds or less than a minute. If you’re running to catch a streetcar, 30 seconds precision matters a lot. Luckily, lots of users love this feature over other apps that provide the same basic use-case. I only show it for the upcoming streetcar, while the subsequent cars are displayed in minutes. The app auto-updates the predictions based on calculations for the count down time, so the user is always shown the most accurate prediction at any given time. It feels kind of awesome standing at a stop looking up from your iPhone running Next TTC and seeing the streetcar arrive exactly as predicted in the app :)

Core Location

Anyone who’s ever had to work with Core Location probably agrees with me when I say it’s a bitch. While the API is great, it was a challenge to find a balance between very accurate location results and also being able to locate the user when location accuracy is very low (no GPS for example). With Next TTC, I wanted to be able to locate the user quite precisely and quite quickly to find the nearest stop, and not find a stop 500 meters away or more.

All devices cache the user’s location and when initially prompting for a user’s location that’s exactly what you get back. It might be an extremely accurate location, but it may also be very old and inaccurate. If you’ve ever opened the Maps app, and seen the blue dot move over a large area before locating you, or having the circle around it cover a very large area, this is exactly what I am talking about.

So in dealing with this challenge, I initially did a whole bunch of stuff in code to try and figure out whether the location was usable, whether to continue trying to find a new, better location, etc. It turned out quite difficult so in Next TTC 2.0 I went back to the basics, but made it possible for the user to quickly re-locate themselves and request new arrival time predictions for their updated location. In Next TTC 1.x I had a GPS arrow button, but it turns out, even though Apple uses this, most users don’t understand the icon. Since I had worked so much on getting a good location initially (which sometimes took several seconds; way too long) I didn’t really make it possible to re-locate oneself, other than picking another stop manually and then hitting the GPS arrow button again. Poor UX, Rune!

Main screen in Next TTC 1.x using user's current location (GPS arrow)

So as dicussed, in Next TTC 2.0 I got rid of lots of code for my Core Location class, and implemented a much easier way to get an updated (and more accurate location if available) if the initial location wasn’t satisfactory. I implemented the pull-to-refresh paradigm, which works wonderfully for my app.

Example of my custom "pull-to-re-locate" implementation of Pull-to-refresh seen in lots of apps

Clutter or not?

When dragging the bottom view down, it reveals a button to add a stop to favourites. When this button is hidden, I added a small light that allows the user to quickly see whether it’s a favourite (light is on) or not (no light), without having added yet another button that takes up a bunch of screen real estate and doesn’t get used 90% of the time if that much!

Extra hidden menu bar reveals "Add favourite" button

The great thing about this extra menu bar is that I can add features/buttons in the future without cluttering up the UI more, leaving the user to focus on the most important thing to them: “When’s the next streetcar arriving at this stop?”

I did add a button in the centre of the toolbar, to open/close the hidden menu. Based on beta tester feedback, it wasn’t obvious enough that dragging/pulling down on the picker view would reveal the extra menu bar.

Next TTC 2.0 has the same grey noise background as Next TTC 1.x as well as light letters. When I released the app back in February it was winter and the sun wasn’t shining very much. As the months passed and spring arrived, I started receiving feedback from users that the UI was too dark and very hard to discern in bright sunlight. Sure enough, I tested it and the only thing I saw on my iPhone screen was my own face reflected on the glass screen.

Based on this feedback, I added a “Dark on Light UI” setting in the app, which changes the background to a noisy off-white with dark text, making it much easier to read in direct summer sunlight.

While not as pretty as the default setting, the "Dark on Light UI" setting makes it possible for Next TTC users to easily read the content on the screen in bright sunlight

Wrapping up

I hope you’ve enjoyed a bit of insight into the choices that went into the user experience and design of Next TTC 2.0. Here’s a few points to wrap up what I think you should take away from it:

  • While you may have a UI in mind early on, UI and UX design is closely related to the data you need to present. While considering your UI, really dig through your data and decide early on what’s important and what parts of the data you want to present to the user, or what takes precedence.
  • Create a scope early on. This will help you on your path to completing the app and provide clear guidelines for designing and coding your app, since you’ll have the data and the user in mind.
  • Revise, revise, revise. Don’t settle on a particular design just because it looks great. If it doesn’t work well in terms of usability or if it doesn’t allow you to present the data or the user to interact with the data in an appropriate manner, scrap it and figure out a better way of making this possible.
  • Don’t be afraid to make big changes. Next TTC 2.0 was a huge update for me. I completely rewrote the core of the app and redesigned 80% of the app. I consider it a brand new app (which also made it painful in deciding it’s a free update to the thousands of current users who’d this awesome update for free, only having paid a dollar for the previous version).
  • Listen to tester and user feedback and make appropriate changes to your app. Something might appear important to you, or easy to use from a UX point of view, but if several users tell you it’s not, listen to them.

ColorKit: A Color Assessment Utility App

For this week’s #idevblogaday post, I’ve written a small utility app that’s freely available for download on github.

ColorKit is a tiny iOS app (iPhone) which allows for quick and easy color-sampling for a UINavigationBar + UIToolBar. It allows developer to easily assess the appearance of tintColor on the device.

Last week, I talked about adding textures and depth in your app, in particular to a UINavigationBar. While this effect is great when used appropriately, UINavigationBar’s tintColor property is extremely handy and useful to give your app a unique look with one line of code.

Finding the right colour for your app can be a bit of a hassle, especially due to differences in colour appearance depending on which monitor or device you’re using. Furthermore, UINavigationBar and UIToolbar are coloured with a gradient and has a glossy shine, so knowing exactly which RGB value to use is often impossible.

ColorKit builds and runs right on your iPhone and makes it extremely easy to quickly play around with various RGB settings to find the perfect colour for your app.

Inside the app is a UIImageView which allows you to add a screenshot from your app to better see how the colours may look with your UI.

You can download a copy of the code here: https://github.com/runmad/ColorKit

Pro-tip: Do not use bright colours. Play around with the values to create more “faded” colour. Brighter colour wash out the title text and generally look horrible.

Faking depth and textures in your app

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

Groceries is a great app from Sophia Teutschler. Here’s a screenshot taken from the App Store page for Groceries:

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.
  • Shadows create depth in your UI

For further reading, Mike Rundle posted a nice post, Crafting Subtle & Realistic User Interfaces, where he talks about gradients more in depth as well as tips for using materials in your UI design.

Assisted word of mouth: Get users to sell your app

You can spend lots of money and time advertising and promoting your app. Advertising your app through social network sites and Admob and the like is pretty well the most wasteful and ineffective way of spending your money, in my opinion.

Spend your money and efforts in developing an amazing and great-looking app that will naturally attract users to your app. Spend the money on hiring a graphic designer or other efforts that goes directly towards making your app better.

Most users find out about your app from friends

In this post, I will detail another great addition you can add to your app, which will help sell more copies, let’s call it: “Assisted word of mouth.”

While everyone strives to reach top App Store ranks and have their app featured on various lists, only a select number of apps reach the top rankings, and mostly only for a somewhat short period of time. The top ranks and featured lists are a great way of attracting new users, but these spots are mostly occupied by the same apps week after week.

Consider how often you have heard “Check out this app I just got!” or “Can I check out what apps are on your iPhone?”… That’s right, lots and lots of iOS users hear about apps from their friends, a reliable source they can rely on for input about the latest and greatest apps. A lot of users also get a kick out of being one of the first users of an app, or the one to discover a new great app. “Check out this app, I have discovered.”

Let’s assume your app is great, your users simply love it and you could potentially sell a lot more, if only more people knew about it.

Gifting

I suggest that you include an easy way for your users to to share the app and their experiences with the app via email, SMS, Twitter, Facebook and most importantly through gifting.

I have a feeling lots of App Store customers do not know about the gifting feature. Imagine if you’ve already convinced one person that your app is awesome, they’ll actually purchase your app again and give it to their friend/family. You’ve just saved yourself having to try and get that person’s attention and convince them why they should buy your – their friend and your current user just did!

While this isn’t factual, I actually think users find it much easier spending another $1.99 (or whatever your app costs) to give a great app to a friend, over buying the app without knowing anything about it. Once the user is hooked and love your app and want to share the experience with their friends, they’re more prone to purchase to app again for a friend.

Sharing options

Following in the footsteps of my previous #idevblogaday post, App support: What’s it worth?, I suggest that you place a simple link in your settings view, or perhaps on your main screen if your app is a game, calling it “Share [APP NAME] with a friend” or just “Share App” if you’re using a smaller button.

When tapping the button, bring up a UIActionSheet with your sharing options. In this example, I am not including Facebook, but add it if you want to. Note: Be sure only to display those options available on the device (so no “Email” option if the device doesn’t have an email account setup, and no “Text Message” option if the device does not support text messaging).

Custom, direct-to-App-Store URL

Create a custom bit.ly (or other) to your app, so it’s easily read and remembered. For example, I created http://bit.ly/NextTTC for my app Next TTC.

Make this link directly to the App Store, not your website. You can only assume that a user will share the link with someone they already know have an iOS device, getting them one step closer to a purchase when they don’t have to visit your website, however great it may be. When they open the link on their iOS device or desktop, it will automatically open the App Store (or iTunes preview site if iTunes isn’t installed).

Use the link in all the sharing options even use it for the gifting option, since it allows you to track clicks. Or use in-app analytics, or create several custom URL links for each option if you want to see stats for each.

Use a short and catchy tagline to use in text messages and Twitter, so it fits within a tweet and text. The users can add/erase text if they want. I use the following: “Get instant, location-based TTC streetcar arrival predictions with Next TTC for iPhone http://bit.ly/NextTTC”.

For the email sharing option, consider creating a nice template instead of just “Hey check out this app {link}”. Mike Piontek (@robotspacer) from June Cloud uses a beautiful template when sharing deliveries (and it’s also a great way to share a link to his app) in his app Delivery Status. MFMailComposeViewController takes HTML and CSS, so you can get pretty creative.

For Twitter either use have the user select their preferred app, or just link to Twitter (twitter://post?message=TEXT) or another app like Tweetbot (tweetbot://screenname/post/TEXT) or just the Twitter website (http://twitter.com/?status=TEXT).

Lastly, the gifting option. As I mentioned earlier, this feature is somewhat unknown to lots iOS users, so if the user selects this option, a brief description in a UIAlertView is probably a good idea.

Once all this is done, you should be all setup and hopefully see some additional sales without a lot of additional effort!

A few points from this post:

  • Traditional marketing and advertising efforts can be expensive and exhaustive
  • Word of mouth is the most effective advertising you can find!
  • Give the user several options/ways to share a link with their friends: Twitter, Text Message, Email, Facebook and App Store Gifting
  • Use a custom URL which links directly to the App Store, so you don’t create an extra step to your website where you potentially loose their interest
  • Consider tracking effectiveness of each option. If gifting is pretty effective, maybe place it in its own option right on your About/Main/Settings screen
  • If you got the time and skill, create a nice email template
  • For the gifting option, briefly explain to the user what will happen and what steps are required to gift your app, since gifting isn’t a widely known feature of the App Store

Hope you enjoyed this post! By the way, I’ll be at WWDC again. If you’ll be there too let me know. Follow me on Twitter (@runmad) and let’s meet up!

Random tips

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 own
You’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:

BOOL twitter = [[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"twitter://user?screen_name=runmad"]];
if (!twitter) {
	[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"http://www.twitter.com/runmad"]];
} else {
	[[UIApplication sharedApplication] openURL:[NSURL URLWithString:@"twitter://user?screen_name=runmad"]];
}

List of URL Schemes: http://wiki.akosma.com/IPhone_URL_Schemes

Tip #2: Getting a free UINavigationController in your UIViewController
I 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:

RootViewController *rootViewController = [[RootViewController alloc] init];
UINavigationController *navigationController = [[UINavigationController alloc] initWithRootViewController:rootViewController];
[self.navigationController presentModalViewController:navigationController animated:YES];
[rootViewController release];
[navigationController release];

Tip #3: Getting a free UIToolbar in your UINavigationController
This 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.

Quick guide to updating your app’s UI for iPhone 4

iPhone 4 will make your UI look stunning. Everything in UIKit has been scaled up already so it will require only a bit of work on your end to make the rest of your app look amazing on iPhone 4. If you only code and don’t touch Photoshop, you’re in luck. However, if you’re a UI designer or have the skills to do your own UI, hopefully you did your original artwork in a nice high resolution – if not, you have a bit of work cut out for you with updating all the UI elements to 2x the resolution.

Updating your app’s UI to be compatible with iPhone 4’s Retina Display is amazingly simple. Since the scale works in points, not pixels, you will have to do very little work on the layout itself. Apple Engineers have made it really simple to use new graphics for all your UI on iPhone 4, at the same time as being compatible (and not using 2x memory) on older, lower resolution, lower memory devices.

All you have to do is add the same image file at 2x the pixels to your app’s resources and name it the same it’s lower resolutions sibling with the following suffix: “@2x”.

For example, in your Resources folder, you will now need to have two image files, one for older devices called myImage.png and one for iPhone 4 called myImage@2x.png, which is twice the resolution.

This way, when you call [UIImage imageNamed:@”myImage.png”]; (or contentsOfFile:) iPhone 4 will automatically grab the filename with a @2x suffix, and lower resolution images will grab the lower resolution copy. You don’t have to check for the device loading the image and write any additional code to grab the correct image. Genius!

If you have seen an iPhone app on the iPad in 2x scale, that’s pretty much how your app is going to look on the iPhone 4. Perhaps not so drastic, but there will be a noticeable difference from app not optimized for iPhone 4 and “Retina Apps” as Apple calls them.

Thoughts on @2x on iPad…
I didn’t hear anything at WWDC regarding this, but my thought is that they’ll integrate this into the iPad for the next major OS release. Basically, it will be able to do the same and grab the higher resolution image appropriately for iPhone apps running at 2x scale.

Happy Photoshopping to UI designers and happy relaxing programmers!

UPDATE JULY 7, 2010:

I have discovered a bug in Apple’s code that deals with grabbing the correct image on iPhone 4. If you are using imageWithContentsOfFile: the code will in fact not automatically grab the @2x if running on iPhone 4. I have submitted a bug report to Apple, and they’ve informed me they are now aware of the issue and the Engineers are currently working to fix the bug. So for now, stick with imageNamed: for all your images.