In designing the interface for my app, I wanted to have a nice way to display numerical information in a graphically clear and pleasing way. So I came up with the idea of creating a graphic which looks like a light and can be used as a background for labels. I taught myself how to create my idea in pixelmator.
We’ll be creating a green version of the light shown above for this tutorial. Click on the images to make them larger.
First create a new file. I made mine at 640×960 pixels as this is the Retina iPhone screen resolution.
Create a rounded rectangle using the rounded rectangle tool. This will become the light component of the graphic.
Fill it in blue and set the stroke to transparent. You need to set it to a slightly different color than the one you want it produce in the end as you will apply a filter later.
Create another rectangle, this time with a black fill. This will provide a background and part of the border of the light.
Set its stroke to a greyish color and set it to be on the outside of the shape. This forms the border.
Align it so the grey borders the blue rounded rectangle.
Turn the blue rounded rectangle into an image as shown so we can apply filters to it.
Apply a “Twilight” filter to the blue shape.
Apply a “Honeycomb” filter to the now green rectangle and create another rounded rectangle with a transparent fill and a grey stroke.
Set it to sit around the green rounded rectangle. This forms another part of the border.
Increase the thickness of the black rounded rectangles grey stroke until it looks good.
Apply a “Fog” filter to the green rounded rectangle.
Arrange the layers as shown so the light shines over the border.
Add a text layer, and you’re done!
When creating an iOS app there is more often than not some sort of Internet aspect to it. This has been something that I have been working on at the moment in my app. It could be loading content from a website (alienblue), opening up a wiki page in safari (MC-Splashes) or doing complex data uploads and downloads (Facebook). I’ve learnt that each one of these situations requires a different approach and level of involvement in managing connections.
Alien Blue interacts with reddit.com and presents its content in an iPad and iPhone friendly way. This means it must download the data from the site, load it into the app and present it. This is not particularly difficult to do because the website is either available or not available, and the app does very little uploading to the site. Reddit is mainly a consumer site where few people upload content for many to look at and comment on. So the app does not need to have much complex connection management for uploading posts. But when it does, it operates in a similar way to the Facebook system detailed below.
MC-Splashes is an app that displays all of the current Minecraft splash texts in an easy to use format. It was also the app I made to test the App Store submission system. Unbelievably, over 3000 people have downloaded it. Anyway, back to the point. One of its features is a button which when pressed shows the Wikipedia page on Minecraft splash texts in Safari. This requires no connection management at all as that is up to Safari. Simple.
The last example is the one I want to focus on as it is the one that best represents my own app. The official Facebook application is very heavy on user interaction and content sharing and therefore requires a lot of connection management. A classic example of this is the messaging system. If someone attempts to reply to a message and then their Internet connection cuts out there is an immediate problem. Facebook stores that message until it detects that the connection to the Facebook servers is established again. Then it can send it. This requires a local storage method (Core Data, text files or other) and a monitoring function which detects connection losses and reconnections and stores messages, statuses or likes etc. until the connection is re-established. This is exactly how I plan to solve the problem of connection management in my app. Store objects locally until they can be sent to the server.
I’ve learnt some really interesting stuff this week about how to design for different platforms. I face this problem a lot in my app as I am designing for both iPad and iPhone and I need two different basic modes of functionality for each. There are many ways that you can go about solving these design conflicts. Some people go for the lazy option and simply scale up an iPhone design to iPad. This can leave an interface looking chunky if the UI items are scaled up and sparse if the space in between them is scaled. This is not a good solution, as you need to design with the user and device first and foremost in your mind. The other solution is to use the classic scale up method of different view layouts. This is when you use a single view with a navigation bar to switch between views on an iPhone and a sidebar interface to switch between views for iPad applications. A classic example of this is the layout on the Mail.app included with both devices upon shipping. I don’t particularly like it as it has been used in so many apps that it has almost become too common making your app blend into the crowd. You need your app to stand out somewhat so that the users will remember the experience. I am yet to find a solution to this problem but I should soon with some careful thought.
There are some other issues as well which are not as commonly recognized when designing for different devices. One example of this is the way in which a user holds a device. With the iPhone, a teenager or adult sized hand should be able to touch with a thumb all the UI Items on the screen in any orientation without too much trouble. This is the common way that most users interact with the iPhone (though often when used on a table the forefinger is used for interaction). However, iPads are vastly different. When they are used on tables forefingers are generally used to select and interact with items. But when the device is held in the hand, it carries a decent amount of weight. This means that you must design to make sure that the user must not need to change the area of the screen in which they are interacting too often. Consider playing Fruit Ninja on an iPad while standing. It is not easy as you must precariously balance the iPad in one hand and swipe with the other. Your hand is constantly moving around the screen making it difficult to balance the device and distracting from the experience. Perhaps it is necessary for this game but it is a good idea to avoid it for a normal utility app. This is something that needs careful consideration and real world testing with mockups to ensure it is done right.