The way UITableView is constructed makes it really well suited to displaying dynamic data, through the use of the delegation pattern. The control caters really well to data changes, by not storing the data that is to be displayed, but rather asking for it when it is needed.

The problem with UITableView really lies in displaying static content – content that largely doesn’t change, and content which is known to you at development time. Good examples of this would be any form of navigation, such as the hierarchical navigation structure in Settings.app, or an interface that is fixed, such as the detail view for a single contact in Contacts.app.

For these kind of interfaces, although you may want the table view look and feel, implementing the delegate/data source methods often feels very verbose for how you are using it.

I really like the article Fraser Speirs has written to counter the problems associated with UITableView in such a scenario. The idea is essentially to create enumerations for the sections in the table view, and the rows in each section. This provides constants as mappings between row and section indexes, and the data you want to display. What’s more is that each enumeration is ended with a constant which can be used for the number of sections/rows in that enumeration, which works on the fact that the enumeration is 0-based. Here is an example:

enum Sections {
     kHeaderSection = 0,
     kTitleSection,
     kAuthorSection,
     kBodySection,
     NUM_SECTIONS
};

Now you can return NUM_SECTIONS in-numberOfSectionsInTableView:, which will always be the number of sections in the enumeration, and you can use switch statements in row or section-dependent methods such as -tableView:cellForRowAtIndexPath: with these constants, rather than having to hard-code row and section numbers.

Although much more resistant to future change and more structured, the problem with this method is that your code quickly devolves into a mess of switch statements, which doesn’t make the code much less verbose.

Solving the problem with PXSimpleTableAdapter

My primary motivation for PXSimpleTableAdapter was to overcome this problem of verbosity, and make setup and getting information into a table view really easy.

Why did I name it “Simple” table adapter? Because the classes are designed for only this use case – where you have “static” data. If you have dynamic data, UITableViewDelegate and UITableViewDataSource are the way to go.

Get the source

As with all of my open source projects, you can clone the project straight from GitHub:

git clone git://github.com/Perspx/PXSimpleTableAdapter.git

Or have a look at the project page at http://github.com/Perspx/PXSimpleTableAdapter.

Classes

The structure of the classes is simple:

• PXSimpleTableAdapter: This is the class which transforms the data you pass it into cells that can be used by a UITableView, as well as handling selection.
• PXSimpleTableSection: This class encapsulates information about a section in the table, including the rows it contains.
• PXSimpleTableRow: This class encapsulates information about a row in the table, such as its title and icon.

Using PXSimpleTableAdapter is very straighforward:

1. Lay out a UITableView in Interface Builder.
2. Create an instance of PXSimpleTableAdapter in your view controller class and set the tableView property to your table view instance. This property is declared as an outlet so this step can also be done in IB, by dragging out an Object from the Object Library for your table adapter instance then hooking this up to your view controller as another outlet).
3. Create an array of PXSimpleTableSection instances, and set each section’s array of PXSimpleTableRow instances.
4. Pass the array of sections to -setSections: on the PXSimpleTableAdapter instance.

Convenience methods can be added if sections or rows need to be added or removed. Have a look at the PXSimpleTableSection and PXSimpleTableRow header files for more information.

Data Model

Each PXSimpleTableSection instance encapsulates:

• The header title for the section
• The footer title for the section
• The array of rows for that section

Each PXSimpleTableRow instance encapsulates:

• The title of the row
• The icon for the row (if needed)
• The accessory type (from the UITableViewAccessoryType enumeration)

Rows also have a selection block and an accessory tapped block property. These blocks are invoked when the row is selected, or their accessory button is tapped, respectively.

Example

Here is an example of creating a view which looks similar to that of Settings.app (if using a table view with the grouped style):

NSArray *firstSectionRows = [NSArray arrayWithObjects:[PXSimpleTableRow rowWithTitle:@"Sounds"],
                                                      [PXSimpleTableRow rowWithTitle:@"Brightness"],
                                                      [PXSimpleTableRow rowWithTitle:@"Wallpaper"], nil];

PXSimpleTableSection *firstSection = [[PXSimpleTableSection alloc] initWithSectionHeaderTitle:nil
                                                                           sectionFooterTitle:nil
                                                                                         rows:firstSectionRows];

NSArray *secondSectionRows = [NSArray arrayWithObjects:[PXSimpleTableRow rowWithTitle:@"General"],
                                                       [PXSimpleTableRow rowWithTitle:@"Mail, Contacts, Calendars"],
                                                       [PXSimpleTableRow rowWithTitle:@"Phone"], nil];

PXSimpleTableSection *secondSection = [[PXSimpleTableSection alloc] initWithSectionHeaderTitle:nil
                                                                            sectionFooterTitle:nil
                                                                                          rows:secondSectionRows];

NSArray *sections = [[NSArray alloc] initWithObjects:firstSection, secondSection, nil];
[firstSection release];
[secondSection release];

PXSimpleTableAdapter *tableAdapter = ...
[tableAdapter setSections:sections];
[sections release];

For such static content, this is much more manageable, and the code to set up the view resides in one method only, rather than 5 or so delegate messages with their own conditionals.

Custom Cells

By default, the data encapsulated in each PXSimpleTableRow is transformed to a UITableViewCell with the default style. This cell is then passed to the table view for display.

To use a custom cell in rows, you must subclass PXSimpleTableRow where you can provide your own cells and set them up as necessary. You must create one PXSimpleTableRow subclass for each type of cell you are going to be using.

There is more information on how to do this in the project README.

But what about delegation?

Delegation is one of my favourite patterns used in Cocoa and it really is powerful. The aim of this project is not to break delegation or suggest that this is the way UITableView should go.

However, the aim of PXSimpleTableAdapter is simply as a convenience for implementing this particular use case of table views in a simple manner.

Support/Bugs

If you have any bugs to report then you can do so on the GitHub project page.

If you have any queries about the project, first check out the project README on GitHub, or the Demo App bundled with the source. If your question still remains unanswered, you can contact me here. I’ll do my best to reply to any queries if I can.

1. the user (if it is a visual component)
2. the developer who is going to be interacting with it.

I’m a firm believer in user-driven design, and will tend to structure my classes in order that they make most sense to how they will be organised on-screen, if they are visual components. However equally important to this is designing classes and their interfaces with other modules in such a way that they are easy to interact with from other modules. This is paramount to a well-structured application.

As a Cocoa developer the place where I find this philosophy is most important is the exchange of data from Model to View, passing through a Controller — the mediator in the MVC pattern. As a developer who often designs and builds data-intensive views, building something which not only works well for the user but also the developer is important to structuring classes which have clean interfaces and exchange of information between one another.

The bigger picture

In an object-oriented context, my first thought with all of my classes is how am I or someone else going to use this thing? You could have the best implementation in the world but a poorly thought-out public interface for other classes is likely to lead to problems down the line. This task comes before I even start to implement anything internally in the class.

The main benefit to this is that by designing the interface before you do any actual coding of inner workings, it gives you a broader sense of the class and will allow you to make changes as early as possible, potentially saving you a lot of time.

This is supported by Hunt and Thomas in The Pragmatic Programmer, in the section on Prototyping Architecture:

Most prototypes are constructed to model the entire system under consideration. As opposed to tracer bullets, none of the modules in the prototype system need to be particularly functional. In fact, you may not even need to code in order to prototype architecture—you can prototype on a whiteboard, with Post-it notes or index cards. What you are looking for is how the system hangs together as a whole, again deferring details.

Of course internal details are important and can affect how the class will be used, but designing the interface around the implementation is rather backward, because the internal implementation has little dependency on anything (aside from some fundamentals such as the storage and structure of data, for instance). The public interface, however is important to get right as a bad one can make other parts of your application inefficient or poorly constructed.

Development process

1. Design the public interface by listing methods

I usually start out by creating a list of public methods which other classes will call; be that processes or querying or setting state.

A lot of Cocoa classes use the delegation pattern. That is, the class will query its delegate (a Controller in the MVC pattern) for data to such as information to display in a table, or to notify it that something of importance has happened. At this stage I will also write a list of methods that will be called upon the delegate, to get a feel for how the interchange of information will work.

Of course at this time you may not know the full picture of how this class is going to work, but build upon what you know already. Doing it to the best of your knowledge at the time is what you are trying to do, rather than going in completely blind when building the control.

2. Test how other classes will interact with your new class

Next, I will actually call these methods that I have defined on my new class in another module, or implement delegate methods in my class’s delegate, using a test Model if they return any data.

This is invaluable when starting out, because it allows me to get a feel of how I will interact with this class when I am finished with it; at that point the internal implementation will be irrelevant from the point of view of any external classes, and this is an opportunity to revise the public interface of the control before getting bogged down by the internal implementation.

This might seem a somewhat back-to-front approach; instead of implementing the internal workings of a control, then creating the interface for other classes to interact with it, I will implement the public interface with no internal backing, then implement the internal parts later.

However, this approach has several advantages:

• You get a better sense of the overall design of the control. Before you start coding anything internal, you get a much broader picture of how the class is going to operate, which can be useful when it comes to implementing the internal workings later.
• It makes you think about how other classes/modules will use it. Doing these steps first allows you to think about how you (or another developer) will want to use the class, irrespective of how it will function internally. For another developer who may not understand the exact inner-workings of your class, making this abstracted to suit the needs of other classes will make using it much easier.
• Changes to the interface at this point are very cheap. If you decide you don’t like the public interface at this point, it is very easy to change it with few repercussions. If you design the interface as you go along, any changes you make will often affect the internal structure which can be costly.

3. Revise the interface

If there are any things which I’m not happy with I will now change these with quite a minimal impact, as there will be no underlying changes to the new class. I can then make sure the class I’m testing interactions with is updated to reflect these changes, and I will keep repeating this until I have something I’m initially happy with to start implementing.

4. Internal Implementation

Now I can start to build the internal workings of the class, with this rough guide for how I want it to behave and how it is constructed.

Of course as the implementation continues you may have to alter the public interface as you add features and capabilities to the module, but the initial design you have come up with will likely minimise this, if you have enough of an idea of how the module is going to work.

To Conclude

It may seem that I am suggesting that this is an ideal process, one by which up-front design will create a perfectly designed interface that won’t have to be revised; this is not the case in many places, and as you start to build more complexity or requirements change it is certainly possible that you may have to gut your class.

Real software development is anything but perfect and ideological, but by thinking and revising module design and architecture up-front, it will help to reduce throwaway code that you write, and on the whole save you time.

cocos2d for iPhone is an open-source framework that is used to create 2D graphics and games for the iPhone and iPad, based on the original cocos2d project (which is written in Python). cocos2d for iPhone is a port to iOS and is written in Objective-C, and is built upon OpenGL. The cocos2d for iPhone project has been successful with games written for the iPhone, and there is a long list of apps which use the library.

In recent months it has been ported to the Mac (presumably with the upcoming opening of the Mac App Store) and in this post I’ll walk you through getting it up and running for Mac projects and then finish by listing some of the differences between the iOS version and the Mac port.

1. Get the source

At the time of writing, the Mac port of cocos2d is still in beta; but the latest version can be found on GitHub or is easily cloned from the command line with Git:

$ git clone https://github.com/cocos2d/cocos2d-iphone.git

You can also checkout the develop branch if you want the blindingly up-to-date code, but I didn’t bother.

2. Build the cocos2d static library

Once you’ve checked out the source, there is an Xcode project called cocos2d-mac in the root directory. Open this up in Xcode, and select the cocos2d target, which is a static library.

With the upcoming opening of the Mac app store, building cocos2d as a static library is the best way to go, since it is likely that the only permitted way of linking against third party libraries is if they are static libraries (this is where the compiled object files are copied into the application executable when it is built, rather than being loaded at runtime; see this post for more information).

I did a Release build and set an installation directory for the static library as a “shared” folder I store libraries in that I use in several projects.

To do an installation when the project is being built, you need to set three values in the Build settings for the static library target (Ensuring the Configuration dropdown box is for a Release build):

1. Set the Installation Build Products Location to the root directory that you want to copy the static library to when it is built.
2. Set the Installation Directory to the relative path that you want to copy the static library to when it is built. This value is appended to the installation build products location, forming the full path to which the library is copied to.
3. Check the Deployment Location checkbox.

Now do a Release build of the cocos2d static library target. The library will be built then copied to the location that you specified in the build settings.

3. Setting up the project

With the static library built and copied to a shared folder, you now need to create a new project and add cocos2d. First you need to add the static library that you have built. By default, the cocos2d static library is built as libcocos2d.a.

If you did a Release build and installed it to a folder then locate this and drag it into the Frameworks > Linked Frameworks folder in the Groups & Files Pane. Uncheck “Copy items into destination group’s folder” and check the checkbox for the application target that you want to link cocos2d with.

Now you need to add some other frameworks to your application target, namely:

• ApplicationServices.framework
• QuartzCore.framework
• OpenGL.framework
• libz.dylib

These are the dependencies of cocos2d and have to be added to the project because cocos2d is being linked as a static library.

You also need to set a flag in Other Linker Flags in the Build settings for your application target, which is -all_load. This forces copying of all the object files from the cocos2d static library to the application executable, and you will run into problems later if you don’t, for example when using cocos2d objects in Interface Builder, since the relevant object files won’t have been copied into the applicatione executable from the static library.

Have a look at this technical note for more information.

4. Using cocos2d in your projects

For those who have used cocos2d on the iPhone/iPad, building an application using the framework is pretty much the same process as for iOS devices. For those who haven’t, I would recommend looking at the following resources, especially before reading further with this article:

• The official cocos2d for iPhone Programming Guide
• The cocos2d for iPhone API Reference

Although both are listed as being “for iPhone”, the documentation is almost identical for both platforms.

However, there are a few distinct differences between using cocos2d for iOS and for the Mac, namely:

• The input devices are different
• Integrating with AppKit/UIKit is slightly different

Fortunately, since the Mac port of cocos2d is a port, most of the work has been done for us.

Event Dispatcher

Those who have used cocos2d on iOS devices will be used to using CCTouchDispatcher with the CCTouchDelegateProtocol for touch events.

For the Mac, you will be using the CCEventDispatcher instead, which handles both mouse and keyboard events. To register a node to receive mouse events, call -addMouseDelegate:priority: on CCEventDispatcher:

[[CCEventDispatcher sharedDispatcher] addMouseDelegate:node priority:0];

To register a node to receive keyboard events, call -addKeyboardDelegate:priority:

[[CCEventDispatcher sharedDispatcher] addKeyboardDelegate:node priority:0];

The priority argument denotes the priority of which mouse or keyboard events are sent to the delegate(s). The nodes that have been registered with a lower priority will be notified of the events before the nodes with a higher priority.

Mouse delegates are notified of:

- (BOOL)ccMouseDown:(NSEvent*)event;
- (BOOL)ccMouseDragged:(NSEvent*)event;
- (BOOL)ccMouseMoved:(NSEvent*)event;
- (BOOL)ccMouseUp:(NSEvent*)event;

- (BOOL)ccRightMouseDown:(NSEvent*)event;
- (BOOL)ccRightMouseDragged:(NSEvent*)event;
- (BOOL)ccRightMouseUp:(NSEvent*)event;

- (BOOL)ccOtherMouseDown:(NSEvent*)event;
- (BOOL)ccOtherMouseDragged:(NSEvent*)event;
- (BOOL)ccOtherMouseUp:(NSEvent*)event;

- (BOOL)ccScrollWheel:(NSEvent*)theEvent;

- (void)ccMouseEntered:(NSEvent*)theEvent;
- (void)ccMouseExited:(NSEvent*)theEvent;

Keyboard delegates are notified of:

- (BOOL)ccKeyUp:(NSEvent*)event;
- (BOOL)ccKeyDown:(NSEvent*)event;

The event process is much like the Cocoa responder chain, in that delegates with the lowest priority are sent the event notifications first. If they respond to the event, they return YES. If they return NO then the notifications are sent to the delegate with the next lowest priority, and so on, until someone responds to the event or the list of delegates is exhausted.

MacGLView

The MacGLView is a subclass of NSOpenGLView which is used to integrate with the cocos2d framework.

When you create the view that you want your cocos2d project to run in, drag an NSOpenGLView out into Interface Builder then change its class to MacGLView, or create a MacGLView in code. Then when you call -setOpenGLView: on CCDirector pass the MacGLView reference in.

Final thoughts

This is just an introduction to using cocos2d in your Mac applications; for more information have a look at the project website or the project page on GitHub.

The version which had the Mac port included is also currently in beta; although I didn’t find any bugs when doing some tests, if you are using cocos2d in any production applications, bear this in mind.

Also make sure to observe LICENSE.cocos2d that is bundled with the source.

You know you’ve achieved perfection in design, Not when you have nothing more to add, But when you have nothing more to take away.

— Antoine De Saint-exupery

I find this especially relevant when there is lots of information to be presented in an interface, to help with deciding which parts need to be displayed, and which bits don’t.

Lists

The list based interface seems to be a popular choice when displaying lots of information; all you have to do is look at sites such as Twitter, Facebook, YouTube, Delicious, Vimeo – or even iPhone apps, where list-based interfaces are pretty much the way to display information – to see that this is true.

Lists work as a way of displaying information for a few reasons:

• They display a set of connected items.
• They can be used to display sorted data, often used when there is a chronology to information.
• They are useful in summarising information which can be quickly and easily scanned through.

Whilst a useful way of displaying lots of information, lists often fall short because of the amount of information that is presented in a small space, which leads to a cluttered interface.

Swamped by Metadata

Think about the actual content which is displayed in a list: statuses, blog entries, bookmarks etc. Most of these have associated metadata and this is often the cause of the problem of information crowding.

Take a Tweet on Twitter (as part of a conversation) for instance:

@alextgordon I’m surprised (but probably shouldn’t be) those are on different code paths

That is the content, but is outweighed by its associated metadata:

• Author username: @rentzsch
• Author real name: rentzsch
• Time posted: 13 hours ago
• In reply to: @alextgordon
• Posted with: Mobile Web

And it also has associated actions:

• Favourite
• Retweet
• Reply

The challenge with listing information effectively lies in deciding which of these bits of information to display. Take the ‘New’ Twitter web UI, for example, which I feel displays far too much unnecessary information. The ‘conversations’ feature (probably inspired by clients such as Tweetie) has made it into the web app but feels too densely packed:

The conversation consists of only 2 tweets, but often Twitter conversations consist of many more. For serving the purpose of displaying an overview of the conversation, a lot of irrelevant information is displayed, such as “in reply to…” and the Favourite, Retweet and Reply actions (which are duplicated from the tweet in the main Twitter feed to the left). Because of all this information although the actual content (the Tweet itself) is only 88 characters and displayed in a larger font, it feels crowded by this metadata, which makes it harder to scan for the relevant information.

Non-web apps such as Tweetie and Echofon have already implemented conversations pretty well in a minimalist way which gets the most important information across and makes it easy to scan through the conversation:

Here the use of speech bubbles indicates that the tweets are connected and are replies to each other, which removes the “in reply to” line that the Twitter web app uses. The names and Twitter usernames have also been removed to further compress the information, and the interface uses avatars instead. The information is much easier to digest because there is lots of space and an absence of unnecessary data.

Nothing more to take away

In order to list information effectively, work out how much of it can be removed whilst still serving its purpose. Is that full timestamp needed? Do the number of comments on that blog entry make sense as a hook for what people want to read? These are all things you need to think about when deciding how to display information in the most effective way possible.

It seems that many of the apps in use today rely on or display feeds or lists of data; be that a Twitter timeline, an RSS feed or a list of history in a version control system, there’s a common trend in UI for using lists.

But displaying lists in applications can be much more than trivial, certainly for applications on Mac OS X, especially when you have to deal with large quantities of data, and have to solve problems such as variable row heights or changes to this information.

Ever since using Tweetie, a Twitter client for Mac OS X, from a development point of view I was always curious as to how the list view for the Twitter timeline was implemented; hundreds of rows of tweets can be displayed in this control, and the performance hit appears to be minimal; scrolling is smooth, there doesn’t appear to be a huge memory footprint. So how is it done?

Lists in Tweetie

If you class-dump Tweetie, you can see three classes at work:

• ABScrollView: A subclass of NSScrollView. It’s not clear as to why there is this subclass but an ABColor object is used for the background (as opposed to an NSColor).
• ABTableView: A subclass of ABScrollView which is used as the list control.
• ABTableViewCell: The cell class used to display each row in ABTableView.

The interesting part of the class hierarchy is contained in ABTableView and ABTableViewCell. ABTableView is a subclass of ABScrollView (not NSTableView) and is a control which can display a list of ABTableViewCells. However the real misnomer here is the cell part, because ABTableViewCell is a subclass of NSView, and not NSCell.

So essentially what we have here is an implementation of something similar to NSCollectionView, which has a set of subviews which each represent a row and have their own place in the view hierarchy. But how, then, is the Tweetie list view so performant?

@interface ABTableView : ABScrollView
{
    ...
    NSMutableDictionary *reusableTableCells;
    ...
}

...
- (id)reusableCellsArrayForIdentifier:(id)arg1;
- (id)dequeueReusableCellWithIdentifier:(id)arg1;
...
@end

Reusing Cells

The answer seems to lie in a method declared on ABTableView, which is -dequeueReusableCellWithIdentifier:. For those of you who are iPhone developers, you will be familiar with a method on UITableView with exactly the same method signature.

For those who aren’t, I shall explain: certainly compared to simple NSCell instances, NSView instances are pretty expensive. In fact, NSCell is actually designed as a “mechanism for displaying text or images in an NSView without the overhead of a full NSView subclass”¹. In light of this, if we have 100, 1,000 – or even more – rows in a list, we don’t want the overhead of 1,000 instances of NSView, each used to represent a row. What’s more is that most of these cached views are wasted, since 1,000 rows cannot be displayed in the viewport at the same time. The iPhone takes advantage of this, and ensures that there are only enough view (in this case UIView) instances to cover the height of the table view; if the associated rows are scrolled off screen, then the views are removed from the view hierarchy.

Scrolling works much like laying down track for a train by picking up track from behind it; when a row is scrolled so that it is no longer visible, it is removed from the table view and “enqueued” (ie stored in an array); when a row that is not visible is scrolled so that it becomes visible, the data source should first check to see if there are any enqueued views, and if so it is then added to the view hierarchy and displayed.

What this means is that hundreds of rows can be displayed in one control without a large performance hit, and is one of the optimizations that makes the iPhone UI so responsive.

Lists in Echofon

After class-dumping, you can see that Echofon implements their list views in pretty much the same way as Tweetie, using two main classes:

• FastTableView: A subclass of NSScrollView which is the list control.
• FastTableCell: A subclass of NSView which represents a cell used for the table view.

Although not as explicit as the enquing/dequeuing in Tweetie’s list control, it would seem that FastTableView does a similar job as it has declared on it -popCellForRow:fromArray: and -popSpareCell.

Also to note is the use of NSControl and not NSView as the superclass of the table “cell” object, unlike with Tweetie. I would guess that this is for some of the additions that NSControl provides, perhaps the target/action mechanism.

Final word

When displaying large amounts of data in a list, as many applications do, often NSTableView is not enough. It is a pretty performant class, but when you start doing things with variable row heights, it isn’t really cut for the job. Nor is a class such as NSCollectionView; again it doesn’t implement variable row heights and lots of items can slow it down.

It seems that using view objects for each row, which have an established presence in the view hierarchy is the way to go, if you have the optimizations on top of this. For one you get the added convenience of using instances of NSView, and not simply working with NSCell.

As a final note, a quote I recall from Marcus Zarra‘s book on Core Data says:

The lesson I took away from that story is to expect my users to put thousands of times as much data into my application as I would ever consider reasonable

When working with large quantities of data, it is these kinds of optimizations that make your app more responsive and provide a better experience to the user.

But now you need people to buy it. You release a demo version of your software which allows your potential customers to get a feel for the app and decide whether it’s right for them, or not. And in doing so, you screw up the entire thing.

Where demos suck

It amazes me how many software companies get demo versions of their applications wrong. Demos aren’t a trial period for you of your users, but rather a trial period for your users of you and your software. And if you want to sell your app, you’d better make a good impression.

But time and time again, demo versions of applications aren’t done properly, and rather provide more friction for making sales than acting as a way of convincing your users that your software is worth them buying. Common areas where application demos fall down are:

1. You have to register an account to download the demo.
2. The emphasis is placed on purchasing the app rather than downloading it.
3. The demo places a crippling restriction on the software that doesn’t let you get a proper feel for it. For example, restricting major features.
4. There is a time limit on the demo which pressures users into purchasing the full version.
5. An annoying window prompting you to buy the app is displayed at frequent intervals.

All of these elements create a negative experience of you and your software, right from the very start. But what is it about some of these irritations that make such demos a bad experience for your users, and what are the alternatives?

1. Account registration

Everyone hates account registration. I – like most other people – already have too many online accounts, and to be quite honest, I don’t want any more.

But where this is even more of a problem for people who want to try out your apps before they buy is that you’re already putting rope around their neck. They may just want to try out your app but you are already asking them to make a partial commitment by signing up to try out the demo.

An example of this is with the FileMaker Pro trial download. Before you get a copy of the software to try out, you have to fill in a form, providing your name, address, operating system, and other market research questions such as how you heard about the product. This will be a huge turnoff for any potential customers because they will be less inclined to go through this entire process, just to see whether the application is something they’re interested in or not.

The solution to this problem is simple: don’t do it. On the main page for your app, place a prominent “Download” link which allows people to download your demo in one-click, no strings attached. This way they can see whether your software is relevant to them, without them feeling as if they’re being tied to anything.

2. Emphasis on buy, not try

Another problem with demo software is that the emphasis of the product is immediately placed on buying the software, not offering users to try it first. This ties in with making the users register to download the demo version first, or nagging for them to hand over their credit card details and is again, annoying because it ties them down and makes them feel that they are making a commitment rather than just trying out the software in their own time.

A good example of this being done well is on the Agile Web Solutions downloads page; it is clear that the focus of the section is downloading a demo version of the software to try out first, and not immediately placed on buying it, as shown by the prominence and alternate colour of the “Download Now” button compared to the “Buy It” button.

3. Crippling restrictions

Of course, some form of restriction needs to be placed on your demo applications so that people who have a genuine need or interest for your app can’t use it forever for free.

However, these crippling kinds of restrictions include things like restricting major features from the demo version, which is often counter-productive, because it doesn’t actually let your users see whether your software is right for them, since they don’t have access to certain features, which might be the main reason that they would be interested in using the full version.

Instead of imposing restrictions such as this on your demos, where possible it is better to provide some other restriction that allows your users to get a feel for the application, but perhaps provides an upper bound on their use of it. A good example of this is with LittleSnapper, which limits the number of images in your library in the demo version to 30, but so long as you have 30 or less images in your library you get access to all the other features available in the full version of the app.

From a business perspective, you want to make sure that the restriction you place means that people who are genuinely interested in using your software can’t do so forever without paying, but which doesn’t provide a barrier for those who aren’t yet sure to see whether the app is right for them.

4. Time restrictions

This is probably one of my main annoyances with demo applications – where time limits are imposed  on the use of the demo. The reason I find this such a turnoff is that it it similar to being sold something by a salesman on commission: there is constant pressure on you to purchase the full version rather than doing it in your own time.

Again, this seems attractive from the business side of software, and sometimes this may be appropriate, as there is no other justifiable alternative as a restriction on the demo, but this should only be used as a last resort.

And as Matt Gemmell suggested on one of the World According to Gemmell segments on the MDN show, if you are going to impose a time limit as a restriction, make sure that the time limit only applies to the days that the software is actually used. For example, if you impose a 30-day time limit and the user first uses the demo on the 1^st of the month, but doesn’t use it on the 2^nd, 3^rd or 4^th and comes back and uses it on the 5^th, only count that as 2 days of use, not 5.

5. Prompts to buy

This is probably my biggest annoyance of application demos: where they constantly nag you to purchase the full copy; be that on launch, on exit, or even just during use of the application, it’s a definite no and will not get me – and most other people, I imagine – on your good side.

As I mentioned earlier, application demos are a way for your users to decide whether your software is right for them, and whether it is worth their time (and money). But this is another really annoying feature of demos because it is again pressuring users to purchase your software, rather than letting them decide first whether it is right for them or not.

In this process, it provides your users with a negative experience, and pushes them in the opposite direction to buying your software.

Final word

Application demos are a way for the user to decide whether your software is right for them. It’s your one shot to impress them and convince them that your software is worth investing their time – in learning how to use the software – and money.

Although it might seem like a convenient excuse to offload a whole load of marketing onto your potential customers and pressuring them to make a purchase, this reflects badly on you, and if you offer multiple products they are unlikely to try out others if you create a bad first impression.

The key is to provide a user-friendly experience which portrays you and your software in a positive light; if the software is presented in this enticing manner and people have a genuine need or interest in your software then you are going to make some sales.

As developers, it is hard for us to detach ourselves from what we do and cater to the user. We live on the other side of the fence and are often restrained from making the right decisions because of the way we think, and usually need an objective opinion. We have the curse of knowledge by being so deeply focused in on our software, and what seems intuitive and easy for us is unlikely going to be the same for the people who use our creations.

Thinking from the user’s perspective

The amazing thing about a lot of usability and application design is that most decisions come down to simple thought of how your software is going to be used, and to anticipate and accommodate the user’s various needs. It’s about thinking “I shouldn’t put that text field there because the relation to that other form is confusing” or “I should relabel that button because the current label is misleading”.

As software developers, our main subjects are not computers (even though we do instruct them on what to do) but rather people. We have to be psychologists to some degree and accommodate their needs – our software of which is an end to a means.

The reality

As Matt stated on an earlier MDN show podcast, users want to spend as little time in an application as possible, so that they can get on with their lives. But because we have an affinity with the software we produce it is often hard to detach ourselves from the way we go about our business and think in this way.

Of course this doesn’t mean that we shouldn’t design and architect our applications in a maintainable way, and doesn’t mean that we should write crap code that looks like something the dog threw up. However bear in mind that the user doesn’t actually see any of this. To paraphrase Gemmell again, all the user sees of our applications is the interface.

At the end of the day, users couldn’t care less whether you have a PHP backend or the UI implemented using Rails; they have such a different perspective of what we create. What they care about is how your software solves their problem and how it makes their life easier by doing so.

It was the second and final day of the NSConference 2010 Mac Developer Conference and most delegates were tired and a little hungover. But there was another great line up of speakers for the day, and it was another day of socialising and fun, as well as all that other learning stuff.

Perhaps the biggest things I took away from the Mac conference was taking a pragmatic approach to anything which became a recurring theme in a lot of the talks – like yesterday’s conference, extremes were presented such as Dave on not using singletons, but at the end of the day it’s a judgement call and you shouldn’t do or not do something ‘because Dave said it’, but rather because it’s either right or not right for what you want to do. There was also some recurring memes, such as The Matrix and kitties, which snuck their way into certain presenters’ talks, but most of all, I learnt that people can be (fairly) civil when discussing version control, and also that the GPL sucks.

Jeff LaMarche – Writing Super Superclasses

Jeff was still jetlagged and tired, and made several comments as such throughout his talk. However, despite this, his talk on the Objective-C runtime was very interesting and informative to listen to. He started the talk off with a cliché – ‘you can’t see the forest through the trees’ – and likened this to software development. As developers we are often too pedantic and only focus on the little things, but we also need to be able to step back and look at our projects as a whole on a larger scale.

He then went into the guts of his talk, talking about such things as dynamic method resolution and introspection at a lower level. He introduced Objective-C as different from other languages in terms of the patterns used and also touched on a criticism by others that it is missing things, however this is by design and not simply an oversight.

He then started talking about his SQLitePersistentObjects project which leverages the Objective-C runtime in several ways, and then demonstrated some of these features such as dynamic method resolution using IMPs and was well explained with the associated pros and cons of using certain runtime features. Like many of the other talks, he explained the limitations of using the runtime, for example Apple may not approve apps for the App store that use it, and also to be pragmatic about its use and not simply use it because you can.

Andy Finnell – Brushing up on OpenCL

I’ll be honest, after listening to Andy’s talk, I felt stupid. And I think there were other attendees around the room who were in a similar boat. He opened up with a demo, which was a great start to his talk, a demo which simulated the effect of watercolours on a canvas, and leveraged OpenCL to provide the graphics and calculate the drawing of the pigment and the interaction with the surface.

Although the maths and physics was way above me (and wasn’t helped by lack of sleep) it was still an informative and interesting talk, and I liked the structure of the presentation – cool demo at the beginning which made you interested then the rest of the time spent explaining how it all worked.

Andy also opened with a short intro on OpenCL and how it operated which was nice for those who hadn’t been at Drew’s Concurrency workshop on Sunday, however it would have been nice for this section to be expanded a bit, with less of a focus on the mechanics of the demo.

The presentation was also entertaining with accommodation for British spellings (“watercolo(u)r”) which is always a nice touch and other comical remarks and slides which helped a bit when it came to digesting the hardcore code samples. The coding side was also a nice contrast from the higher-level talks that were presented over both days of the Mac conference which also made it a useful and informative talk.

Dave Dribin – Version Control System Shoot Out

[Apologies for not having an accompanying photo]

Dave’s talk was all about version control and mostly a history or comparison of the different VCS’s out there. There was a feeling before the talk that it could go horribly wrong but Dave kept it pretty objective and didn’t particularly favour any of the VCS’s.

He presented the history of version control systems first, with SCCS, RCS, CVS, SVN and other systems that use similar acronyms, before moving onto distributed version control with Git, Mercurial and Bazaar, quoting Linus’s talk where he explained the naming for Git: ‘I’m an egotistical bastard and I name all my products after myself, first Linux and now Git’. With all the version control systems he presented the pros and cons, and only discredited Git slightly. Overall a pretty well rounded talk for the allotted time of about 35 mins.

Graham Lee – Code Signing

Graham had been given the opportunity to present at very short notice, and it was very well executed. It was astounding the quality and detail of his talk despite the little preparation time that he had, and he had a great presentation style which was very entertaining. He also included lots of puns and other fun comments, such as a reference to a hypothetical harmful piece of injected code which he called Malicious Monster and also referenced as Malicious Library. For those who didn’t attend, the reference to the Matrix had become kind of a meme by this point and even though Graham had prepared his presentation in about 24 hours he still managed to fit it in.

He also did a live demo which was very useful and demonstrated some of the code signing in action; he also anticipated our needs well by cutting a few minutes short in aid of food. Overall a brilliant, informative presentation.

Aaron Hillegass – The Many Faces of Data Persistence

Aaron’s talk was – as you probably guessed – focused on data persistence and the what the options are on Mac OS X. He started off by stating ‘The file is dead’ and explaining how his HDD is essentially a cache for data that is stored in the Cloud, which prompted him to comment ‘Long live the cache!’. He used the example of iWork on the iPad in that it uses a “Library” to store files which is essentially an abstraction for the filesystem and that this is the way forward.

He then went on to talk about archiving in Cocoa and Cocoa Touch, discussing Keyed vs Unkeyed archiving and the associated pros and cons. He also presented a timeline of events in terms of data persistence, from the early 90’s with NeXT right up until Core Data in 2005. He presented some nicely formatted object graphs of some of the Core Data things which was also useful.

He spent most of the second half of the presentation talking about his new data persistence project, BNRPersistence, which provides classes that wrap Tokyo Cabinet which is used to store the data, which received much applause from everyone when he announced that it was open-source, available on GitHub, and not licensed under the GPL. It was certainly an interesting project and he had some numbers for certain cases compared to Core Data and it performed much faster. But he was dealing with object graphs that had 1K and 1M objects and for “everyday” use with smaller objects it was unclear whether BNRPersistence would be better than Core Data because he didn’t have any figures on it.

What I liked about Aaron’s talk which I don’t think any of the other speakers did was that he was more engaging with everyone whilst he was talking – his style was like a lecture, but he periodically checked that we were all following everything, something which I guess comes from the teaching which he does, and was a nice touch.

Cocoa Rumble

The rest of the allotted time had been reserved for something different, in the form of a “Cocoa Rumble”. Earlier in the day, Scotty had announced that people could put their names in a hat to be chosen for this mystery event. Names were picked out of this hat and each person chosen was assigned a speaker from the conference.

The combined speakers and delegates were then split up into three groups and had to pick from the hat which now contained another set of slips of paper, which had written on them different “Core–” frameworks. The three chosen were Core Text, Core Audio and Core Image, and the teams had some time to prepare a presentation for why their framework was the “Core of the Year”. All presentations were very entertaining, with talks from Mike, Wolf and Graham and at the end, Core Image (presented by Graham) won for the compelling reasons that he had put into a table.

Whilst the teams were preparing, there was also a chance for the speakers and some of the delegates to provide tips, and there were some great tips from such people as Uli who provided a load of cool Xcode tips, Aaron on having the old Xcode documentation browsing behaviour, and Jeff on conditional build settings.

A nice fun end to the day, with something different and all in the community and social spirit.

Final thoughts

It was my last day of NSConference and what a brilliant conference it had been, with Matt Gemmell’s workshop on Sunday and the Mac developer conference too. It was great to socialise with loads of Mac developers who were all really friendly and I entered into some interesting discussions, and I took a great deal away from the conference which was something that Scotty laid out as one of the goals at the beginning.

I would like to thank Scotty, Tim, Dave, Rob, Simon and all the other people who made NSConference possible, because it was a great experience indeed, and to all the great people that I met there. Thanks also to Uli for setting up the NSConference Reflector.

It was the first day of the NSConference 2010 Mac developer conference and a great lineup was ahead.

In terms of the day generally, it was a brilliant experience. It was well organised and many thanks go to Scotty, Tim, Dave and all the other NSConference staff. The WiFi (although irritating that you had to keep filling out the signup form) worked quite well and you could get some pretty good speeds, which was good considering that the room was filled with over 100 developers, almost all of which I imagine had a Mac or iPhone for most of the day.

It was also a great social event, and the breaks were a nice chance to go around and talk to someone you’d never met before and have some interesting discussions. It was also nice to be in this tight community, separated from all the “normal” people who were also around at the venue.

In terms of the talks generally, I felt that they were all very well done and it was clear that they had put a lot of work into them. The presentations were very well laid out and simple, and not wordy and the speakers all obviously knew what they were talking about and had lots of interesting things to say. However one big thing that I felt could be improved on was the interaction with the audience – that is, many of the slides were in more of a lecture-style and although a couple made up for this with a Q&A at the end I thought this could be improved upon.

Scotty – Conference Introduction

Scotty kicked off the morning with a nice introduction to the conference, welcoming everyone and thanking us all for being here. He presented his recent case of being rushed into hospital for a “routine” operation as a metaphor for what we’re doing here, and he explained how even though he has little knowledge of the detailed ins and outs of the medical profession, he had a respect for them due to the reputation that the collective members have earned over the years. This was related to Mac development and our collective ‘responsibility to the platform’ and what we do, and the expectations of the Mac or iPhone platforms which is ultimately our responsibility. He also talked about how there is pioneering but also sharing of ideas in the medical profession and again linked this to our role in the Mac/iPhone/iPad community.

He also went on to talk about the community spirit, and emphasised that all the speakers had given up their own time (and money) to be here which because of this, and was a nice to start the day.

Mike Lee – Conference Keynote: Engineering Life

Mike’s presentation was evidently something slightly different and original to start the day but was a nice sideline to our ability to crank code, and was more thinking at a higher level about what we do, and perhaps being a bit more philosophical about it. He was relating what we do and our profession to life in general, and how we can ‘engineer life’. He defined problems as ‘reality we do not like’ which was a topical tie-in with software development since problem solving is one of the key aspects to what we do.

Mike also used several anecodes during his presentation which brought in a realistic sense rather than something purely theoretical, reality which is often missed when talking about software and software development, with purely theoretical statements. He also likened the Universe to a computer in that both are simply entities which are constantly changing state.

The next part of the talk became perhaps a little morbid with discussion on ‘Death 101’ with the conclusion that ‘death sucks’ but you can’t really do anything about it and you’ll be dead in the ground so won’t care about it anyway. However he also likened this to fear and how you can engineer your way around fear and tackle it head-on rather than let it get the better of you. He also talked about having a legacy and a part of you that lives on when you die by accomplishing something that you are remembered for, which can perhaps give you a kind of immortality.

He finished on the note of ‘be the hero’, and overall the talk was an interesting and somewhat unusual. I heard later on that there was about a 50/50 split on people who liked/disliked the presentation but I thought it was an interesting, though-provoking topic and good to be a part of.

Wolf Rentzsch – Spelunking OS X

Wolf started with the statement that he had ’90 slides in 60 minutes’ and it was pretty fast-paced, although for the most part fine to follow. He dug into Mac OS X under the hood and ways you can access this information and interact with it, introducing such tools as otx, otool and class-dump.

The low-level nature of his talk was a great contrast to Mike’s previous talk which was a demonstration of the breadth of talks within NSConference and was more of a code and tool-based talk. He introduced hexadecimal editors such as HexFiend, which ‘are your friend’, then went on to deal with different sections with prying into OS X internals such as static analysis with strings and files, and code injection.

The great part of presenting these tools was the accompanying screenshots of a terminal and the associated output, and also examples of useful commands and how they could be used, which was probably the killer feature of the presentation for me. He also had a clear presentation style and after talking to him later at the bar was a nice, bubbly person to talk to and obviously knows his stuff.

As a suggestion for improvement it would have been nice to see a live demo of some of the tools in action – he had some screenshots of probing applications such as TextEdit, but a live demo of the tools live would have been a nice addition.

Dave Dribin – Clean Code

I think that Dave’s presentation was perhaps my favourite of the day and talked about different ways of writing clean code and bad ways that can introduce “code smell” and ways to get around this and I agree that it is an important part of being a programmer.

He used the analogy of the iPhone as a way into the presentation; with the divide between internal and external quality – the external beauty is the interface that is seen by the user but the internals are the code that we write and sits behind the scenes. With an application it’s the difference between a beautiful interface and the underlying implementation of that in code.

The presentation was filled with quite a lot of tips, such as guidelines on naming classes and common principles such as DRY (Don’t Repeat Yourself) and OAOO (Once and Only Once) with the example of using enumerations or constants for dictionary keys instead of repeating strings throughout your code.

The Q&A was also useful and for most of the other talks there wasn’t time so it was a nice feature to be able to ask questions about the content discussed.

Drew McCormack – Data Presentation in Mac Apps

Drew lead into the presentation by talking about his scientific background and explaining how different data can be displayed and visualised in different ways. His presentation was also nice because it was one of the ones that wasn’t directly related to churning code and was more about the UI and talking about the various controls – standard or custom – and where they are best used.

I liked the format of looking at these different controls – he presented images of each and then talked about the advantages and disadvantages of each. This was particularly useful when comparing controls, such as the NSTableView and the NSCollectionView, and his slides were perhaps the best of the day and contained very little text on them, just visual cues such as images and the likes.

To this end I learnt a lot about how different views are implemented – he explained using Tweetie (Mac) as an example that it uses an NSTableView to display its list of data, and also Versions implements some of its custom controls using HTML, CSS and Javascript with WebKit.

Near the end he did talk about non-standard controls and focused on drawing graphs with CorePlot. However he spent quite a long time talking about this, which although interesting it would have been nicer if he’d demonstrated a few more, different controls.

Marcus Zarra – Core Animation

Marcus started his talk by explaining how Core Animation wasn’t just for designers, and used himself as an example of a non-designer, but that it could still be used to enhance or help create sleek interfaces. However he also warned that Core Animation can easily be overused and turn a simple, clean UI into something horrible and even very unintuitive. He also explained how Core Animation, although its interface is quite simple, it is also very powerful.

He gave a few examples of using Core Animation, and then gave a live demo of an application that was doing lots of complex animations using Core Animation and how smooth and seamless they all were. It was evident that he had spent a lot of time on the project and he explained how the rotating gears displayed were constructed as paths which was a nice touch to the talk, to get a real demo application.

However even though he had an hour slot, he only used about 35 minutes talking and left the rest of the time for questions, which was quite a nice idea since it was more engaging with everyone rather than simply a lecture. However, it would have been nice for him to use more of his allotted time to show some more Core Animation examples.

The first day of NSConference 2010 kicked off with two workshops – Concurrency Programming on Snow Leopard by Drew McCormack, and The World According to Gemmell, by the Legend himself, of which I was an attendee.

The session started with a discussion about a certain recently released Apple product which was very interesting and allowed us to present our thoughts on the device. We covered such areas as the human psychology behind it, the display of “real” objects as the interface and the much more emphasised touch interaction including two-handed UI, as well as getting “wanky” about the emotional connection with the device.

Andy had also created a great model of the device, that was the exact dimensions (although the back didn’t slope like the real thing) and half the weight of an actual iPad. This was really useful in the talk from Matt, when he was explaining such things as how people would hold the device.

We also discussed the changing seeds of user interfaces and the switch away from clutter-based interfaces, such as inspector panels which ‘can edit anything that has ever lived’.

Our workshop

A few weeks ago Matt sent an email round to all the workshop attendees asking whether we had any UX topics that we wanted to discuss that could form the basis of the workshop. This was a great structure and in the session we got through 7 or 8 discrete topics, from such topics as the evolution of your app and removing features to when the best time to release your 1.0 is.

Although Gemmell said that he had put the slides together quickly and a bit haphazardly (and Scotty had been fiddling around with the slide animations*), the slides were well arranged, and contained only a few – although thought-provoking – bullet points for each topic, and allowed us to really discuss the ins and outs and how one would go about dealing with these problems. The workshop dynamic really helped this section and the group discussion bit was great as we could all have our opinions heard and commented on, with Matt being the suspiciously-bearded ringleader of the event.

Workshop dynamic

Matt’s talk was arranged as a workshop and consisted of around 30 people. The tables had also been arranged into groups of about 5 or 6 and all of this combined made a great, much more personal dynamic for the session, because as Matt himself put it, we were all participants and it was our workshop, not just his.

It was a great social occasion to this end, and allowed for group collaboration which was a real strength of the workshop and made it a really enjoyable event.

Final thoughts

A brilliant first day to NSConference and a great thought experiment with lots of things to take away and think about. As I mentioned when speaking to Matt in one of the breaks, the Mac/iPhone/iPad platforms are so brilliant partially due to the fusion and interwoven nature of code and design, the latter of which is given a lot of thought in most instances, which made the workshop a very topical and interesting one indeed.

The Mac conference (Monday 1st Jan – Tuesday 2nd Jan) has a lot to live up to but a great start to what I’m sure will be a great conference.