[sugar] Tagged Journal Proposal
Gary C Martin
Wed Oct 15 23:56:43 EDT 2008
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
>> | the HIG in the area of tagging, and even suggest a set of canonical
>> | tags for various types of content. (Localized, of course.)
>> | 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
>> | worlds. The system can "automatically" file things away in a
>> | reasonable subdirectory of the Journal, but the kids can always
>> | *anything* they've done, in chronological order, by looking in the
>> | Journal itself (before selecting one of these path-tags as a
>> Please don't conflate a good idea with a bad one. Activities
>> 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
>> only when trying to maintain compatibility with non-Journal
>> 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...
Size: 18477 bytes
Desc: not available
Url : http://lists.laptop.org/pipermail/sugar/attachments/20081016/fa8f8159/attachment-0001.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*.
> ( http://cscott.net/ )
More information about the Sugar-devel