Designing a Utility application with Dashcode
This is our final chapter on Dashcode Application Development. After we explore this Dashcode module, we have worked from all the available Dashcode templates. Getting this far in application development is an accomplishment you should be proud of. Take a look at the canvas view of this app.
It may not be readily apparent what you would be able to do with the Utility template. As a utility app its utility is unclear as we have not specified the purpose of the text area. In order to get a better sense of what was intended, we can consult the templates menu – Dashcode describes the utility app as, ‘…a Utility application has a front view you can customize with items from the Library window and a back view you can use to display settings or useful information.’ I think the key to understanding what the application can do for you is to hit the Run button in the Taskbar and launch the blank template in the iPhone simulator.
Note that the description (basically we have a window with a front and back view) is holding true, except the second level of content is not quite what we’re accustomed to seeing at another level of content. We’re usually seeing a scrolling effect to a second level of browser information. The effect here is a little different (the screen flips to a second level of content) but you still understand its basic functionality; the Utility app provides an interface for typing in text. This is very basic functionality and we’re not going to be doing too much configuration with what already exists. What we now understand about mobile computing design and delivery is that fewer objects on an interface means more easily navigated apps.
One probable way to make this a utility app for library service would be to build it as a sort of suggestion box for the library. What I mean by this is a place where users can drop in ideas for the library, a digital ‘notes’, but in this app we’ll be taking suggestions via email. For simplicity I am going to be designing an iPhone app that lets iPhone users give their recommendations for books or other content the library should order. The functionality of the iPhone is such that when you select a text field, the keyboard interface is loaded and you are then able to start typing in your free text. The means by which the typed information is emailed to the library is to have the user copy that text from the app text field, tap the email button (which we will add) from within the utility app, which loads your library collection email address and, finally, the user then pastes their requested library collections into the email.
Figure 6.3 provides an example of what the finished app will look like.
The elements you see in the lower portion of the screen are not application-specific, but rather portions of the mobile Safari browser screen. The top portion and the bottom portion of the screen are actually browser elements. Should you choose to run this in full-screen mode, you will be running the application without those top and bottom bars. Perhaps the buttons on the lower portion of the screen are intuitive. If you haven’t had any experience with the mobile Safari browser, consider the following as your introduction: the right and left are forward and back arrows of the browser. You get the equivalent functionality from standard browsing. The plus button is the button that adds the page as a bookmark – so you can add this mobile Safari page to the home screen of your iPhone if you wanted, and it would act, for the most part, as any app that you downloaded to your iPhone would act. The open book next to the plus button is your bookmarks – if you don’t bookmark the app to your home screen, this is the other location where you can access your bookmarks. Additionally, the screen next to the open book – or the icon to the far right of the screen – lets you open additional browser windows, akin to opening additional tabs in your browser, clicking that button lets you access the other pages you have open or gives you the option to open a new browser page.
By loading this app onto their iPhone or iPod touch, your library users are able to tell you (at anytime, but also precisely at the point of need) what to order for the library. The user can communicate a collection need at any time and from pretty much anywhere; they don’t have to be in the library to deliver to your suggestion box suggestions of things to order. The good news for you is that your users are able to directly contribute information to inform library collections decisions. The user basically has more engagement with the library selection process. Even if your library is unable to make acquisitions in every area suggested, you will still be able to gather useful feedback about library service. The library user could be watching the news, listening to a report, reading the paper, any of these things, and hear about some new possible information resource – a new video, or book that will soon be available in bookstores (or, more basically, a topic such as healthcare reform); they click on the iPhone app they have for suggesting library collections and then type in the title of the resource they want. Because you have their email address, you can also follow up with an email when the book becomes available for checkout. You can do other things with the information you collect from this iPhone app as well. Think of in-house library collections that you currently have: you could take the suggestion box information as a way to examine the way you advertise your collections. One way to advertise your content is by making this available on your main library webpage: you could build a ‘collections spotlight’ based on the information you receive in this app. Subsequently, in order to supplement the online environment and the in-building experience, you may want to make available a display in the library that shows your users the books (or other collections) you have on a topic that you want to tell other users about.
A user picks up their iPhone and types in a resource or set of resources they would like you to purchase. Perhaps you go ahead and make that purchase; you may also, in the same week or month, put together a library display on that topic and say ‘Here are additional books about Ireland’, and your users who have suggested travel books on Ireland will have truly influenced what their library looks like. The user of the app will then be more inclined to participate in the suggestion process – and in turn you are going to have a happier, perhaps more fulfilled library user base. Let us configure the application interface here and then connect the pieces to make the iPhone app suggestion box a reality.
This app is very simple and has very basic functionality – the essentials are definitely what you want to aim for in mobile application design. I want the users of this application to suggest a purchase for the library. I begin by changing the default text in this main canvas screen. I will replace the text box ‘Tap to enter a new message …’ with a new default message for when the app is loaded. I want it to be a quickly understood message for the user, so I enter in the new phrase, ‘Suggest a purchase here.’ and also at the top, in the heading field where is currently reads ‘Utility’, I replace this with a heading that better explains the purpose of the app, ‘Suggest a Purchase’. Finally, there is one additional parts element I want to use for this app. From the Parts Library I drag the email element onto the app screen and drop that at the bottom, just below the text field. We want to configure the email button so that it will send the suggested purchase email to your library collection email account. This is done by clicking on the Inspector tool when the email button is highlighted. Locate the Attributes tab for the mail button – described at the top of the inspector window as Attributes(mailButton). The bottom of this box has the fields for Recipient, and Subject; see Figure 6.4 for the exact locations to place your collections email address and the subject of the email.
Providing settings from the Navigator refers to the ‘reverse side’ of the application. I have highlighted the page in hierarchy in Figure 6.5, showing the settings page in Canvas view:
From the Inspector tool you can modify the elements of this page – i.e. changing the color of the text responses – or from the library you can drop additional buttons here. For the functionality of the app I am building, it’s important for users to be able to quickly communicate what they want the library to purchase. So, I’m not too concerned with adding more elements here now. Perhaps your app will have a different kind of functional application for users, and if that is the case, then you should go ahead with adding pieces that make it easier for your iPhone app users to do the things which this app is intended to perform.
You have by and large accomplished all that is required for the app to work as described in the narrative. Go ahead and run the app from the simulator. If you want to practise actually sending yourself an email from this app, you should upload the component files to your server and then access the web-based app from your mobile safari browser on your iPhone or iPod touch. Also, if you will be planning iterative use studies, you definitely need to have the app available online so that other library users can have a chance to test out its functionality.
Iterating design should be a recognized part of your application development strategy by now. Because it is fairly straightforward to go back and readjust layout, or even to rethink functionality – consider making small changes as a result of your user observations so that you can align the design of the app with tasks that the user will actually complete using your app.
Another way you can iterate design is to use analytic software to tell how your app is being utilized. There is freely available software at http://www.supercrazyawesome.com which is simply an application analyzer for the iPhone. Or, alternatively, because the web apps for the iPhone are run from your server, you can also run server-side analytics to understand how your library users are accessing your web-based iPhone apps.
What exactly happens when users find an iPhone app that lets them suggest a purchase? It is important to see what users think the next step for the app is – the app is quite straightforward; it just records the text that users enter into it. Again, probably not a lot of explanation goes into this app – it could be a great public relations tool for your library if your library users value having a library presence on the iTunes App Store. It could also be the case that there isn’t an especially eager user population looking for this basic-level iPhone app.
For you the developer, this could provide a good case on how to get an app onto the iTunes App Store. This chapter gives you probably the easiest opportunity for designing your app and you can then perhaps spend your development time understanding how to use a tool like PhoneGap (the topic of Chapter 8) to get your app onto the iTunes store. The submission process to the iTunes App Store is not difficult but is somewhat process-heavy – so if you’ve been avoiding the App Store because the app design has been labor intensive, perhaps here is your chance to begin uploading an app that doesn’t take too much design time; you can focus your application development efforts on the process of getting the application available on the iTunes App Store, the subject of the next two chapters.