Wednesday, October 04, 2006

Google groups

Google Groups has been revampled including integration of Google Page Creator. Groups have RSS feeds. When they add Google Spreadsheets, Google Calendar, Writely and Google Blogger to Google Groups this will be a sensational resource for small organizations, like my cub scout troop.

Even now one can tie those things together independently, but as a kit they'll be worth much more.


Subversive: build google gadgets into your web page

Sneaky. Very sneaky. You can now put a Google gadget on a web page. Will they work with Safari? I suspect not. Another nail in Safari's coffin -- Long-live Safari/Gecko.

Is it my imagination, or has Google made a sudden dramatic shift away from a 'portal' strategy to more of an 'cloud' strategy? Diffuse functionality everywhere...

Insidious.

Sunday, October 01, 2006

iTunes 7: can't select multiple playlists

iTunes 7 no longer allows shift-click selection of multiple playlists for either playing or moving into folders.

One of several highly annoying "features" of this "update".

Mac OS X 10.3.9: failed connection to WPA2 WLAN after Airport security update

Mac OS X 10.4.8: AirPort does not auto-connect to existing networks after restart or wake from sleep is NOT the bug I just had after installing the recent AirPort sercurity patches.

I couldn't connect with my 10.3.9 802.11b iBook to my WLAN. The connect icon was black, but all tcp/ip services were unavailable. Shut down / restart didn't fix anything.

I had to switch from non-Admin to an Admin account and get the 'keychain updated dialog'. Then I switched back to my regular account and this time it showed the 'keychain updated' dialog. Then it worked.

A relatively minor bug with this update, but it would have flummoxed most users.

What's better: Bloglines or the New Google Reader?

I was surprised to read that Matt Cutts, a senior Google developer, is a longtime Bloglines user. Like me, he thought Google's Reader was fairly lame.

Now he compares Bloglines to the new Google Reader and calls it a draw. Since he's a Google employee, he'll switch.

That's fair enough! I'll stay with Bloglines since I'm not a Google employee, but I'll try running Google reader in parallel on occasion. Note Matt Cutts pays attention to "Lock-In", while also advocating the Google vision of cloud-based personal data. I'd like to see him reconcile the two concerns ...

For most people the choices now are Bloglines or Google's Reader, and Bloglines has been good for much longer ...

Saturday, September 30, 2006

Why doesn't Aperture use iPhoto's date ...

Update 10/2/06: I wonder if the surprising failure to allow date modification is related to Aperture supporting XMP export but not XMP import. Clearly it makes no business sense to support only XMP export, so it's very likely XMP import was pulled from the product late in the release cycle. I wonder if support for editing dates was pulled at the same time ...
---
I have worked for years in product design and product management. There are lots of reasons seemingly obvious things don't get done. Sometimes they just got missed, but when customers are complaining frequently that doesn't happen. More often the problem was much harder than it seems, or the product manager thinks it's a bad idea.

Aperture 1.5 is a great update, with one amazing omission (assuming all the Apple Discussion Group users didn't miss something). I don't think this was an accidental omission, so the interesting question is .... why?

That's what I asked on Apple's Aperture Discussion Forum. It's the kind of question they usually delete, so here it is for the record. If anyone has a theory, please add it to comments.
Apple - Support - Discussions - Why doesn't Aperture use iPhoto's date ...

This is how image date logic works in iPhoto. This image date value is used in queries and sorts.

1. Image date is stored in database.
2. Initial value taken from image metadata if available.
3. If image metadata not available, use file date.
4. User can edit database date (does not change file header).

This is how it seems to work in Aperture 1.5

1. Image date is stored in database.
2. Initial value taken from iPhoto database if import from iPhoto.
3. If not import from iPhoto, initial value taken from image metadata if available.
4. If image metadata not available, use file date.
5. User CANNOT edit database date.

I was shocked (really, I'm still stunned) that Aperture 1.5 still does not equal iPhoto's date management capabilities. Since Aperture is a Pro application it's reasonable to have several date fields, but one of them should behave like iPhoto. That metadata field should be useable in queries/filters, sorts, display, book printing, etc. It should be the default date metadata element for all date related operations.

Please note, it's fine that Aperture does not muck with image file (exif) metadata -- that's dangerous. EXIF is a quasi-standard badly implemented.

So now, my question. Why?

Aperture 1.5 was a huge update. They fixed much more than I thought was possible. It could have been labeled Aperture 3.0. Offering it free to users was a genuine apology, gratefully accepted I'm sure. It took all my strength of will not to order it immediately, waiting instead for the initial reviews to come in.

So there had to be a reason Aperture's Product Manager, Joe Schorr, chose not to implement iPhoto's image date behavior. Something he'd thought carefully about.

What was it?
My guess is that this was a high priority item originally, but the metadata management portion of the application code is very badly done. The team decided to do a complete fix rather than a hacked patch, and they couldn't get the fix done in time. So they backed it out and left this for version 2.0.

Alternatively, the product manager has a peculiar blind spot about date metadata, but that I don't believe.

Now I wait to see what iLife 2007 is like, then see what Adobe's Lightroom is like, then wait for Aperture 2.0 ...