Tapworthy: Designing Great iPhone Apps by Josh Clark

“Designing a tapworthy app means designing for an economy of time, attention, and space.”

The Review

Tapworthy is an indispensable resource for developers trying to make quality mobile applications for all platforms.  While the book uses iPhone apps and user interface elements to illustrate the concepts discussed, many of the observations made about the mechanics, human interactions, and the psychology of what makes great applications are applicable to all mobile applications.

The book does a good job of exploring the user interface elements found in iOS apps and provides a good summary of how and why you would use the elements in your designs.  The coverage of this material is quite good but pales in comparison to the exploration of what goes into making a tapworthy app.  It is in this exploration of what makes a tapworthy app that I got my two main takeaways from the book.

The first is to be ruthless when cutting scope and narrowing the focus of your app.  To help developers and designers do this, a series of questions are provided and discussed.  It is amazing how quickly issues with your design arise when your ideas are subjected to simple questions like:

• What does your app do and why?
• What specific problem does your app uniquely solve for users?
• What makes this app mobile?
• What mobile context are you designing for?
• Why would you use this app when you are away from your computer?

These questions are straightforward and may seem somewhat obvious, but they are an easy way to vet ideas.  If you can’t quickly provide a compelling answers for these questions, then you might not have a best selling app idea.  Conversely, the questions can be used to identify weaknesses that might need more attention and potentially turn a good idea into a great one.

The second takeaway was to recognize the three mobile contexts: microtasking, local, and boredom. To make a good app, you need to tightly wrap the answers to the 5Ws (who is the user, what are they doing, why are they doing it on a mobile, where are they, and when are they doing it) around one or more of these.  Something common among the most successful apps is how easy it is to identify the answers to the 5W questions plus which mobile context it applies to.  When the scope of an app is perfectly tailored to a specific scenario or use case, users will find that every tap has a payoff and accomplishing tasks within the app will seem effortless.  Efficiency becomes a feature.

The Summary

There is so much to like about this book.  Tapworthy forces us to ask the right questions in designing mobile apps and provides invaluable tips and insights about maximizing your app’s user experience.  If you are serious about making good apps, do yourself a favor and pick this book up.  You won’t regret it.

It’s late and I am tired so I’ll be brief.  I just pushed the binding of official Facebook iOS SDK to github.  In addition to the bindings, the DemoApp, which was included along side the SDK, has been ported to MonoTouch.  The code is straightforward and does a good job of getting you up to speed with the important elements of the SDK. 

If you want to run the demo application, you will have to create a Facebook application on Facebook and grab the app id.  You need the app id to pass back to Facebook during the login process and you can find out where to put it by looking through the comments of the DemoAppViewController class.

Please let me know if you have any issues with this library.  Enjoy.

For my latest app I wanted to collect some analytics to see which screens and content included in the app are the most useful to users.  In evaluating my mobile analytics options, Flurry’s free of charge service and easy to use API made the decision to go with them over Google Analytics and Mixpanel an easy one.

Integrating Flurry analytics into your app is pretty easy but there is a small amount of setup to be done prior.  You will need to grab the iPhone SDK from Flurry and also register your application with them to get an API key.  The API key is unique to your application and provides Flurry a way to know who is sending events and notifications back to them to log.  The SDK includes a couple header files and the Objective-C libraries you’ll need to include and link against in your MonoTouch projects.  Once the Flurry libraries and the MonoTouch bindings have been obtained and an API key has been generated, we can integrate them into MonoTouch application and start collecting data.

Initiating data collection is as simple as calling the StartSession method with the application’s API key.  That is all it takes to start collecting basic information about your app like the amount of times it has been launched, the number of different users using it, and other bits of info like hardware version and service provider.

Here is some code showing how to turn analytics on.

using System;
using MonoTouch.Foundation;
using MonoTouch.UIKit;
using Flurry; // include the MonoTouch binding lib

namespace Foo
{
    [Register ("AppDelegate")]
    public class AppDelegate : UIApplicationDelegate
    {
        public const string FlurryApiKey ="...";

        public override bool FinishedLaunching (UIApplication app, NSDictionary options)
        {
            // 1 liner to kick the session off
            Flurry.FlurryAPI.StartSession(FlurryApiKey);

            // Do you app thing here...
        }
    }
}

If more detailed analytics are desired, there are additional methods available to help you glean whatever meaningful information you need from your application.  The example below shows how you can automatically track the changes in navigation within a tab bar.  When you pass a UINavigationController or a UITabBarController to the CurrentPageViews method, each navigation action as you move from one view or tab to another gets tracked.  This is ideal for seeing which parts of your app users are interacting with the most.

using System;
using MonoTouch.Foundation;
using MonoTouch.UIKit;
using Flurry; // include the MonoTouch binding lib

namespace Foo
{
    [Register ("AppDelegate")]
    public class AppDelegate : UIApplicationDelegate
    {
        public const string FlurryApiKey ="...";

        public override bool FinishedLaunching (UIApplication app, NSDictionary options)
        {
            // 1 liner to kick the session off
            FlurryAPI.StartSession(FlurryApiKey);

            // create a navigatable controller to watch...
            UITabBarController tabBarController = new UITabBarController();

            // ...and pass it to CurrentPageViews.
            FlurryAPI.CurrentPageViews(tabBarController);

            // Do you app thing here...
        }
    }
}

I am touching on just a few things that you can do with Flurry.  The SDK docs describe a number of other things you can do like creating and logging custom events and tracking how much time is spent performing activities.  I’d recommend checking them out after you download the libraries.

I’ve just started collecting analytics during beta testing and things appear to working smoothly.  If you find any issues with the MonoTouch bindings please let me know.  Enjoy!

Reto Meier’s Professional Android 2 Application Development does a great job of educating the reader on what is necessary for developing Android applications. Core application fundamentals and advanced Android features are presented to the reader via a series of real-life application examples.  Readers who work the examples and leverage the breadth of coverage provided on the Android 2 framework will be well on their way towards establishing an excellent foundation for building compelling Android applications.

After giving the customary history lesson and tour of the toolsets and development environment, the first half of the book deals with the components that make up an application. Chapters are devoted to activities and life cycle, UI views, data and file access, and key Android concepts like intents (message-passing mechanisms) and content providers (ability to expose data to other apps).

Once the fundamentals have been covered, the remainder of the book is spent exploring the advanced and optional features available in the SDK. Android-centric concepts like background services, notifications and widgets are given the same in depth treatment given to the fundamentals so you get a lot of the “why” along with the how. Features and functionality that naturally lend them to being abstracted away via an API like media playback, GPS and Bluetooth are given adequate coverage of what is available via the framework and, where pertinent, the Android-specific behaviors are highlighted.

While the book is divided into fundamentals and advanced topics, continuity is maintained throughout via the example applications used to emphasize the concepts presented. By building the to-do list, compass, and earthquake monitoring service applications while reading through the book, passive learning is transformed into active, directed learning. Unlike some programming books I’ve read in the past, these examples do real work, accomplish specific real-life tasks, and provide some utility once completed. Readers are not just extending these applications one feature at a time, they are also adding one key concept to their proverbial tool belt while doing it.

The speed at which the Android platform is being evolved and improved upon is staggering. Since April 2009 there has been 4 major releases of the Android OS with a 5th release rumored for this fall. While the breadth of coverage provided for the APIs and framework is nice while it is still relevant, the real strength of this book comes building an understanding of the core Android fundamentals. Readers looking for a solid introduction to Android development need to look no further than Professional Android 2 Application Development.

The upgrade process done by Visual Studio on your current projects and solutions will only migrate the file format to the newest schema and will not retarget the framework to the latest version.  That is where the script I’ve included below comes in.  It will retarget all the C# project files found under the path provided to version 4.0 of the .Net framework

C# project files are XML based and navigating the DOM with Linq to XML is a cinch but there are a couple small but important steps that the script needed to include.  First, you need to append the namespace to the individual element names or else the elements will not be able to be found.  Second, when saving the modified XDocument, a XmlWriterSetting instance needs to be instantiated and the OmitXmlDeclaration property set to true.  Setting this property to true will make sure the XML that we save will be considered a valid project file by Visual Studio.

I’ve included the full script below as well as created a gist that can be found here.  It is important to note that this script will edit all the csproj files found under the directory specified in the path variable.  Make sure you backup these files or have them under source control prior to running the script.  Enjoy.

[UPDATE: Added change suggested in comments by Jeffery Snover]

[Reflection.Assembly]::LoadWithPartialName("System.Xml.Linq") | Out-Null

#specify the root of your source tree below
$path = "C:\Code\chatsworth"

$ns = "http://schemas.microsoft.com/developer/msbuild/2003"
$xname = [System.Xml.Linq.XName]::Get("PropertyGroup",$ns)
$tfname = [System.Xml.Linq.XName]::Get("TargetFrameworkVersion",$ns)

$xws = New-Object System.Xml.XmlWriterSettings
$xws.OmitXmlDeclaration = $true
$xws.Indent = $true

function updatefx($filename)
{
    #Write-Host $filename
    $xml = [System.Xml.Linq.XDocument]::Load($filename)

     $result = $xml.Descendants($xname)

    foreach ($i in $result)
    {
        $fxelem = $i.Element($tfname)
        if($fxelem)
        {
            $i.SetElementValue($tfname,"v4.0")
        }
    }

    $xw = [System.Xml.XmlWriter]::Create($filename, $xws)
    $xml.Save($xw)
    $xw.Close()
}

$csprojs = Get-ChildItem $path *.csproj -Recurse

foreach ($file in $csprojs)
{
    updatefx $file.FullName
}

Lately I have been thinking about user design and experience as I prep my app for the App Store.  Here are six things that stood out most about the Evernote iPhone app and the take-away ideas I got from looking closer at the app.

1. The mobile apps immediately present 4 distinct actions for note acquisition.

Evernote breaks down into two key activities: note acquisition and note retrieval.  Given the detached nature of the mobile device and the sluggishness still experienced with cellular networks, the note browsing and searching experience is not ideal.  The constraints of the device and the unpredictable nature of the network, I believe, led to a focus on what a mobile device is good for (note capturing) and make that the key action in the mobile versions of its application.

Having the app launch into the note acquisition screen implicitly signals to the user that this is the type of activity that you should be doing on the device.  It seems counterintuitive to restrict features to simply not port them directly from the desktop or web offering.  But by limiting the scope of the application, it actually maximizes the experience for the user.  In Evernote’s case they cannot completely focus on note capture at the expense of cutting out the other actions.  These additional activities are included, but they are relegated to the tab bar on the iPhone and the sub menus on Android devices.

2. Smart layout and design can make sub-optimal experience tolerable

Given the limited real estate available on mobile devices, it is unsurprising that note browsing is a sub-optimal experience.  That being said, I think that Evernote does an excellent job making due with what little space it has.  Visually we are given two options, depending on the orientation of the phone, in which we can browse our catalog of notes.  While holding the phone in portrait mode, each note’s metadata is visible and allows the user to see titles and tags in addition to a thumbnail image of the note.  While holding the phone in landscape mode, the note browser is transformed into a tiled-thumbnail view which shows more notes in the visible frame.  If you can recognize the note by the rough appearance or layout of the text, you can pretty rapidly find what you are looking for. 

Most people hold the phone in portrait mode so it follows that the default view is the easier of the two to quickly grasp.  The two views provide the user with choices and trade offs: lower information density with a greater amount of detail or higher information density with less detail.  By giving the user options, Evernote overcomes the inherent limitations of the mobile device and improves the user experience.

3. Search function is a key but clunky feature in the mobile app.

Evernote has outstanding OCR software that makes everything searchable.  Given that search is the killer feature of Evernote, it is surprising that search on mobile devices seems like a second-class citizen.  The typical standard search box is visible on most of the non-note capturing screens, and the text search works as expected.  Search does have some enhanced features like map view and search near here offered as options to help refine your search, but I am not a fan of either.  The actual search queries appear to be executed on the server side and, as a result, the processing time can vary depending on your network connection.  In order to do a location based search the app has to make network requests for the search results and get the map coordinates, and this typically translates to a noticeable wait when these types of searches are performed.  I feel like search could cut out the location-based search filter entirely and be no worse off.

4. Sync Button is a “kitchen drawer” tab on the iPhone App

The sync tab is mislabeled, and the label masks all the other functions that are exposed on that tab.  Contextually, account information and device-specific settings aren’t readily associated to sync even though the sync process in Evernote synchronizes everything associated to your account.  The action of synchronizing your notes could be integrated into the note screen, and the settings, account information, and about information could all be separate tabs managed by the tab controller already being utilized in the iPhone application.  In fairness the move to limit the tabs is consistent with the less-is-more type of attitude, and the combination of the multiple actions into the single tab is most likely a compromise to simplify the interface.

5. The tips UX on the iPhone is well executed and non-obtrusive

The tips screen, integrated into the main view of the Evernote iPhone app, is an excellent way of sharing information about features and activities without being pushy and obtrusive.  With a smooth animation that peels back the main view to show the tips view, the user can get a quick suggestion on a feature and then be back capturing or browsing notes.  This is a small but well executed design element that adds to the experience.

6. Sharp branding

As far as the aesthetics go, I like the Evernote logo.  A combination of an elephant and piece of paper plays off the “memory like an elephant” saying and the note-based nature of the application.  The logo, paired nicely with a soft green color and a nice font, is the focal point of the splash screen welcoming you into the application.  The other platforms do not utilize a splash screen since the application load times aren’t as great as the iPhone, but the same basic logo/font/color scheme is consistent in the icons used on all platforms.

Lessons learned from the Evernote app:

• Instead of frustrating users with clunky interfaces and hacks to enable certain features of your service or app, only port features or activities that enhance the service and take advantage of the features of mobile devices rather than expose the limitations of them.
• Focus on the activities that can capitalize on the advantages of a mobile device instead of fighting the platform.
• Optimize for those specific use cases that make sense that you want to capitalize on.
• Be ruthless in what you cut out or be stingy in what you put into the mobile version
• Be consistent in your branding, color scheme, and feel of your applications.
• Good design can always speak louder than any type of instruction.  Help users fall into the pit of success.

You can get the iPhone app in the iTunes App Store

When used with a using statement, the indicator is turned on when the object is constructed and turned off when the code within the using statement has finished executing and the object’s Dispose method is called.

public class NetworkIndicator : IDisposable
{
   public NetworkIndicator ()
   {
      UIApplication.SharedApplication.NetworkActivityIndicatorVisible = true;
   }

   public void Dispose ()
   {
      UIApplication.SharedApplication.NetworkActivityIndicatorVisible = false;
      GC.SuppressFinalize(this);

   }
}

Usage:

using(new NetworkIndicator())
{
    //Make network call here
}

You wouldn’t want to wrap this around a UIWebView (add the toggling of the indicator to the LoadStarted and LoadFinished events) but anytime your app is making calls out the network you can wrap the using statement around the method invocation and get the user friendly network activity notification.

Overall Themes

Two main themes that emerged during the sessions: the future of mobile is web-based apps rather than device specific apps, and the road to mobile riches probably doesn’t run through an app store.

Multi-platform development is hard

Certainly scenarios exist where multi-platform apps make sense, but it is imperative that the risk/reward ratio be in your favor to have a chance to be successful.  Don’t underestimate the amount of effort and headaches that developing and supporting multi-platform apps will create.  Going the mobile web app route has it’s limitations, but it is the closest thing to “write once, run anywhere” that mobile has.

Cool Tools

Really cool tools like PhoneGap and jQTouch are out there that help lower the barriers to making apps and, in the case of PhoneGap, multi-platform apps.  Both tools have been released under MIT licenses and are free to use.

One Man’s Secret Sauce for Success

David Whatley gave a funny presentation that provided a lot of laughs and some great insights into how the iPhone app store works.  Even better was his ability to back up what he was saying with some real sales data and numbers.  His secret sauce for success:  PR, code re-use, and playing to your strengths.

App stores are glorified catalogs

Standing out or even being noticed amongst all the other apps is extremely difficult.  Relying only on the app catalog to drive sales is effectively a “post and pray” strategy akin to trying to win the lottery.  Try to find a niche and solve a problem.  Focus on creating value for markets not just an app for it.  Mark Murphy described many ways to make money in mobile other than direct app sales during his talk and in a series of blog posts about Android Business Models.

Links

• PhoneGap
• jQTouch
• iPhone Dev Depot
• Mobile Web Development Tips and Tricks (Slides)
• Making Money at Mobile (Slides)
• http://github.com/mikelaurence/CoreResource (Cool iPhone library)

Books Recommended During the Conference

• Aiming at Amazon
• The Dip
• The Whuffie Factor

Overall, the signal-to-noise ratio at the conference was good but not great.  I did manage to glean at least one or two new ideas from most of the sessions I attended, and it was great to see the enthusiasm that the Chicago tech community has for events like this.

I was following along with the documentation for binding new Objective-C types on the MonoTouch site, and as a way to ease into the binding process, I chose a class to define from the CloudMade SDK that I am looking to expose in MonoTouch.  The class selected was the BBox class (bbox.h) and I went about creating the following API definition shown below:

using System;
using MonoTouch.Foundation;
using MonoTouch.ObjCRuntime;

namespace CloudMade
{
    [BaseType(typeof (NSObject))]
    interface BBox
    {
        [Export("westernLongitude")]
        float WesternLongitude {get;set;}

        [Export("southernLatitude")]
        float SouthernLatitude {get;set;}

        [Export("easternLongitude")]
        float EasternLongitude {get;set;}

        [Export("northerLatitude")]
        float NorthernLatitude {get;set;}

        [Export("asString")]
        string AsString();
    }
}

$ btouch BBox.cs
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(46,71): error CS0117: `CloudMade.BBox' does not contain a definition for `Messaging'
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(28,30): (Location of the symbol related to previous error)
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(57,71): error CS0117: `CloudMade.BBox' does not contain a definition for `Messaging'
/var/folders/E4/E44PAZnZGKGpVrmseo2N3++++TI/-Tmp-/9qgrm9nm.lnv/CloudMade/BBox.g.cs(28,30): (Location of the symbol related to previous error)
Compilation failed: 2 error(s), 0 warnings
btouch: API binding contains errors.

Do not give the file that the API definition is being saved in the same name as one of the interfaces that you are defining.

Steer clear of that and you’ll be binding Objective-C types with ease.

Likes:

• Speed.  I have the older iPhone 3G hardware and from a user experience perspective it was not that bad.  When compared to the Nexus One, however, it is down right sluggish.  This probably isn’t as big of a factor when comparing a 3GS versus Nexus One, but for someone coming from a 3G iPhone, it is a huge plus.
• Being able to run apps in the background.  Browsing the web while streaming Pandora and downloading an app in the background works flawlessly and shows no noticeable signs of lag or sluggishness.
• The OLED screen is really nice.  Higher resolution and OLED screen looks great in low-light situations and is supposed to save precious battery by not drawing less power than normal LCD screens.
• The Android OS is pretty sweet.  It has a lot of nice features like the status bar, an active “desktop” that you can put interactive widgets on as well as app icons, and an easy way to get music and files on and off the device.  
• Integration with Google Apps is fantastic as expected.  I love getting mail and talk updates in the status bar and the overall experience with the apps on the Nexus One is better than on the iPhone.

Dislikes:

• Cut and Paste is clunky.  I can see why Apple needed to spend awhile working out the UX issues before rolling it out.
• The touch interaction with the device has not been as good as the iPhone in my experience.  I am not sure where the blame lies (hardware or software), but I sometimes find it difficult to select elements in the UI.  This is not something that occurs frequently, but in the short time I’ve owned the device, it has occurred enough to be noticeable.
• 4GB of storage out of the box is lacking.  It is an easy upgrade but given the amount of money that Google is charging for the device, this seems like they are skimping here.
• The Android Market place experience is integrated nicely but isn’t as tightly integrated as the iTunes App Store.  This is arguably a good or a bad thing depending on how you look at it.  As a user this is a bad thing since it makes finding and buying apps more difficult than just popping open iTunes.  I’ve found the Android Marketplace, both on the phone and the web, hard to browse.

There are a few negatives that I can’t pin exclusively on the device but are still worth noting.  I have been using my AT&T SIM with the Nexus One and most likely will do so until my contract is up in a few months.  With that caveat out of the way, the talk quality seemed poor and the phone gets really hot when talking for periods greater than 10 minutes.  I hesitate to even mention these issues since I am not using the phone on the network it was intended, but  I know there probably are others considering doing what I did, and this feedback might help if someone is on the fence.

The Nexus One is exactly the kind of phone and competition that was needed to push Apple.  I strongly recommend anyone looking for a smartphone to give it serious consideration before running out and getting an iPhone.