3 Replies Latest reply: Jul 18, 2011 1:46 AM by Richard Liu
Richard Liu Level 1 Level 1 (45 points)

Here is the feedback that I just sent to Apple:


"Why is defining a place such a hassle?  Don't bother telling me the steps -- I know them too well.  Tell me why, when I select a photo, type something in the teeny-weeny Assign a Place... dialog, then select one of the suggestions, what happens next depends on whether the selected suggestion is a custom place or one that Google found?  Tell me why, if it's the former and I move the pin around and assign it a new name, I effectively modify the place, just as if I were working in Manage my Places, whereas if it's the latter, I define a new custom place?  Tell me why, if the custom place that I define happens to overlap other custom places, the photos assigned to them will be reassigned to the new custom place?  Tell me why I can't adjust the radius of the place in the teeny-weeny Assign a Place... dialog to prevent that from happening ... by the time I do that in Manage my Places it's too late!  Tell me why, with every new version of iPhoto 11 the usability of Places just gets worse?"


Of course, I don't expect Apple to answer, but I would appreciate any hints for solving, or, at least, avoid the problems described above.  They weren't problems in the previous major version of iPhoto.


The latest patch, 9.1.3, seems to have brought new Places problems.  I assigned a photo to Martinskirchplatz in Basel.  It wasn't in My Places, so it's a place that iPhoto found through Google.  Naturally, it overlapped other custom places nearby:  Rheinsprung, Alte Universität von Basel, Basler Rathaus.  So, after adjusting the radius of Martinskirchplatz in Manage my Places to avoid overlapping them, I switched to the Places view and selected Martinskirchplatz to see all the photos that really belonged to the overlapped places but had been reassigned, and painfully assigned them back to the correct places.  Then I found a photo that I had originally assigned to Rheinsprung and reassigned it to Martinskirchplatz, since that's exactly where I had taken it.  When I exited Places, re-entered and selected Martinskirchplatz, only the photo for which I had defined that place was there, not the one that I had reassigned to it.  No matter what I did, I could not convince iPhoto to show me both photos for that place, despite the fact that, in the Info displays for both the place was correct, and it only appears once in Manage my Places.  So I decided to repair and rebuild the library, and iPhoto decided to surprise me by only retaining the places for photos taken with the iPhone (presumably because they contain the GPS coordinates).  WHO UNDERSTANDS THAT Rebuild Library from backup MEANS THAT CUSTOM PLACES WILL BE LOST?  Just what kind of backup is it that doesn't backup the places?




MacBook Pro, Mac OS X (10.6.7), 2.66 GHz Core i7, 17", 8GB RAM
  • Jonathan Jensen Level 1 Level 1 (5 points)

    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. 

  • taquitopete Level 1 Level 1 (0 points)

    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.

  • Richard Liu Level 1 Level 1 (45 points)

    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.