Asset Search and Tagging

The entry at the top of Mike's asset pane mockup is a keyword-based live search; the user would enter keywords, and the assets shown in the pane would be restricted to those whose tags matched all of the given keywords (if any are given).

To avoid search result "yo-yo-ing" due to incompletely entered keywords, our thinking is that the new contents of the search entry shouldn't take effect until the user:

1. types a whitespace character
2. "commits" (hits enter, changes input focus, etc)
   
3. stops typing for some short (empirically determined) amount of time

Rather than showing the filenames (as shown in the mockup), we'd probably show the tags in edit-in-place form instead. An otherwise untagged asset would get default tags generated from its filename; for example (and I suppose the the availability of these examples demonstrates the value of a more detailed mockup):

• Columbo.svg → svg image columbo
• uccello_profilo_02_archi_01.svg → svg image uccello profilo archi
  
• tweets.ogg → ogg audio tweets
  

Note that the file extension tag is placed before the rest of the generated tag, to avoid confusion with the filename, and also the addition of a tag reflecting the type of content (perhaps the filename and type tags should be automatic and implicit always, though?).

Generally the ordering of results would be most recently used/added/updated first; probably all unused assets would get placed before any used assets as well.

Update: Mike's convinced me that if we're adding additional tags beyond what we get from the filename, we should probably move them all to the end of the tag list, with the extension tag, as they just obscure the more important tags otherwise (and there's less risk of confusion with the filename anyway).

Update: Internationalization's going to be a problem for the automatic tagging, given languages which tend not to separate words with whitespace. Such users should hopefully still be reasonably comfortable using whitespace when manually tagging, but probably aren't going to be using easily-recognizable delimiters in their filenames.

Update: On the other hand, if we're doing substring matching on tags, it probably doesn't matter too much.