Beginning Dashcode development: remediating an RSS feed to the iPhone
The iPhone SDK will not install to a computer that is not running a Mac operating system. Utilizing the resources of a Mac computer are important for accomplishing much of the work discussed herein – as we may need to draw on iPhoto, iTunes, GarageBand and iMovie. Knowing a little about each of those tools makes your toolkit for iPhone apps much greater. You simply need to have the Mac and everything it usually entails, such as the iLife suite of software. With only a little creativity on your part those tools will help you do incredibly useful projects for your library anyway.
This book will model the design of iPhone apps by using the Dashcode templates provided. Each Dashcode template holds the potential for creating powerful library applications; the perspective of this book is one of aligning available functionality of iPhone apps with user needs. We do not try to retrofit every library access tool or library service to an iPhone interface. The philosophy for iPhone development used here is one of re-engineering services for easy and quick access – the iPhone is a tool best suited for certain quick tasks – and not every task of the library can be remediated in exactly this manner. Nor would a library mission be completely served by solely relying on the iPhone to do all its work.
The first template explored in this book is the RSS application. Before remediating an informational RSS source web feed to the iPhone, let us consider its attributes and associated user tasks. RSS is a way to syndicate frequently updated online content. Syndication makes it easy for the user to retrieve notifications of an updated website. There are a few library catalogs and e-resource management tools which also create RSS feeds for searches and other kinds of electronic content. Another popular use of RSS is to syndicate blog content. Library blogs have multiple associated user tasks. A user may want readers’ advisory notifications, library events, upcoming library tutorials and workshops. Additionally, there may be patrons of the library user community who would rather receive an RSS notification of new titles of books, the example we will work from in this chapter.
We begin to put into practice the frame of data independence as we consider how RSS achieves its extensibility and portability to other systems. RSS is marked up using XML, and that XML file supports extensibility. This means that you can use the marked up RSS content as the content for this iPhone application. RSS as XML achieves data independence: it is designed for portability. If your library has encoded content in XML it has taken a step toward data independence and potentially more efficient systems.
One way to gather user needs is through focus groups. A topic of these groups might be to uncover ways to improve library services. Perhaps there are services to discontinue, or services that require additional functionality. A focus group dedicated to iPhone service might uncover the desire among library users for a way to view new titles in the library collection. Perhaps through focus groups and observation of users in the library you’ve also learned that use of the iPhone has increased among your user population recently. Collecting these data at the start of the iPhone application development helps to ensure you are creating a tool the library user population desires. Ongoing user requirements through additional library user input helps you, the designer, periodically verify user requirements. I’m arguing here for user feedback as a basis for iPhone application development. This is referred to in the engineering literature as iterating design based on feedback.
The strategy used here to illustrate the need for library services developed for the iPhone is to present compelling narratives of use for mobile devices. Consider the university student or library user who owns an iPhone or an iPod touch. An iPhone with a data plan means access to the internet at any time. Also, if the user has an iPod touch, they too can very easily access the internet at pretty much any time they are near a free or open WiFi connection. Users of mobile computing technology are nearly always connected to the online environment. Studies have shown that younger people in the United States spend a majority of their waking hours online – in fact one recent newspaper reported this fact with the headline: ‘If your kids are awake, they are probably online’.1 Such users have the ability to be always connected to information resources. I see the landscape of information seeking as one that is overwhelming and fractured, and consequently those users of mobile computing technology will not seek a library website as their primary starting point in their search for information. The reason for this is that mobile reference sources such as Google formatted for a mobile browser (or another mobileformatted search tool) gives users almost exactly what they are looking for with little trouble. If your library had compelling, easy-to-use applications, perhaps the landscape of information search may find a ready filter and make ubiquitous data access a manageable activity. Your user may chose a library resource over open web content if it better suits their exact information need.
iPhone applications are simple to add to the device. An iPhone app is not a particularly large file – meaning they don’t take up much of the user’s precious hard drive space, and do not trouble the user too terribly to download and install onto their device. Apple has made downloading applications to the iPhone seamless with the integration of the Apple iTunes App Store into the iPhone (or, iPod touch device). Consider the library patron who truly loves your newest books, would definitely come into the library more often if they knew what newest material was available before they visited, and if they had access to such information while waiting for the bus, for example. Perhaps this user does not have time to come in and physically browse the shelf – so they load onto their device a library iPhone application which delivers to them a listing of the most recently added items to the library collection, they use the iPhone’s multi-touch screen to scroll through all of the material at the touch of a finger and, if they so choose, they can request the item to be held for them. Designing such an app acknowledges that your users are people who have limits on the amount of time they can spend in libraries, or the amount of time they can spend even thinking about visiting a library. This application quickly delivers information about the material which is just added to the collection; and because you are continually updating your library’s collection, the app is dynamic: when the user goes to scroll through it a week from today the chances are that they are looking at all new content, again. All of this has been made possible because of the app we will design in this chapter, the remediation of an RSS feed of new titles.
Finally, I would commend a method whereby at some level you have asked your library population of iPhone users what tasks might be remediated to the iPhone and perhaps even gathered requirements of RSS notification services of your library – perhaps even by way of informal observational analysis of some portion of your user group. My library has discovered our users make heavy use of the virtual bookshelf feed: an RSS feed of recently added titles. I will design in the next section this virtual bookshelf as a web-based iPhone application.
When you launch the Dashcode program you will be prompted to select a template. The web application templates to select from in this version of Dashcode (3.0) include: Custom, Browser, Utility, RSS and Podcast. Select the RSS template.
A note about what we are seeing in the design screen. I will use the same terminology as used in the Dashcode User Guide (the help documentation included in the Dashcode module – search on any help topic while in the Dashcode program – this is the guide that it searches). The Dashcode User Guide refers to the main part of the screen as the Canvas. You will see the template of the app titled ‘My RSS Feed.’ The program defaults to Canvas view; this is how your application will appear on the iPhone. This Canvas view is a ‘what you see is what you get’ (WYSIWYG) editor.
In addition to allowing us to design the interface for the application (the view of the app before you have added any content or function), you also can run the blank application as soon as you load your desired template. You will frequently want to use the ‘run’ function provided here (the green arrow in the top left corner) in order both to see how the application works and also as a means to check how your design changes affect the performance of the application. In fact, although it won’t be spelled out step by step in the remainder of the book, the best way to observe your work as you design is to run the app (at any point in the design process) in the iPhone simulator.
The method of design used in this book is to customize the look of the canvas first, and then go back and connect the other details of the interface. This is akin to sketching out the app before you connect the dots and fill in all the lines. Let us just jump in and do some editing to the canvas screen (we’ll get to the step-by-step workflow after making a few necessary cosmetic level changes). To make a New Books App we will rename the generic feed titles. To rename, click in the Canvas the text ‘My RSS Feed’ and change the name to ‘New Book Shelf’ or another name that indicates to your users the information that the RSS feed provides – it’s probably best not to use terms like RSS feed when talking to a general user population, who might not have any idea what this means.
Continuing our cosmetic approach to designing in the Canvas: use the hierarchical icons in the upper left column, or to use Dashcode terminology, the top Navigator (by way of explanation, the whole left column here is referred to in the documentation as the ‘Navigator’). As you will notice there is a top portion to the Navigator and a lower portion. The bottom of the Navigator, which has tiny icons, is called the ‘bottom edge of the project window’ in the documentation. I have marked up in Figure 2.2 the Apple-provided terminology. You might want to flip back to this image until you get comfortable with the terminology.
From the top Navigator, select the ‘Article Page’, a level additional to the application view that needs to be configured. Closer examination (expand all the triangular icons) of the content hierarchy of pages (referred to as StackLayout, in the top portion of the Navigator) reveals this application as consisting essentially of two levels: frontPage and articlePage. Again in the Canvas, edit the buttons at the bottom of the new books application to reflect the functionality of the application. This application is not actually pointing to blog posts; these are not news articles, but titles of new books. I modify the button from ‘Back to Articles’, to ‘New Books” Additionally, the forward button labeled ‘Read More’ is edited to read ‘Request Book’ to give continuity to the functionality from the RSS feed page to the online catalog where users can request the book be held at a library of their choosing. You will want to edit these buttons as appropriate to the functionality your RSS feed provides.
The Dashcode module, by default, will show in the lower Navigator the workflow steps. These workflow steps will walk us through the four steps to configure and launch this web application. The steps (provided by Dashcode) are:
We begin step 1 of the workflow steps by selecting the first box: ‘Provide an RSS feed’, and adding the source RSS feed into the ‘Feed URL’ For this example application I am making use of a feed developed independently of the iPhone SDK. This example feed was generated using data from the library’s online public access catalog. If your catalog software has the ability to output recently cataloged titles as an RSS feed we will use that feed here. Your library systems may have alternative ways to generate RSS feeds from the online public access catalog. Wherever you get your source feed, be certain that if the source changes you modify the change for this application as well.
The next task is to configure other attributes of the application. The title that the module requests here is the title of the webpage. In choosing the title of the webpage, consider that this can be different or the same as the title of the RSS feed. The title you choose will depend on what you want your users to be able to do with the application. In most cases, the lower cognitive demands your application make of the user, the better the user experience. I’ve added the page title, ‘UGL Virtual New Book Shelf’, and used the name UGL as an abbreviation for the library: Undergraduate Library.
Configure the orientation attribute (under the Viewport heading) next. The orientation attribute concerns how the screen should redisplay should the iPhone be rotated 180 degrees. You can choose to have the screen adjust (the first option) or you can have the screen stretched for the new orientation. When in doubt about iPhone application functions, aim for the simplest functionality. Complicating the application with unnecessary scrolling demands will make for poor user experience. After you have developed a prototype RSS app you can decide to come back to these attributes and configure again for simplicity. Alternatively, if you are unsure about how a checkbox might affect the performance of the app, go ahead and run the app both ways in the iPhone simulator and decide for yourself which would help achieve your specific user tasks. I have found it helpful to upload the files to a server and then try the web app out from my iPod touch and other devices, in order to understand how certain configurations affect performance of the app.
One crucial development point to keep in mind is that your iPhone application requires the RSS feed and the URL source of the HTML to be served from the same domain. This means that the URL you provided from the application attributes step must also be where you finally host the web application.
What do I mean by iterating design? Nielsen recommended this method of iterative design in a classic article from 1993, and this still rings true today: ‘Iterative development of user interfaces involves steady design refinement based on user testing and other evaluation methods. Interface designers complete a design and note the problems several test users have using it. They then fix these problems in a new iteration, which they test again to ensure that the "fixes" did indeed solve the problems and to find any new usability problems introduced by the changed design.’ 2 This is the process of fine-tuning your app. Iterating does not have to take long, actually you can do this in a day or two – just find users in your library with an iPhone and ask them for five minutes of their time. It’s actually good public relations for your library users if they see the library reaching out to their user group to get their input on new services. You might offer a gift card in return for their participation. Most iPhone users would welcome the chance to add additional functionality to their phone. It is relatively easy to make quick changes and re-deploy the web-based application; I would recommend gathering about three to five people who would be using the application and ask them to use the application for its intended function. Usually you will be able to make changes to the application, either in wording of sections or display of content, that will improve the desired functionality of the application. Often the way designers perceive a use for an interface will not seem as intuitive to the user. Best practice in interface design recommends that we make low cognitive demands of the user; we are aiming for simplicity. The RSS template is formatted for the iPhone, so that a user on the iPhone will not be required to do extensive scrolling to size the page to their phone. The application already points to the source website so there isn’t a need for extensive input from the user. You’re probably wondering what exactly iterative design might resemble. The next section provides an example of questions you might ask and changes you might make based on iteration.
There are specific attributes of this app that you will want to perform usability tests upon. For example, are there components of the RSS template that do not make sense to your user population? Did you replace wording appropriately? Has the Dashcode module set this up as a way to remediate your blog content correctly? Suppose that you are not remediating blog content but instead are pulling your RSS feed for new books, as we did here. There will be word choices that may not make sense. You will want to watch someone from your library make use of the app – ask them questions about the wording and see if the utitlity of the app is coming through appropriately.
How many titles should be displayed up front? Do your users want to see more or fewer options when they open the app? When they load the app is its function apparent? Do users understand how to make use of the app for its intended function – to tell them about new titles?
Let’s also consider the second level screen of this app – one thing I did after showing this app to a few users was to remove elements that I thought took away from the presentation. At first the screen had displayed information as the ISBN of the new title and the fund code of the book (essentially a purchasing tag). I thought that the fewer number of attributes displayed, the better – so the essential elements such as location of the book and the call number of the book were left in the interface. Non-essential parts of the interface would have been left in if actual users had not actually looked at the app and commented on the available features.
You load the app onto the user’s iPhone and ask them to try to find the new books. By iterating design using the above questions you will be able to identify those parts of the application interface that confuse the user. When you have identified a part that does not make sense (perhaps in the wording of a button), make a change to that part and then re-test your app on another user. Particularly for this RSS app, either you will improve its ability to let users know about new books in the library, or somehow the change will take away from the intended utility. This is why you want to make incremental changes. You will be looking for the effect of your change in the next user, so to understand the effect, you have to change just one variable – if you start to change numerous buttons and attributes, you won’t be able to isolate what has added to the usability of your app.
There is more than one way to host your app. What we’ve essentially created is a web-based app that can be bookmarked on your users’ home screen of the iPhone, and functions exactly as any app on the iPhone would function. In a sense these web-based solutions allow you to bypass the iTunes App Store if you don’t want to use such a mechanism. Alternatively, we can make this app available by way of the iTunes App Store. The iTunes App Store is a great way to reach a larger audience for your app. Chapters 7 and 8 provide step-by-step instructions on uploading this app to the iTunes App Store.
Dashcode User Guide, iPhone Reference Library Webpage, http://developer.apple.com/iphone/library/navigation/index.html
1.Lewin, T. (2010) If your kids are awake, they’re probably online. The New York Times. 20 January, available at http://www.nytimes.com/2010/01/20/education/20wired.html (accessed 14 September 2010)
2.Nielsen, J. (1993) Iterative user-interface design. Computer 26:11, 32.