Field Guide to the Field Guide

Displaying all posts from Aug 2011:

 

A face for your field guide

19 August, 2011 09:30 by Simon O

Part Four: HTML Layouts

This is the final and perhaps the juiciest part in the series because it’s where the design meets the code in a harmonious display of passion.

Alright, enough flowery language, let’s have a look at how the ‘species’ page of the app works. This is the destination page your users will land on once they’ve selected an animal/item. On the iPad version of the Field Guide it’s a single page that consists of all the details. On the iPhone/iPod app, these sections are split into individual tabs.

Once you’ve downloaded the code, you’ll notice that we’ve chosen to lay out the details with HTML.

Where the HTML things are.The detail view area consists of HTML (in a UIWebView container).
Image: Simon O'Shea
Source: MV

This allows you to easily change presentation, links and styling, but above all, it allows you to transfer an existing design to an iOS app if you already have a web-based version of your field guide. Vice versa, with a bit of tweaking and testing, it also allows you to transfer these layouts to the web or other mobile platforms.

So let’s see what makes up a Species/Item page…

 

The Files

  • Species/Item Page (iPad): template-ipad.html
  • Details Page (iPhone): template-iphone-details.html
  • Distribution Page (iPhone): template-iphone-distribution.html
  • Scarcity Page (iPhone): template-iphone-scarcity.html
  • Stylesheet (iPad): style.css
  • Stylesheet (iPhone): style-iphone.css

  

The Markup

If you’re familiar with HTML, these layout template files should be pretty straightforward. For the iPad template, the page is divided into two main <div>s, with class names leftcolumn and rightcolumn. I’ve labelled these for identification practicality over formal semantics, so feel free to change the names if you’re partial to the latter school of thought. These are set to float left in the stylesheet, next to one another.

The leftcolumn holds the <header> of each animal/item, containing the common and scientific names. This is followed by the main details, each of which has a heading (<h3>), followed by a custom tag that tells the app where to insert specific animal data. The custom tag takes the form <%propertyname%>. For example, to display Distinctive Markings as a paragraph, you would insert the custom tag <%distinctive%> between paragraph tags.

eg:  <p><%distinctive%></p>

The taxonomic data of the animal is displayed as tabular data using a <table> element.

The rightcolumn in the template consists of ‘widgets’ or styled containers that we’ve created to display key information. There are three of these widgets: Distinctive Markings, Distribution and Endangered Status. On the iPad version of the app Distribution and Endangered Status each have information on the ‘back’ to explain the graphical data displayed on the map and status chart. This is initially hidden and can be viewed by the user by tapping the i icon. We’ve enabled this to be accessed using a combination of CSS3 and JavaScript to create a ‘Flip’-style animation. On the iPhone version this information is displayed in a separate widget underneath both the map and status chart.

You may notice that the map <img> tag is repeated in the back div of #distribution, seemingly printing two map images within the widget. This is to give consistent height to the Distribution widget when it is ‘flipped’ and with the styling included it also gives the effect of translucency, showing the reversed map when reading the back pane of the widget.

 

Detail View of the iPad App. Mouse-over to see HTML elements and classes.Detail View of the iPad App. Mouse-over to see HTML elements and classes.
Image: Simon O'Shea
Source: MV

 

The Styles 

The styles for the Species page templates are contained within the linked files style.css and style-iphone.css. I’ve written a number of properties assigned to HTML elements, classes (.) and IDs (#).

Please note that because this is an app for iOS and it’s using the latest Safari rendering engine, there are many CSS properties that may not display when testing in your standard desktop web browser. In particular I’ve used CSS3 properties such as gradients, transformations and animated transitions as well as –webkit specific properties that may not yet be standardised CSS. These fancy styles allow you to push the boundaries of HTML and iOS and can significantly save load time and file size. However, it is worth noting that in order to view them on your computer, you’ll need to test them in a recent version of Apple’s Safari or Google Chrome and to get the best results you should test their compatibility on various versions of iOS.

 

The Images 

Another advantage of using HTML and CSS is that you can save on the amount of images you use. For example each icon used on the Endangered Status widget is an 88px x 88px image. Simply setting a width and height of half the dimensions (44px x 44px) in your CSS means that the icon will render crisply for both the Retina Display and regular displays using just the one image file.

Another example of cutting back on images is using CSS entirely to create graphics. The Endangered Status ‘tracks’ and ‘bars’ are made entirely of CSS gradients and rounded corners. This means that they require no image files and are resolution independent, looking great no matter how far the user zooms in.

By now you’re probably exhausted, so I think that’s enough! If you have any questions, comments or suggestions, please don’t hesitate. We look forward to seeing what you can build on top of our Field Guide. Good luck with your app!

Comments (8)

 

A face for your field guide

17 August, 2011 16:42 by Simon O

Part Three: Interface Icons

The key to making your field guide app accessible and user-friendly for your audience lies in the design of the interface. In addition to this is the behaviour of the app. But for this blog post, we’re going to concentrate on the ‘look and feel’ and what you can do to make your app shiny and fresh on the inside.

In the previous post we scratched the surface of giving your app an identity by creating a splash screen and an icon. For this post, we’re going to look at some of the visual elements within the interface of the app.

The interface is comprised of the layout of the app, icons et al. And in the case of iOS, a lot of the hard work is done for us. With the Museum’s Field Guide, we based our layout for the iPad app on interface recommendations specified in the Apple Human Interface Guideline (HIG) documentation. There were a few reasons for this, which above all was that we wanted the interface to be familiar to iPhone/iPad users and new users alike as well as preventing the interface from getting in the way – letting the content be the feature. In addition we added specific icons and elements tailored to the Museum’s fauna content. For example, each animal species page has an image gallery, audio browser and ‘widgets’ that we created to display distribution information and the endangered status.

Let’s begin by taking a look through each of the visual elements that make up the Field Guide app. First and foremost is the main menu that contains access to the animals. This is the ‘Animals by Group’ home screen menu on the iPhone and iPod Touch or the menu on the left of the iPad app, which can be accessed by tapping ‘Animals’ when in portrait mode. Each top-level navigation item displays a silhouette icon of the animal group and once tapped displays a secondary navigation containing a square thumbnail photo of the specific animal. So let’s have a look at these closer and get a bit technical…

  

Animal Type Icons (top level navigation)

Each of these has a silhouette icon with two instances or ‘states’ – a default state in which a light grey icon is displayed and then a white icon in its active state (when the user taps on it). Of course you can make these any colour you like, however it’s best to always have the active state white, so that when tapped it ‘reverses’ out from the active blue highlight that surrounds each item in the list, matching the white text of the item.

Icon StatesActive state of an animal group, in this case, Butterflies.
Image: Simon O'Shea
Source: MV

It is also best to create your icons as a vector or line-based image rather than a pixel-based image. This means you can increase or decrease the dimensions of the image in future, without losing any quality of the original image. Vector images can be drawn with a software package such as Adobe Illustrator, Corel Draw or Inkscape.

Vector iconsVector icons.
Image: Simon O'Shea
Source: MV

Once you have the look of each icon, you need to determine the size and file type for export. It might be an idea to transfer your vector files to a pixel-based editor for the export process. An application like Adobe Photoshop, Fireworks, GIMP or Paint.net is best. You need to create two versions of each icon, one with default dimensions for iPad screens and iPhone and iPod Touch screens which are earlier than 4th generation. You also need to export versions of these for the Retina Display, which need to be double the dimensions. These versions should be exported as 72ppi 24-bit or 32-bit PNG files with transparency. In the Field Guide the icons need to fit within a width and height of approximately 60 pixels (120px for hi-res Retina). I’ve made our animal icons 56px × 43px each and 112px × 86px for the hi-res Retina Display. Therefore for each icon we need four files in total – one default state, one active state, one hi-res default state and one hi-res active state.

Resources:

 

 

Comments (0)

 

30 days hath September, April, mumble and November...

16 August, 2011 15:59 by Simon S

Here's a little known fact: There are actually 77 days in June. Seriously, who are you going to believe, me or some nursery rhyme? Is "hath" even a real word? Earlier in the year, I said that the source code for the field guide project would be released by the end of June. Well, today the source code for the field guide project is available to download. Welcome to the 77th of June.

The project is being hosted on Google Code, and has been released under an MIT license. This is a pretty broad license, allowing you to use the code as is, or mix and mash it to your hearts content. You can sell your app, or give it away for free. 

We’d just ask you to do a couple of things. First up, if you build an app using the source code let us know! If it’s published in the app store, send us a link. If it’s only an internal app, send us a description of how you’re using it and some screen shots. Releasing the source code is an experiment, and we want to build up a picture of how the source code is being used.

Secondly, we’d appreciate it if you mention that your app is built on the field guide project source in your app’s about page. Include a link to either the field guide home page at MV, or to the field guide project home page on Google Code and you’ll have our thanks. We’ve helpfully included an example in the default about page for the project.

Thirdly, let us know if there are bugs or if there’s better ways to do things in the code. This is my first Objective-C app, and no doubt there’s plenty of room for improvement in the construction of the code. Releasing the code like this feels a little like performing on the trapeze without a net, scary and exciting. Everyone who's watching can see if you make a mistake. On the other hand, the more people that are watching, the more likely it is that someone will catch you if you fall.

So what happens next? Well, you may notice that we’ve called this version 0.9. That’s just to give us room to tweak the code and fix any issues based on your feedback. We won’t be adding any new features before we call it 1.0 though.

We’ve still got a couple of blog posts to come on how to customise design elements within the app, and no doubt there will be a couple of posts based on questions and feedback about the code. There’s also a post coming up for those of you who’d like to produce a field guide that’s not about animals.

So grab the code, make cool stuff and enjoy this last day of June. :-) 

 

Comments (4)

 

Presto, chango

16 August, 2011 12:57 by Simon S

In my last post I described how to build the file that contains the initial load data for your field guide. At the same time, I sent the code off to an external beta tester. He came back with the question: How do I change the data once its been loaded by the app? When we were testing of the field guide, if we needed to change the data, I just reset the simulator or deleted the app from the testing device.

Not something you can really do once you've released your app to production.

So, with a couple of changes to code, we have two new properties. One in the animalData.plist file called versionID and another in CustomSettings.plist called currentDataVersion. The value of these two properties should always be identical. The first time the app is run on a device, the database is set up and the value for versonID is stored in the database. On subsequent start-ups, the app compares the value of versionID stored in the database against the value of currentDataVersion from CustomSettings.plist. If they're different, the app clears the database and reloads it from animalData.plist.

Why are we storing the same value in two different plist files? If you've got a lot of species in the app, the animalData file will contain a lot of information. It is overkill to parse this file every time the app starts just to find a short string. Since CustomSetting.plist is already loaded every time the app runs, it's the perfect place to put the check value.

Adding versionID as a property to animalData.plist has resulted in a change to the structure of that file. It was an array of arrays, like this

(

(array of taxon data),

(array of animal data),

)

The code determined the content by an element's position in the array. The file is now structured as a dictionary, like so:

{

taxonList=(array of taxon data);

animaldata=(array of animal data);

versionID = 1.0;

}

It's a small change, but it means that any future additions to the list will be easy to incorporate. Here's a new example animalData.plist file and a CustomSettings.plist file for your perusal.

Comments (1)

 

Getting your data out

9 August, 2011 16:02 by Simon S

Were going to take a break from the talk about design for this post, and talk about how you get your data into the app. All the animal data is stored in a property list file called animalData.plist (imaginative, I know). The first time the app is run on a device, it creates a database and loads all the data that file.

The file doesn't just contain the animal data, it also contains the information for the taxon menu. Since thats a bit simpler than the animal data, I'll start with that. Each taxon type has three properties: taxonName, highlightedImage and standardImage. A single taxon entry appears like this

{

highlightedImage = "animalActive_05_insects@2x.png";

standardImage = "animal_05_insects@2x.png";

taxonName = "Crawly Things with 6 legs";

}

Each line is a key value pair. On the first line, highlightedImage is the key, and animalActive_05_insects@2x.png is the value. Note that each line ends with a semi-colon (;).

The property standardImage is the filename of the image displayed next to the taxon name (in this case a grey silhouette of a winged insect). highlightedImage is the filename of the image displayed next to the taxon name when the row is selected. In this case, a white silhouette of a winged insect stands out better than the grey against the blue background.

Within the plist file, the taxon types for your app are contained in an array. So, if you only had invertebrates in your app, your taxon array would look something like this.

(

{

highlightedImage = "animalActive_05_insects@2x.png";

standardImage = "animal_05_insects@2x.png";

taxonName = "Crawly Things with 6 legs";

},

{

highlightedImage = "animalActive_03_freshInvertebrates@2x.png";

standardImage = "animal_03_freshInvertebrates@2x.png";

taxonName = "Freshwater Invertebrates";

},

{

highlightedImage = "animalActive_10_spiders@2x.png";

standardImage = "animal_10_spiders@2x.png";

taxonName = Spiders;

},

{

highlightedImage = "animalActive_11_terrestrialInvertebrates@2x.png";

standardImage = "animal_11_terrestrialInvertebrates@2x.png";

taxonName = "Terrestrial Invertebrates";

},

{

highlightedImage = "animalActive_08_marineInvertebrates@2x.png";

standardImage = "animal_08_marineInvertebrates@2x.png";

taxonName = "Marine Invertebrates";

},

)

The brackets ( and ) mark the start and end of the array. It's important to note that the order of the taxon entries in the document is irrelevant; they are listed alphabetically in the menu.

The data for each animal is also listed as key value pairs. The following properties are simple key value pairs (e.g. species = sapiens)

  • biology
  • species
  • genus
  • order
  • family
  • class
  • phylum
  • diet
  • distinctive
  • distribution
  • habitat
  • identifier
  • identifyingCharacteristics
  • lcs
  • ncs
  • wcs
  • nativeStatus
  • taxonGroup
  • taxonSubgroup

The remaining properties: commonNames, audioFiles, profileImages, mapImage and squareCropImage require a little more structure.

An animal can have many names, so the value for commonName is always an array, even if there's only one entry. The first entry in the commonName array becomes the display name of the animal. So for Turdus merula, the key value pair is

commonNames = (Common Blackbird, Eurasian Blackbird,);

and the name displayed in listings is Common Blackbird.

The audioFiles, profileImages, mapImage and squareCropImage are also arrays, even though youll only have one mapImage and one squareCropImage. Each file reference has two properties, filename and credit. You can leave out the caption in the file references for mapImage and squareCropImage.

profileImages = (

{

filename=image1.jpg;

caption=Great Photographer;

},

);

mapImage = (

{

filename=map1.jpg;

},

);

When you put it all together, you get a document like this. This has been a fairly technical post, if there's anything that needs clarification, let me know in the comments.

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.