On Wed, Oct 15, 2008 at 6:03 PM, <[EMAIL PROTECTED]> wrote: > a few random observations that i had today, prompted by scott's > talk/demo: > > - while people don't tend to name their jpegs (today), they > do tend to group them into folders (e.g. "vacation_pix"). > the equivalent of this in a tagged world would be bulk > tagging. i assume scott has thought about this in his > UI, though i don't recall noticing it.
His prototype did sport the checkboxes for the creation of multiple selections. When such a selection exists, a toolbar with any actions which can be performed on multiple objects (delete, tag, copy, send, etc.) will appear. There are certainly some details to work out. For instance, I expect that we might need a way to "show only selected items" via a filter, so that managing the selection is easier. We may also need "select all" so that it's easy to apply actions to the entire set of results in a search. > - likewise, removing all the files in a directory, or moving > half of them elsewhere (imagine rearranging the photos > you just pulled off the camera), implies that there > should be equivalent tag operations for doing bulk tag > removal, and bulk tag editing. (note that this need is > independent of the path-component-as-tag feature -- these > operations are simply required of any system intended to > replace hierarchy with tags.) Good point. I've been envisioning the tagging UI as a space with current tags (editable), and with tag suggestions (clickable, to add to the current tags). In the case of a multiple selection (made in any manner discussed above), the current tag section would only list tags which apply to all of the items in the selection. The suggested tags, of course, would naturally include many, or all, of the tags which apply to only some of the selected; their frequency would determine which are most important to show (if we need to limit the suggestion list). In this manner, I could select a dozen photos I took in order to tag them all "vacation"; I might also notice that the "photo" tag only appeared in the suggestions, implying that some (or all) of these didn't contain that tag. Clicking on the suggestion would then apply it to all. The current tags could also be edited (or removed) directly. > - jim made the observation that he found himself using tags > less and less over time, once he realized that the > full-text indexer he was using made traditional "filing" > unnecessary. i've found the same thing (i index my MH > mail folders with mairix) -- but i do still use folders > (i.e., "tag equivalents") to make it easy to retrieve > things for which i think i may not remember the right > search terms later on. and of course i especially use them > when the tags (folders) can be assigned automatically > (with sort filters). all of which is to say that i view > tagging as an extension of full-text search, not a > replacement. It's certainly an extension in many cases. It is a replacement for most non-text formats. Of course we can hope to depend on some automatic metadata as well, but as we've seen already from experience, the automatic metadata we have now is insufficient. On a related note, the current DS "forgets" (that's a kind word, I think) all metadata supplied by activities, which undermines a lot of possible advantages to activities (like storing the current page in Read), as well as preventing them from going to the trouble to provide any metadata which might be useful to the kids for finding things later. Proposal (off the cuff, please poke holes in this): We might beef up the HIG in the area of tagging, and even suggest a set of canonical tags for various types of content. (Localized, of course.) Combining this with Scott's "path-tags", we might introduce Images/, Videos/, Documents/, and Audio/ tags in such a way that we get the best of both worlds. The system can "automatically" file things away in a reasonable subdirectory of the Journal, but the kids can always find *anything* they've done, in chronological order, by looking in the Journal itself (before selecting one of these path-tags as a query). - Eben > - we need to be mindful of erik's concern that if the goal is > to solve the problems deployments are reporting, whether > with file management or anything else, that we not > over-engineer the design in a way that keeps us from > finishing the implementation. while our mission may be > to build something "better", we shouldn't let that get in > the way of building something that, while "old", is very > useful. (e.g., if we haven't made enough progress on the > "real" solution, and kids would be best served in 9.1 by > a file manager activity of some sort, then we should > provide one.) > > > =--------------------- > paul fox, [EMAIL PROTECTED] > _______________________________________________ > Devel mailing list > [email protected] > http://lists.laptop.org/listinfo/devel > _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
