Why is using Places in iPhoto 11 such a hairy hassle?

The problem with Places is not the development, but the design, so learning how to develop (I presume you mean program) an application isn't going bring you any closer to understanding why Places doesn't "work." In fact, Apple's refusal to address the problem of overlapping custom places indicates that this is the way it's supposed to work, but Apple provides no explanation about the underlying model, i.e., how we're supposed to think about custom places.

As nearly as I can tell, custom places are supposed to provide GPS coordinates for photos that don't already have them, or have them wrong. Look at what happens when you import a photo from, say, the iPhone. Provided you haven't switched off the Location facility, the photo has GPS coordinates. And, providing you haven't switched off the option in iPhoto to place photos, iPhoto will look up the coordinates in Google Maps and get the most precise name it can. Apple's solution to the problem of photos which don't have GPS coordinates should have been, allow the user to supply them.

Now, there's a second problem with geo-tagged photos, regardless whether they were automatically or manually tagged. Sometimes we would like to provide a more precise area than Google Maps. For example, Google Maps might supply just the city Basel for photos taken anywhere in Basel, whereas we might want to distinguish various areas in Basel. This, too, has an easy solution. Allow the user to define closed polygons, circles, etc. which constitute a level of detail finer than the finest level that Google Maps supplies. So what if the custom areas overlap? No problem. The photos have coordinates, so if the coordinates of a photo put it in multiple areas, that's OK.

So far, so good. For each problem we have an independent solution. Now, there's a third problem that's specific to manual geo-tagging. Maybe I don't remember or don't care where exactly on the Marktplatz in Basel I took a photo. Why should I have to assign it to a point? Here is where Apple apparently got too clever for its own good. Instead of supplying a separate solution to this problem as well (e.g., by introducing the concept of an area of uncertainty around a point, or by providing a facility to assign a photo the same coordinates as another), we now have what amounts to one solution for two problems: when you think you're defining a custom place, you're really defining a circular area and assigning the photo the coordinates of the center of the circle. So, what's so bad about that? First, the process of defining a new place never makes it clear that it's actually an area that is being defined. Second, even if you're aware of this, you cannot specify the size of the area at the same time that you define it, so there's no way to prevent it from overlapping other places that you've defined. And what is the problem with overlapping? Since the photos are not attached to the areas to which you assign them, but only derive their implicit coordinates from the assignment. Now, anybody could understand that, if two areas overlap sufficiently, in particular, if one overlaps the center of the the other, then the photos assigned to the two places might be displayed when the large place is viewed. But, for some strange reason, reducing the overlap in Manage My Places, or eliminating it altogether, doesn't rectify the problem. Instead you must reassign the "victim" photos of overlap.

The lesson here is: Good design means a single solution to a single problem. Three problems? Three independent solutions! This allows the user to do just what he wants, and to understand what he is doing. Don't want to define an area? Fine. Just assign a coordinate to a photo. Don't want to assign a coordinate, because that would imply precision, or because you don't recall exactly where? Fine. Just define an area of uncertainty and assign the photo to it. As you and/or your needs develop, you can do more sophisticated things with three solutions than with a single one, and you still understand what you're doing.

Somehow I don't believe that Apple doesn't know all this. I could imagine this is an attempt to "simplify" the UI in preparation for supporting a touch interface like that promised for Lion. Unfortunately, the price for reducing three separate operations to a single one is semantic overload and an opaque underlying model.

Richard