Chapter 5: Designing with Dashcode: using the Custom template – iPhone Application Development

5

Designing with Dashcode: using the Custom template

This chapter focuses on how to design an iPhone application using the Custom template within Dashcode. This is one of the most versatile Dashcode templates. It requires the most investment of advance planning of all the apps we will construct in this book. We will make extensive use of elements from the parts library. We have more freedom here to build something unique and offer highly functional application to our library users. And it is the most advanced web-based application designing we can do with the Dashcode module. It also requires that we really understand what is happening with buttons, JavaScript, icons, etc. For example, we’ll really start to understand and appreciate here that it is JavaScript that does much of the work in these applications.

Previous chapters, on RSS feed and podcast app templates, were somewhat limited in their functional versatility. We can only really make a podcast application with a podcast template; it is somewhat limited in that previous applications can generally perform one type of function. The RSS feed which we repackaged for the iPhone can pretty much display only the textual content of a blog or similar news-like web feature. The template of the custom app allows us to use anything (any of the parts and code we see) in Dashcode. What we’ve learned in the previous chapters is really a means to understand the parts. We will take the most useful parts from what we have already discussed and tailor them into a unique library application.

Figure 5.1 Choose the Custom icon for the template used in this chapter. Be sure to select only the ‘develop for mobile safari checkbox’

This chapter is going to use the phone element from the parts library and also experiment with a JSON data file. We can also add in a mapping element from the parts library if we anticipate making use of the library user’s position as a means to provide information. Scrolling through the Dashcode parts library we have many options to utilize and many elements we want; at the same time, try not to overwhelm your users with functions just because you can. Aim for functional simplicity. Some of the things that your library users might want to do can be addressed with these tools. Also, consider a combination of tools. Once you have read through this chapter it is a good idea to go back through and experiment with some of the other components in the parts library. You may want to revisit your video tour app and add on a phone element as well. Or use a phone element and an email element to begin connecting users directly to your services from the phone. The phone element can be used to connect iPhone users directly to your research desk and the email element could direct your users to a chat interface at your research desk, as well. Some email interfaces can be set up to receive and respond to SMS questions (e.g. Google Voice). With the tool developed in this chapter you can integrate an additional tool for reference services in your library or provide another means of library learning.

Design versatility and having the freedom to incorporate any manner of page elements is something that we’ve been building towards. By now, you will have the sense that Dashcode is a powerful tool for iPhone application development. Part of the power of this tool rests in the reuse of elements that Apple has already created for use. By now you’ve seen that designing an iPhone application does not mean you are starting completely from scratch. You have shoulders to stand on in your application development work; having these building blocks and a newfound freedom in the form of this Custom template to design as openly as we wish does make a significant difference for mobile design.

Functional tasks of the custom iPhone app

Given the range of possibilities for such a template, I’m going to go ahead and give it some much needed context by discussing user tasks associated with this template. What I’m going to design here is another kind of library service which is like an in-building tour using your mobile phone – but it uses the most basic functionality of your mobile phone, namely the dialer and the speaker, i.e. the voice portion. I’m going to be repackaging a mobile phone tour from my library. This tour only exists as a handout with a phone number. The user walks into the library, picks up the handout and then dials the tour number with their phone. The number they call has 14 mailboxes configured to support providing information to the user based on which stop they are at from within the building.

What I’ve narrated so far probably sounds like any self-guided mobile phone tour, popular in museum settings. At my library we’ve been calling this a cell phone informationpoint tour. I’m going to repackage the self-guided tour for the iPhone; the app will be named the infopoint app as information is delivered based upon your position within the library. The library has signs throughout the building and handouts to explain the tour, with a layout of the building, so in many ways the infrastructure of the building is already set up to support the functionality of the app. The tour itself is useful for those who haven’t been in the building before. A design consideration here is the concern for those people who are new to the library and desire independence in exploring the building. Many new students at university actually prefer to be self-sufficient in their information seeking – which means, like many people, they don’t necessarily like to ask for help, or rather do not consider the library to be an appropriate place to ask questions. This is too bad, because there is a range of support services the library can provide for the student, and what I’m trying to get at through the book, and in more than one application, is that by creating iPhone applications, librarians are engaged in bringing increased awareness to library services.

The design of the app will begin to incorporate some of the capabilities of the iPhone that gives it advantages over a desktop computer. For example, using the phone as a phone (making calls) and the number pad for in-building engagement is a good use of the ‘mobile’ part of being mobile. You cannot very easily carry a desktop computer around the building with you as you take a computer-aided tour of the library. We have the task of building a mobile phone tour set out before us, but I’m just going to go ahead and state that this is just one probable way to make an application with the custom template. You will want to allow for your own local user needs paired with the elements here to guide development of the custom application. It could be the case that something suited for one library population in central Illinois has little actual uptake for a library in London.

User narrative: envisioning how a library user will use the infoPoint app1

This section describes how we can pair those needs with a compelling mobile experience for the user. We have discussed in-building exploration – how a user can really make use of the infoPoint app: they already have a cell phone and they can already dial the number? The application we’ll develop as a repackaging of the tour actually makes it that much easier and convenient for the iPhone user to make use of the tour.

This application uses location in the library as a way to provide library information. After the user selects the building location, the tour stops are loaded, and note here also that there isn’t a need for the user to begin the cumbersome process of reading the phone number from the advertisement or the handout. On the second-level page, the stop information is already loaded onto their phone. The library user isn’t necessarily required to use this app in their library; they can take a phone tour from any location. As a result of the application’s functionality many students could actually have their anxieties about the library alleviated before they ever step foot in the building.

Dashcode workflow step 1: lay out interface

We have selected the template and are looking at the canvas of this template. It should look as in Figure 5.2.

Figure 5.2 This is a blank template we are starting from. It is highly customizable and there are many uses beyond the work we will do in this chapter. In other words, this is a template to come back to and experiment with

I’m going to pull from the Parts library a Browser element, as I envision users scrolling through at least one page level of to another. The browser element is familiar functionality for us because we have seen this from the Browser template chapter, but we need to do a little more configuring of its elements if we’re going to make it function as we have come to expect of the browser element. We’ll configure the attributes of this part below. Notice from the top navigator window that when you drop the browser element into the canvas you now have a ‘view one’ and ‘view two’ – that is, two levels of browser content here on the one html page. Most of the scrolling links to other parts of the page are actually accomplished with a handler, which then points at a JavaScript code snippet that we’ll configure for moving to the second level of content.

This is a mobile phone tour application, so I will need that phone element. I’m going to place this element on the second level of browser content. Using the parts library, take that green phone button and drag this element onto the canvas. Your users will want to know what they are calling when they push this. I have added a text box element in the second level browser page (LevelTwo). This text box can be used to incorporate any free text from a JSON element, and is also a deceptively simple element; it is actually quite versatile, as we’ll see shortly.

Figure 5.3 This should look familiar. The layout resembles portions of the Browser app

Additionally, this tour actually encompasses two library buildings, so to organize the pages to be able to scroll to additional levels of content, I drop in a Rounded Rectangle List – those bars for scrolling out as well. Finally, I want to see if this is a good place to respond to messages from my users (or rather have users be able to send an email from this app, should they have questions about library services or spaces). So, I’ve added in an email element button as well. This may be too noisy (too cluttered) for the application so in order to understand the amount of page elements my users can actually use, I will undertake observational study later of how users might make use of these elements. Figure 5.4 shows what my canvas screen looks like after I’ve incorporated these parts. It might not be the most functional of layouts but I can tweak these later after I’ve observed how library visitors make use of this app.

Figure 5.4 This is what the simulator models after I incorporate the data from the JSON array

Figure 5.5 The JSON data relation is working properly but note that the text is displayed in a manner that still needs formatting changes to be read more easily

Dashcode workflow step 2: add handlers and code

Adding handlers and code means we will configure what the parts will do when they are clicked on. For example, if you go forward and run the app in the simulator and take a look at how the list functions when you click on any of the list links, they don’t scroll to the second level. This is because we’re not working from a browser template (where the parts have been pre-configured to operate without any additional configuration from the designer) and we have to do a little more customizing and design work here than we’ve typically been accustomed to in a template. This section will show you how to make use of a JavaScript code snippet that will make the page scroll to the second level of page content [the place that we’re going to have our phone button, email button and other multi-modal/dynamic content (pictures, videos, etc.)]. For the scrolling code, go to the Parts Library and click on the middle tab, code tab. This isn’t too difficult because you don’t have to have any experience with programming to copy and paste the snippets of code.

Moving to other levels of content using Handlers and Javascript

Before I add the JavaScript code to scroll to additional levels of content, I need to tell Dashcode about the handler for the list element. A handler is what tells the browser what code to execute when certain actions occur. This is configured with the Inspector tool. To inspect the events that trigger JavaScript code, locate in the top portion of the navigator the list hierarchy. Just below the heading list will be the element listRowTemplate. Highlight the listRowTemplate element and click on the Inspector button. Inside the inspector window locate the tab at the far right, the Behaviors tab. Note the list of events which can potentially trigger a JavaScript action. On the right side of the column are the events, and on the opposite side of the columns are blank fields for us to write the name of the function that will be called when this event happens. We’re only going to concern ourselves with the event that happens when any of the three list bars are clicked. This refers to the first event, the ‘onlclick’ event. Next we will type in the name of our JavaScript function; I re-used the event used from the browser template: ItemClicked(event). The ItemClicked(event) is the JavaScript code that gives your application the scrolling effect and that will move the browser window from one section of the browser (LevelOne) to the second level of browser information. From the parts library select the middle tab, the code library. Scroll down to the ‘Go forward in a browser’ code snippet and then drag this part into the file called main.js. I placed my code snippet at the bottom of the file. The reason I placed the file at the bottom of this file is due to the nature of programming; I don’t want to interfere with parts already generated by Dashcode for the main.js file, so I’ll just add this code snippet at the bottom. The code needs to be edited, but not extensively: what you have to replace in this file is the name of the second level of page content; by default the second level of page content in a Browser element is called ‘view2’. Locate the code snippet text in your main.js and replace the ‘level2’ name with ‘view2’ (the name of your second level of content) in which the name after the comma is whatever you want the name of the second level of content to be; for now I have named my second level ‘call location’. Alternatively, you can also leave this second page un-named, so you could remove that second listed element, if you wanted.

To summarize: the above is the step-by-step process of configuring the handler and then pointing that handler to a function of JavaScript code. We then edited some of the placeholders within the existing JavaScript code so that the code would make sense given the context of the names of elements for your specific application. The code will only work properly if it is referring to the elements by the names they have in the application it exists within.

Associate a data source with page elements

We need to insert a Javascript file and mark up a JSON array so that we can link the item arrows with building locations. I copied the sampleData.js from the browser template to re-use here. All you need to do to incorporate that file here is to open the Browser template and copy the sampleData.js and then paste it into the Custom template.

From the previous chapter on the browser template, we have experience linking JSON elements to parts elements: we used a JSON array file to link videos to different parts of the browser, depending on what was clicked. With the list that we’re using in this app we have three possible parts to browse to. I am separating the mobile phone tour into two main parts that are dependent on library location. The first library location I want to bring users to is the Main Library Building, so that will be one main part of the JSON as I will model shortly. The second main portion of the mobile phone tour focuses on the Undergraduate Library Building, another building within the library complex. There is then the last portion of the list, which I’ve made a help page. Take a look at the example screen shot I am running from the iPhone simulator based on the JSON array I’ve modeled:

This is what the second level of scrolling looks like after you have clicked on the Main Library button.

This is the JSON array I used:

{

title: ‘Locations’,

items:

[

{name: ‘Main Library’, information: ‘8 Main Library, 9 Information Desk, 10 Reading Room, 11 Stained Glass Windows, 12 The Stacks, 13 Central Access Services, 14 - for Card Catalogs, 15 – For Bronze Tablets’, location: ‘Main’ },

{name: ‘Undergrad Library’, information: ‘1 Career Information, 2 Reference Collection, 3 Print Card Machine, 4 Video Collection, 5 Question Board, 6 Moving Shelves, 7 Magazine Collection’, location: ‘Undergraduate’ },

{name: ‘Help’, information: ‘stuff here’, location: ‘none’

}

]

}

What you will notice here is that I’m connecting each sublevel page with the mobile phone tour information. The two building locations have text strings associated with the name of the page, and there is also an image to display in the background depending on page. I’ve also made one of the JSON elements a help page and the information there simply explains what the app itself does. This may not be something that many people want to spend a lot of time reading. Mobile app design best practice is simply to go ahead with intuitive functionality and not require your library users to have to read a help file to understand the functionality of an app.

As you are now familiar with, you want to go to the data source icon and then create bindings to link the data structure with the page elements. You do this in the same way as linking the data structure from Chapter 4. To test that your data are linking properly, run the app in the simulator and double check your work. Once the parts elements are linked to the data properly, you are now ready to upload these files to your web server and test the application’s functionality with library patrons.

Iteration based on use

Be flexible enough with your design of apps that when it comes time to run a few user studies you can accommodate user feedback into subsequent versions. Be willing to make incremental small changes that will improve the user experience of the app: does it function quickly and easily to deliver simple access to information in an engaging manner? After observing users making use of our apps you should readily recognize the elements that clutter and the elements that add to the functionality of the app. Although the Dashcode module provides extensive customizability in the re-use of JavaScript code, button elements and the assortment of JSON data, we need to be vigilant in our design for ease of use.

Regarding iterating design for this specific app, you will definitely want to recruit someone to help you with user studies, which is to say a usability participant from your library, i.e. find a user of your library who owns and makes use of their iPhone. We cannot use an iPod touch to iterate design for this app. Also, your usability participant should not be you or anyone else who helped to design the app. They need to provide a fresh perspective of the interface. You may be thinking: ‘I’m the one who designed this iPhone app, why shouldn’t I be the one to test it out?’ Although you have placed a lot of your time and hard work in this app, it will be a drawback to the iteration if you do not have an unbiased opinion. Consider how exactly a user will react after finding your app in the iTunes App Store and consider when that user downloads it to their phone – that perspective of the first-time user to the app is the perspective that you need to iterate, as the person who will inevitably find and use your iPhone app will not have the same experience and expertise with it as you.

Test that the buttons make sense. One the first level page, we have three tabs – are the functions of those tabs obvious for the first-time user of the app? On the second level page, when your user has the infopoint iPhone app in hand, is it obvious that the green button loads the call interface? Pay attention also to when the user loads the phone interface – do they understand what is happening? Should there be additional explanatory text at the point where the phone interface is loading? It can be disorienting for the user when different components of the device are activated unexpectedly.

Does the infopoint tour work best in the library? If you are able to test how it might be used outside of the library it would be sensible to try to understand if the app works best for in-library exploration or if it is equally useful to users at a distance. Your design for the app may have been for only in-library exploration – if that is the case, perhaps just include a footer at the bottom of the app to indicate that the tour is best experienced in the library.

What I’m seeing from how users behave when they see the list of locations is that they are just all strung together, and it runs together in a way that is confusing. In order to address this cluttered nature of the infopoint stops I consult the parts library for something simple. I’m looking for a tool that can perhaps make the presentation of this list more comprehensible for the first-time user of the app. A list element may be more useful here.

The change I decided to make after collection feedback was to layout the interface again using lists rather a text box. Figure 5.6 shows the resulting screens of the app:

Figure 5.6 I decide to use a more streamlined look and feel in the next iteration of the app

The first change I made was to reduce the number of tabs from this first introduction screen. A more drastic change was made for the second level of the application (Figure 5.7). I decided to make each point on the tour an element of the list, making the stop locations easier to differentiate. This new layout will give users a clearer understanding of the app’s function. I tried to pare this app down to its essentials such that it only now exists as three screens of content.

Figure 5.7 Notice the stop locations now are more easily read by using a list rather than a box for text

Once you get to this level of iteration – where you’ve made changes based on user feedback and made a new design that users begin to understand – you can upload the app to the iTunes store with some certainty that the firsttime user will understand how it works.

Reconfiguration of the interface has the potential to make you think about the way you’ve structured the underlying data. For example, I had a JSON array with the entirety of the data I thought I wanted to present. The JSON was pushed in dynamically. When I thought about how I wanted to model the app I realized that I didn’t have to dynamically use a data source because these locations in the library will always be locations in the library and I could just make use of a standard static list. That is how I iterated the design here – I removed the JSON arrays from the final iteration. The data that I removed are not necessarily wasted effort; it was a useful modeling execise in which I got to think about the way I was presenting information and what the function of the iPhone could do with the data I was modeling. It is never a waste of time to think about the function and use of information within an interface.


1.This app is only for the iPhone; it won’t work on the iPod touch as this device does not have a phone element, although there are apps that skirt that problem with additional Voiceover internet infrastructures (this app is not one such). Finally, as a nod to future devices which Apple may develop, consider that there may perhaps be devices that are not a phone but are still able to make calls.