Field Guide to the Field Guide

Displaying all posts from Jul 2011:


A face for your field guide

5 August, 2011 15:42 by Simon O

Part Two: Splash Screens and App Icons

In the first post of this series, we illustrated how to create optimised versions of your photos at various required sizes for output. Using these same principles, in this post, were going to show you how to create images for your splash screen and home screen.

One thing to think about if you havent already is the visual identity of your field guide. What will it look like in terms of a logo, branding, colours and featured imagery? This is based on your intended audience and the feeling you'd like to convey. Also give some thought to the consistency of the brand across the various aspects of your app. Using only one or two typefaces and a consistent colour scheme helps your app appear not just professional, but like you've put some thought into how your app represents your content, which you've no doubt been crafting for a long time. If this all sounds foreign to you, its worth getting a graphic designer involved to help you through this process. 

So once you have a look that would make Beyoncé jealous, youll need to think about what it is you want to display when your users start up the app the splash screen or launch image. This is the first thing users will see once they launch your app. It only shows for a few seconds, so keep it as simple as possible. Think of your splash screen as a billboard. If you're driving down a freeway and see an advertisement on the side of the road, you've got a couple of seconds (if that) to read it. So it's best to save that essay for inside the app.

As far as technical requirements are concerned, there are a few versions to consider. For an iPad app splash screen, youll need a PNG or JPEG image with dimensions of 768 x 1004 pixels. The iPhone and iPod Touch splash screen requires a 640 x 960 pixel image for the Retina Display (Apples 326ppi high density display). You'll also need to supply a version at half the size (320 x 480) for iPhones and iPod Touches that arent young enough to have a Retina Display. Here are some examples of the screens we created for the Museum Victoria Field Guide..

 Splash Screens from MV's Field Guide

To get a feel for how your splash screen will look in the real world, you may like to preview these at their native size on the device before you proceed with development. One way to do this is to import the images into iPhoto and then sync them with your iPhone, iPod or iPad.

There is one more image that your users will see before theyve launched your app in fact, before they've even downloaded your app which is the application icon. This is used as an icon on the home screen as well as acting as a badge in the app store. This must be an opaque square image with 90 corners. Apple requires that you provide this with dimensions of 57 x 57 pixels, 72 x 72 pixels for iPad, 114 x 114 pixels for Retina Display and 512 x 512 pixels for the App Store. In iOS, your icon will automatically be displayed with rounded corners and a drop shadow. Your icon will also have reflective shine unless you create a pre-composed image, which you can specify in your apps Info.plist file.

For further information on these image specifications, you can view the Image Creation Guidelines on Apples website.

Comments (8)


Beta Testing

25 July, 2011 15:46 by Simon S

Just wanted to let the two of you that are following this blog that we've handed over the code for the open source code for the Field Guide to our beta tester. We are moving ever closer to the date that you can get your hands on the code.

Why are we beta testing? In getting the code ready to release, I've simplified the code in some areas but also added in a new setting or two. While I know you're a fan of Museum Victoria's particular shade of green, it's remotely possible that somebody with a less sophisticated palette may want to change the colour of the toolbars. A charming shade of mauve may be their choice, or perhaps honeysuckle, if they're up with this year's Pantone colour. The setting for this was buried in a class, but is now set in a configuration file.

Even if I hadnt tweaked the code, it's important to check that the whole thing isn't going to fall in a heap when you get the code and run it yourself.

At the risk of teaching you to suck eggs, after adding your own data to the code, you should put aside a block of time do some extensive testing of the app before releasing it to the public.

Before releasing our field guide, we checked the detail page of each animal, made sure the images were there, maps were appearing, that audio was working and there weren't any unexpected crashes (not that we had a list of expected crashes). I'm not going to lie to you, while the images and audio in the guide are beautiful, it can get a little tedious having to go through a couple of hundred in one sitting.

It's unlikely, but possible, that something in the data for one of your animals will interact strangely with the code. Better to find that out before you publish to the App Store.

Comments (4)


Developers, Developers, Developers

21 July, 2011 11:00 by Simon S

We've talked about data and images, and while theres still more to relate on that score, I want to jump ahead and talk about the something you'll need to do to pull it all together.

You're going to need register in the iOS developer program.

Don't panic, it doesnt mean that you're going to have to become familiar with the intricacies of Objective C and XCode, it just means that you, or your organisation, have to stump up US$99 and jump through the hoops of the registration process. The cost is the same whether you register as an individual or a company. 

Joining the iOS Developer Standard Company Program requires entering into a legal agreement on behalf of your organisation. If you can do that, great! If not, you need to involve a person in your organisation who can. This involvement is going to be an ongoing commitment for that individual. Every time Apple updates the developer agreement they will need to log into the developer portal and check the I agree box (after carefully reading the agreement of course).

Plan on the initial process of getting registered taking a couple of weeks. You need to send through documentation proving that your organisation is real, and that the person who says they can enter into legal agreements can actually enter into legal agreements, and so on.

If your eyes have glazed over at this point, I'll be honest with you. You (or your organisation) don't have to become a registered iOS developer. You can get someone else thats gone through the registration process to compile and publish your Field Guide to the App Store. However, there are a number of downsides to this approach: 

  • In the App Store, your external developer appears as the seller of the App
  • You wont be able to access App Store stats.
  • If its a paid app, Apple sends the cash to the developer. 
  • You will have to use the same developer to make updates to the App


The last point is pretty critical. If you part company with your external developer, your existing Field Guide becomes an orphan. You could partner with another developer to get it back into the App Store, but the App Store sees it as new app. Customers with the old app wont get any updates that you push to the new app.

Registering your organisation as a developer may seem painful, but it's going to save you from a lot of problems later on.

All of this does'nt mean that you have to have in-house developers to publish a Field Guide. An external developer can compile the code and send you the binary. Your development team agent then submits the binary to the App Store.

Easy J


Comments (0)


A face for your field guide

11 July, 2011 10:10 by Simon O

Part One: Optimising Your Images

In this series of blogs were going to discuss the visual aspects of your app and how we approached the design of Museum Victorias Field Guide app. In later posts, I'll cover the design and branding of your app which is seen most prominently on the splash screen and home screen, I'll run you through how to make interface elements such as icons and how to create layouts to display your data, using HTML and CSS.

In this post we're going to focus on the main images of the Field Guide app in this case the photos of the animals. Before we jump straight in, you'll notice that when you select any animal in the Field Guide app that there is at least one hero image for each animal and sometimes multiple images as you can see indicated by the gallery module. There is also a square thumbnail image for each animal. These appear next to each individual animal within the Animal Groups and are usually the same as the first hero image.

So let's take the European Honey Bee or Apis mellifera as an example. If you search for it in the app, it appears like so (Figure 1). It has a thumbnail in the Insects listing as well as three images in the gallery of the main panel.


European Honey Bee (Apis mellifera) on the iPad app. Required image assets highlighted in colour.European Honey Bee (Apis mellifera) on the iPad app. Required image assets highlighted in colour.
Image: Simon O. Photo Credit: Flagstaff Studios
Source: Museum Victoria

The thumbnails should be a square crop of the original image. We found that saving them at dimensions of 150 x 150px was optimal for both the regular iPad and iPhone Retina displays.

Full-size images in the app should not be larger than 1024 pixels in both width and height. So, for example, you could have a landscape image at 1024 x 680px and it would work just fine. The reason you need to keep it within these dimensions is so that you can keep the memory down on the users iPad or iPhone and therefore the images will scroll, pan and zoom without any lag.


Original images (left) and exported images and their dimensions (right).Original images (left) and exported images and their dimensions (right).
Image: Simon O. Photo Credit: Flagstaff Studios
Source: Museum Victoria

Once you've set the right dimensions on your image, you need to export them at a suitable quality. Obviously, you want your images to look nice and sharp and free from artefacts, but if you've got a lot of images, you'll need to find a compression rate that will also keep the file size reasonably small. In this case, photos are best exported as JPEG files. You may also save your files in 24 or 32-bit PNG format, however this will produce larger file sizes.

To apply these settings, use an application such as Adobe Photoshop, or a free alternative like GIMP or For large groups of photos, you can save time by setting a batch process using actions in Photoshop, Lightroom or Aperture.

Be sure not to overwrite your original photos as you may need to export at larger dimensions for future versions of the iPad (or other tablets), which will likely have a higher pixel density.

Good luck and feel free to ask questions or make suggestions by posting a comment below.

Exporting an image of the European Honey Bee (Apis mellifera) with Photoshop’s Save for Web dialog. On the left is the original image and on the right is a 50% JPEG. Notice the slight artefacts around the bee’s antennae.  This will barely be noticeable once on the mobile device.Exporting an image of the European Honey Bee (Apis mellifera) with Photoshop’s Save for Web dialog. On the left is the original image and on the right is a 50% JPEG. Notice the slight artefacts around the bee’s antennae. This will barely be noticeable once on the mobile device.
Image: Simon O. Photo Credit: Flagstaff Studios
Source: Museum Victoria


Comments (3)


July Already?

6 July, 2011 14:24 by Simon S

"I love deadlines. I like the whooshing sound they make as they fly by." - Douglas Adams

It's July, which means that the end of June has whooshed by. By rights, there should be a link to shiny open source Field Guide code right here. In this very spot. You may have noticed that there's not. I'm afraid its going to take a couple of more weeks. In the meantime, we'll be putting up some more posts so that you can hit the ground running when that link appears.

Comments (0)

About this blog

We've released the source code for MV's Field Guide Project under a MIT style license. This blog will help you identify all the material you need to collect so that you can publish a field guide of your own.

MV's Open Sourced Code on Github

View all Museum Victoria's apps

Blog authors

Simon S is the programmer behind the field guide app.

Simon O is the designer behind the field guide app.