Tagged Journal Proposal

[Gary C Martin]

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

> On Wed, Oct 15, 2008 at 8:26 PM, Benjamin M. Schwartz
> <bmschwar at fas.harvard.edu> 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:
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tag_dir_styles.jpg
Type: image/jpeg
Size: 18477 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20081016/fa8f8159/attachment.jpg>
-------------- next part --------------


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