Customizing an Existing Site for iPhone

This article uses LassoSoft's ListSearch Web site as a case study to create a customized Web site specifically for iPhone users which provides access to the most recent messages that have been posted on the LassoSoft mailing lists.

Introduction

The iPhone, iPod Touch, and other sophisticated smart phones are bringing the full experience of the Web to mobile devices. It is no longer necessary to write Web sites in WML or using simplified HTML in order to display properly on these screens. A Web site will render the same in the Safari Web browser built into the iPhone as it does in Safari on the Mac, or even on Windows.

However, if you want to make your Web site the best experience possible for your mobile users then there are some steps you can take.

- First, ensure compatibility with the mobile user's Web browser. To ensure compatibility with the iPhone you should make sure that your Web site works with the Safari 3 Web browser, avoid plug-ins like Flash and Java, minimize the use of images, and use best practice CSS-based Web design when possible.

- Second, you can optimize your Web site to provide a better experience for the mobile user. Decorate URLs for phone numbers and addresses so they automatically dial or bring up the Google Maps interface. Use Safari-specific "webkit" CSS rules to specify how your site can be minimized and maximized.

- Third, you can provide a Web site customized specifically for the mobile user. The user can be made to feel that they are using an application rather than a Web site. Allow the user to access the core information your site provides without navigating through the layers that you provide for desktop users.

This tip uses LassoSoft's ListSearch Web site as a case study to create a customized Web site specifically for iPhone users which provides access to the most recent messages that have been posted on the LassoSoft mailing lists. Future tips of the week will cover other aspects of optimizing existing Web sites for mobile users.

You can visit the iPhone interface for ListSearch at the following URL. The Web site should work in Safari 3 on any platform. It does not work well in FireFox or Internet Explorer.

http://www.listsearch.com/iphone.lasso

This tip of the week is based in part on the iPhone Tech Talk "iPhone User Interface Design". You can watch a video of the tech talk or read much more about all the topics in this tip at Apple's iPhone Dev Center.

http://developer.apple.com/iphone/devcenter/

The ListSearch "iPhone Site" uses the same user interface which was presented in the previous tip of the week "Create an iPhone Site Using Lasso and the iUI Library".

Designing the Web Application

Our goal is to create a mobile user version of the ListSearch Web site. We will explore how best to do this in three stages.

- First, we must identify what we want our Web application to do. What functionality to we want to provide to the mobile user? What is the most essential information our Web site provides to user's on the go?

- Second, we will design the desired workflow for our Web application. How will we group the available information? Will we organize the information into a hierarchy? How can we streamline the workflow to require as little difficult user interaction as possible?

- Finally, we will create the actual Web application. We will implement the workflow as a user interface using elements like lists and buttons which are familiar to the mobile user. We will craft the appearance of the Web application so that it feels like an "application" rather than a "site".

Identify the Solution

ListSearch is a site which allows users to manage their subscription to LassoSoft hosted mailing lists, to browse through recent threads and messages, and to search the mailing list archives.

http://www.listsearch.com/

When we think about the mobile user, they are not likely to want access to all of these features. A mobile user is going to pull the iPhone out of their pocket and use it for a few minutes a session. They want to find useful information quickly. They don't want to be bogged down by a lot of navigation and extraneous options.

For example, how likely is it that a mobile user is going to want to subscribe to a mailing list from their iPhone? Is a mobile user going to want to search the archives or just access the most recent messages? Is a mobile user likely to click on context sensitive ads?

In order to identify the solution which our Web site represents it helps to write an "Application Definition Statement". We should state the intended purpose of our application. Once we come up with this statement it will help us determine what functionality we need to provide and what functionality we can omit.

At its core, ListSearch provides access to the discussions for the user. We can adopt this as our "Application Definition Statement". We want our application to provide access to the discussions for the mobile user. We will use this statement to determine what functionality we need to keep in our application workflow in the next section.

Streamline the Workflow

The workflow of an application is a conceptual design for how the user is going to interact with the data that the application makes available. Is data going to be consumed or created by the user? Will data be organized hierarchically, into categories, or tagged? Will data be searchable by keyword, zip code, custom parameters?

Often our Web sites grow organically. We create some navigation across the top and down the side of our site and we find the best place to put new functionality as it is created. A Web site like Yahoo! goes from a single list of Web site categories to the complex menagerie that we see today. It is very difficult today to determine what the original purpose of the Yahoo! Web site was.

http://www.news.com/2300-1032_3-6072801-1.html

When designing a site from scratch or redesigning a site it is good to take a step back and think seriously about the workflow of the site. What are the essential tasks which the user is going to want to perform? How difficult is it for the user to find the interface for those tasks? How well does the workflow mesh with our application definition statement?

Looking at the ListSearch Web site we see a pretty common Web site design. The site has navigation across the top and down the left side. The left side lists the mailing lists which are archived at the site. The top of the site consists of a navigation bar which provides the options available for each list (about, browse, message, thread). Below this we see a block of advertisements and then the content of the page.

The content is either a list of messages or threads or the detail of a particular message or thread. The header on individual messages provides navigation between threads or messages. The sidebar provides a ubiquitous search interface and also some message navigation. Each list also has an about page with RSS feeds and subscription controls.

When we visit this site on an iPhone we immediately see some problems. The links on the left are hard to read and hard to click. The text on the home page is extraneous. When we select a list we see an about page which again is largely extraneous. A mobile user is not going to be interested in RSS feeds or subscription controls. The message links are too small to click on in the sidebar. Overall it takes us three difficult clicks before we can read a message.

Streamlining the workflow is easy. Our application definition statement is to provide access to the discussions for the mobile user. It is important that the user select which discussion they want to access. Therefore, we can identify the left side list as essential. After selecting a list the user would like to see the most recent messages in the list and then read one or more individual messages. Everything else on the ListSearch site seems extraneous to this basic purpose.

We can model the workflow of the ListSearch Web site using the following table. The user starts at the Home Page, then visits the List Page for a particular discussion list. They then use the Browse Page, Message Page, and Thread Page to search and navigate through the list. Each page serves multiple purposes and hosts multiple kinds of information.

 

Home Page List of Discussions Welcome Message

List Page About the List RSS Feeds Subscription Recent Messages

Browse Page Search Interface Recent Messages Search Results

Message Page Message/Thread Detail Message/Thread Navigation

Thread Page Search Interface Recent Threads Search Results

 

We can model the streamlined workflow of our iPhone site using the following table. The site consists of two lists and a message detail page. None of the extraneous welcome messages, documentation, descriptions, or advertisements are included.

 

List of Discussions

List of Recent Messages

Message Detail

 

It is a good exercise to use note cards or small slips of paper for this kind of modelling. By arranging the notes on your desk you can quickly try out different arrangements of your Web site. A workgroup could do something similar with a white board.

We should note that simpler is not always better. The new site we have designed is considerably easier to navigate than the site we based it on. However, we have also lost a lot of functionality. As we test the site and get user feedback we can determine whether we have cut too deep. Maybe users do want to search the archives and be able to subscribe to discussion lists while on the go. If so, then we need to work back through the process, redefining our application definition statement, designing a workflow that incorporates our newly identified essential functionality, etc.

Create the Web Application

Now we can design our Web application. We will use our workflow as a direct model for the user interface for the application. Our goal is to make our application feel as much like a built-in iPhone application as possible so we will try to match the look and feel and use the same methodologies as the applications which Apple provides.

Lists are one of the most common user interface elements on the iPhone. We see them in the built-in Mail application, YouTube application, and iPod application. It is very natural for us to use lists to implement both the initial "List of Discussions" and also the "list of Recent Messages" for our application.

The iUI library will handle most of the look and feel issues for the lists for us. You can see an abbreviated version of the "List of Discussions" below. Each discussion has a custom icon to help aid the user. The row for each discussion is tall and runs all the way from one side of the screen to the other. Each row is easily clickable with a finger.

When we click on a discussion we immediately see a list of the most recent messages in the discussion along with an option to see (More Messages). Each message displays the subject, author, and date/time the message was posted. The user can choose to view a single message or can quickly move back through time using (More Messages). The built-in back arrow button allows them to see the previous set of messages and the "Home" button allows them to select a different list.

Finally, when we click on an individual message we see the detail for the message. This includes the basic header for the message and the content of the message below. A simple Previous | Next control allows the user to move from message to message.

The site does require a few niceties to round it out. The initial list of discussions also includes an "About ListSearch" page which allows us to include our copyright notice and links to LassoSoft, the iUI library, and this tip.

We don't know whether an iPhone user is going to prefer using our new optimized Web site or if they are going to prefer using the normal ListSearch interface which they may already be familiar with. However, we also don't want to annoy the iPhone user by requiring them to remember a strange Web address. Finally, there's no need o restrict the interface we have created to iPhone users, it actually works just fine in the desktop versions of Safari.

The site uses a cookie to remember whether the user wants to see the iPhone site or the "normal" site. If the user visits the iPhone site then the cookie is set. Any future visit to ListSearch will send them to the iPhone site. The "Switch to Normal Site" resets the cookie so the user will instead see the normal ListSearch site from then on.

Next Steps

The simple ListSearch interface which we have created for iPhone users is just the first step in creating an excellent Web experience for mobile users.

The site has the look and feel of an iPhone application, but does not have many of the niceties of the built-in Mail application. The navigation and mail display could be tweaked to look and feel even more like the built-in application. We may need to customize the iUI library, or create our own library of functionality, in order to get just the functionality we want.

We might want to consider adding features if we find that users are disappointed with the simplicity of the interface. Are we providing the functionality that users expect and need? Can we add functionality without destroying the simple workflow that we have designed?

Finally, we should go back to the original ListSearch interface and apply some of the principles which we have used to create this simple Web site. Why should site visitors have to use three or four clicks to see the most recent messages? Can we reorganize the main interface of the Web site to have some of the same characteristics of this simple interface?

Author: Fletcher Sandbeck
Created: 9 Nov 2007
Last Modified: 1 Mar 2011