Basic Dashcode development: creating a Podcast application
In this chapter we will create a web-based iPhone app that includes in its functionality the ability to quickly access podcast content, i.e. the updated audio files of a themed online broadcast. We will do this by using the Podcast template, as shown in Figure 3.1. The purpose of this application is to provide your users with convenient one-touch access to a specific library podcast from the iPhone and other devices running the iPhone operating system.
Before designing consider the user tasks of the podcast app. A question you might ask is what are the requirements users have for listening to library-developed podcasts? Consider the podcasts’ availability: do your users get the podcasts from an iTunes link, your library website, another website or some other source? You might have user data about how users would like to engage with your streaming content by looking at analytical logs of traffic to your web servers. The manner in which your user group will want to engage with streaming audio content can be informed either by observed needs or perhaps a survey of tasks your users do while on their mobile devices. In other words: how do you know what the user tasks are of the application you are creating? – only through some sort of analysis of the way your users use library information. This can be accomplished informally, through comments from patrons at your library service points, or a more formal assessment by way of some kind of collecting of preferences and needs for streaming audio content.
The podcast app you create in this chapter will enable access to your library podcast that is in some ways far more convenient and accessible to users from the iPhone. The reason why this will be more convenient for your users is that even if they subscribed to the library podcast through a service like iTunes, it would still exist with the total number of iTunes podcasts you have subscribed to on your phone. The app on your iPhone’s home screen is a direct point of access to the podcast content. It enables a sort of one-tap listening to podcast content.
The reason why you don’t want to point to a podcast from a regular standard desktop PC-type webpage is because this will display poorly on the iPhone. The user will have to scroll around to try to see what files are available. Some browsers will not reformat to the mobile browser; and those websites that do not auto-detect and then reformat for the mobile screen make the assumption that the user has a desktop to which files can be downloaded, which is not quite the case as regards the functionality of the iPhone.
The iPhone does have support for YouTube by including a native YouTube app (included as a standard with the phone, the features of which support mobile browsing of this highly popular video website). If your library has a YouTube channel where you have a video presence, you can be assured that mobile-friendly access to your already created content is possible from the iPhone.
Concerning the iPod player within the iPhone, the iPhone functions almost exactly like an iPod; you can subscribe to podcasts from the iPod app running inside the iPhone. The dedicated podcast iPhone app on the home screen is a compelling marketing tool for your library given that your marketing material can include as a selling point the new feature of having the ability to access a library podcast as an iPhone app. The difficulty in putting this podcast together is minimal, with a few framing theoretical concepts to help us along.
In order to create the iPhone app of a podcast we are going to be drawing on the data independence paradigm as a means for understanding the fundamentals of XML, but again the iPhone templates are already designed so we do not have to concern ourselves with too much information modeling. The treatment here of data abstraction will be sufficiently inclusive for you to understand the basics of creating an XML style sheet that essentially describes and makes available the podcast to the iPhone app.
Remember that RSS is marked up in XML, and one way to subscribe to a podcast is by way of an RSS feed. You will notice similarities between the RSS application and the Podcast application. If you have understood the conceptual underpinnings of Chapter 2 you are well versed in the application of data abstraction to an XML file.
What is a podcast? Podcasting is the syndication of an audio file which revolves around a specific theme and in which each discreet mp3 can be thought of as an episode of the podcast. In order to describe this content, we are relying on the method of utilizing an XML-encoded document that describes the elements of our podcast. We are describing the title of the podcast, the date available on the web, the location of the mp3 file (where on the web it is streamed from, usually a location on your library’s server) and additional descriptions of a podcast in the XML elements. All these elements are parsed when encoded in XML (that is, read by your browser or another software component, like the Mobile Safari Browser). This enables re-use of the podcast program for multiple platforms or devices or any other kind of information system that reads XML-encoded data, i.e. across nearly all modern networked computing platforms. This podcast application differs from the RSS application in that this template has the functional purpose of existing only for streaming files like mp3s whereas the Dashcode provided RSS template is suited for textual content, like the contents of a blog, or as we used it, for a new titles feed.
If you have an XML feed configured, you can go forward to the next section; we can use a template from Apple for creating our XML feed. The Apple website has a Podcast XML sheet available that we can use for this project: http://www.apple.com/itunes/podcasts/specs.html#example. You can copy this style sheet (all of that markup in XML) to any document editing program you have and modify the elements from there. For example, I have heavily modified the XML set < item > where between the item start element < item > and where the item element ends, </item >, we should go through and modify the < title > tag and importantly update the < enclosure url >; these are the most essential tags to modify. In addition it is a good idea to modify the date the podcast was published, which exists in the < pubDate > element. As this is a book on iPhone applications rather than about making podcasts, we will not spend too much time on the process of actually authoring this podcast. There are many sources available online which you can draw on for podcast information. Appendix 3.1 covers a few basics with regard to creating a podcast. And see Appendix 3.2 for the XML style sheet.
You next need to save the modified XML file with a filename of podcast.xml, and then upload your modified XML file to the server which will host the application. You have now satisfied the requirements of the URL property (which requires the source of the RSS feed to be the same URL). The XML style sheet describes for the application the minimal information required here for display: the title of the podcast episode as well as the date the episode was available, and the source of the mp3.
Select the podcast template in the Dashcode program. Let us start by considering cosmetic-level parts of the application. Let’s take a look at what we have in the canvas and think about how someone might use the links provided. The interface is not particularly colorful to look at but it is very simple.
Apple does a phenomenal job creating simple interface layouts; the result is that we really have been quite lucky with interface design. Should you choose to add color to your application be aware that this will impact its usability – your users may implicitly believe that a given color may represent something other than what you had intended. Consider what red and green mean as properties of allowances (red for stop, green for go). As always, gathering iterative feedback is recommended to gradually improve the functional utility of an application. These are the steps for changing the color of your Podcast web app:
3. Select the section in the upper Navigator, on the left column: the portion of the view which you need to edit. In the example in Figure 3.3 you can see that I have selected the content portion of the webpage.
4. From within the Inspector window select the fill and stroke tab. Next there is a drop-down box Fill. The default setting will be none. Select color from the menu. Here you can alter the background color of the content part of the browser. Notice in the inspector window you have the words ‘fill & stroke (content)’, which relates to the portion of the webpage that you are editing. Note that the color will not change for the heading or the bottom portion of the web page. Or, if you are editing a page that has multiple levels (most of the templates in Dashcode do have multiple levels), you will have to go through and configure the color for each individual portion of the page.
Another portion of the canvas screen that is configurable is the bottom of the interface. The interface reads by default: Developed with Dashcode. This text can be modified. Think of what the user might want to see at the bottom of their limited screen. They may not know what Developed by Dashcode means. This sentence might be confusing to them, but this will depend on your user population, so consider the population you regularly work with as you modify this portion.
Locate the step-by-step boxes for completing this podcast in the lower portion of the Navigator window. The first step that Dashcode asks you to complete is, ‘Provide Podcast’. Click on the link and you will be taken to the attributes window where you can then input your podcast source into the Podcast URL field. As we will be running this application from our server, we also need the XML feed to come from the same URL.
There are now only a few more application attributes to configure: the viewport and the custom clip. The viewport orientation as mentioned in the RSS chapter simply refers to the page orientation if the iPod or iPhone is rotated 180 degrees. It is my view that ‘adjust page width to fit’ is sufficient because it offers the mobile user the simplest web browsing experience for our purposes.
We will now configure a webclip icon for the application. The webclip icon is the image that is saved to the iPhone home screen when a web safari app is bookmarked there. If you leave the default setting on, then Safari will assign a webclip to your app, a miniaturized shot of the application on the app page.
It is simple enough to place an image from iPhoto into the web clip icon from the canvas view. This file is then included into the set of files you will upload to your server after you have finished designing the app.
Consultation of the Dashcode help guide will always provide the most up-to-date information about the configuration and functionality of the webclip icon. At this point in the Dashcode version 3.0, if you are making a full screen app then you are going to be accessing the application from the home screen. This will require you to provide an icon.
This is where we upload the files that Dashcode generates. To generate those files, in the Test and Share window click on ‘Save to Disk’ and then create a folder for these files. If you have not already done so, make certain that you have uploaded your XML document (describing the podcast feed). You can also find many services online that will create the feed for you, but as we know from working with the Dashcode developer kit, the podcast feed must be hosted from the same URL as the web app. Testing and sharing should also be a familiar Dashcode workflow step for you by now. Your app is now available to users who access the page from their mobile Safari browser. Should you want to make this app available on the iTunes App Store, the next step is to use the Xcode module of the iPhone SDK as well as the PhoneGap framework. This is covered in Chapter 7 and 8.
You iterate design on the podcast app by asking app-specific questions that would work to uncover what the roadblocks are for ease of use. You aren’t necessarily looking for successful comments about the app, but rather what isn’t working. Is it obvious that when you click on the track it will load a podcast? Perhaps the app will need explanatory text – or you can create labels that make the track obvious as a podcast track. For instance naming the track ‘track name (click to play)’ helps to make its use more obvious.
The date notation comes standard in the template. It might also be worth asking if date notation adds to the users’ understanding of your library’s podcast. It may be that your podcast is really just a three-part cast and you do not intend on further updating it. If this is the case, you might consider pulling out the date element of the app. You are by no means required to make use of every part of the template that Apple provides.
We have made changes to the color in this app. Do such changes have any effect on usability? It makes sense to consider if the text of the app remained readable after any color changes. The background colors you choose will either enhance the users’ ability to read the text or will take away from the usability; if users of the app do not comment then the color may be fine and you don’t have to spend a lot of time tweaking it.
Do your users expect something else from the app? What I mean by this is you may have inadvertently left some parts out that your users will point out to you – just explanatory text or even images. Be on the lookout for elements you may be able to add that will increase the functionality of the app.
If your library already has a library tour in mp3 form, you can take this mp3 and chop it up into a series of mp3s which would then be used to populate your Library iPhone Podcast application. Your choice for re-using already existing library mp3s will rest on several variables. For example: do you have content that is suited for delivering to a user based on their physical location in the library? If your content is somewhat location based, then it is a sensible strategy to think about putting in into a podcast app. As you are basically working from a Mac you can reasonably use the tools included in your Mac, the Garageband tool, that can be used to edit an mp3 file. In order to create chapters for the podcast, simply take the mp3 and create sections of it within the Garageband tool. Should you need to create podcast content from scratch, use the Garageband software tool and record a Podcast; the process is easier than creating web-based iPhone applications. In order to develop any kind of podcast app featured in this chapter you will be required to have at least three mp3 files which you can upload to your server and that we can reference in our XML feed of the podcast.
This is adapted from http://www.apple.com/itunes/podcasts/specs.html#example.
< enclosure url=‘http://sif.grainger.uiuc.edu/podcast/ht docs/test1.mp3’ length=‘8727310’ type=‘audio/x-m4a’ />
< guid >http://example.com/podcasts/archive/aae20050615.m4a </guid >