Tagged Journal Proposal

[Eben Eliason]

On Wed, Oct 15, 2008 at 6:03 PM,  <pgf at laptop.org> 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, pgf at laptop.org
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>