More possible iPhoto features
Whilst we’re talking about a couple of possible iPhoto features and overhauls, how about extending Faces by making it actually a bit more useful? Whilst it’s great being able to tag people, the only way to use this information is for uploading to Facebook or when searching. There’s a few things that could be done to exploit this information, especially when combined with other metadata from the photographs.
For example;
- Being able to select multiple Faces in iPhoto and seeing photos that contain all of the selected people.
- A graphical view of a person’s timeline over their lives, either;
- A graph of time (using the datestamp from the photo), or;
- Time combined with a travel map for a certain period of time (using the Places tag)?
- These could also be used with multiple people, for example people who commonly holiday together shown on a travel map over time.
- Being able to customise the Faces view, for example to sort by Surname, change the background etc.
- Better Address Book integration;
- Being able to open an Address Book entry from iPhoto.
- Setting the image in Address Book from a Faces entry.
- A graphical view of relationships between people (as can be set up in Address Book). This is a quicker, easier version of family tree functionality in iPhoto I suggested before.
Getting Genealogy
I’ve been looking into my family history and have been trying to find a decent genealogy application for the Mac. Ideally it would need to have a graphical representation of the tree and relationships between family members, support for photos, dates and locations.
That got me thinking; I already have an application that supports photos, dates, locations and people. iPhoto.
Recently I suggested that panorama stitching support may be the next big thing to hit iPhoto, but what if Faces in iPhoto was extended to include relationships between people, and more metadata like datestamps (such as birth/death/important events, which of course could be linked to photos) and locations like photos already have. This would make it a fairly full featured genealogy application.
It could be fairly trivial to define relationships using drag and drop, and Apple already has applications that do something similar: Quartz Composer forms connections between modules like this, as does Interface Builder in Xcode.
It may seem like a strange direction to take, but if you consider that Apple has developed iPhoto and the whole iLife package to draw consumers to the Mac, and in my experience at least, more and more people are getting interested in their genealogy. It could also integrate with online genealogy services as it already does with FaceBook and Flickr.
iPanorama?
A few years ago I found myself wishing that iPhoto had facial recognition and location tagging. They were subsequently added with Faces/Places.
Recently I have been thinking that I’d love iPhoto to have the ability to create panoramas stitched together from multiple photos. Going on my good record of predicting features I’m hoping I get three out of three and iPhoto adds this in the next couple of years. This could be relatively easy to do the basics at least, using an open source project like autopano-sift or something similar. Then it would of course need the traditional Apple polishing and ease of use to make it a good iPhoto citizen.
The love affair between the MacBook and FireWire is over
I recently predicted that FireWire would eventually be replaced by Light Peak on all Macs, and that FireWire was only back on the MacBook temporarily. Little did I know then that only a couple of days later Apple would announce the new MacBook and kill off FireWire so quickly (on the MacBook at least).
It’s a shame, I shall miss it. The fast peripheral bus is dead, long live the fast(er) peripheral bus!
Firewire makes a (temporary) comeback?
Last year I speculated about the future of Firewire on the MacBook and came to the conclusion that the most logical path for Apple would be to build firewire into the Ethernet port via the new Firewire specification IEEE1394c.
Apple may have taken this in a new direction entirely (which frankly we should all expect from Apple by now!), if reports of Light Peak, the new peripheral bus from Intel are to be believed. More on that later.
Firewire has now been reinstated to the MacBook line, albeit in a roundabout way. Firewire 400 is still available on the white plastic MacBook which was the only surviving member of the old MacBook generation that wasn’t transitioned to the new Unibody enclosure borrowed from the MacBook Pro. Those MacBooks paid the price for their svelte looks and lost their FireWire ports in the process. Apple has now reinstated Firewire in the form of Firewire 800 to these and rebranded them as the new 13″ MacBook Pros.
So here’s the situation. Once more every Mac has Firewire (apart from the freak of the family, the MacBook Air). Although I haven’t had personal experience with the new models, presumably once more every Mac has Firewire Target Disk mode (once again excepting the freak).
So is Firewire back for good? I don’t think so. I think Apple was frankly surprised at the backlash to losing Firewire (especially after it was dropped from iPods with only a little angst) on the MacBook, and that was part of the reason to it’s comeback. But I believe it will only be a temporary measure, until Light Peak replaces it. When I first heard about Light Peak I was amazed that we didn’t have a peripheral bus based on fibre optics already, and that no-one seemed to have thought of it before. I firmly believe that the future will be in wireless peripheral communication, but wires aren’t going away any time soon. If we have to have wires, why not have one small, high capacity connection that can carry all types of communication now that fibre optic has matured to make cables flexible and durable enough for this purpose?
My only concern is that Light Peak will be developed as a master/slave architecture that will make technology like Target Disk mode and daisy chaining (that makes Firewire great) impossible to implement. Its multi-device, multi-protocol design would most probably make that unlikely though.
