Some Adventures With Keywords

I like many features of the Keyword system supplied with Aperture very much. But there are a few things which have been a little frustrating.

* The way the autocompletion feature works in the "Add Keyword" field in the Control Bar makes it too easy to misenter a keyword. You type your keyword, hit "Enter", and--oops--you've entered something you didn't mean to enter.

* Keywords entered in the HUD sometimes capitalize themselves when you don't want this. I haven't been able to determine why this happens, but I can't really understand why I would ever want the program to capitalize a word I didn't capitalize myself. Sometimes this is really frustrating--if I already have a keyword in the HUD, like "lake", and try to enter a phrase like "Kabetogama Lake" in the Control Bar field, Aperture simply won't let me make the "l" in lake uppercase no matter what I try.

* When you apply a keyword via the Control Bar field, if it doesn't exist in the Keyword HUD Aperture automatically it. Many times I do not want this, and there ought to be a preference to allow turning this off.

* The "keyword checkbox" interface of the Search HUD does not scale very well. As long as the pictures selected only contain a dozen or two unique keywords, this is fine, but when there are many all of the checkboxes and keywords overwhelm the HUD. Also, the HUD for some reason cannot be made wide enough to show long keywords after each checkbox, no matter how wide the screen on which it is displayed is.

* In my library, the search HUD shows multiple checkbox items with the identical keyword. Interestingly, selecting one or the other provides different results from the search. However, entering the phrase in the "Quick Search" field does return the correct picture subset. Perhaps rebuilding the library would help with this problem.

* I thought that the point of the hierarchical structure of the Keywords HUD would make it automatic to enter mutiple keywords which were related. For example, if I have a keyword of "tree" with a subcategory of "oak" I thought you would automatically get "tree" when you applied "oak" to a picture or pictures. Unless I'm missing something there is no way to do this. May a modifier key held down while dragging a keyword to a picture could add the parent keyword(s) as well.

Has anyone else had similar experiences?

Powerbook 15", Power Mac G5, Mac OS X (10.4.3)

Posted on Feb 3, 2006 1:02 AM

Reply
19 replies

Feb 16, 2006 12:15 AM in response to patH72

Sure, but then every time I did one of these searches
I'd end up with another album cluttering the
interface (although I could delete it). Since most if
not all cataloging programs provide a straightforward
capability for this kind of search Aperture probably
should have done so from the beginning as well.


So in other words, it's not impossible (as first asserted) - it's simply annoying (which I'll grant).

I don't really think it's a major omission from a 1.0 app, most search abilities in 1.0 apps are far more stunted than what Aperture offers already. I agree it's kind of flat though and they'll probably allow for more complex searches later.

Feb 16, 2006 12:16 AM in response to patH72

The search performance issue crops up in another way as well.

Aperture's Search HUD uses the standard Search field interface object now common on the Mac. That object operates in one of two ways--a search is done as you type in the term in the field, or a search is commenced when you finish typing and hit the Return key. I think the latter approach violates the traditional Mac interface guidelines, in that the Return key is the only way to issue the command, and is not a shortcut for a menu command or button, but that's not the Aperture team's problem.

However, the Aperture problem exists because they use the "search while typing" approach. This is really only appropriate when the search is fast enough to return results in more or less real time. In the Search HUD, I type a few characters, and before I can finish my term the spinning beach ball comes up and interrupts me while Aperture starts its long search. Eventually it finds something, and the beach ball goes away, but then if I try to finish typing my term it starts searching again and interrupts my typing with the return of the beach ball. This is obviously frustrating.

A better approach would be to do the search after the user hits return. I don't see the advantage to the exisiting approach anyway, and Aperture searching is just too slow on many machines at present. Also, I'd like to see Aperture make better use of multithreading or some other approach to reduce the frequency of the beach ball and interface lockout.

Feb 16, 2006 10:50 AM in response to patH72

patH,

I'm not so sure about this. I'd prefer Apple get the db queries working faster/efficiently rather than get round the perfromance problem.

You are correct about the lack of multi-threading for searching. I selected 'All images' (17k, mostly raw) and started typing in the query window, yup colourful pinwheel for 5-10 sec before i get to type again. Checking Activity Monitor shows the query only maxes one core 100%, while the remaining three go on vacation. This must be a prime case for better coding to use the cpu power available.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

Some Adventures With Keywords

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.