Design Briefs

In today’s lab you are going to team up with another student in the class and come up with solutions to design briefs. You will then present your results to the rest of the class and we will discuss the pros and cons of your solutions.

Keep in mind the App Design Guidelines when thinking about these problems.

  1. Design a control interface for a 2D platformer game for the iPhone.
    • You need controls for moving to the left and to the right, and for controlled jumping, i.e. the user needs to be able to perform short and long jumps.
    • Because of the limited space on the iPhone screen, you can’t use a directional pad.
  2. Design the complete experience and interface for a video kiosk app for iPad.
    • The app is intended for a museum setting, as a guestbook for patrons to leave comments at the end of their visit.
    • The app must record a short video using the camera and submit this video to the museum’s YouTube account. It can provide any features you feel are necessary to perform this main task.
    • Include all the screens you design and the flow from screen to screen in your solution.
  3. Design the control interface for a Tetris game for the iPhone.
    • You need controls for moving the falling piece to the left and to the right.
    • You need controls for rotating the falling piece clockwise and counterclockwise.
    • You need controls for dropping the falling piece instantly onto the game floor.

App Design Guidelines

Before diving into code, you need to take the time to properly design your app, both from an interface and experience point of view. It is important to take the time to define an app’s feature set and intended audience to help guide the design process. This must be done while keeping in mind the features and limitations of the platform this app will run on. Tailoring the experience to the function, to the user, and to the platform are all necessary to the development of a successful app.

  1. Determine what the app’s main purpose is.
  2. List all the features you think are important for this purpose.
  3. Determine who your users are.
  4. Filter the feature list for your audience.
  5. Filter the feature list for the target platform.

Platform Characteristics

The display is at the heart of the user experience as it is both the main input and output interface. The content is viewed on screen and the experience is driven by touching that same screen.

Users must be able to “grab” a control without seeing it. All controls should therefore be large enough and spaced apart enough so that there is no confusion when they are being selected. A good rule of thumb is to have controls of at least 44 x 44 points in size.

The device being handheld, it is often rotated in different orientations. This can happen for a variety of reasons, from the user being tired to feeling that some tasks are more natural in specific orientations. This is something that must be taken into account and accommodated in the app design if it makes sense.

Finally, it is important to remember that apps respond to gestures, as opposed to mouse clicks and keyboard typing on desktop devices. Furthermore, a gestural language has been established over the last few years because it has been adopted by many apps, and should be considered when designing interactions. For example, dragging to scroll or pan, and pinching to zoom in and out.

Human Interface Principles

A great user interface does not focus on the device capabilities but on the way users think and work. It must be inviting, simple, and intuitive.

Aesthetic Integrity – How well does the appearance of the app integrate with its function? For example, a game should be immersive and take over the entire screen, while a to-do list should be more subtle and sober.

Consistency – This includes both consistency with other apps and within the app itself. Does the app take advantage of established standards users are comfortable with? Does the app maintain its visual identity throughout the experience? Do UI elements mean the same thing and are used the same way all the time?

Direct Manipulation – The multi-touch screen allows users to directly manipulate elements instead of going through a separate interface. For example, instead of having buttons for zooming in and out of an image, use a pinch gesture.

Feedback – Users expect immediate feedback when interacting with an interface. If an operation takes a long time, like a network request for example, let them know that the system is “thinking”. If an operation takes longer than expected, offer a status update reassuring them that everything is under control.

Metaphors – References to real life objects allow users to quickly understand how to use an interface. For example, a switch can be flicked to toggle a setting, or a rotary dial can be turned to fine tune a value.

User Control – The user should always initiate any action and feel in control while using the app. Users also expect to be able to undo or cancel an action that is underway.

User Experience Guidelines

Focus on the primary task – If a feature does not relate to the main purpose of the app, it is unnecessary. This also works on a feature basis. You should analyze what information is needed in each screen, and get rid of anything extra (either including it in a different context or removing it altogether).

Emphasize the content users care about – Decrease the weight of the UI by minimizing the number of controls and their prominence on screen. For example, you can fade away navigation controls in a slideshow if the user has not interacted with them for a few seconds.

Think top down – The top of the screen is most visible to users as they tend to hold the device in their hand, interacting with the screen using their thumb. The most important and frequently used information should be placed at the top.

Make usage easy and logical – Navigation through the app should be predictable. Users should immediately understand how to use the app and where to find information they are looking for. For example, clicking on a person’s name in the address book reveals their contact information.

Use user-centric language – You want to avoid technical terms and keep terminology simple yet accurate. For example, “load a webpage” instead of “perform an HTTP request”.

Keep file-handling in the background – Users do not expect to have to deal with files and folders on a handheld device. Information about file paths, saving, loading are usually irrelevant to the experience and should happen silently.

Start instantly – Users tend to interact with apps for only a few minutes at a time. Avoid splash screens, only display about screens on user request, and delay login screens as much as possible.

Always be prepared to stop – Save data reasonably often and save the app state when it moves to the background to allow the user to continue where they left off.

Make it pretty – Use beautiful graphics and subtle animations to make your app attractive and enjoyable to use.


It is often useful to start thinking about an app outside of Xcode and even completely offscreen. Although a napkin and a pen are good enough to sketch out an initial idea, some tools can come in handy when moving forward into more concrete interface and experience design.

Pen and Paper

iPhone Application Sketch Template (Oliver Waters) – Printable iPhone template with grid squares at every 10 pixels, and tick marks indicating the position of the status bar, navigation bar, and tab bar.

App Sketchbook (Square Position, LLC) – Booklet with iPhone or iPad stencils for sketching mockups, with a notes section at the bottom of the page.

Stencil Kit (UI Stencils) – Stencils for commonly used iPhone and iPad controls and icons. A sketchpad and PDFs at the same scale are also available.


iPhone Mockup (Lukas Mathis) – Online stylized design tool including standard component library. Designs can be collaborated on by sharing the URL.

MockFlow – Online wireframing tool with a large library of user-generated content.

OmniGraffle (OmniGroup) – Diagramming application that can be used for creating wireframes and flowcharts. Many free iPhone and iPad stencils can be downloaded from Graffletopia (and various other places on the web) for interface design.


iOS 6 GUI PSD (iPhone 5) (Geoff Teehan) – Photoshop document containing a complete and well-organized collection of standard UI elements for iOS.

iOS Photoshop Actions & Workflows (Bjango) – Photoshop actions for performing common iOS design tasks.

DevRocket (Ui Parade) – Photoshop plugin for performing common iOS design tasks.


Cocoa Controls – Collection of user submitted interface elements for iOS apps.

  1. iOS Human Interface Guidelines. Apple, Sep 19 2012.

Settings Bundle

As we’ve seen previously, NSUserDefaults is used to store preference data in iOS apps. There are then two options for displaying these preferences: directly inside the app and as a section in the Settings app.

Where you display preferences is up to you, and how you expect your users to interact with preferences. Usually, you’d want preferences that are accessed frequently inside the app. When displaying preferences inside the app, it’s up to you to decide how and where to display them.

However, a specific format must be followed to display the preferences in the Settings app. This is done using a Settings bundle, a collection of files describing the structure and presentation style of the preferences.

You can create a Settings bundle in Xcode using the New File menu.


This will generate two files in the bundle. The one holding all the configuration options is Root.plist. .plist stands for preference list, and it’s just an XML file.

Preferences items are set by adding entries to the list. Each entry has an identifier and a type, and a few extra options depending on the type. The file generated by Xcode is prepopulated with 4 entries: a Group, a Text Field, a Toggle Switch, and a Slider. You can see these by running the app on a device or the simulator, and then opening the Settings app.

The identifier is used to access the value of the preference in the app.

To add a preference, you simply add an entry to this list. There are many types of preference items.

  1. Group creates a new group of items. All items below this one will be part of the group, until the next Group item.
    • Title
  1. Text Field displays an editable text field, with an optional title.
    • Title – The text field name (optional).
    • Autocapitalization Style – Options to capitalize words, sentences, or all characters.
    • Autocorrection Style – Whether or not to autocorrect the input text.
    • Keyboard Type – The type of keyboard to display when editing (Email Address, Number Pad, etc.)
    • Text Field Is Secure – Replaces typed characters by (useful for passwords).
    • Default Value
  2. Toggle Switch displays an ON/OFF button.
    • Title
    • Default ValueYES or NO.
  3. Slider displays a slider, with customizable range.
    • Minimum Value – A number.
    • Maximum Value – A number.
    • Default Value – A number.
  4. Multi Value pushes the view to display a set of options to choose from.
    • Title
    • Titles and Values – Arrays holding the titles and values for each option. Both arrays should hold the same number of elements in matching order.
    • Default Value
  1. Title displays a read-only label.
    • Title
    • Default Value
  1. Child Pane displays a link to another .plist file, which can be used to display more options.
    • Title
    • Filename – The name of the linked .plist file.

Constants and Statics


A constant is an identifier whose value cannot be changed. It is said to be read-only. Think of it as a literal that can be referenced by name. Constants are useful when you need to reuse a literal value, for example when setting a margin for multiple UIView objects. If this margin ever needs to change, you would only need to do it once where the constant is defined instead of throughout the code.

A constant is defined using the const keyword.

Constants must be declared and defined on the same line. If you try to do this in more than one step, the compiler will throw an error, thinking that you’re trying to edit the constant.

It’s important to be able to recognize constants in your code, so you should use a different format than variables for naming them. There are many different conventions used for naming constants. One is to capitalize the name and use underscores for spacing.

Another is to prefix the name with the letter k.

Constants are widely used to store names for keys and identifiers. We can edit our notifications app from last class to do just that.

Read-only Properties

Sometimes you’ll want to make properties available to outside classes only for viewing (reading) and not for editing (writing). This can be achieved by adding the readonly modifier when declaring a property. What this does behind the scenes is only create a getter and not a setter for the property variable.


A macro is a find-and-replace rule applied to source code before it is compiled. Macros are declared using the #define keyword.

Macros look very similar to constants, and are often used for similar purposes. However, the way they are integrated into source code is very different. Constants are handled similarly to variables by the compiler. They are stored in a table in memory, and their value is read whenever their name is encountered during compilation. Macros are interpreted in the pre-compilation phase. Much like a find-and-replace operation, a script goes through the entire code and replaces any occurrences of the macro name with its value. Macros have the advantage of running faster, since their value is immediately available. Constants on the other hand, are more useful for debugging, as they can be referenced when an application runs.

Another main difference is that constants are typed, whereas macros are not.

Macro errors can also be hard to debug as the compiler will not always provide you with a relevant message. Consider the following two seemingly correct macro definitions.


One of the greatest advantages of macros is that you can use them to write small scripts. These scripts can be used like functions, as they will get inserted wherever the macro is used.

You can even pass arguments to macros if needed.

Static Attributes

A static attribute is owned by the class itself, as opposed to by an instance of that class. Its lifetime spans the entire time that the app is running, as it is not associated with any particular instance of the class.

We’ve already seen static methods before, they are the methods whose definition begins with a +. In Objective-C, these are called class methods. One of the most commonly used ones is NSString‘s stringWithFormat:.

Variables can also be static and these are used locally inside a class implementation. They are defined using the static keyword.

You can initialize static variables in the initialize class method. This method is called on every class in an app before it is used.

A static variable can be used by any instance of the class it belongs to.

If you ever want to use a static variable outside of the class its defined in, you need to create a static getter for it.

Header Source


The singleton design pattern is used when you want to restrict the instantiation of a class to a single object. Note that this is not the same as having a static class; The class does get instantiated, but only once. This is particularly useful when you need some type of coordination within the entire app. An example of this would be a data manager singleton, which ensures that the entire app is populated with the same set of data, and that any change to this data is reflected all around.

When creating a singleton, you need to insert checks to ensure that only one instance of the class is ever created. This can be done by using a static variable for the singleton, and setting it up in the initialize class method.

Header Source

As nothing prevents the rest of the program to call initialize directly, we need to add a check to make sure our singleton is only instantiated once.

We can simplify this even more, by initializing our singleton directly in the getter.

This will work fine in most situations. However, it does not take a special case into consideration. If two threads in your app try to access the singleton at the same time, sharedInstance might be called a second time before it completes its first run, and might create two instances of the singleton. Although this is unlikely, it might happen, and a safety against this condition must be created. This is also the type of bug that is nearly impossible to track down, so it’s better to be safe than sorry.

Using a @synchronized block will ensure that whatever code is inside of it will never execute more than once concurrently.

  1. Constant (programming). Wikipedia, Sep 24 2012.

  2. Macro (computer science). Wikipedia, Oct 24 2012.

  3. Singleton pattern. Wikipedia, Oct 23 2012.