Re: Tagged Journal Proposal
On Wed, Oct 15, 2008 at 11:56 PM, Gary C Martin [EMAIL PROTECTED] wrote: 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: Ooh, I like the look of that a lot. It does seem like it would be a little harder to learn that typing '/' gives that magic shaped tag, but maybe tag-completion does that for us by magic. ie, in a context where foo/ makes sense, typing footab will give you the slash-shaped foo. Now, how to code that in GTK... (sigh) Maybe splitting the widget into body and 'cap' will make dealing with non-rectangular widgets less painful. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Fwd: Tagged Journal Proposal
forgot to reply-all -w -- Forwarded message -- From: Walter Bender [EMAIL PROTECTED] Date: Wed, Oct 15, 2008 at 7:07 PM Subject: Re: Tagged Journal Proposal To: [EMAIL PROTECTED] Haven't had a chance to review the talk note yet, but one observation based on Paul's comment: 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. The Record activity in fact does group photos based upon the session they were taken. This is the sort of thing that could be delegated to activities, where the higher-level knowledge to create sets would be available. As long as there is a way to communicate this to the datastore/journal we should be OK in this regard. In other words, the UI should probably be elsewhere. -walter -- Walter Bender Sugar Labs http://www.sugarlabs.org -- Walter Bender Sugar Labs http://www.sugarlabs.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tagged Journal Proposal
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]
Re: Tagged Journal Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason 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. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj2iiwACgkQUJT6e6HFtqQRGACffQ6zRi3sOM+UdKztvR5+hG3l VgQAn2EBk+9Va0PV6utSykMKsh2j4LQG =6zjn -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tagged Journal Proposal
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. 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/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tagged Journal Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | Heh, Ben doesn't like path tags, it looks like. ;-) No, I don't. (I do like Scott, and I do like Scott's demo in general and in other regards.) | Someone mentioned that facebook adds magic image | tags based on *recognizing the faces of your friends* -- that seems | like a much better working example. Oops, that's a miscommunication. Facebook provides a GUI that allows you to tag specific image regions as being particular people, by hand. Maybe a better tag would be victory for objects representing chess games that I won? - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj2kkEACgkQUJT6e6HFtqQf3wCeK3sf9SJ67mThMtT2dxkRAvJ9 vN0AoITIlmZjDAx6S3Z5mGWLOuYXFbN7 =XQop -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tagged Journal Proposal
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
Re: Tagged Journal Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | A hand-drawn proposal for what a Journal supporting directory | traversal as well as tag space exploration is in the attached PDF. | Discussion welcome! Could you please point me to a description of the semantics for these ordered tags? Since I do not know how the tags are meant to work, I cannot provide any feedback on the UI. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjZMcUACgkQUJT6e6HFtqSAKACfelYUC+nbT6H+Ei38mXEagM3n 69gAn3lFWjXQ/tgDQ3zqyqpYO+ewnRLC =fdWU -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Tue, Sep 23, 2008 at 02:05:55PM -0400, C. Scott Ananian wrote: A hand-drawn proposal for what a Journal supporting directory traversal as well as tag space exploration is in the attached PDF. Discussion welcome! I am unable to view this PDF. It appears blank on this end. Would you provide a PNG? Erik ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Sep 23, 2008, at 2:05 PM, C. Scott Ananian wrote: A hand-drawn proposal for what a Journal supporting directory traversal as well as tag space exploration is in the attached PDF. Discussion welcome! FWIW, I made several impassioned proposals for these features -- in fact, with some visual resemblance to your own -- on the Pentagram whiteboards, but the Pentagram folks were opposed on account of excess complexity. -- Ivan Krstić [EMAIL PROTECTED] | http://radian.org ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tagged Journal Proposal
On Tue, Sep 23, 2008 at 2:13 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | A hand-drawn proposal for what a Journal supporting directory | traversal as well as tag space exploration is in the attached PDF. | Discussion welcome! Could you please point me to a description of the semantics for these ordered tags? Since I do not know how the tags are meant to work, I cannot provide any feedback on the UI. Previous discussion: http://lists.laptop.org/pipermail/sugar/2008-September/008432.html Briefly: in addition to specifying multiple tags as a b c you can also separate some of the tags with slashes, like a/b c. A search for a/b only turns up entries tagged a/b not entries tagged b/a or a b, although a search for a b turns up all of them. Most of the tag browsing is borrowed from either gmail or epiphany; Eduardo's walkthrough of epiphany at the link above should give you a good idea. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tagged Journal Proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | On Tue, Sep 23, 2008 at 2:13 PM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | C. Scott Ananian wrote: | | A hand-drawn proposal for what a Journal supporting directory | | traversal as well as tag space exploration is in the attached PDF. | | Discussion welcome! | | Could you please point me to a description of the semantics for these | ordered tags? Since I do not know how the tags are meant to work, I | cannot provide any feedback on the UI. | | Previous discussion: | http://lists.laptop.org/pipermail/sugar/2008-September/008432.html | | Briefly: in addition to specifying multiple tags as a b c you can | also separate some of the tags with slashes, like a/b c. A search | for a/b only turns up entries tagged a/b not entries tagged b/a | or a b, although a search for a b turns up all of them. OK, so if I understand you correctly, you are not actually adding any semantics at all to the tags. What you are saying is that I can tag objects with arbitrary strings that may include the / character, and then filter objects by substring search on their tags. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjZWOsACgkQUJT6e6HFtqRBpgCfd+Gxdi1Jfmam1++tTZLtyiBP d60AniDjqESTQAMD3H+2/TYHYl36teI1 =WI64 -END PGP SIGNATURE- ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Tagged Journal Proposal
On Tue, Sep 23, 2008 at 5:00 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: | Briefly: in addition to specifying multiple tags as a b c you can | also separate some of the tags with slashes, like a/b c. A search | for a/b only turns up entries tagged a/b not entries tagged b/a | or a b, although a search for a b turns up all of them. OK, so if I understand you correctly, you are not actually adding any semantics at all to the tags. What you are saying is that I can tag objects with arbitrary strings that may include the / character, and then filter objects by substring search on their tags. If you mount a USB key, and it has files in Music/Bach/Disc1, they appear in your journal's object view tagged as 'Music/Bach/Disc1'. They show up in searches for 'Music' and 'Bach'. If a legacy application saves a file to ~/Journal/cute/cats/my-picture.jpg, then my-picture.jpg shows up in the Journal tagged with 'cute/cats'. This is pretty much indistinguishable from being tagged cute cats, unless you happen to care enough to do ordered searches (young kids presumably would not). --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Tue, Sep 23, 2008 at 5:46 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Scott, I thought you came to the conclusion that there was no use for ordered tags. What changed your mind? Was it the abilty to browse hierarchical systems with the Journal? I also thought you came to the conclusion that turning directory names as tags alone worked. I would drop them if I have to, and I don't expect them to be used often, but I think having the 'escape hatch' is useful. The only time they really show up is when you're importing content from an existing legacy device. I don't expect there to be much difference in practice between browsing Activities/GCompris/Math/Easy and Activities GCompris Math Easy. And, in fact, the unordered tags might make the Activities GCompris Easy search easier to find. So, I've changed my mind from ordered tags are absolutely vital to ordered tags could be useful in edge cases. Since it's my proposal I'm drawing up, I threw them in. =) How would the results be different if you searched for: a/b a b b a No difference in the last two. The first search would only find a/b not b/a or a b or b a -- but it would also return a/b/c and c/a/b and a/b c, etc. I imagine it's your idea of having the journal be able to browse hierarchically external devices, and the current filesystem above /home/olpc/Journal ? That's there where icon in the top bar. Where = Journal (~/Journal), NAND (full filesystem), USB, SD, etc. As to Ivin's point that he brought this ui design to pentagram in the past, and it was rejected for being too complicated, If the kid doesn't use tags, then a lot of the busyness goes away. I expect that Activities would probably still come tagged as Activities; that and Trash would be the only thing in the left-hand panel. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) Goof idea! I hope it's not too bad, as well. ;-) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Tue, Sep 23, 2008 at 6:05 PM, [EMAIL PROTECTED] wrote: c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. Hah, you're getting into implementation details now. I believe that anyone creating indexes for or on removable devices is living in a state of sin. The searches should still work immediately, with no indexes: they might just take a while. This ends up being a recursive directory traversal, but it's not Death. That's fine, we can show the immediate results immediately, and the rest just take a while. We can probably write some hints for use during the current session, esp for large devices (attached USB cards, persistent SD) but we can't assume that these hints are persistent across mounts, or aren't corrupted in the process of removing the device. (As a special case, for devices formatted ext2/3 we can probably play some tricks with the mount count and dirty flag to let us know when it's safe to use old hints.) --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Tue, Sep 23, 2008 at 6:20 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: I also imagine that the Extra options menu would appear in the main toolbar in the Detailed view. And aditionally, like in one of eben's mockup, once a entry is checked in this list view, either the main toolbar changes to provide contextual actions (those you placed in that menu, copy, apply label, etc.), or a new menu appears bellow the main one with these options, so as not too loose the searching/filtering features which can be handy to have for various journal entries and still have handy the search and filtering features. Top-left corner, More Actions. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
I'm paying attention to this thread, quietly. I like a lot of this. :) I'll let it continue without interfering, for now, but I wanted to point out that the new toolbar design (posted on the wiki) would make that more actions option much nicer. For that matter, as Eduardo mentions, they don't mean anything until you make a selection, so we could reveal them in a toolbar only then, perhaps. - Eben On Tue, Sep 23, 2008 at 6:20 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: I also imagine that the Extra options menu would appear in the main toolbar in the Detailed view. And aditionally, like in one of eben's mockup, once a entry is checked in this list view, either the main toolbar changes to provide contextual actions (those you placed in that menu, copy, apply label, etc.), or a new menu appears bellow the main one with these options, so as not too loose the searching/filtering features which can be handy to have for various journal entries and still have handy the search and filtering features. Eduardo 2008/9/23 [EMAIL PROTECTED]: c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. paul =- paul fox, [EMAIL PROTECTED] ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Tue, Sep 23, 2008 at 6:25 PM, Eben Eliason [EMAIL PROTECTED] wrote: I'm paying attention to this thread, quietly. I like a lot of this. :) I'll let it continue without interfering, for now, but I wanted to point out that the new toolbar design (posted on the wiki) would make that more actions option much nicer. For that matter, as Eduardo mentions, they don't mean anything until you make a selection, so we could reveal them in a toolbar only then, perhaps. I believe that page for the toolbar design is (correct me if I'm wrong Eben): http://wiki.laptop.org/go/Designs/Toolbars I also REALLY like this idea. Perhaps if the journal integrates the idea of a license icon/tag, content that is backed up to the school server that is creative commons or similarly licensed could be made available to other students. I like the idea of a hierarchy of aggregation and sharing. It would also allow a form of non-real-time collaboration that we currently don't support. I am a little unsure what the Actions, Objects and Labels tabs do however. Bobby - Eben On Tue, Sep 23, 2008 at 6:20 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: I also imagine that the Extra options menu would appear in the main toolbar in the Detailed view. And aditionally, like in one of eben's mockup, once a entry is checked in this list view, either the main toolbar changes to provide contextual actions (those you placed in that menu, copy, apply label, etc.), or a new menu appears bellow the main one with these options, so as not too loose the searching/filtering features which can be handy to have for various journal entries and still have handy the search and filtering features. Eduardo 2008/9/23 [EMAIL PROTECTED]: c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
On Tue, Sep 23, 2008 at 7:36 PM, Bobby Powers [EMAIL PROTECTED] wrote: On Tue, Sep 23, 2008 at 6:25 PM, Eben Eliason [EMAIL PROTECTED] wrote: I'm paying attention to this thread, quietly. I like a lot of this. :) I'll let it continue without interfering, for now, but I wanted to point out that the new toolbar design (posted on the wiki) would make that more actions option much nicer. For that matter, as Eduardo mentions, they don't mean anything until you make a selection, so we could reveal them in a toolbar only then, perhaps. I believe that page for the toolbar design is (correct me if I'm wrong Eben): http://wiki.laptop.org/go/Designs/Toolbars That's the one. I also REALLY like this idea. Perhaps if the journal integrates the idea of a license icon/tag, content that is backed up to the school server that is creative commons or similarly licensed could be made available to other students. I like the idea of a hierarchy of aggregation and sharing. It would also allow a form of non-real-time collaboration that we currently don't support. Yeah, I'd love to see this kind of information sharing happen. I am a little unsure what the Actions, Objects and Labels tabs do however. They are alternate views, or ways of organizing, the data. The action/object split is elaborated upon in the posted Journal designs. (http://wiki.laptop.org/go/Designs/Toolbars) I'm not sure what Labels is. Scott? - Eben Bobby - Eben On Tue, Sep 23, 2008 at 6:20 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: I also imagine that the Extra options menu would appear in the main toolbar in the Detailed view. And aditionally, like in one of eben's mockup, once a entry is checked in this list view, either the main toolbar changes to provide contextual actions (those you placed in that menu, copy, apply label, etc.), or a new menu appears bellow the main one with these options, so as not too loose the searching/filtering features which can be handy to have for various journal entries and still have handy the search and filtering features. Eduardo 2008/9/23 [EMAIL PROTECTED]: c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
Scott, I thought you came to the conclusion that there was no use for ordered tags. What changed your mind? Was it the abilty to browse hierarchical systems with the Journal? I also thought you came to the conclusion that turning directory names as tags alone worked. How would the results be different if you searched for: a/b a b b a ? I imagine it's your idea of having the journal be able to browse hierarchically external devices, and the current filesystem above /home/olpc/Journal ? I love your idea of showing tags along side the journal entries. Clicking them would add them to the current search. Of course, there would be a limit to how many are shown for space-sake. As to Ivin's point that he brought this ui design to pentagram in the past, and it was rejected for being too complicated, I don't understand why they thought that. Having meta-tags (a tag which collects various tags, akin to dynamic virtual folders) and tags visible on the left would make: The most popular tags visible Tagging could be done by dnd object entries to the left-sided tags Clicking on the tags would add them to the search This seems like an easier taggin Journal to use, since tag management isn't hidden on the detailed view only. And if need be, the left tags pane could be toggled on/off by some 'tag' button. I hope Eben takes a look at your ui proposal and give it his Sugar love and polish to it :) Eduardo Eduardo 2008/9/23 Benjamin M. Schwartz [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 C. Scott Ananian wrote: | On Tue, Sep 23, 2008 at 2:13 PM, Benjamin M. Schwartz | [EMAIL PROTECTED] wrote: | -BEGIN PGP SIGNED MESSAGE- | Hash: SHA1 | | C. Scott Ananian wrote: | | A hand-drawn proposal for what a Journal supporting directory | | traversal as well as tag space exploration is in the attached PDF. | | Discussion welcome! | | Could you please point me to a description of the semantics for these | ordered tags? Since I do not know how the tags are meant to work, I | cannot provide any feedback on the UI. | | Previous discussion: | http://lists.laptop.org/pipermail/sugar/2008-September/008432.html | | Briefly: in addition to specifying multiple tags as a b c you can | also separate some of the tags with slashes, like a/b c. A search | for a/b only turns up entries tagged a/b not entries tagged b/a | or a b, although a search for a b turns up all of them. OK, so if I understand you correctly, you are not actually adding any semantics at all to the tags. What you are saying is that I can tag objects with arbitrary strings that may include the / character, and then filter objects by substring search on their tags. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjZWOsACgkQUJT6e6HFtqRBpgCfd+Gxdi1Jfmam1++tTZLtyiBP d60AniDjqESTQAMD3H+2/TYHYl36teI1 =WI64 -END PGP SIGNATURE- ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Goof idea! Eduardo 2008/9/23 C. Scott Ananian [EMAIL PROTECTED]: On Tue, Sep 23, 2008 at 5:00 PM, Benjamin M. Schwartz [EMAIL PROTECTED] wrote: | Briefly: in addition to specifying multiple tags as a b c you can | also separate some of the tags with slashes, like a/b c. A search | for a/b only turns up entries tagged a/b not entries tagged b/a | or a b, although a search for a b turns up all of them. OK, so if I understand you correctly, you are not actually adding any semantics at all to the tags. What you are saying is that I can tag objects with arbitrary strings that may include the / character, and then filter objects by substring search on their tags. If you mount a USB key, and it has files in Music/Bach/Disc1, they appear in your journal's object view tagged as 'Music/Bach/Disc1'. They show up in searches for 'Music' and 'Bach'. If a legacy application saves a file to ~/Journal/cute/cats/my-picture.jpg, then my-picture.jpg shows up in the Journal tagged with 'cute/cats'. This is pretty much indistinguishable from being tagged cute cats, unless you happen to care enough to do ordered searches (young kids presumably would not). --scott -- ( http://cscott.net/ ) ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
I also imagine that the Extra options menu would appear in the main toolbar in the Detailed view. And aditionally, like in one of eben's mockup, once a entry is checked in this list view, either the main toolbar changes to provide contextual actions (those you placed in that menu, copy, apply label, etc.), or a new menu appears bellow the main one with these options, so as not too loose the searching/filtering features which can be handy to have for various journal entries and still have handy the search and filtering features. Eduardo 2008/9/23 [EMAIL PROTECTED]: c. scott ananian wrote: On Tue, Sep 23, 2008 at 5:57 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ah, so that's why you separate these legacy-hierarchical files with a light grey slash (/) . So that a kid who only knows the Journal tagging world can ignore it, and users who have know the hierarchical world can understand it and make advance usage of that knowledge when transfering from or browsing hierarchical filesystems. Exactly. =) seems like acknowledging the path form of these directory-derived tags might also make working with devices for which no tag list has been, or can be, created. i.e., when you first install a large new USB stick, there will certainly be a delay before a tag index can or will be built. the grey slashes might be black during that time. paul =- paul fox, [EMAIL PROTECTED] ___ Sugar mailing list [EMAIL PROTECTED] http://lists.laptop.org/listinfo/sugar ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: [sugar] Tagged Journal Proposal
One extra thing that epiphany has that you didn't explicitelly showed in your mockup is, as you select/type tags, the most popular and/or recent section of the tag pane gets related tags thrown into its mix. Related tags are those which have been applied to objects along side the typed one(s). Also, what completion should be made for text typed in the Search box? I think it best to only suggest tags, not only to make it simple (and performant), but also because the object entries results could be seen as already being suggestions. As for labels, there are the static saved searches (which may be usefull to collecting for a frozen bunch of found entries), and dynamic saved searches (your fuzzy idea! Perhaps more usefull to power-users, but that is the point of sugar, let kids reach for the sky, right?). Eben also suggested once just adding an extra unique tag to a bunch of different objects, thus making a static collection of objects (So you would archive a project called Report on solar system, and this label would be added to photos, conversations, text, webpages, etc. which where part of it). Hope I've not confused this last part about collections and saved searches (it certainly is becoming confusing to me :) ) Eduardo 2008/9/24 C. Scott Ananian [EMAIL PROTECTED]: On Tue, Sep 23, 2008 at 7:48 PM, Eben Eliason [EMAIL PROTECTED] wrote: I am a little unsure what the Actions, Objects and Labels tabs do however. They are alternate views, or ways of organizing, the data. The action/object split is elaborated upon in the posted Journal designs. (http://wiki.laptop.org/go/Designs/Toolbars) I'm not sure what Labels is. Scott? Yes, I drew the 'object' view. The 'action' view is at http://wiki.laptop.org/go/Designs/Journal. I don't really know whether the tagging and filtering makes sense in the Action view, but I would like it to. Perhaps 'actions which include objects matching the current search' is what is displayed? The 'Labels' view is my fuzzy thinking about 'saved searches'. I'd like to be able to save any current search as a label to be applied; the 'Labels' view would let you view and edit those saved searches. I don't have a good design for that, and I'm certainly not certain it should be accorded equal weight with the 'object' and 'action' views. Ideas welcome. This is power-user territory: unless either I or someone else gets better ideas about how it would work, I'm inclined to omit it for now. --scott -- ( http://cscott.net/ ) ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
