I, like others, manage a gallery for other people I know — mainly, my family members. I personally use smugmug, but since I can’t really effectively share my smugmug account, I still use gallery for everyone else’s pictures (plus dreamhost just upgraded us to 20G, so there’s plenty of room).
The new embedded Java-based upload applet seems to be a win, though it looks rather odd on Mac OSX. Uploading photos one by one in Gallery 1.x was always a big, if not the biggest, pain point, and the gallery remote usually didn’t work too well either.
Gallery 2, however, is starting to smell of what I will call ‘module bloat’. It’s a trend that’s especially prevalent in open source stuff, but it seems like people like to design systems that are super modular, super pluggable, super extensible in the like, so much so that the base system without the modules has no functionality.
As a system design principle, that may be fine, but as a UI design principle, it usually doesn’t work out. As far as Gallery 2 goes, now it means you have all kinds of side bar items, all kinds of tabs, all kinds of drop down items, based on the combination of modules you happen to install and enable. I think Eclipse is also a good example of how modularity can go wrong. Eclipse modules can change just about anything in the Eclipse UI.. at that point, you have to really start thinking of and designing it as a UI framework, rather than an application with extensibility.
If Apple has taught the world anything (or at least, if it has taught me anything), is that a particular piece of software’s useful features should be integrated by default, with the ability to be disabled — not the other way around. That means the java web upload applet should be there by default, and the old web form based method should be a fallback. I mean, who really wants the latest greatest Gallery, configured with the world’s most cumbersome upload UI ever? I mean, are they catering to people who upload using w3m or something?
More modularity in open source projects too often means ending up with something that requires too much configuration to actually solve the problem its intended to solve.