Currently Being ModeratedMay 17, 2011 5:22 AM (in response to Richard Liu)
I also feel your pain - I have invested and wasted too much time in iPhoto's buggy places feature to care anymore. Made the switch to Picasa today. Very disappointed as a longtime mac user and stock holder.
Currently Being ModeratedJul 17, 2011 11:50 PM (in response to Jonathan Jensen)
Places is such a fantastic idea. I love the fact that I could potentially have a map of the world with little pins that show every place I've ever taken a photo. In a previous version of iPhoto the places feature was clunky, not intuitive, and barely possible to figure out. In the current version, as far as I can tell, if you are trying to add a place and assign photos to that place, if that place isn't a physical address (for instance a lake), and the place isn't in whatever database iPhoto leverages (which isn't Google Maps because I can find it easy enough on Google), then as far as I can tell there is no way to create and assign the place.
I am sooooooo annoyed by this program!
I want to learn how to develop software just to understand why this doesn't work.
Currently Being ModeratedJul 18, 2011 1:46 AM (in response to taquitopete)
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.