Field Guide to the Field Guide

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.

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

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.
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).
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 Paint.net. 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.
Image: Simon O. Photo Credit: Flagstaff Studios
Source: Museum Victoria

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

In high school, I bucked the normal Maths/Science stream by studying French instead of Biology (yeah, I’m a rebel). So I spent my evenings memorising the past imperfect conjugations of irregular verbs rather than Linnaean classification systems. Fast forward an undisclosed number of years and while I still haven’t been to France to wrestle with verbs that need more fibre in their diet, I have spent a lot of time in meetings talking about how Phylum, Class, Order, Family, Genus and Species should be displayed in the Field Guide.

When animals are shown in the listing or the search results, you see the thumbnail on the left, common name in bold and scientific nomenclature subtitle.

Screenshot from the Field Guide
Source: Museum Victoria

The subtitle is created and formatted using the taxonomic data entered for the animal. Genus and species names are always displayed in italics. Of course, you may not need to have a species or genus name for a particular animal. A fresh water pond may have dozens of different examples of Copepoda, but your average explorer is unlikely to have a microscope handy to tease them into their different genera.

The logic for creating the subtitle starts with species and works its way back up the taxonomic ranks. In the sample listing, the Yabby has an entry for Genus and Species and the subtitle becomes the full scientific name (e.g. Cherax destructor). The Spiny Crayfish only has an entry for Genus, so Euastacus sp becomes the subtitle. The Cyclops Copepod doesn’t have an entry for Genus, so the subtitle is created using the lowest taxonomic rank there is an entry for, Order. With the value, Copepoda, and Order: Copepoda becomes the subtitle.

And that’s how the taxonomic information about an animal gets converted into its scientific name within the Field Guide code. If you’re wondering about the title of this post, it’s the start of a good mnemonic for the order of the Linnaean ranks: Keep Plucking Chickens Or Face Getting Sacked.

Most of the information youre going to store about an animal will be simple strings. Images and sounds are the exceptions. Each image and each sound requires two pieces of information: a filename and a credit.

For images, the credit is shown in the bottom right corner of the image panel.

For sounds, the credit is listed in the audio popover.

The filename for each image and audio file you use in the app should be unique.

When youre sourcing your images and sounds, get the largest, highest quality file that you can. Currently, the maximum size of an image on the app is 1024 pixels square. As memory, processor power and screen resolution of these devices increase, so will the maximum size of the image. Scaling an image down is easy, scaling up an image isn't except on television shows.