deeje.com/musings

Notes on writing a history-driven client-server synchronization engine

2009-06-05T14:51:05-07:00

I've been working on a synchronization engine for an iPhone application called Clinks, and wanted to share some notes to help others down the road. This is a hefty topic… heck, even the title had to be somewhat unwieldy. With that, lets roll up our sleeves and dive in…

Goals

First off, you're probably reading this because you recognize that native iPhone clients need to go above and beyond a polished web experience. In particular, native apps need to function regardless of the state of an internet connection. This means making sure that sufficient data is cached locally, and that any local changes get propagated to the server/cloud when an internet connection is re-established.

Second, the synchronization engine you consider building will be highly dependent on the goals of your app and on the schema of your data. I've seen basic algorithms for sync engines that attempt to sync *everything* from the client up to the server, and *everything* on the server back down to the client, but in my experience, this isn't a solution to any real-world problem, just a starting point.

By way of example, Clinks is a social wine journal that allows wine enthusiasts to keep track of the wines they try and like, and share that information with their friends. The underlying schema contains, in high level terms, tables for person, product, and experience, where experience captures the tastes and ratings of a product by a person. Users can add experience records to their journal, which may or may not create new product records (they may add an experience record for an existing product, for example). For our sync scenario, we want to push all changes to the experience table, and only push new product records. We also want to pull down friends' experience records as they change too.

We've kept things simple: sync on a record level, and collisions in the history tables are handled using simple FIFO logic. Your needs may vary, and will directly affect the complexity of your sync algorithms.

History

One way to implement record-level sync is by using a history table, which is basically a separate table in your schema that tracks all the changes made to records in the other tables. In your code, whenever a user creates, updates, or deletes a record, your code also insert a new record into the history table that captures all that information: person, table, record, action, date.

Note that each client has a history table, and the cloud/server has a master history table. With that, the sync engine on the client basically reconciles the local history table with the history table on the server on a periodic or on-demand basis. The reconciliation can be optimized by keeping track of the last history record sync'ed, and then on subsequent syncs only processing history records after the previous last history record.

GUIDs

Before we proceed, we must address the issue of primary keys. All databases support a primary key field for uniquely identifying a record, which is crucial for edit operations as well as relationships between tables. Unfortunately, almost all databases assume management of primary key (PK) fields by default, and don't have any concept of a "distributed" PK space.

To illustrate, consider two users starting with fresh databases on their iPhones. When each user creates a record, each database will assign a PK of 1 to the records. Now when those users try to sync to the cloud/server, there would be two records with the same PK value (disregarding typical checks for uniqueness, etc.), making a mess of downstream searches, edits, and sync.

The simple solution is to add an additional "GUID" field to all tables that are to be synchronized, and to generate globally unique identifiers for each new record. Many operating systems and languages have APIs to do just that, generating sufficiently long and random unique ID strings that are statistically unlikely to ever collide.

In practice what this means is that your sync engine will deal with GUIDs, while your database engines will continue to deal with PKs. One significant change you'll need to make to your server is to implement fetch based on GUID rather than by PK. For Ruby on Rails, we simply overrode the GET resource to use the GUID field, then left all the other verbs, like PUT, POST, and DELETE using the PKs.

Algorithm

Here's some pseudo code tying all this together:


// push
get lastClientHistoryDate
get clientDeltaList from client History where (date > lastClientHistoryDate)
for (clientHistoryItem in clientDeltaList)
  if (clientHistoryItem.guid isn't on server)
    switch (clientHistoryItem.action)
      case create:
        get clientItem from client where (guid = clientHistoryItem.guid)
        new remoteItem
        remoteItem.guid = clientItem.guid
        remoteItem.data = clientItem.data
        post remoteItem
      case update:
        get clientItem from client where (guid = clientHistoryItem.guid)
        get remoteItem from server where (guid = clientHistoryItem.guid)
        remoteItem.data = clientItemData
        put remoteItem
      case delete:
        get remoteItem from server where (guid = clientHistoryItem.guid)
        delete remoteItem
    add clientHistoryItem to server History table
  set lastClientHistoryDate = clientHistoryItem.date

//pull
get lastServerHistoryDate
get serverDeltaList from server History where (date > lastServerHistoryDate)
for (serverHistoryItem in serverDeltaList)
  if (serverHistoryItem.guid isn't on client)
    switch (serverHistoryItem.action)
      case create:
        get remoteItem from server where (guid = serverHistoryItem.guid)
        new clientItem
        clientItem.guid = remoteItem.guid;
        clientItem.data = remoteItem.data
        save clientItem
      case update:
        get remoteItem from server where (guid = serverHistoryItem.guid)
        get clientItem from client where (guid = serverHistoryItem.guid)
        clientItem.data = remoteItem.data
        save clientItem
      case delete:
        get clientItem from client where (guid = serverHistoryItem.guid)
        delete clientItem
    add serverHistoryItem to client History table
  set lastServerHistoryDate = serverHistoryItem.date

Note that you must fetch the record from the opposite DB using GUIDs in order to get the PK for that record for subsequent DB operations.

Note also that the algorithm appears to push changes up, then process those same changes coming back down. While this is true, the algorithm is actually designed to support *multiple* clients for a user, all syncing to the cloud/server, so there could be unprocessed history items on the server that client hasn't yet fetched.

And finally, note that this algorithm doesn't speak to relational schemas. You'll need to map the relationships between record GUIDs to the record PKs on each database accordingly.

Dates

One final thought on date fields. We use dates as a way to optimize the sync engine, allowing us to only process history records that are newer than the last sync date. Its important, therefore, to declare your date fields the same on both client and server, or to otherwise normalize the date values when comparing them.

Links for 2009-06-01 [del.icio.us]

2009-06-02T00:00:00-07:00

creating toolbar Icons with OmniGraffle

Links for 2009-05-28 [del.icio.us]

2009-05-29T00:00:00-07:00

TVOut

Links for 2009-05-26 [del.icio.us]

2009-05-27T00:00:00-07:00

Is it possible to draw on a sprite? - cocos2d-iphone-discuss | Google Groups
Time Lapse of Galactic Center of Milky Way rising over Texas Star Party
According to William Castleman: "The time-lapse sequence was taken with the simplest equipment that I brought to the star party. I put the Canon EOS-5D (AA screen modified to record hydrogen alpha at 656 nm) with an EF 15mm f/2.8 lens on a weighted tripod. Exposures were 20 seconds at f/2.8 ISO 1600 followed by 40 second interval. Exposures were controlled by an interval timer shutter release (Canon TC80N3). Power was provided by a Hutech EOS203 12v power adapter run off a 12v deep cycle battery. Large jpg files shot in custom white balance were batch processed in Photoshop (levels, curves, contrast, Noise Ninja noise reduction, resize) and assembled in Quicktime Pro. Editing/assembly was with Sony Vegas Movie Studio 9."

Links for 2009-05-19 [del.icio.us]

2009-05-20T00:00:00-07:00

Links for 2009-05-14 [del.icio.us]

2009-05-15T00:00:00-07:00

Links for 2009-05-12 [del.icio.us]

2009-05-13T00:00:00-07:00

OpenGL ES from the Ground Up: Table of Contents
10 Bottles Of Wine You Can’t Afford To Uncork
Oh, how I'd love to taste a 200-year-old port!

The myth of the myth of self-commenting code

2009-05-01T08:59:34-07:00

Synchronicity! I was thinking of writing on this topic, and up pops this gem…

The Accidental Businessman wrote:

The myth of the myth of self-commenting code

On Code Commenting And Technical Debt | BrandonSavage.net

Interesting post by Brandon—I disagree only on one main point:

This myth of self-documenting code needs to be squashed once and for all. Commenting is important, and unless your code does nothing other than display “Hello World!” it’s going to need some explanation.

I find this view of coding a little misguided, to be honest—in fact, I would go as far as saying that code doesn't need any comments.

Wait, did I just say that? Yes, I did, and here's why: code is a discussion between the developer and a machine. Writing code that cannot be comprehended by another human being is a bit like writing a letter to your dear friend in a language you can write but not read—strange, at best.

Good code should be self-documenting insofar as you should be able to understand what the code does without the assistance of any comments—after all, the computer gets it, so why shouldn't you? This can easily be done by the judicious use of clear logic and good programming practices like giving your variables names that are actually related to what they do.

What I suspect Brandon really means is that the comments are there to illustrate the intentions of the author when those intentions are not immediately made obvious by the code itself. This, I daresay, is the crux of Eli's argument that commenting inside the code is the most important contribution that a developer can make towards eliminating technical debt. That's because commenting inside the code helps understand the reasoning behind the choices that were made when writing the code, rather than what the code itself accomplishes…

Having re-invested myself to production level coding, and having dug into lots of existing code bases over the years, I've come to a similar conclusion… comments in code are only necessary to explain choices that are otherwise not obvious.

Links for 2009-04-29 [del.icio.us]

2009-04-30T00:00:00-07:00

kinetic wave sculptures

2009-04-25T10:43:15-07:00

I had the pleasure of seeing one of these sculptures at the Exploratorum some years ago… steve cooley presents wrote:

kinetic wave sculptures

This was too cool not to repost:

Rating Systems

2009-03-24T22:35:11-07:00

How do you use the various rating systems you encounter in your life? Do you use the full resolution of each rating system, or have you unconsciously developed a mapping of your own classifications to the rating systems being provided?

Numerous products incorporate rating systems. Ideally, these systems allow users to develop profiles that then help recall past products and experiences, as well as discover and select new products and experiences in the future. The most common rating systems I've seen include:

5 stars
3 Stars
Thumbs Up/Down
100 Point

Ratings for collections

In Apple's iLife suite, both iTunes and iPhoto incorporate the 5 star rating system, and underneath the hood, these ratings are stored on a 100-point scale.

I find it interesting how similarly and differently I use these rating systems in each of these products. In iTunes, I reserve the 5 star rating for songs I consider true classics, songs I believe will hold up over time and come to represent the best music I've ever heard. With a modest collection of 3806 items in my Music tab, only 34 items are rated 5 stars, less then 1%. 373 items are rated 4 stars, just shy of 10%, and 1547 items are rated 3 stars, which represents less than half my library. I have smart playlists defined for each of these ratings, and generally tend to play music with 3 or more stars, and I rarely mark music with less than three stars. In fact, of the 6 potential ratings available, I only really need 4: none, good, great, awesome.

In iPhoto, I use a similar 5, 4, and 3 star system. 5 star photos represent the absolute best moments of my family's life. Photo's with 4 stars and great, and photos with 3 stars are worth sharing with my family. I make little distinction between 1 and 2 stars, and only both marking photos with those low ratings as a way to indicate a photo worth preserving. As with iTunes, I have smart lists in iPhoto that find all these photos at various ratings. As with iTunes, I'm not really using all 6 rating positions (0-5), but only need: none, save, good, great, awesome.

Ratings for entertainment

Because these are collections I curate, it makes sense that these ratings to be only positive. But there are lots of places where I want to capture a negative rating because I am not collecting things but rather experiencing them.

Netflix offers a 6-position rating scale, with dislike, none, and 1-5 stars. I rarely mark something as dislike, though I do remember rating a bunch of things early on to give the recommendation system something to chew on. And I rarely mark something less than 2 stars, where 2 stars is meh, 3 stars is good, 4 stars is great, and 5 stars is something I would consider buying.

Hulu's approach to ratings mixes a negative-to-positive spectrum on top of a positive rating scale, where 1 star is "Hated it" and 5 stars is "Loved it". I personally don't consider this system to be a good design… it feels very first-grade-ish, where even the worst performance merits a "star" for effort. Unfortunately, there is no antithesis of the star symbol, and so it isn't easy to craft a rating scale with stars at the positive pole and something metaphorically connected at the negative pole.

So far, all of the rating systems I've described have suffered a bit from too much resolution, in that there are more choices available than I need to express an opinion or make a classification. I have to mentally transcode my own value onto the rating system available to me. For shared systems, this creates aggregate rating systems are are noisy and course, because even with a vocabulary of only 5 words, people may still not be saying the same things to each other.

To contrast this, consider one of the better (IMHO) approaches to rating experiences, the San Francisco Chronicle's movie reviews "little man". Except perhaps for the empty seat, each of the icons is very clear and understandable when seen alone, and makes complete sense when seen in sequence. Moreover, there is no ambiguity, and I believe most people can express their own responses to a movie using this scale with little-to-no adjustment on their part. The resolution of the rating system seems just right.

Ratings for wine

Now we turn to the rating systems for wine… Ug! What a mess! In the mid-20th century, wines were often rated on a 20-point scale, often credited to UC Davis. Then in the late 1970s' Robert Parker started publishing wine reviews using a 100-point scale. Talk about too much resolution! What's the difference between an 82 and an 83? Nothing really, but because Parker has become so powerful in the wine industry, the difference between an 89 and a 90 can make or break a wine maker. For good or bad, the rest of the industry has pretty much jumped on board.

There's no denying that the U.S. population can apply their grade-school experiences to understand the value of 90 points as representing a good wine. It's unfortunate that, unlike movies or food or music or just about any other experience, people rely far too much on wine critics' ratings and not nearly enough on their own experiences to judge and compare wines. And the sheer inanity of the 100-point resolution compounds this fact for the average wine drinker.

For Clinks, we concluded several things: first, that the 100-point scale isn't going to be replaced any time soon (certainly not by a few eager wine drinkers who decided to write a cool iPhone app); second, that the cure for the Parker monopoly is the emerging democratization of wine reviews and ratings, aka Wine 2.0; and third, that people need a way to express their experience of a wine that was easy, unambiguous, and direct. So, we came up with a rating picker that focuses on the near-universal metaphor of thumbs up and down, which maps back onto the 100-point scale.

In this way, the 100-point scale is collapsed into a manageable resolution. By no means will this quell the growing debate about the value and validity of the 100-point wine rating scale, but we think is does help average wine drinkers rank their experiences more easily, which then helps them remember the good wines next time they're at the store. It will be interested to see how people react to it.

My default computer configuration

2009-03-24T19:44:04-07:00

Over the course of this year, I've had to configure a number of machines for daily use. Thru sheer habit, I didn't want to buy a new notebook until after Macworld back in January, so I added accounts to both my wife's and my kid's notebook computers until after then. Once Macworld had come and gone, I bought a MacBook, opting to balance weight with performance.

In all these configurations, I've come to appreciate the core set of tools I use on a daily basis:

OmniFocus - i've moved away from Mail as a to-do list, and have committed to OmniFocus, both on the Mac and the iPhone. I had already started to incorporate GTD principles at the start of 2007, so this has felt like a natural adoption.
iDisk - I decided to turn on automatic sync'ing, and have been thrilled with the results so far. Now I don't have to worry about where I create documents, I just always save to my iDisk, and know I can get to them everywhere.
NetNewsWire - I'm pruning my subscription list significantly, and not spending nearly as much time reading.
MarsEdit - I'm queueing up a bunch of blog entries, so that there's always something to write about, and if I feel blocked on one topic, I can just pick up another topic and take it forward.
Cocoalicious - am trying hard to not leave tabs open in NetNewsWire and Safari... I either read a page right away, or tag it as a reference for future use.
Keynote - I'm doing a lot more presentations these days, whether one-on-one in SyncDev interviews, or to audiences at various conferences.
Xcode - I'm actually really liking this IDE, particularly the auto completion capabilities.
Versions - version control is now a habit.
Fireworks - Just the right level of image editing capabilities, suitable for graphics art in applications.
Interarchy
OmniGraffle - great tool for diagrams.
Keynote

GPS on a snowboard

2009-02-22T16:50:51-08:00

During my first (and probably few) snow days of the 2009 season, I took along a Garmin eTrex GPS unit. Now I've got some very interesting data to look at, giving me a new perspective on one of my favorite sports.

On day 1, I didn't turn the unit on until late in the afternoon, whereas on day 2, I captured the entire day. Here is the overall waypoint map:

As you may recognize, I went to Northstar, on the north shore of Lake Tahoe.

Here is the elevation map:

From this, I get some interesting stats:

Highest elevation: 8621 ft
Longest run: 2.9 miles
Deepest vertical drop: 2299 ft
Total number of runs: 13
Total distance travelled: 35.73 miles
Average lift speed: 10 mph
Average speed on runs: 20 mph
Peak speed on runs: 40 mph

Internet TV Value Chain

2009-02-04T10:45:23-08:00

I define Internet TV as professionally- or prosumer-created video delivered over the internet, often thru a web browser. That definition doesn't quite cover all of YouTube, since so much of their content is random (to use as kind a word as I can find), but certainly YouTube in toto is part of Internet TV, too.

I've gained a tremendous amount of experience and exposure to the processes involved in delivering Internet TV content, and its much more complicated than most people imagine. When I go to tech conferences and sit in on sessions titled "How to publish video online", I'm flabbergasted that these presentations often revolve strictly around the presentation layer inside HTML, and ignore the complexities of publishing for-profit video content online.

The value chain for publishing Internet TV involves the following components:

Encoding
Video Content Management
Advertising
Protection
Delivery (CDN)
Playback
Measurement

Depending on your needs, you can fill each of these components using desktop software, server software, or web services. Surprisingly, there are few one-stop shops for all of these components, and custom requirements often make these challenging to choose.

Here are some additional thoughts on each of the value chain components.

Encoding

Encoding means transforming video sources into digital bits suitable for transportation over the Internet. It used to be that encoding was integral to Delivery and Playback, but as the entire video industry moves to standards like H.264, encoding can become independent of these downstream value chain components.

That doesn't necessarily make encoding any easier. Even with an emerging standard, there are still many considerations for encoding, starting with the nature of the video source. Libraries of existing video content can be processed in batches asynchronously. Live video feeds must be processed in real-time. Ideally you must also encode at multiple dimensions and quality levels (translating into an array of different bit rates). This means additional processing power for live events, and additional storage for libraries. And of course, you should make all your live events available afterwards on-demand.

Video Content Management

Like any other kind of content being published on a regular basis, video content needs to be managed. Fundamentally, this means keeping track of which content is ready for publishing, and which content is already published. From there, you can imaging all sorts of additional business rules and related metadata that you'd like to manage for your content, which is often encoded as XML and stored in databases on robust back-end systems.

Often times, video content management encompasses many of the value chain components in aggregate, such as encoding files that are uploaded, storing them on servers, publishing them to websites, communicating with advertising systems, and so on. And sometimes, they don't, which means you'll have to integrate these other components yourself.

Advertising

There are two aspects to advertising that you must consider when assembling your solution: where to put ads in and around your video content, and what ads to display.

The "where" question is often defined using a "playlist" concept, which may be component managed by your video content management system. With a mix of the old (TV) and the new (Web), the playlist may include a sequence of content segments, interspersed with in-roll (pre-roll, mid-roll, post-roll) video ads, along with parallel companion banner ads that appear next to the content and overlay ads that appear on top of the content.

For short video segments, the playlist may want to have complex business rules that dictate in-roll ads only after N plays or only after N minutes of playback. For longer video segments, the challenge is in identifying the natural breaks within the video content suitable for traditional mid-roll advertising. For professional content, these breaks are already built into the content for traditional broadcasts by the editor, and the industry must move towards standards that allow editors to pass this metadata along thru the encoding and publishing steps with as little additional effort as possible.

Once the "when" question is addressed, the next challenge for advertising systems is the "what", to fill the ad spots at playback that are most suitable for the viewer of the content. Ultimately, the value of each ad will be measured by the relevance of the ad to each viewer. Some advertising solutions focus on matching ads to the context of the content, while others focus on matching ads with the behavior of the viewer.

Each have their strengths and limitations, IMHO. Educational or informational programming, like cooking shows, will benefit most directly from contextual advertising, because viewers are specifically in the mindset of knowledge acquisition.

Protection and Delivery

Good fences make good neighbors. Good content protection makes your content available most conveniently to your viewers, while preserving the business model you need to remain viable. The corollary is that castles aren't very inviting: make your content too difficult to use, and no one will try.

For Internet TV content, protection is often closely tied to the form of delivery, either streaming or download.

Streaming involves delivering bits in real time to a viewer in an encrypted fashion, such that the bits are displayed and then immediately discarded. The pros for content owners is that the content remains centrally managed, and the content is available on-demand for viewers. The cons are that any disruption in that real-time delivery can translate into a disruption of the playback experience, and that users must be online in order to watch the content.

Downloading involves delivering bits in asynchronously, in an encrypted fashion on a per-viewer basis. The pros for viewers is that they can watch the content regardless of the state and quality of their online connection. The cons are that viewers will opt to download higher bitrate versions of content, increasing the delivery costs.

Speaking of delivery costs, the CDN cost difference between streaming and download have dropped significantly in recent years, and streaming has incorporated protection, while protecting downloadable content is still a separate step and cost at this point.

Playback

The emergence of standards like H.264 take video quality almost completely out of the equation when evaluating playback environments. But the other aspects are still tremendously important, including protected delivery and advertising.

And of course, Internet TV should eventually transcend traditional TV, particularly in terms of interactivity. What that actually looks like in 50 years, I don't think anyone really knows. But playback environments need the developer base, tool set, and device support to enable exploration and experimentation.

Measurement

After all that, we come to the most important, and least mature, component of the entire Internet TV value chain. You can't manage what you don't measure, so make sure you put measurement in place *first*, and the rest of the components as you see fit. Fundamentally, this means figuring out what questions you want answered, then figuring out how best to answer them.

The challenge with measurement is defining exactly what you want to measure, and understanding what metrics the various other components provide. Server-side components may track hits, and client-side components, rolled into your playback environment, may track starts and stops. The industry is starting to tackle the challenges around definitions of measurement, and how to translate low-level metrics like these into higher-level metrics like audience size and engagement time.

What I learned at ZAP 2009

2009-01-31T18:00:01-08:00

If you follow me on Twitter (@deeje) you probably noticed a ton of posting today rating various wines. I was at the ZAP Zinfandel Festival 2009 at Fort Mason today, and was field testing our new iPhone app. Here are a few quick observations while they're fresh on my mind.

First, I didn't see anyone actually taking notes on what they were tasting. ZAP does provide a paper guide for tasting notes and I did run into some friends who pulled out their tasting guide to tell me about some of their favorite zins. Clearly, people are trying to keep track to a limited degree, but it wasn't overt or widespread.

Next, we've already been thinking about a "twitter limiter" setting so that low ratings don't get posted. The takeaway here is that my rating is not consequential... I'm no expert, I'm just trying to keep track of what I like and don't like. There's no point in posting low ratings, only the stuff that really impresses.

Third, while we've spent considerable time making our app easy to user, and in particular, easer to enter data, there's still a bunch of aspects to identifying wine that are tricky. For example, what's the difference between Zinfandel and Old Vine Zinfandel? How important is the vinyard? Clearly the winemaker makes the distinction, and so should we when we want to remember and find that wine again. But we also don't want to make identifying wines a burden... tricky.

The notion of scanning bar codes to identify wines seems obvious to everyone we talk with, but the practical reality is that bar codes are not universal. In the context of a large wine tasting event, however, i could see it making a journal drop dead simple to use.

Lastly, I'm not so deep on wines yet to really appreciate all the nuance between the 14 different zinfandels I tasted. I'm looking forward to the San Francisco Chronicle Wine Competition public wine tasting event in Feb.

One of the world's longest exposures noahkalina: One of the world’s longest exposures...

2009-01-11T19:24:04-08:00

Mike Hudack's Tumblog wrote:

ericlodwick: noahkalina: One of the world’s longest exposures...

ericlodwick:

noahkalina:

One of the world’s longest exposures ever. For 6 months between the winter and summer solstice, Justin Quinnell left open his homemade pinhole camera. The lowest arc shows the first day of exposure on the winter solstice, the top curves were captured in the middle of summer.
(via: ptrbkr)

Beautiful.

Indeed!

The Passion Factor

2009-01-09T12:09:33-08:00

After I parted ways with Adobe, I reached out to my former colleagues with an oft-burdensome request to recommend me on LinkedIn. Very graciously, many responded. Thank you!

In thinking about where I want to go next, I've also been thinking about the best ways to describe what I do. I've worn many hats over the years, and no one hat seems to satisfy me enough. Engineer, architect , product manager, business development... But I'm beginning to see some themes that connect the hats I like best.

Reviewing the recommendations I've received, a common term used to describe me is "passionate". In the context of business, I've channeled my passion into building great products. The way that this passion is manifest is two-fold. First, I'm passionate about understanding customer needs. And second, I'm passionate about defining experiences that satisfy those needs.

After returning to college to earn a Business/Marketing degree a few years ago, I got the rare opportunity to learn a new product development methodology called SyncDev. SyncDev is a process that involves changing the fundamental order of new product development. A typical order is "design, build, sell", but in SyncDev, the order becomes "sell, design, build".

Part of what makes SyncDev so great is the iterative nature it brings to all aspects of product development: market segmentation, market requirements, product requirements, promotion, and engineering. In SyncDev, you're constantly testing your theories about each of these aspects against real customer feedback, to ensure that the final result is worth doing and very successful.

It seems like an obvious optimization, but its also amazing how many companies build before they sell, provide answers before they've asked the questions. Now that I've experienced the SyncDev process, I won't build another product without practicing SyncDev along the way. And I will be providing coaching services to help companies incorporate SyncDev into their DNAs. For those interested, I highly recommend you check out their site at SyncDev.com

After the customer, problems, and features start to come into focus thru SyncDev, I love the challenge of designing experiences that are efficient and delightful. I've worked on almost a dozen consumer products over the last two decades. TouchBase was one of the first highly successful address book apps for Mac, which we sold to Aldus. Photo Deluxe put task-based UIs on top of the power of Photoshop. PuppetTime brought automated 3D animation to screenwriters, which we sold to Cycore. Contribute enabled easy web page editing before blogs and wikis. And Adobe Media Player tackled the business and technical challenges of a completely on-demand television experience.

In each case, I've used the latest and greatest frameworks and technologies. Early on, I realized that while user interfaces can be broken down into building blocks, user experiences cannot. Great experiences are often defined by the little details that most users don't consciously see or feel, and by the complexity of the solutions that they hide. They make the user feel more efficient, and bring delight repeatedly.

I'm currently working with some colleagues on a wine journal app for iPhone, using SyncDev to better understands the wants and needs of wine drinkers, and defining and designing experiences that will, we hope, help wine drinkers move from casual to connoisseur.

I'm looking forward to sharing more with you soon... In the meantime, what are you passionate about?