The design process attempts to address objectives, within a multi-dimensional space of constraints. Within the particular dimension of any given constraint, there may exist an optimal solution. But within a multi-dimensional space, the design solution will sit at some (hopefully optimal) intersection.

It’s highly improbable that that intersection will coincide with the optimal solution in every constraint dimension, and so the design solution in the multi-dimensional space implies compromise in each individual constraint dimension.

So in the sense of “trade-offs”, compromise is already inherent in any non-trivial design activity.

To complicate matters, the relative arrangement of these constraint dimensions are not assured to be static, as they can be influenced by priorities, and priorities can shift throughout the lifecycle of a design activity. In response to these shifts, we must be prepared to accept compromise, in the sense of “negotiation and agreement”, as part of the process as well.

And we can’t wait to tell you about it!

The background

In 2007, Makalu was engaged by The Ecology Center of Berkeley, California to design and build a website that would provide American consumers with an effective tool to combat the growing number of unwanted catalogs they receive in the mail. The website — CatalogChoice.org — was launched, and quickly received the attention of nearly every large media channel in the United States, including a focus spot on “Good Morning America”.

Within one year, the service signed up more than one million members.

When Catalog Choice members receive an unwanted catalog, they login to their account, search for the catalog they received, and register an “opt-out” request. At that point, the Catalog Choice system acts as a powerful agent on behalf of the consumer to get request processed by the sending merchant. In this way, the consumer saves the effort of having to interact with individual companies, and benefits from the effectiveness the influential service has in getting their requests honored.

Through use of Catalog Choice, consumers reduce clutter and simplify their lives. And on the collective scale of millions, the service is helping the environment by considerably reducing the natural resources used in the production of unwanted catalogs.

Re-engaging with our friends

After Catalog Choice’s first year, when it was clear that a market existed for the service, a dedicated non-profit was formed, at which point The Ecology Center and Makalu handed the project over to the team that was established to manage and operate the service moving forward.

Five years later, we’ve re-engaged with our friends at Catalog Choice to:

1. Redesign the website, harmonizing the contextual changes and features that have evolved over the past half-decade, and to

2. Design and develop an iPhone app, which is the first in a suite of premium products known as, MailStop.

We’ll first take a look at the website redesign, and then look at the iPhone app.

Catalog Choice website redesign

Over the years, the service has expanded beyond catalogs, allowing consumers to opt-out of all types of unwanted mail — everything from credit card offers, to phone books. In addition, the service has established special relationships with local communities and townships throughout the United States, which are reflected in various ways throughout the site. Accommodating these changes, along with the introduction of a set of premium services, necessitated a fresh look at the overall site architecture and design.

The service is preparing to launch the new design, which so far has addressed the home page, and the purchase workflow related to the new MailStop products. We focused on simplification, higher sign-up conversion, and clearer communication of the service’s message.

We’re thrilled to show you three sneak-peek screenshots of the new look:

We’re really happy about the design, and looking forward to seeing its launch, and extended implementation throughout the site.

The MailStop iPhone App

The MailStop suite was conceived as a set of premium add-on services that both extend the ways in which consumers can be protected, and make using the existed Catalog Choice services even easier.

In that regard, Makalu was engaged to design and develop an iPhone app that saves consumers the effort of even having to login to the website. Having purchased opt-out credits (as an in-app purchase), users of the service can simply capture the relevant information related to their unwanted mail in images, and submit them directly to the service. Catalog Choice takes it from there.

With the MailStop iPhone app, it couldn’t be easier to opt-out of unwanted mail!

The design process

The experience of RaceSplitter and Rebalance (still ongoing) has taught us that it’s far more time consuming and expensive to change app code than design mockups (when, for example, you realized you’ve gone in a wrong direction), and so with the MailStop app, we went much further into the UI design than we have in the past, before starting the development.

The results were good. We found that a reasonable level of discussion and review were, in fact, possible around just a set of mock-ups, as opposed to playing with a working prototype. On the other hand, it wasn’t perfect. Although it was possible to satisfy all the requirements and constraints in abstract design, once the product came to life in the form of a prototype, we realized that no matter how careful you are, you can never completely appreciate the subtle interactions and frictions that make themselves apparent when actually using a product.

For example, during the design process we iterated six times on the workflow in which a user captures “up to” three images to capture three critical pieces of information (the catalog name, mailing label, and merchant data.) How do you efficiently communicate to the user that they can take up to three images, but that one is often sufficient? Given that they are to capture three pieces of information, the risk is that they assume they must take three photos.

As you can see in our screenshots below, our solution feels more described than direct, and that’s an important disctinction. The designed solution works, but it’s not perfect. We’ll take the opportunity in version 2 to design something which feels more direct and intuitive, and better avoids the potential correlation in the user’s mind of the number of photos available, and the number of information pieces we need.

The design and development process, however, was definitely an improvement over the experience we had with RaceSplitter (in which we built prototypes too early). We’re pleased with the results, but we didn’t yet hit the sweet spot; and so there’s process improvements still to be discovered.

A visual tour of the app

And with that, we’d love to show you the app, with this 10-image tour.

Look interesting? Why not give it a try right now? It’s free, and available today on the App Store!

The changing rooms in many retail outlets are surprisingly overlooked, when you consider they’re often the place at which a consumer makes the final purchase decision.

• Many retailers start off the experience by suggesting you’re an unwanted thief. You have to ask for a key, because all the doors are locked. And don’t think about taking in more than three garments at a time.

• Some have curtains, rather than doors, which can leave the timid a bit too focused on preventing the world from getting a sneak peek at their backsides. The good places have solid doors, that make a comforting clunk when closing.

• Often, changing rooms provide nowhere to place the clothes you’re taking off. Who wants to drop their clothes in a big clump on the floor? The good places provide hangars, a bench or a shelf. (And this concept can be extended to other consumer needs we can anticipate — like what to do with the 22 pins evidently required to hold a folded shirt in place.)

• And last, but definitely not least, there’s the lighting. How do they get such an obvious thing so wrong? We’ve all been there, getting half-naked in a changing room lit by cheap florescent bulbs, casting their light down at just such an unflattering angle that one glimpse in the mirror provokes a quick decision that the more prudent purchase would be a gym membership.

We seem to have done well, which is great, except for one thing — we’ve never been able to shake a nagging feeling of dissatisfaction. Although we’re doing good work by external standards, we know deep down that we’re not doing our best work, by our own standards.

Is it something we should just accept, or should we do something about it? In case others in our industry might share in this internal tension, I decided to put our thoughts into an article to share.

Doing great work

Doing really great work requires focus — getting in the zone, and staying there, uninterrupted, until you come to whatever milestone makes sense in the context (a wireframe, a mockup, a prototype iteration, or a blog article.) And, unfortunately, you can’t know in advance exactly how long it will take to get there. You might know it usually takes a day, but sometimes it takes three.

So to create great work, we need uninterrupted focus, for as long as it takes.

Running a services business

Customer engagements (even if you’re your own customer) introduces constraints that work contrary to producing ones best work.

The owner of a services company can, through policy, control some of these constraints. When talking with potential customers, you can communicate that your company’s mission is to do great work, and therefore you avoid certain things. In our case, that would include fixed-price projects, and projects involving severely limiting budgets or time contraints. We’ve done a good job sticking with this policy.

But what we haven’t been able to avoid, is the necessity of working on multiple projects in parallel.

Project concurrency to address idle time

All service projects involve idle time, such as when a customer reviews an iteration, or when a delay is introduced. We could try to forcibly manage flow by contract, but nobody likes that. Both customers and providers appreciate a process that allows projects to follow their natural dynamic, and reasonably accommodate the unforseen. So we accept that (sometimes unpredictable) idle time is part of our way of doing business.

So how can we address the cost impact (and profit loss) of idle time? Our approach has been to operate multiple projects in parallel, for a given team, in an effort to keep our resources busy. It doesn’t eliminate idle time, and it introduces its own challenges, but it’s the best approach we’ve found.

Of course, if we take on too many projects, we’ll end up the source of project delays, and we don’t want that. We’ve found, through experience, that things go well if we take on no more than two projects at a time, per team.

Effort scheduling

So we’re working on two projects, each of which has some current milestone that we’re working towards. How do we schedule our time?

We’ve tended to schedule our time weekly, by day — Monday (Project 1), Tuesday (Project 2), Wednesday (Project 1), Thursday (Project 1 & Project 2), Friday (Project 2) — taking into account, as best possible, the various needs of each project.

(Since we don’t know how long it takes to get to a milestone, and if we insist on providing at least a minimum level of quality, then a consequence of this planning is that we can’t tell Client 1, “We’ll finish XYZ by Monday night.” Instead, we can only say, “We’ll be working all day Monday, Wednesday and half of Thursday, and we think we might get to XYZ.”)

This loading (two projects at once) and planning strategy has worked well during the past few years — we haven’t gotten terribly behind on any project, we’re maintaining a consistently high ratio of chargeable/non-chargeable time, our customers have all been happy, and we’ve remained profitable.

But, there’s that darn elephant in the room.

At the end of the day, we just don’t feel satisfied. We try to soldier on, but it keeps popping up. We keep asking ourselves, “We only have one life to live. Are we really OK with not doing our best?”

A new approach — scheduling in blocks of a week

Analyzing things, we suspect that the focus (essential to great work) lost with daily (and sometimes mid-daily) context switches is just too consequential. Knowing that we’re switching context so frequently seems to create too strong a feeling of urgency, encourages taking shortcuts, and going with known patterns instead of pushing the envelope. It seems to lead to good enough.

To address this, we’re going to try experimenting with planning things in blocks of a week — i.e. Week 1 (Project 1), Week 2 (Project 2), and so on. We’re hoping that focus blocks in units of weeks will give us enough time to reflect and explore, allowing us to get deep enough to make the work great.

That’s the target, at least. I’m sure it’s going to prove easier said than done. Implementing this will imply both economic and scheduling concessions on the part of our customers. But, if it gets us closer to doing our very best work, maybe it’ll prove worth it — for both us, and our customers.

We’ll see, and I’ll report back.

We designed similar ads (and ran similar multi-ad tests) on both platforms, and ended up with about a 0.012% CTR at Facebook, compared to about 0.900% at Google. In absolute terms, these are probably not great numbers; we’re pretty new at running online ads. But since the ads ran on both platforms were almost identical, the comparative performance is interesting.

Our initial expectation was that Facebook might outperform Google. Why? While both platforms allow you to target your ads, Facebook gives you the ability to very precisely target your audience. Want to only show ads to people between the ages of 25 and 40, who live in the US or scandinavia, and have expressed an interest in the coaching of nordic skiing? With Facebook, you can do it. We imagined that putting our ad in front of precisely our target audience would be optimal.

So why did Google outperform Facebook? We can only speculate, but our guess is the following: It’s more valuable to target what somebody is doing, rather than who they are. When a Facebook user sees our ads, it’s unlikely they’re looking for something; rather, they’re more likely to be socializing. When someone on Google sees our ad, however, it’s while they’re searching for something, and probably something relevant to our product (since our ads are targeted to specific search terms).

Of course, this is far from scientifically conclusive. A portion of our Google ads appeared on networked sites, and perhaps Facebook ads shouldn’t be designed like Google ads. But in hindsight, the logic make sense, and the comparative data was very interesting.

Today, a new review came in from iTunes — giving the product “one star”, i.e. essentially saying it couldn’t be any worse. Let’s take a look at user WEDALLARD’s review of RaceSplitter (in an iTunes view that also shows us his other product reviews).

If I could figure out how to contact this person, here’s what I’d have to say:

1. I needed a timer that everyone can see. The timer does not come on the full screen. I can only presume you’re talking about some sort of projection system at the event? Where in our product description or website have we advertise that the product “comes on the full screen”? This comment is equivalent to buying a Honda Civic, and giving it a one-star, because, “I actually needed a bus; I can’t fit 32 people inside at once.”

2. I don’t want to input racers. Would like to use an excel file. We have never claimed that races in RaceSplitter can be built from Excel spreadsheets. (That would be a cumbersome thing to do in an iPhone app.) But here’s the thing — we actually support doing just that from our website! If you visit RaceSplitter.com — and this is clearly stated in the product’s tutorial section — you can create a race from Excel data that can be imported into RaceSplitter.

So, thank you, WEDALLARD, wherever you are, for giving our product the worst possible review — and possibly influencing future potential customers — because it doesn’t do something it never claimed to, and because of your own oversight of a feature we actually do support. And thanks for submitting that review without even having contacted us (we’re also known for excellent, fast customer support).

Looking at his other reviews, I’m inclined to think this is just some kid, but this reflects something I feel is fundamentally broken in the iTunes system — there’s no way to have such reviews removed, and there’s no way for the product owner to follow up with the reviewer.

Coming from a company who’s major product upgrades over the past years have included new features along the lines of, “Enhanced Toolbar Icons”, and “Includes free copy of Stuffit Expander”, my hopes weren’t high.

And it’s a good thing they weren’t. The email pointed to this page of insulting corporate speak.

I’ll do you the favor, and translate it here to plain English.

Will Quicken for Mac work on the new Mac operating system, Lion (Mac OS X 10.7)?

Currently, Quicken for Mac 2005, 2006 or 2007 will not work on Lion. However, Quicken Essentials for Mac will work on Lion. If you are using Quicken Essentials for Mac, make sure you are on the latest Quicken Essentials patch version for full compatibility.

To answer the question — does Quicken run in Lion — uh, no. But wait! To answer a different question — does Quicken Essentials (a different product) run in Lion — YES, YES, YES! And we love to end with Yes!

Why will Quicken for Mac not work on Lion, Mac OS X 10.7?

Quicken for Mac 2005, 2006 and 2007 were originally built for the older PowerPC architecture, and were able to run on newer Intel-based Macs due to an Apple technology called Rosetta. As of Mac OS X 10.7, Apple has discontinued support for Rosetta.

You see, it’s not our fault. It’s that blasted Apple! They’re pulling Rosetta right out from under us, just like they did with the floppy drive! Nearly a decade just wasn’t enough time to get our software updated. So blame them!

What are your plans related to personal finance solutions for Apple customers?

We are committed to supporting Apple products and our Mac customers. We are actively working on a personal finance solution for the iPad, as well as continuing to deliver the highly rated Mint.com iPhone application. In addition, we are evaluating options for Quicken Essentials for Mac.

We are committed to the Mac, until we decide we’re not. And the iPad looks pretty hot, so we’re committed it to, for now at least. And you remember Mint, that service you’ve heard nothing about since we bought it? We’re committed to it too. And, we’re committed to thinking about some other stuff as well.

What are my options?

If you do not plan on upgrading to Lion (Mac OS X 10.7), no action is required. You can continue using Quicken 2005, 2006 or 2007 as is.

We never upgraded our software, so maybe you shouldn’t upgrade yours.

If you plan on upgrading to Lion, you have a few options.

Try Quicken Essentials for Mac – For a limited time you can receive 50% off the regular price! This option is ideal if you do not track investment transactions and history, use online bill pay or rely on specific reports that might not be present in Quicken Essentials for Mac.

This option is ideal if you never used half the features of Quicken!

Try Mint.com. You can set up an account in less than 5 minutes. This option is ideal if maintaining your transaction history is not important to you.

This option is ideal if you don’t mind starting over!

Move to Quicken Windows. You can easily convert your Quicken Mac data with the exception of Investment transaction history. You will need to either re-download your investment transactions or manually enter them. This option is ideal if you use Quicken to track investments.

Intuit is committed to completeness, and in the interest of completeness you gotta admit this is an option. (And, as with the other options, it’s ideal if you don’t mind losing your investment data.) And if you went for this option, you could buy a Zune.

I wish Intuit could have just manned-up, and wrote the truth. It’d probably go something like this:

So, yeah, Apple are removing Rosetta from 10.7, and that means, unfortunately, that Quicken for Mac won’t run any longer.

If you know anything about software development, you’ll know that as a software product evolves over time, especially as it’s passed from developer to developer, it grows in complexity.

We’ve been evolving Quicken for almost 20 years, so just imagine. It’s a god-awful mess of spaghetti code now, and there’s actually not a single person at Intuit who understands it anymore.

So, getting Quicken for Mac to run under Lion would require a complete rewrite, from scratch. And that’s just not something we’re interested in doing.

There are some options, except for those of you who have been tracking investments. For those, you’re unfortunately out of luck.

We know this sucks for you, and we’re sorry. :-(

1. Expensive — Contracting a professional chip-timing service, the cost of which can easily exceed 1,000€.

2. Painful — Manually recording times, using a stopwatch and paper, or typing into an Excel spreadsheet on a laptop.

An exciting new option exists that costs a fraction of a professional service, is convenient and easy to use, yet provides high quality, reliable results.

INTRODUCING RACESPLITTER

RaceSplitter is a new race timing application for the iPhone, iPad and iPod Touch, available for purchase in the iTunes Store for a one-time cost of 20€.

RaceSplitter includes everything an organizer needs for DIY (“Do it yourself”) race timing:

1. Build the race — Easily build a race online (race configuration and start list) at RaceSplitter.com.

2. Import the race — Import the race into RaceSplitter on the iPhone (or iPad, or iPod Touch). Last minute changes? No problem; updates can be made in seconds.

3. Time the race — As racers cross the finish line, type their bib numbers into RaceSplitter, and record their times.

4. Publish Results — After the race is over, tap a button in RaceSplitter to instantly publish results to RaceSplitter.com.

5. Share & Print — Online published results are immediately available to print and/or share with everyone.

BENEFITS TO THE ORGANIZER

• Reliability — applications running on the iPhone are highly reliable, and the battery life is easily compatible with the race length.

• Ease of use — in the heat of the race, you don’t want to find yourself confused. RaceSplitter was designed, and extensively tested, for ease of use.

• Fast information — RaceSplitter continually displays current race standings, and online published results are instantly available for browsing and/or printing after the race.

• Flexibility — RaceSplitter supports mass start races, as well as races involving wave or interval starts. It even supports racer “compensation” for events involving handicapped/disabled racers.

UNLIMITED INTERMEDIATE TIMES

Once a race is built at RaceSplitter.com, anyone given the web link to the race can download it to their own copy of RaceSplitter.

Organizers of trail running events love this feature, as it allows them to have several people on the course, recording intermediate times of racers at interesting locations — for example, as they pass some mountain peak.

Once the race is over, each person timing the event with RaceSplitter taps a button to instantly publish their results to RaceSplitter.com — which combines them all into a single set.

Viewing these combined results, it’s possible to see the evolution of each participant’s position throughout the race!

Achieving such functionality with chip timing systems is logistically difficult, and very expensive. With RaceSplitter, all you need is a few iPhones or iPads.

IS IT REALLY THAT EASY?

Absolutely. All a race organizer needs to conduct their own timing is a copy of RaceSplitter (20€) and someone with an iPhone, iPad or iPod Touch. That’s it. Really.

CASE STUDIES

RaceSplitter has been used extensively in trail running events. The following case studies include published results and blog articles (if you want to read more).

Case 1 — Copa de España en Sierra Elvira.

RaceSplitter was used as the backup timing system at the Sierra Elvira Spanish Cup trail race. Four times were recorded by three people with iPhones — as the racers arrived at the highest peak (twice during the event), as they passed the last water station, and as they finished the race. Results were published here:

• Results:http://racesplitter.com/results/9C9759D2B
• Blog: http://bit.ly/jEYhyu (English)
• Blog: http://bit.ly/jJTNVB (Spanish)

Case 2 — INFINITA Ultra Trail.

The company organizing the INFINITA Ultra Trail event in Cortes de la Frontera chose RaceSplitter for the timing of their complex, three race event.

• Results: http://racesplitter.com/aventyevent
• Blog: http://bit.ly/ksqmJh (English)

After the race, event organizer Ramiro Rejón commented, “Once they see how easy to use, yet complete, this solution is, every trail running organizer in the world will use RaceSplitter. Guaranteed!”

Case3 — Carrera Montaña Sierra de Ubrique y Benaocaz.

RaceSplitter was used at the primary timing system at the first mountain race in the Sierra de Ubrique and Benaocaz, Spain. At this event, one person with an iPad took an intermediate time at the 11km point, and another person with an iPhone took the finishing times.

• Results: http://racesplitter.com/results/76B7B5A03

Case 4 — Carrera Popular de San Pedro

Since it requires typing in bib numbers as racers pass (or finish), RaceSplitter wasn’t designed for races in which very large groups of participants finish together. However, the cost savings are so compelling that even organizers these races are now choosing RaceSplitter.

They channel finishing racers into a single file line, where they record their bib numbers with RaceSplitter — thereby getting the finish order exactly right, while trading off the recording of an approximate finish time.

This was the case for the recent 7km “Carrera de las Aguas” road race in Istán, Spain.

• Results: http://racesplitter.com/results/C0326FA5A
• Blog: http://bit.ly/k5rhar (English)

FOR MORE INFORMATION

If you organize races — professionally, or just as a hobby — you really need to check out RaceSplitter! For more information, visit:

http://racesplitter.com

…or send an email to Matt Henderson at support@racesplitter.com

http://infinitaultratrail.es

CHOOSING RACESPLITTER

To better understand RaceSplitter’s usage, Ramiro met me at the “Carrera de las Aguas” event in Istán, where we setup and timed the race together. Having used the product in a real event, Ramiro decided that he wanted to use RaceSplitter, but his partners were still apprehensive; it’s a new product, requires manual data entry, etc. Can it really be trusted for such an important, commercial event?

I encouraged Ramiro to just go for it, and join the hundreds of organizations successfully “doing it themselves” with RaceSplitter. Considering the cost savings — a one-time 20€ purchase, compared to over 1,000€ to contract a professional timing service — Ramiro and his partners decided to trust their race to RaceSplitter.

Still a little uncomfortable, I agreed to join them for the event, and lend a helping hand.

THE SETUP

One of the reasons Ramiro and his partners were apprehensive about using RaceSplitter, related to the complexity of the event they were planning. The INFINITA Ultra Trail would actually include three concurrent events:

1. A 13km trail run.

2. A 42km (marathon) trail run.

3. A 10 hour ultra run.

In the interest of the spectators, the course consisted of three loops, each of which began and ended in the Cortes sports center:

1. A 13km mountain trail loop. All participants, in all races, would run this course at the same time — starting at 6pm on Saturday afternoon. Those who would only run 13km wore a blue bib.

2. A 29km mountain trail loop. Those participants in the marathon race, having completed the 13km loop, would leave the sports center and start out on this second mountain trail loop of 29km. These participants wore a red bib.

3. A 5km urban loop. Those participants in the Ultra race, having completed the marathon (i.e. having completed both the 13km and 29km loops), would immediately continue running the 5km loop — as many times as possible before the overall 10 hour time limit, with the winner determine by the number of loops ran. These participants wore a black bib.

We decided to organize the RaceSplitter timing by creating three separate races.

1. In the 13km race, only the blue bib participants were included in the start list.

2. In the 42km race, all the red (marathon) and black (Ultra) bibs were included, since it would be possible that an Ultra participant also ends up being a podium finisher in the marathon event.

3. For the Ultra race, we only included the black bibs.

On Friday evening the three races were created online at RaceSplitter.com by uploading a CSV file containing each racer’s name, bib number and category. Ramiro, JuanMa and I each downloaded the races to our iPhones (and my iPad) and then imported them into RaceSplitter.

When I arrived to Cortes on Saturday morning, a few changes and additions needed to made. We logged into Ramiro’s account at RaceSplitter.com, made the changes (adding a couple of participants, changing the category of others).

When finished, RaceSplitter.com emailed each of us fresh copies of the race files, which we all imported into RaceSplitter. At this point, we were ready to go.

TIMING THE EVENT

At 5:30 pm — 30 minutes prior to race start — one of the marathon runners decided he wanted to participate in the Ultra. Ramiro initially said no since we were so close to start time, but then I told him it’d only take 5 minutes to update RaceSplitter.

Using the “Personal Hotspot” feature of the iPhone 4 to create a wifi network, we used my MacBook Air to connect to RaceSplitter.com, and make the change to the race files, which were automatically emailed to myself, Ramiro and JuanMa, at which point we quickly updated our copies in RaceSplitter.

The update took less than five minutes; no problem!

At 6:00 pm, all three races were started. On my iPad, I started the 13km race, and the 42km marathon in RaceSplitter. The idea was that I would time the 13km participants arriving, ignore the 42km as they passed the 13km point, and then switch races to time the 42km racers a few hours later when they’d returned from the 29km second leg of the race.

JuanMa started the Ultra race on his iPhone. (We had agreed that I’d time the 13km and 42km races, and then head back to the hotel, while he stayed on until 4am timing the Ultra runners doing their laps.)

Given how hilly the 13km course was, it occurred to me that racers would not be arriving in large groups, and so I decided to try to time all the arrivers — both 13km racers (finishing) and the 42km at their 13km split point.

Turned out, this worked fine. I was able to easily switch between the two active races, and time the participants in their appropriate races (remember, their bibs were color coordinated to indicate to which race they belong.)

PUBLISHING THE RESULTS

After the last 13km runner arrived, I stopped the race, and immediately published the results to RaceSplitter.com:

http://racesplitter.com/results/92C9F97CC

Ramiro, with his own wifi connected laptop, accessed this page, and printed out all the category results. The racers were amazed that within five minutes of the race conclusion, the printed results were posted for all to see! This also allowed Ramiro to hold their awards ceremony immediately, so that those who needed to, could go home without having to wait for the other races to conclude.

At this point, the 42km marathoners were out on the second 29km leg of the race, and I had a moment to relax.

A few hours later, the red and black bibs started arriving. I timed each arriving racer, concluding the 42km race, while JuanMa recorded the first split time of those black-bibbed racers — i.e. those who would continue running the 5km laps of the 10 hour Ultra. (So, in the Ultra race, the first split corresponded to the marathon leg of the event.)

Once again, I tapped a button in RaceSplitter to instantly publish the results of the 42km marathon to RaceSplitter.com:

http://racesplitter.com/results/77B97D1A5

And once again, Ramiro was able to give the awards to the marathoners.

Each time that Ultra runners would return from a 5km loop, JuanMa would record a split time for them in RaceSplitter. At 4am, the Ultra race concluded, and JuanMa published his race results to RaceSplitter.com.

http://racesplitter.com/results/D47E1DFEE

What can be seen from these results is that presently RaceSplitter.com doesn’t support an ideal results listing for a race which has a fixed time, as opposed to fixed distance. In the above results, every participant except the winner is listed as Did Not Finish (DNF), since only the winner ran eight loops. However, the results are listed in correct order, so that, ignoring the DNF labels, the results could still be printed and used in the awards ceremony.

(We’ll be making an update later to address this.)

CONCLUSION

After the race, I was talking to both Ramiro and JuanMa, and they were absolutely ecstatic about RaceSplitter, and plan to use it in all their future events.

They agreed that the biggest challenge for the product is to effectively communicate to race organizers:

1. How complete RaceSplitter is as a product for timing an entire race.

2. How easy it is to use, and that an organizer can really confidently organize their own timing. All they need is a couple of volunteers with iPhones.

3. How tremendously cost effective the whole system is, compared to traditional contracted timing services.

For more information about RaceSplitter, just visit:

http://racesplitter.com

To see all the photos from the event, click here.

THE SETUP

The race was scheduled to take place on Sunday morning at 11:00 am. Sign-ups would be taken on the morning of the event.

We arrived at around 10:00 am, and found Toni Garcia of the San Pedro Atletismo Club having already taken around 40 registrations. For each participant, he was entering bib number, first name, last name and age-group category into an Excel spreadsheet.

At 10:45 am, he closed the registrations and emailed me a CSV file exported from Excel.

I had my MacBook Air and iPad 2 connected to the internet through my iPhone 4′s “Personal Hotspot” wifi network. Using the MacBook Air, I logged into our RaceBuilder online service, created a new race, and configured the start list by uploading the CSV file that Toni had sent me.

In the meantime, about five late arrivals registered at the last minute, and I added them manually to the race in RaceBuilder.

When done, I clicked the save button in RaceBuilder and the website sent me a copy of the RaceSplitter file to my email address.

I turned on the iPad 2, opened the RaceSplitter file attachment in Mail, and clicked to import it into RaceSplitter as a new race.

At this point, I’m done, and ready to time the race. All in all, it took less than five minutes to create the race in RaceBuilder, email it to myself, and then import it into RaceSplitter.

TIMING THE RACE

In the end, there were 75 participants, in about six different age categories, running a 2km race.

Toni fired the start gun, and the racers were off. I tapped the “Start Race” button in RaceSplitter, and got ready to record times.

Since RaceSplitter’s method of timing racers involves manually typing bib numbers, and hitting “Record”, Toni agreed to help organize finishing racers into a single-file line, so that I could time them. (This was ensure that I could capture the finish order correctly, in the case that large groups finished together.) In the end, however, the largest group that finished together was three racers (it was a tough 2km!), I was easily able to accurately record all the racer’s times, without any assistance.

When the last racer crossed the line, I tapped the “Stop Race” button.

PUBLISHING AND CLEANING UP THE RESULTS

After the race, I connected the iPad to the internet again via the iPhone’s “Personal Hotspot,” and tapped the “Publish Race Results” button in RaceSpitter. Instantly the results were online, and I received an email with a link to the results page.

http://racesplitter.com/results/3BDAFE55F

On the results page in RaceBuilder, Toni printed out the final results in each category (taking advantage of the nice print styling), and posted the results next to the organizer’s tent.

Once everyone reviewed the results, there were two complaints:

1. The first child finisher had cut the race course short, and should be disqualified.

2. One of the adult men’s racers had been registered in the wrong category.

In order to correct the first, we assigned the disqualified child to a category called “DNF”, so that he would no longer be included in the results calculation for his category. Having made this change, Toni printed out the corrected version of the kids category. (Lucky for us, that change put my son in third place! :-)

To correct the second problem, we simply updated the category of the affected racer, and then reprinted the results for the category to which he was assigned, as well as the original category in which he was mis-assigned.

CONCLUSION

The event represented another very successful showing of RaceSplitter! Race creation took about 5 minutes. Timing the fast race, even manually, went off without a hitch. And instant internet publishing (and results printing) allowed all the participants to review their results within 15 minutes of the race having concluded.

For more information about RaceSplitter, visit:

http://racesplitter.com