In the past few months, Mozilla has been hinting that they might start to work on a Firefox experience for iOS. Recently Firefox VP Jonathan Nightingale said at Mozilla’s work week of 2014 (Mozlandia, Portland): “We need to be where our users are so we’re going to get Firefox on iOS”.
With the release of iOS 8, Apple provided developers full access to its fast JavaScript engine. Earlier, the Nitro engine was exclusive to Safari, as a result of which third party browsers such as Google Chrome were slower than Safari. Firefox will only work on iOS 8 and above, as it uses WKWebView.
“We are in the early stages of experimenting with something that allows iOS users to be able to choose a Firefox experience,” Mozilla’s press release center said in a blog post. “We work in the open at Mozilla and are just starting to experiment, so we’ll update you when we have more to share.”
The GitHub repository for the Firefox for iOS project’s first commit was made on 4th November 2014. The repository is chiefly written in C, Objective-C, Swift, C++ and JavaScript. It also makes use of popular Swift libraries like Alamofire and SwiftyJSON. The project uses Bugzilla for bug management and tracking pull requests. However, GitHub issues are enabled for the repository as well.
Since Firefox for iOS is still under planning and development, we had a few questions about it. Karen Rudnitski, Senior Manager, Firefox Mobile at Mozilla was kind enough to answer our questions about Mozilla’s upcoming product.
1. How different/ similar is the product going to be as compared to other versions of Firefox for different mobile OSs?
Karen points out, “Our goal is to ensure there is product familiarity across all of our Firefox products. This is also balanced with ensuring users of each OS we support also have the same sense of familiarity with their chosen platform.”
2. What is the current priority of the project?
She says, “We are actively working, developing and iterating on the product. It is a product we all want to see in the market so it is resourced accordingly. ”
3. Is Firefox for iOS going to showcase any new features?
Karen adds, “Our mindset is to start thinking how selected new Firefox features can be accessed by all of our Firefox browsers, regardless of the platform. Specifically regarding Firefox for iOS, it’s still a little too early to confirm the final feature list as we’re still quite early in the cycle. But our aim is to provide delight to existing Firefox users who have an iPhone or iPad, as well as anyone interested in stepping into the Firefox ecosystem for the first time on iOS.”
Key Features
Mozilla’s wiki lists some key features that will be available in Firefox for iOS.
You can also file a new bug for the project, or browse the existing bugs. The description of the repository warns: “Don’t get too attached to this code. Tomorrow everything will be different.” This is because there may be large amounts of changes in the codebase before the code is ready for release.
Conclusion
Mozilla Foundation‘s new initiative will bring users of iOS more freedom of choice while accessing the web. An open web allows the denizens of net the right to privacy, and Firefox is best known for being the most ardent supporter of an open web and net neutrality. You can get the latest updates by following Fennec iOS on Twitter.
This tutorial assumes that you are familiar with both SpriteKit and Objective-C. To interact with the shader and the scene editor without input lag, I recommend that you download and install Xcode 6.1 or later. Download the Xcode project from GitHub, if you'd like to follow along.
Series Format
This series is split up into two tutorials and covers the most important new features of the SpriteKit framework. In the first part, we take a look at shaders, lighting, and shadows. In the second part, I'll talk about physics and SceneKit integration. While each part of this series stands on its own, I recommend following along step-by-step to properly understand the new features of the SpriteKit framework. After reading both parts, you'll be able to create both simple and more advanced games using the new features of the SpriteKit framework.
1. Introduction
SpriteKit provides a rendering pipeline that can be used to animate sprites. The rendering pipeline contains a rendering loop that alternates between determining the contents and rendering frames. The developer determines the contents of each frame and how it changes. SpriteKit uses the GPU of the device to efficiently render each frame. The SpriteKit framework is available on both iOS and OS X, and it supports many different kinds of content, including sprites, text, shapes, and video. The new SpriteKit features introduced in iOS 8 are:
Shaders: Shaders customize how things are drawn to the screen. They are useful to add or modify effects. The shaders are based on the OpenGL ES fragment shader. Each effect is applied on a per-pixel basis. You use a C-like programming language to program the shader and it can be deployed to both iOS and OS X. A shader can be applied to a scene or to supported classes, SKSpriteNode, SKShapeNode, SKEmitterNode, SKEffectNode, and SKScene.
Lighting & Shadows: Lighting is used to illuminate a scene or sprite. Each light supports color, shadows, and fall-off configurations. You can have up to eight different lights per sprite.
Physics: Physics are used to add realism to games. SpriteKit introduces four new types of physical properties, per-pixel physics, constraints, inverse kinematics, and physics fields. The per-pixel properties provide an accurate representation of the interaction of an object. Thanks to a variety of predefined constraints, boilerplate code can be removed in scene updates. Inverse kinematics are used to represent joints using sprites (anchor points, parent-child relationships, maximum and minimum rotation, and others). Finally, you can create physics fields to simulate gravity, drag, and electromagnetic forces. These new physics features make complex simulations much easier to implement.
SceneKit Integration: Through SceneKit, you can include 3D content in SpriteKit applications and control them like regular SKNode instances. It renders 3D content directly inside the SpriteKit rendering pipeline. You can import existing .dae or .abc files to SKScene.
2. Project Overview
I've created an Xcode project to get us started. It allows us to immediately start using the new SpriteKit features. However, there are a few things to be aware of.
The project uses Objective-C, targeting only iPhone devices running iOS 8.1. However, you can change the target device if you like.
Under Resources>Editor, you'll find three SpriteKit scene (.sks) files. In this series, you'll add a fourth SpriteKit scene file. Each scene file is responsible for a specific tutorial section.
A shader can be initialized one of two ways. The first uses the traditional method while the second uses the new SpriteKit scene method. The objective is that you learn the differences and, in future projects, choose the one that fits your needs.
If you instantiate an SKScene object using a SpriteKit scene file, you'll always use the unarchiveFromFile: method. However, it is mandatory that you add for each SpriteKit scene file the corresponding SKScene class.
If you instantiate an SKScene object without using a SpriteKit scene file, you should use the initWithSize: method like you used to do in earlier versions of iOS.
The GameViewController and GameScene classes contain a method named unarchiveFromFile:. This method transforms graphical objects defined in a SpriteKit scene and turn them into an SKScene object. The method uses the instancetype keyword, since it returns an instance of the class it calls, in this case the SKScene class.
Download the project and take a moment to browse its folders, classes, and resources. Build and run the project on a physical device or in the iOS Simulator. If the application is running without problems, then it's time to start exploring the new iOS 8 SpriteKit features.
3. Shaders
Step 1: Create SpriteKit Scene
In the Xcode project, add a new SpriteKit Scene file. Choose File>New>File... and, from the Resource section, choose SpriteKit Scene. Name it ShaderSceneEditor and click Create. A grey interface should appear.
Step 2: SpriteKit Scene Configuration
In the SKNode Inspector on the right, you should see two properties, Size and Gravity. Set the Size property taking into account your device screen resolution and set Gravity to 0.0. You'll notice that the size of the yellow rectangle changes to reflect the changes you've made. The yellow rectangle is your virtual device interface. It shows you how objects are displayed on your device.
Step 3: Add a Color Sprite
Inside the Object Library on the right, select the Color Sprite and drag it into the yellow rectangle. Select the color sprite and open the SKNode Inspector on the right to see its properties. You can interact with the object in real time. Any changes you make are displayed in the editor. You can play with Position, Size, Color, or Scale, but what you really want is the Custom Shader option. However, you'll notice that there's no shader available yet.
Step 4: Add a Custom Shader: Method 1
Add a new empty source file (File> New >File...), choose Other> Empty from the iOS section, and name it Shader01.fsh. Add the following code to the file you've just created.
The above code block generates a fusion of colors taking into consideration the center of a circle and its edge. Apple showed this shader in their SpriteKit session during WWDC 2014. Return to the editor, select the color sprite object, and in the Custom Shader select the shader you've just created. You should now see the shader in action.
Step 5: Real Time Feedback
Programming shaders using Xcode and SpriteKit is easy, because you receive real time feedback. Open the Assistant Editor and configure it to show both the SpriteKit scene as well as the shader you've just created. Let's see how this works. Introduce a runtime error in the shader, for example, by changing a variable's name and save the changes to see the result. As you can see, Xcode provides a quick and easy way to alert the developer about possible shader errors. The advantage is that you don't need to build or deploy your application to your device or the iOS Simulator to see if everything is running fine. It's now time to add another shader and manually program it.
Step 6: Add a Custom Shader: Method 2
In this step, you'll learn how to:
call a shader manually
assign a shader to a SpriteKit object
create and send properties to a shader
In this step, you'll add a custom SKSpriteNode at the position of the user's tap and then you'll use a shader to modify the texture color of the SKSpriteNode. The first step is to add another shader. Name the new shader shader02.fsh and add the following code block to the shader's file:
Open the implementation file of the ShaderScene class. The first step is to detect whether the user has tapped the screen and find the location of the tap. For that, we need to implement the touchesBegan:withEvent: method. Inside this method, add a SKSpriteNode instance at the location of the tap. You can use any sprite you like. I've used Spaceship.png, which is already included in the project.
You may have noticed that the shader's source file references a myTexture object. This isn't a predefined shader property, but a reference your application needs to pass to the shader. The following code snippet illustrates how to do this.
Build and run your project. Tap the Shaders (initWithSize) button and tap the screen. Every time you tap the screen, a spaceship sprite is added with a modified texture. Using this option, you see that the first shader is not presented on screen. This happens because that shader was created and configured inside the SpriteKit Scene editor. To see it, you need to initialize the ShaderScene class using the unarchiveFromFile: method. In GameScene.m, you should see a section that detects and parses the user's taps in touchesBegan:withEvent:. In the second if clause, we initialize a ShaderScene instance as shown below.
Build and run your project again, tap the Shaders (initWithCoder) button, and tap the screen. Both shaders are now active in a single SpriteKit scene.
4.Lighting and Shadows
Lighting and shadows are two properties that play together. The aim of this section is to add several light nodes and sprites, and play with their properties.
Step 1: Add a Light
Open LightingSceneEditor.sks and browse the objects inside the Media Library on the right. In the Media Library, you can see the resources included in the project. Select and drag background.jpg to the yellow rectangle. If you haven't changed the default scene resolution, the image should fit inside the rectangle. When you select the sprite, you'll notice that it has several properties like Position, Size, ZPosition, Lighting Mask, Shadow Casting Mask, Physics Definition, and many others. Feel free to play with these properties. For now, though, it's important that you leave the properties at their defaults. Drag a Light object from the Object Library on the right onto the background sprite. The position of the light isn't important, but the light's other properties are. You can configure the Color, Shadow, and Ambient color to configure the light and shadow. The Z Position is the node's height relative to its parent node. Set it to 1. The Lighting Mask defines which categories this light belongs to. When a scene is rendered, a light’s categoryBitMask property is compared to each sprite node's lightingBitMask, shadowCastBitMask, and shadowedBitMask properties. If the values match, that sprite interacts with the light. This enables you to define and use multiple lights that interact with one or more objects. You've probably noticed that the background has not changed after adding the light. That happens because the lighting mask of the light and the background are different. You need to set the background's lighting mask to that of the light, which is 1 in our example. Update the background in the SKNode Inspector and press enter. The effect of this change is immediate. The light now illuminates the background based on its position. You can modify the light's position to see the interaction between the background and light nodes in real time. To increase the realism of the background or emphasize one of its features, play with the Smoothness and Contrast properties. Play with the values to see the changes in real time.
Step 2: Populate the Scene
It's now time to add a few objects that interact with the light node. In the Media Library, find the croquette-o.png and croquette-x.png sprites and add them to the scene. Each sprite needs to be configured individually. Select each sprite and set the Lighting Mask,Shadow Cast Mask, andthe Z Position to 1. The lighting mask ensures that the sprite is affected by the light node while the shadow cast mask creates a real time shadow based on the position of the light node. Finally, set the Body Type (Physics Definition) to None. Do this for both sprites. You should have noticed that, even after setting the properties of lighting and shadow, you cannot see the interaction between the light and the nodes. For that, you need to build and run the project on a physical device or in the Simulator.
Step 3: Manual Lighting
You already know how to add lights using the scene editor. Let's see how to add a light without using the scene editor. Open the LightingScene.m and inside the didMoveToView: method we create a SKSpriteNode object and a SKLightNode object. For the SKSpriteNode object, we use the Wicked-Cat.png sprite. The position of the node isn't that important, but the values of zPosition, shadowCastBitMask, and lightingBitMask are. Because SpriteKit parses the data sequentially, you need to set the node's zPosition to 1 for this sprite to be visible, on top of the background sprite. We set shadowCastBitMask and lightingBitMask to 1. This is what the didMoveToView: method looks like so far:
Next, let's add the SKLightNode object. You should take special attention to the categoryBitMask property. If you set it to 1, this light will interact with every sprite. Name it light and set zPosition to 1. The complete snippet for the SKLightNode should look like this:
At this point you have a second light. But let's add some user interaction. For that you should add the touchesMoved:withEvent: method and change the light position, taking into consideration the tap location.
Finally,build and run your application. Tap the Lighting button and you should see something similar to the below screenshot:
Conclusion
This concludes the first tutorial in our two-part series on the new SpriteKit framework features introduced in iOS 8. In this part, you learned to create custom shaders and lighting effects using both the SpriteKit Scene editor and through code. If you have any questions or comments, as always, feel free to drop a line in the comments.
In terms of function, there are certainly some areas of app development that are not the "designer's job" per se, but still have a great impact on the design conceptually and in application’s creative direction. If you are working on an app, and these jobs are not being filled, find someone who has these skills to do so or give it a try yourself. Skipping these steps can lead you down a costly path of revisions when your users find that your app is missing functionality or has painful design flaws.
What is the Application’s Primary Task?
Once an idea for an app has been generally scoped out, it’s time to narrow down the application functionality to the core of what the app does. The most popular apps establish and maintain focus on ONE primary task. To do this you must determine what that primary task is by creating a concise explanation of your apps main purpose and its intended audience, also known as a product definition statement.
I know it sounds geeky and useless, but this is the phrase you should have tacked on your wall the entire time you’re working on the design. It’s the core of what the app is all about. So, pick the few features that will be the most frequently used by the majority of your users and are most appropriate for the mobile context. A quick way to do this is to fill in these blanks for the application you're working on:
(Your differentiator) (Your solution) for (Your audience).
Here's an example for the iPhone's "Photos" app:
(Easy to use) (digital photo sharing) for (casual iPhone users).
Market Research Market research may sound like another one of those *yawn* tasks, but skipping this step is...dumb. If you don’t want to do it, hire someone else who does get excited about this kind of work. Don’t fall into the trap of “no one else has done this” and “this idea is totally original” or “I want to keep my idea pure, protected from outside influence.” If you buy into these ideas, your app will be perfect, but only for you.
Step 1: Prepare to Compare
The best way to cross reference and document all of you research is to paste it into a spreadsheet or word processing document. You can create your own, OR I’ve created one on Google Docs you can use: Mobile App Research Spreadsheet. I’ve put in examples relevant to the app we’ll be working on in this article. Just replace this data with your own! This makes it nice and easy to cross reference all of the features, benefits and technology other products offer.
Step 2: Look for Existing Solutions
I say “existing solutions” rather than “competition” because not all related products will be competing in your mobile marketplace. Some may be web apps, desktop applications or even offline sources in the same field of interest. The best way to find existing products is to search every variety of keywords related to your application on:
Google narrow the search to ‘blogs” and “news” to get really recent results iTunes App Store Android Marketplace Step 3: Uncover Technical Limitations
During market research be prepared to uncover technical limitations you weren’t expecting. As a designer, you may say, “Who cares? That’s the developers job!” Maybe so, but you would be surprised how many technical feasibility discussions wind up impacting design! Believe me, you want to be a part of that discussion.
Examples of technical limitations might include: What if you wanted to create an app that would allow you to block calls from a specific number? Uh oh, the iPhone SDK doesn’t support that functionality. Alternatively, let’s say I wanted to create an app that allows you to find the nearest coffee shop? Better think about how many hits your app may get, because Google and Yahoo! both start charging once you exceed a certain daily volume of search requests in your app!
Step 4: Planning for Future Functionality
This is VERY important. When you become discouraged by learning about all of the things that are not possible today, good news - you can still plan for t hem in your design! Did the first iPhone have a video camera? No, but developers that had their game once started thinking about opportunities in that area that would inevitably open up in the future.
Another reason to plan for future functionality is for the applications ability to scale or grow. The same as websites, apps often go through growth spurts of one kind or another. Sometimes that means adding features or content, sometimes it means peeling things away! Think about how you can maintain a balance between creativity and modularity. Allowing pieces to be plugged in and out easily from a layout standpoint and you’ll have a lot less headaches down the road!
Target Audience Knowing your target audience is very important in defining a design style, typography, and layout. Does your app appeal to accountants or 18 - 25 year old gamers? Having this information and diving even deeper to develop "personas" is essential to understanding what the demographic wants to see, and the context in which they'll use the app.
For example, Mike Todd is an 18-year old college student in New York City. This tells us a lot more about Mike. He is in college, around other students his age, most with similar schedules. Mike may want a game with 2-player interaction. Would we have thought of 2-player interaction if we only knew Mike's age? Depending on the app, maybe or maybe not. Regardless, drawing out personas brings richness to your brainstorming and helps draw out functionality that's important to your target audience, and important to the design.
Use Case Scenarios Once personas are defined, the characters need to be placed in relevant, true-to-life, “mobile” circumstances. Where are the users that use the app? Are they on foot, by car, or train? Forty-three year old Bill is driving to a meeting in downtown London and wants to stop for a cup of coffee. Should the app require that Bill tap the screen several times before finding his coffee shop? Absolutely if your brother owns a body shop! Thinking through the variety of circumstances users find themselves in, and dialing in on scenarios where certain functionality repeats is the key to defining what screens you'll be designing.
Sitemap Sitemaps for mobile are critical to design. To design a flow that's intuitive, understanding the relationship of content to other content provides a way to design simple and usable controls. Mobile app sitemaps differ from website sitemaps as mobile apps should not present the user with multiple ways to get to one place. One door to one room: that's it. Mobile users don't have time to make a wrong move then go "back" and try to find the proper path.
Wireframing and Paper Prototyping Data collected from the use case scenarios will define the content and controls that need to be present on the screens defined in the sitemap. From there you have to design a preliminary layout that will account for each of these design elements. Define a grid and establish the importance of information using the color, shape, and size of design elements.
Ergonomically speaking, users hold touchscreen mobile devices in a way that the thumb position is typically pointed towards the middle of the screen. So, if you want to navigate users around the app quickly, give them controls that allows them to move around holding the device with just one hand!
Also, consider the variety of ways content can move on and off screen. For example, mobile sheets are a great way to hide actionable controls until the user is ready to use them. Think about how you can minimize user input. Who wants to be bogged down with entering a bunch of text? Provide users with a Picker Table so they can select a choice from a menu instead.
In mobile design, paper prototyping will save you lots of time. Much like any design or illustration process, having iterations of your design allows you to explore a wider variety of design options to a deeper degree. And with paper prototyping there's less "risk", less attachment to a scrap of paper than a polished Photoshop file. For example, working on post it notes is useful in being able to re-order, add or delete screens until the flow is right. See this Tumblr thread for a nice collection of mobile wireframes.
Creating Final Files Once you’ve fine-tuned your paper prototypes, it’s time to bring those sketches to life in Photoshop. If you haven’t already, jump back to my previous post on iPhone Design Templates and grab a few to get you started. In that article you will also find specifications on how to set up your files at the proper size and resolution. If you’re lucky enough to work with a developer who can slice out images for you, please be polite and organize your file using folders.
Conclusion This is certainly an abbreviated version of each step in the mobile design process so please be sure to leave me a comment below and let me know which area you would like for me to expound upon!
Today I'm going to show you how to build an alternate page and style sheet for the iPhone and iTouch. We will cover how to detect if the user is using an iPhone to view your page as well as the orientation of the device - whether it be landscape or portrait. To accomplish this we will be using javascript, and some Safari mobile specific CSS tags. Getting Started We're going to start off with 2 psd's I made and get those working in an iPhone page. I am using images for the background and header although you could use just straight colors instead of images. The plus side to not using images is that it obviously loads faster but also when switching between landscape and portrait the images take a moment to load, depending on how large they are. You can find the source psd files here or you can make your own. Something to keep in mind is that we are building a page specifically for the iPhone or iTouch. If you do not have the device yourself you can download the iPhone SDK freely from Apple and it includes an iPhone simulator. if you would like to detect the iPhone on your standard browser page and either load the iPhone css and html through conditional statements or send the user to a different page entirely, use the following code:
<script type="text/javascript"> var browser=navigator.userAgent.toLowerCase(); var users_browser = ((browser.indexOf('iPhone')!=-1); if (users_browser) { document.location.href='www.yourdomain.com/iphone_index.html'; } </script> The code above explained:
Line 2: Create a variable that holds the users type of browser ( among other things ) Line 3: Assign the browser type a value if the iPhone browser is present. Line 4 - 8: An if statement that redirects the user to an "iPhone formated page" if the variable "users_browser" returns a value ( meaning the user is using an iPhone or iTouch to view the current page ). Below the code will use html conditional statements to hide the code from a regular browser.
<!--#if expr="(${HTTP_USER_AGENT} = /iPhone/)"-->
<!-- place iPhone code in here -->
<!--#else -->
<!-- place standard code to be used by non iphone browser. --> <!--#endif --> Step 1: The HTML So we now know how to point the user to your iPhone page if they are on an iPhone or iTouch device. Now, we will start working on the iPhone HTML page; the code below has some key differences from a regular XHTML transitional document.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<link rel="apple-touch-icon" href="images/myiphone_ico.png"/> <link rel="StyleSheet" href="css/iphone_portrait.css" type="text/css" media="screen" id="orient_css"> The code above explained line by line:
Line 1 - 5: This is standard 1.0 XHTML Transitional Doctype. Nothing special yet. Line 6: This line is iPhone and iTouch specific. It sets initial values for the viewport in the Device's browser. width=device-width states the width of the page to be the same width of the device. initial-scale and maximum scale set the starting point for the zoom of the page, maximum-scale is how much the page cane be scaled up. Line 9: This link element is pointing to the web pages icon. this is used when a user saves the page to their "Home Screen". Line 10: A link element points to the iPhone style sheet. This element has the id orient_css assigned to it. This is so that we can point to it with javascript to change the css file it points to when it comes to adjusting the layout for the orientation of the device. Step 2: Laying Out The Divs We now continue with the rest of the html before we add any javascript functions for orientation detection. Start with ending the head and then start the body. In the body element we add onorientationchange=orient();. So I just lied, that is a bit of javascript, but this is needed to call our "orient" function (we'll go over this in a bit) when ever the device detects a different orientation.
</head>
<body onorientationchange="orient();">
<div id="wrap"> <div id="header"> </div> <div id="content"> <p>This is the main content area of the page. </p> <p>Using css and javascript we can manipulate any of these divs using an alternate css file. The css files in this project are for landscape and portrait views.</p> <p>Some more filler text here to demonstrate the page.</p> </div> <div id="bottom"> </div> </div> </body> </html> Step 3: The Orientation Javascript In the head of the page you will want to place the code seen below
<script type="text/javascript"> function orient() { switch(window.orientation){ case 0: document.getElementById("orient_css").href = "css/iphone_portrait.css"; break;
case -90: document.getElementById("orient_css").href = "css/iphone_landscape.css"; break;
case 90: document.getElementById("orient_css").href = "css/iphone_landscape.css"; break;
} } window.onload = orient();
</script> switch(window.orientation) works off of the onorientationchange() method in the body element. This will check to see if the current rotation is equal to the "case value", if it returns true it will execute what is after the colon. After an orientation has been matched it breaks out of orient();. window.onload() runs the orient function when the page first finishes loading.
After each case (value) : we have javascript pointing to the link elements id that our css file is attached to. Depending on the case value, 0, 90 or -90 ( there is also 180 but it is not supported on the iPhone at this time) the portrait or landscape css file is attached to the href tag in the link element. 0 is upright (portrait), 90 is landscape counter clockwise. -90 is landscape turned clockwise and 180 although not supported yet would represent the device being upside down.
Step 4: Implementing The CSS Even with all of this code, the page doesn't do much. That's because we need to add background images and style it all. We will create 2 css files, one called iphone_portrait.css and another called iphone_landscape.css. We will place the portrait css file into the link element as the default css file to use.
body { background-color:#333; margin-top:-0px; margin-left:-0px; }
p { margin:5px; padding-left:25px; width:270px; font-size:10px; font-family:arial,"san serif"; }
#bottom { background:url(../images/<span class="skimlinks-unlinked">bottom_corners.jpg</span>); background-repeat:no-repeat; height:31px; margin-top:-5px; } The above code is for the iphone_portrait.css file and is rather straight forward. Some things to note are:
in the wrap style description overflow:auto makes sure floated items are kept inside the wrap div to keep the page nice and tidy. the dimensions for the page are 320px wide by 480px tall. be sure to state this in the wrap div. Below is the code to be placed inside the iphone_landscape.css file. the only differences between portrait and landscape css files are the background images, the wrap dimensions are reversed and the margins are adjusted accordingly.
body { background-color:#333; margin-top:-0px; margin-left:-0px; }
p { margin:5px; padding-left:25px; width:370px; font-size:10px; font-family:arial,"san serif"; }
#bottom { background:url(../images/<span class="skimlinks-unlinked">l_bottom_corners.jpg</span>); background-repeat:no-repeat; height:37px; margin-top:-5px; } If you are using my sliced background images your page should now look like the image below when in portrait mode.
Or, in landscape mode?
Where To Go From Here? So now that you have a page formatted and styled for the iPhone and iTouch, what else can you do? Well, if your page is meant to be more of a web app you may want to check out the IUI by Joe Hewitt which is a framework that makes your pages look like native iPhone or iTouch apps. Also keep in mind that you can set 3 specific css files; so you can have one css file that styles the page if its turned clockwise to landscape and a different file again for when its turned counter clockwise to landscape. This will allow for some interesting outcomes. Good luck!
In the previous article in this series, we introduced some basic iOS design specifications and templates. Now it’s time to explore what makes designing for touch screens and mobile devices so special! Unlike design for desktop websites and/or applications, the variety of ways you can interact with and get feedback from a mobile devices radically differs from its desktop counterpart. Mobile apps aren't just pretty pictures; you're developing a piece of software. Designing for mobile is a combination of interaction and usability, product development, and graphic design.
Think about all the things a mobile touch screen device can react to: touch, shaking, tilting, vibrating, audio input and feedback, geolocation, and time tracking. With these elements, design takes on an entirely new dimension. It's your job as a mobile designer to consider these features when conceptualizing how an app will work.
It is Easy to be Average Average applications take average advantage of the iPhone’s capabilities. Extraordinary apps find unique and interesting ways to take ordinary interactions and make them faster, easier and more intuitive to use. Think about how you can push the status quo and come up with interactions that will really engage your audience!
Gestures To perform actions on a touchscreen device, users use their fingers to swipe, drag, pinch, tap and flick on-screen elements. Apple’s own remote app is a great example of a gesture-based control system.
Planning for and integrating these gestures into your design provide a rich user experience that takes advantage of the unique attributes of touchscreen devices. One thing to keep in mind is users do have expectations with regard to “standard” gestures. These are gestures that Apple has defined in high usage apps like Mail and SMS -you do not want to re-invent them. If there is a gesture that users commonly understand to perform a certain action, stick with that nomenclature. For example, you wouldn't require users to use the pinch gesture to scroll a list view.
photo courtesy of Kyle Buza
Tap
Tapping is the most basic gesture used in iPhone applications, allowing the user to perform practically any function.
Tap + Hold
This is a gesture that does not have one standard path of usage. Tap and hold on the springboard icons, and you are able to delete and/or rearrange them. Tap and hold a link in the safari browser and you are prompted to open the link in a new page. Tap and hold an image in an email and you’re prompted to save or copy the image. Generally speaking, tap and hold is helpful in invoking contextual menus that allow you to do what you want with the on-screen element.
Double Tap
Double taps on the iPhone are used most frequently to zoom in or out on content and also to bring up additional context menus. In Safari, for example, when you double tap on a webpage it zooms in to make the text more readable. In the Photos app, double tapping an image triggers a contextual menu that allows you to do more things with the image.
Pinch
Using the pinch gesture allows users to zoom in and out on a piece of content.
Flick
Flicking content is a cool UI gesture that isn’t used often enough!
Horizontal Swipe
The horizontal swipe can be used to shift content horizontally on and off the screen. The current content section is usually indicted with navigational dots along the bottom of the content area. Horizontal swiping is also commonly used with list items in a list view to delete or edit rows.
Accelerometer The iPhone accelerometer is probably one of the most under-used input elements available to designers. Practically speaking, it is most often used to detect portrait or landscape mode and to light or dim the screen when we put the phone to our ear. Accelerometer data can also detect positioning and location as it relates to the compass and GPS functionality. However, these functions barely scrape the surface of possibilities in creative use of this unique functionality
Game developers have made the most use of the accelerometer, but, even in game development, execution is sometimes awkward. The user is often left feeling like they’re going to drop the device while trying to play the game. Doodle Jump and Popper! are great examples of addictive, casual games that make great use of the accelerometer.
Shake and Tilt
Shaking and/or tilting the phone has become a fun novelty gesture in a lot of apps. Making music, firing a gun, and getting search results (UrbanSpoon) are all examples of apps that take advantage of this functionality. What if shaking or tilting did something even more unexpected? What if it turned the pages of a book or skipped to the next song in a playlist?
How can designers use the accelerometer in new, cool ways? Think about where people use mobile devices - everywhere! That opens up a lot of options as far as the context in which the accelerometer might be useful.
For example, pretend there’s an app for the restaurant where you’re having lunch. You open the restaurant’s app. After you’re ready to place your order, instead of signaling the waiter or hitting a button in the app for service, you instead just turn your phone over with the screen facing down. The app detects that you’ve turned your phone over and calls the waiter for you. This is faster and easier than looking at the screen and hitting a button, right?
Time/Clock When thinking about how cellphones have changed the way we interact with time, it is an incredible realization that the change has taken place over just the past few years. The average wristwatch tells you the time, and perhaps the date if you’re lucky. But how much information does it give you about the rest of your day? Zero. Contrast recent history with the information overload we have regarding every minute of our day via mobile smart phones! These devices have dramatically changed our daily routine.
How is this fact relevant to design? Let’s say we’re designing an app that locates retail outlets in a particular area of town. We query for shoe stores. We have our list of stores to visit which is great, but it would be even better If the list sorts based on the days and hours of operation! Why list a store first if it’s not open when we want to go shopping?
Time is incredibly relevant to design. We want to design apps that help users get to the most relevant information available at any given time and date.
GPS Often you’ll find that time and date brainstorming naturally dovetails into location awareness. Remember, GPS isn’t relevant to just mapping applications. It can also be used to tag content based on location (photos/notes), search for things based on your current location (food/retail), or check into a social networking app for offline socializing (Foursquare).
Other cool uses include documenting the GPS coordinates of items for future reference (cars/keys) or finding/tracking the location of other people. This is a fun area to let your mind dream about how the features of your app could incorporate this technology.
Vibration Although not available on the iPod touch or the iPad, vibration is still an element of app design worth thinking about. Typically, vibration is used when audio alerts would be a distraction or an annoyance. When designing your app, think about the various ways your app needs to communicate with the user in discreet ways.
How could you replace an audio or text alert with a vibration? When would the user be satisfied with a vibration alert versus an audio alert? Brainstorm elegant and unobtrusive uses of this hardware feature for your app!
Audio Input/Output
Audio is an element with endless possibilities. Typical usage of audio input includes talking on the phone and voice controls like Google’s voice search. Typical audio output includes listening to media (music, video, podcast), phone calls, alerts, or app sound effects. How can you use audio in ways that aren’t so common?
Where audio gets interesting is thinking about when and where users can make use of audio input and/or output. Noise can be a distraction whether it is incoming or outgoing. Ask yourself when is audio feedback appropriate? What traditional interactions could you replace with audio? When is typing impolite or even dangerous?
Opus is an example of an app that relies completely on audiological cues and physical gestures. The app requires zero visual interaction, claiming that it is “safer” to use than competitive products because you are not distracted by looking at the screen.
Conclusion By now your head may be spinning with ideas, and that’s okay! The best thing to do is to bookmark this post and use it as a reference when your next iPhone design project comes up to get your brain going on the various ways you can use these features. The main point to remember is that you don’t have to do things like everyone else. The primary boundary is not “how other people do it” or a standards guide. If people can jump into your app and easily understand what to do, then THAT is your design goal! Have fun!
It’s easy to get excited about app ideas. I hear great ideas every day, but in most cases they’re ideas that originate around a task or function, rather than a specific audience. The target audience is considered as an after thought, only important when formulating the marketing plan. The more apps I design and launch, the more I’m convinced it’s better to start with a specific target audience and create ideas based on the needs of that audience.
Why Start With the Audience?
"But my idea is great! Even I need this app!" I’ve said this myself. I AM my audience, so why do I need to think about who I’m targeting with this app? Simply put, the "I am my target audience" methodology is flawed. Speaking from personal experience, if I had spent more time researching and polling my audience, I would have either brought some of the apps I’ve published to market much differently, or, in some cases, perhaps not at all.
A perfect example is our app, Doodle Bright. When the idea originated, the iPad had not even launched - I was using a wooden prototype to draw and test ideas. The problem is we identified our initial target audience as previous Lite Brite users, a novelty, retro app that adults who enjoyed the original toy would buy. Right, but mostly WRONG. Those people were buying the app, but they were buying it for their kids! If we had taken a week or two to poll the idea for the true target audience we would have very quickly narrowed down a very concise and targeted plan around:
Pricing - What are parents expecting and willing to pay for an app that is fun, but not educational? Maybe the pricing should be less than an educational app. Upsell Opportunities - What is the value to parents? Does it keep the children entertained for 15 minutes or 15 seconds? If the value is high - perhaps they would be willing to make an in-app purchase to amp up the entertainment level even further. Design - Our original design was not targeted towards children. It was targeted for adults who got into the original toy. Once gameplay begins, the playful colors have eye catching appeal for a child, but if presented with a choice of our design versus a very kid-centric design, Doodle Bright would have a tough time competing. Interaction Design - The app was not designed specifically for a child’s mind. We did not do research on the most successful apps for kids before designing Doodle Bright. Not to say that the interface doesn’t work for kids, but we certainly made tweaks to the interface once we realized who made up the bulk of our audience. Marketing - We first market to the parent, but build the app for the kids. This is an insight we did not have during the "idea phase" because we started with the idea, not the audience. If we had taken extra steps to reveal the entirety of the audience, our marketing efforts would have been more successful. Instead, we marketed to adults in general, not parents. Notice how knowing information about your audience touches many pieces of the product development? It doesn’t just impact marketing. It it a critical piece of the entire process.
How to Fine Tune Your Idea
If you’re reading this article, you probably already have an idea or perhaps have a client with an idea. You need to find out who is going to go crazy for your app idea. Or, even if you don’t have an idea, answering the following questions is a useful exercise to help you narrow down audiences that are a good target for mobile apps.
Does Your Audience Need an App? Businesses with an existing customer base are the first to fall into the "we’ve gotta have an iPhone app!!" brouhaha. People want to "stay up with the technology" without considering if the product will bring value in the mobile context.
As an example, a company called me a few months ago that helps doctors offices generate more revenue by making phone calls to patients to remind them of appointments. Great, maybe they can make an app that reminds their patients of their appointment! Problem is, 99% of their patients do not own a smartphone. Which leads me to our next point.
Is Your Audience on iPhone? You would think this is a no-brainer, but I’ve had dozens of calls from people with ideas like the above example. Think about how many ideas you’ve had or heard about that include an audience that simply isn’t on iPhone! I hear great ideas for apps all the time that are perfect for Blackberry users.
Does Your Audience Use Apps? When I first began polling friends and family about the types of apps they use, I was surprised to learn how many "regular" people do not use a great quantity of apps. I then reflected on my own habits, which include testing apps for "work", but for my own personal use revolve only around 3 - 4 apps! Do some asking around to make sure the people you have in mind to use your app are in the habit of using more than just the Mail and Phone applications!
Is Your Idea Mobile-Centric? porting to mobile is a natural next step for growth of that product. Sometimes products are a good fit for mobile, but sometimes they aren’t.
For example, WebMD is in the process of porting their content to mobile. Is this the right move? Let’s think about their audience. People are at doctors offices waiting for appointments, a perfect time to surf their smart phone for more information on their health problem. In this case, the content is very mobile-centric.
Another example is a company that wanted to devise a lie detector test based on books they have written on the topic of deception detection. We sliced and diced the idea a million ways before deciding that there wasn’t a way to create a real, working lie detector for iPhone because using their methodology relied heavily on human evaluation of the subject.
Who is on iPhone?
Once you have narrowed down that your idea is mobile centric, and your users have iPhones and have needs, it’s time to learn more about their physical and emotional makeup and surroundings. Two components to research include demographic and psychographic information.
The iPhone Demographic What is the iPhone demographic? It depends. Are you talking about iPhone and iPod touch or just iPhone? Generally speaking, iPod touch users skew younger than iPhone. You have kids whose parents buy the iPod touch for music and text messaging, before the child is old enough to own a phone. Do your research for the latest reports of iPhone to really understand who is using the device and how they are using it. Or, better yet, do some independent polling of your own on Twitter or with friends and family. The results might surprise you!
The iPhone Psychographic Audience demographics are a common consideration defining a product’s target audience, but what about psychographics? Psychographic variables are any attributes relating to personality, values, attitudes, interests, or lifestyles. Although not "iPhone" specific, a study by Mindset Media found that Mac users are: superior, arrogant, open, perfectionists. Oye that hurts!
Seriously, it’s important to think about the emotional impact your app will have on its audience. Does it give a sense of relief because they don’t miss a plane? Or a sense of accomplishment by checking off an entire to-do task list? I’ll list out some brainstorming questions below that will help you identify some of the psychographic characteristics of your target audience.
Advertisement Questions to Ask Yourself
The below list of questions will help you to fully explore the demographic and psychographic makeup of your audience.
Are they male/female? How old are they? Where do they live? Do they have children? Are they married? Where are they when they use the app? Do they love a competitive app? Why? What do they do? What do they have in common? Why are they interested in the topic? Who are they trying to impress? Who impresses them? What are their biggest fears? What are their biggest hopes? What Internet tools do they use most every day? What Internet tools do they not use ever? What drives my target to make decisions? Can they afford my app? Can I reach them with my app? Are they accessible? Are there enough people in your target to be profitable? How does your idea resonate with your audience on an emotional level? Do you need to break your target up into niches?
Conclusion - Who Cares?
If you have only one takeaway from this article, it’s to ask yourself one question: "Who Cares?" Sounds a tad cynical, but a simple phrase to keep in the back of your mind during the app development process. Will anyone really care about this app? If the answer is yes - Godspeed!
There is a lot of “process” that goes into designing for mobile devices, but sometimes you just wanna jump in and get your hands dirty! This post is designed to give you the tools you’ll need and the basic design and technical requirements to get you up and running quickly.
Standard Screen Sizes and Icon Sizes
If you haven’t read the Apple Interface Guidelines for iPhone and iPad yet, you should. It’s a lot of information, but well worth the time spent to understand how Apple thinks about application design. These guides also spell out detailed specifications for screen size, icon size, and resolution. Next, I’ll address a few commonly asked questions and summarize these specifications in an easy to digest format!
What’s the Resolution of the New Retina Display?
The iPhone retina screen is a spectacular thing to see. When viewing the new and old screen side by side, it’s obvious there are changes in this display that affect the design of your app. See this side-by-side screen comparison video.
You can see in comparing the two devices that the screen dimensions for iPhone 4 are unchanged from the previous model. However, both the iPhone 4 screen size and the pixel density of the screen is DOUBLED, giving it a 640 x 960px screen size (compared to the previous 320 x 480px size) and a whopping 326 pixels per inch (compared to previous 163ppi). This new screen squeezes 4 pixels where there used to be one - that’s why the images look so crisp and delicious!
When reading about screen resolution it’s easy to quickly become confused. The fact is the final exported file type on the iPhone is usually .png and Xcode doesn’t consider the ppi value saved when rendering images. If you follow the dimensions specified below, you’ll be in good shape!
Photoshop Setup Specs:
iPhone 3.0 Screen resolution: 72 ppi Screen size: 320 x 480 px Icon size: 57 x 57 px File format: PNG-24iPhone 4.0 Screen resolution: 72 ppi Canvas size: 640 x 960 px Icon size: 114 x 114 px File format: PNG-24iPad Screen resolution: 72 ppi Canvas size: 768 x 1024 px Icon size: 72 x 72 px File format: PNG-24 Graphics for the iTunes Store Icon: 512 x 512 px (.tif, .jpg or .png, 72dpi, RGB) iPhone Screenshots: 320 x 480 px or 640 x 860 px (.tif, .jpg or .png, 72dpi, RGB) iPad Screenshots: 1024 x 768 px (.tif, .jpg or .png, 72dpi, RGB)
The Future of Screen Sizes
While we’re discussing screen sizes, it’s important to talk about the future of digital devices in general. I’m no fortune teller, but in the past year alone it’s no secret touch screen devices of all kinds are multiplying like rabbits and they’re producing offspring with varying screen sizes. Aye! As designers, that means we need to be prepared for how to translate designs to multiple devices and operating systems.
An app life cycle can run one of many courses. Some apps live on one platform exclusively, others branch out into other mobile devices or even a web-based presence. Creating scalable graphics saves you the headache of re-creating graphics for each specific platform. Using shape layers or vector smart objects is the best way to deal with the proliferation of screen sizes and operating systems.
Design for 3.0 or Retina First?
Designing icons for iPhone was my first introduction to the decision of “start small and scale up” or “start large and scale down.” For me, it became obvious after a few executions that designing for the 320 x 480px screen size and then sizing up to 640 x 960px is the better option. Designing for the smallest screen size eliminates the disappointment of losing details when a design must be sized down later.
How to Create App Graphics for Retina Display
Let’s say you’ve designed an app for a 3.0 iPhone and you want to prep this app for the iPhone 4 retina display. What do you do? Just size it up from 320 x 480 to 640 x 960? Yes. The problem is, if you haven’t created all of your graphics using shape layers or vector smart objects you’re images are going to look pixelated and grainy.
How Big to Make Your Buttons
For both iPhone and iPad the minimum size tap target area Apple recommends is 44 x 44 pixels. Leave it to Apple to quantify the average fingertip size of human beings. :) If you want to go smaller be sure to adequately space tap-able areas to prevent mis-taps.
Testing Your Design
“Testing” a design may sound odd, but designing for a mobile device on a laptop or desktop monitor can be tricky. Even if you follow standard guidelines like the 44 x 44px tap target rule, proportions and sizes may look significantly different when displayed on the device vs. your computer screen.
The easiest way to test your design is to “Save for Web” each screen design in .png format and sync to your phone using iPhoto. Once the images are synced, you can flip through and simulate what the actual app will look like. This is also a great way to share mockups with clients to give them a true preview of the app.
Design Templates for iPhone and iPad
Now that you have some basics under your belt, it’s time to start designing! Luckily there are plenty of resources available to help you get acquainted with the various iPhone and iPad interface elements. Even if your goal is to create completely customized interfaces, these templates are helpful in getting a baseline grid or dimensions of on-screen elements properly proportioned.
iPhone Templates iPhone GUI PSD from Teehan + Lax iPhone GUI PSD Retina from Teehan + Lax iPhone Stencil for OmniGraffle from Patrick Crowley iPhone UI Vector Elements from Mercury Intermedia
iPad Templates iPad Stencil for OmniGraffle from Information Architects iPad GUI PSD from Teehan + Lax iPad Vector GUI from Icon Library
What File Format Do I Use for iPhone Graphics?
All graphical assets that will be used to build an app are exported in Portable Network Graphics (.png) format. Technically, the iPhone can display other file formats as well, but PNG files are automatically optimized by the iOS SDK, and consequently should be the preferred format.
This applies to all elements (nav buttons, bars, etc.) and any other imagery showcased in the app. For example, let’s say your app is a portfolio for a photographer. The photos showcased would also be exported in .png format.
The setting to export .png format in Photoshop (File > Save for Web and Devices) looks like this:
Preparing Files for Your Developer
Before handing your files over to a developer, it’s important to understand their capabilities with regard to slicing and dicing your file. If your developer is experienced in slicing and exporting, it can be a huge time saver to offload that task. Personally, I prefer to cut up all of my files to ensure all images are sliced out properly.
When saving out your final images, try using intuitive file naming conventions that will make locating and referencing the correct image files easier for your developer. Here are some example prefixes and suffixes I use:
“btn-” for all button images “tab-” for all tab bar images “bkg-” for all background images “-up” for in-active state buttons “-down” for active state buttons “-hover” for hover state buttons “@2x” this is a standard suffix required for all retina display graphics Another tool I use to communicate with developers is a .pdf file that includes all screens plus notes regarding the design. I define the typefaces, sizes, line spacing and all other styling so there is an easy reference that the developer can use without having to open Photoshop. Yet another resource I provide, especially when I’m working with off-site developers, is a screencast (ScreenFlow and iShowU are my favorites) of the app, walking them through every aspect of the design. This is especially helpful if the app contains animations and/or transitions that are better illustrated in a video.
Conclusion
Technical specifications aren't sexy but they're important. Commit these details to memory and you will save yourself a lot of headaches down the road!
