On 16 Oct 2008, at 01:51, C. Scott Ananian wrote:

On Wed, Oct 15, 2008 at 8:26 PM, Benjamin M. Schwartz
<[EMAIL PROTECTED]> wrote:
| 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).

Please don't conflate a good idea with a bad one. Activities providing localized metadata (both tags and key:value pairs) automatically could be
a very good thing.  Even better would be internationalization: if
Activities use specific machine-readable words, then when objects are
passed around, those words can be localized for each user's Journal.

This is completely independent from the "path tags", which would be useful only when trying to maintain compatibility with non-Journal filesystems,
and are tremendously confusing otherwise.

Heh, Ben doesn't like path tags, it looks like. ;-)

As far as I'm concerned, whether it's "Images/" or "Images" is a tiny
implementation detail; I don't care much either way.

More straw men for the fire.

I'm not a fan of lots of little / characters everywhere (fine if a user want to type them in the unified text search area to look somewhere specific), but you could show entries that came (or are) outside of the local datastore by using different shaped tag icons that hint at the differences between a path tags, and arbitrary tags:

<<inline: tag_dir_styles.jpg>>



The first would be for when you're looking a a USB stick (or remote network disk etc), the second would be what you'd see if the files was copied into the local datastore or created there in the first place.

The main curiosity is what happens of someone tries to manipulate the tag path Images/holiday/Edinburgh version (i.e looking at file on external file-system). Some options:

* Don't allow them to be manipulated, do nothing

* If clicked, turn it into one full length input area "Images/holiday/ Edinburgh" and allow kid to edit the path, once done the file would be moved and/or directory tree for it created

* Try to allow them to be manipulated as 3 separate objects, drag reorders, deletion (order is maintained), click one to rename that bit of the path. After each change update the external file system to match.

Notice, that for my own sanity I'm assuming a Journal view is of a specific 'where/place'. In my mind this would be by default the local datastore (whatever that may turn into), or a filesystem (usually USB, or SD card, but kid could ask for a view of / or /boot). Note that you'd either see path tags, xor arbitrary tags, you'd never see both in the same view at once (path tags == external support or file geeking, arbitrary tags for items copied to local datastore).

I like the way the Journal visually, concretely, presents a USB or SD card when one is inserted, not sure how you'd want to represent more arbitrary geeky views of /usr/share/sugar/shell for the 0.1% of potential kid coders out there. So this makes copying items to and from USB, SD, datastore, just like it is now (drag and drop)**, but not sure how to cover the UI case where you want to copy to some where arbitrary in your file system.

** A datastore object tagged "images holiday edinburgh", when copied to USB or SD could be put in /images/holiday/edinburgh (datastore arbitrary tag order would need to be preserved and manipulatable, that also makes moving stuff back and forwards more friendly)

But I'm not convinced that "Images" and "Video" etc are useful tags to add; both
of these are already available via the "What" searches (ie, implicit
in mime-type info).  Someone mentioned that facebook adds magic image
tags based on *recognizing the faces of your friends* -- that seems
like a much better working example.  If Record can automatically add a
"Tom" tag to my pictures of Tom, that would *rock*.
 --scott

--
                        ( http://cscott.net/ )


--Gary
_______________________________________________
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Reply via email to