Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Sat, Sep 20, 2008 at 1:41 AM, Albert Cahalan [EMAIL PROTECTED] wrote: The case of b/a being distinct from a/b is necessary. You may call it a necessary evil, but in any case is is necessary. Surprisingly, it's not: http://wiki.laptop.org/go/Experiments_with_unordered_paths I still think it's worth supporting as an edge case, but from my actual experiments, it seems that path ordering is almost never actually necessary (!). For the journal to be truly usable, it needs to support pretty much all that we ask of a filesystem. You'll know you're doing OK when you can build joyride out of the journal. (git works, gcc works, etc.) This is a good test case. I'll confirm it, but I believe that this should actually work with unordered paths. The trickiness comes wrt to security in a multiuser system; Michael has been thinking hard about that. (I prefer just to punt it for the moment.) Give priority to tags (and anti-tags) which split the set of files most evenly. This greatly reduces search time; it is equivalent to balancing a binary tree. It turns out that only about 3 tags are needed to find any directory among the 900,000 files in my home directory (I'm working on getting better statistics, sorry). So the opposite criterion might be more important: give priority to tags which 'most narrow' the search -- that is, they match the *fewest* things! Once you've entered two search terms, the exact thing you are looking for ought to be in that list; you don't want to be distracted by terms held in common by lots of files which don't appreciably narrow your search. I hope to implement experiments (as described in the wiki page cited above) to start getting real life experience with these tradeoffs. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
Hi, http://wiki.laptop.org/go/Experiments_with_unordered_paths [..] I hope to implement experiments (as described in the wiki page cited above) to start getting real life experience with these tradeoffs. Awesome. We should try to get the GNOME people interested in rethinking this¹ involved as soon as we feel competent to talk about what the best thing to do is -- if we can get just a few GNOME hackers working on this, progress is going to happen extremely quickly and we'll end up with a shared implementation with the desktop, etc. The Boston GNOME Summit is October 11-13, so that'd be a great place to get people together and give a talk, I think? - Chris. ¹: http://www.gnome.org/~federico/news-2008-07.html#document-centric-gnome -- Chris Ball [EMAIL PROTECTED] ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. For example, when you type 'fsf', both 'http://fsf.org/' and other things tagged with 'fsf' show up. This ties in with one of my frustrations with google's tag system: I have olpc, olpc-fedora, olpc-sugar, olpc-sugarlabs, etc tags in google, when what I really want is 'olpc/fedora', 'olpc/sugar', etc. Sometimes I want to see all olpc-related mail, sometimes only sugar-related olpc mail, etc. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of files that are the result of a search (which can look very much like groups of files which are in a specific directory). Rather than having two separate views for 'hierarchy' and 'journal', this unifies them so achieve a more consistent and growable interface: you don't have to discard everything you know and learn a new metaphor and interface when you start to use 'folders'. From irc: (02:18:45 PM) C. Scott Ananian: by default searches will be confined to ~/Journal; the real question is how to search *outside* that directory. (02:18:51 PM) HoboPrimate: look at nautilus (02:19:04 PM) HoboPrimate: you see the directories as buttons. (02:19:19 PM) HoboPrimate: imagine seeing just a Journal button there (02:19:24 PM) HoboPrimate: below, the search box (02:19:33 PM) HoboPrimate: this would mean, you are searching within the journal only (02:19:49 PM) HoboPrimate: now, if you click on the journal button, it expands to allow changing it [...] (02:21:59 PM) C. Scott Ananian: HoboPrimate: well, in my ideal world you could apply a tag to any file (02:22:05 PM) C. Scott Ananian: HoboPrimate: it will just be a special xattr (02:22:27 PM) HoboPrimate: that would rock. (02:22:45 PM) HoboPrimate: so tagging wouldn't be a Journal specific thing, but (02:23:04 PM) HoboPrimate: be propagated when you move the file to other non-sugar but xattr aware systems (02:23:14 PM) C. Scott Ananian: yes The dynamic tag suggestion and ordering stuff that epiphany has (nicely presented by eduardo) would be directly applicable; all we need is the special idea that *all files are tagged by default by their path* and *there are special ordered tags* to extend the journal into a filesystem browser. Browsing a directly hierarchy feels just like browsing through tag sets; once I pick the 'Music/' tag, the 'Music/Bach' and 'Music/Beethoven' tags show up as possible extensions to my search. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
2008/9/19 C. Scott Ananian [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. For example, when you type 'fsf', both 'http://fsf.org/' and other things tagged with 'fsf' show up. This ties in with one of my frustrations with google's tag system: I have olpc, olpc-fedora, olpc-sugar, olpc-sugarlabs, etc tags in google, when what I really want is 'olpc/fedora', 'olpc/sugar', etc. Sometimes I want to see all olpc-related mail, sometimes only sugar-related olpc mail, etc. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. I don't follow this. Thinking in Journal terms, where currently the only access is through the search box, you could search for olpc sugarlabs to see your olpc-sugar e-mails, or olpc to see all which fit under olpc, i.e. olpc-fedora+olpc-sugarlabs+olpc-sugar. A search which doesn't work if you follow the containerization way of directories, would be if you searched just for sugarlabs . This would give you olpc-sugarlabs results, but also would find sugarlabs tagged entries which didn't belong to the olpc- root (like a logo of Sugarlabs, or some document about it). To go back to the way Gmail works, or should work, would be having the ability to assign multiple tags to each label, i.e., make them be virtual folders. So in your case you would have one which showed results with tags olpc, sugar, another olpc, fedora, and olpc, sugar, and olpc, sugarlabs. Then you could still have one just with tag olpc which would show all of the above, or you could just search for olpc tagged entries giving all of the above as well. So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. (Debian has had for some time debtags, which are a more advanced method of tagging objects originally developed for libraries, but I think is too formal for kids, since it would need for them to learn a new classification system to categorize their library of objects.) If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of files that are the result of a search (which can look very much like groups of files which are in a specific directory). Yep, I think this is a good idea to move files from a hierarchical system to a non hierarchical system (the Journal) and still reuse the information contained in that first organizational system. Rather than having two separate views for 'hierarchy' and 'journal', this unifies them so achieve a more consistent and growable interface: you don't have to discard everything you know and learn a new metaphor and interface when you start to use 'folders'. I hope, like I said above, that virtual folders or saved searches (they're the same, just differently named) would replace static folders. From irc: (02:18:45 PM) C. Scott Ananian: by default searches will be confined to ~/Journal; the real question is how to search *outside* that directory. (02:18:51 PM) HoboPrimate: look at nautilus (02:19:04 PM) HoboPrimate: you see the directories as buttons. (02:19:19 PM) HoboPrimate: imagine seeing just a Journal button there
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: 2008/9/19 C. Scott Ananian [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: Ideas for Journal: How epiphany browser manages bookmarks just with tags (and does it nicely, with potential of improving of course). I made a screenshot slide-show of how tagging and the dynamic bookmarks menu based solely on tags work in Gnome's Epiphany browser. I hope this can be usefull to gather ideas for how the tagging system in the Journal could work. This could also be helpful if tagging in the future can be done within activities, so that they are easily, and thus more often, used. I show how in Epiphany: tags are searched; tags are suggested; pre-existing and new tags are added; tags are presented; and how tagged bookmarks are organized in a menu. The size is a bit big because of all the screenshots, it's 46.7 MB . C_scott uploaded it for me, at http://dev.laptop.org/~cscott/eduardo-epiphany-tags.pdf Eduardo Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. For example, when you type 'fsf', both 'http://fsf.org/' and other things tagged with 'fsf' show up. This ties in with one of my frustrations with google's tag system: I have olpc, olpc-fedora, olpc-sugar, olpc-sugarlabs, etc tags in google, when what I really want is 'olpc/fedora', 'olpc/sugar', etc. Sometimes I want to see all olpc-related mail, sometimes only sugar-related olpc mail, etc. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. I don't follow this. Thinking in Journal terms, where currently the only access is through the search box, you could search for olpc sugarlabs to see your olpc-sugar e-mails, or olpc to see all which fit under olpc, i.e. olpc-fedora+olpc-sugarlabs+olpc-sugar. A search which doesn't work if you follow the containerization way of directories, would be if you searched just for sugarlabs . This would give you olpc-sugarlabs results, but also would find sugarlabs tagged entries which didn't belong to the olpc- root (like a logo of Sugarlabs, or some document about it). To go back to the way Gmail works, or should work, would be having the ability to assign multiple tags to each label, i.e., make them be virtual folders. So in your case you would have one which showed results with tags olpc, sugar, another olpc, fedora, and olpc, sugar, and olpc, sugarlabs. Then you could still have one just with tag olpc which would show all of the above, or you could just search for olpc tagged entries giving all of the above as well. So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. I don't mean to belittle the utility of virtual folders (I think they're quite powerful), but you can also get a close approximation to them by applying a sufficiently unique tag to a group of items as well. In fact, a basic implementation of such a feature could do exactly that, requesting a name for the virtual folder and then tagging the selected items with vf:Name of virtual folder (or something similar, but you get the idea). The real question (I didn't overlook this!) regarding the concept of virtual folders (or, more specifically, saved searches) is whether or not they are dynamic. That is, does the saved search represent an expression or a value? My above tag idea is only valid, of course, when they are represented in value form. For more power (but more complexity) one would store the search terms, filters, etc. and re-apply them on the fly to a growing list. I'm not sure which of these is more desired. They both have merits. (Debian has had for some time debtags, which are a more advanced method of tagging objects originally developed for libraries, but I think is too formal for kids, since it would need for them to learn a new classification system to categorize their library of objects.) If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: 2008/9/19 C. Scott Ananian [EMAIL PROTECTED]: On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva [EMAIL PROTECTED] wrote: If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. I don't follow this. Thinking in Journal terms, where currently the only access is through the search box, you could search for olpc sugarlabs to see your olpc-sugar e-mails, or olpc to see all which fit under olpc, i.e. olpc-fedora+olpc-sugarlabs+olpc-sugar. A search which doesn't work if you follow the containerization way of directories, would be if you searched just for sugarlabs . This would give you olpc-sugarlabs results, but also would find sugarlabs tagged entries which didn't belong to the olpc- root (like a logo of Sugarlabs, or some document about it). My example might not have been the best, but independent tags start having real problems when I have a lot of tags and many of the tags are duplicated. Some more examples: * jill/joe might be what jill thinks of joe, while joe/jill might be what joe thinks of jill. * techsquares/lists is email relating to the mailing lists I maintain for tech-squares, while lists contains all my subscription information for mailing lists I belong to, and lists/techsquares is thus my own mailman login for the techsquares list (which I'm on, as well as maintain). * The total list of tags in my gmail instance is very large! But the top-level list could be much smaller if I could order them hierarchically. So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. I think this is a separate functionality. This lets me take my 'techsquares/lists subscribe-requests' search and turn it into a top level tag. Containerization is meant to prevent all tags from becoming top level. Rather than having two separate views for 'hierarchy' and 'journal', this unifies them so achieve a more consistent and growable interface: you don't have to discard everything you know and learn a new metaphor and interface when you start to use 'folders'. I hope, like I said above, that virtual folders or saved searches (they're the same, just differently named) would replace static folders. They're complimentary. If you look at [[Olpcfs]], there's a way to navigate 'tag space' and even 'search space' as if it were a directory. Ordered tags are a way to navigate directory space as if it were a tag soup. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
On Fri, Sep 19, 2008 at 4:57 PM, Eben Eliason [EMAIL PROTECTED] wrote: Two) to get at the thing you're looking for. So, again, I'm not sure that order really matters. Of course, if it DID really matter for a reason I'm not presently considering, we could allow tags of the form: A/B To match on A, B, A B B A, and also A/B (but not B/A). In other words, the addition of the slash to the tag format is used similarly to the way quotes are used to group two tags into one. Instead of grouping, however, it orders instead. It's interesting, but I'm not sure I see a good utility there yet. I think there is compelling utility in terms of mapping tag space to a filesystem and back. I hope that (like quotes) there is not all that often when you need to use them -- but they are a useful power-user feature. The following are all related searches: A B-- matches these tag sets A B C, B A C, A/B C, B/A C, etc. A/B-- matches A/B, C/A/B, A/B/C, etc. B/A-- matches B/A, C/B/A, B/A/C, etc. A B -- matches 'A B' C, etc /A/B -- matches A/B/C but not C/A/B They express slightly different meanings, but in many cases will be indistinguishable from A B. I think they add a lot of power to the tag language, although naive users won't need to use it often. Completion on a search for A/B would suggest A/B/C if there is a 'subfolder' C; it would suggest A/B C if there was an item labelled with A/B and tag C. If a young user has never made subfolders, then the slash-separated options will never be suggested and all this power remains hidden. An interesting point Eduardo brought up was the relationship between folders and saved searches. Do tag completions (ie sub folders or related tags) show up in the journal itself, or only in a pane during a search? If they show up as first class objects, then it might be nice to have searches in general as first class objects. I think I'm arguing that tag completions are not the same thing as journal items, and only show up during a search. I could be convinced otherwise. Another interesting point: gmail's UI never lets you see the results of the 'empty' search (that is, all objects). By default the search is restricted to 'in:Inbox' and the easiest UI mechanisms always restrict the search to a 'folder'. You can click 'Search Mail' with an empty search query, though, and what you get is very similar to what one might imagine the Journal to be: a chronological list of all your email (activity instances), grouped by thread (version), with a list of clickable tags on each which you can use to find other similar emails (activity instances). Gmail does have a flexible 'rules' system to help automatically tag/categorize/file documents, though; it may be worthwhile thinking what the Journal could do in that regard. --scott -- ( http://cscott.net/ ) ___ Sugar mailing list Sugar@lists.laptop.org http://lists.laptop.org/listinfo/sugar
Re: [sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags
Eben Eliason writes: On Fri, Sep 19, 2008 at 3:59 PM, Eduardo H. Silva hoboprimate at gmail.com wrote: 2008/9/19 C. Scott Ananian cscott at laptop.org: Eben, Eduardo, and I have been chatting about this some over IRC. What I find most interesting here is how *filesystem paths* (well, URL paths in this particular case) are integrated with tags. It's more than interesting. Solving the path problem is critical. Paths allow compatibility with the world, including the laptop itself. They are also a decent way to organize things, far from perfect yet Superior to the overflowing inbox. BTW, I'm delighted to see some serious consideration of the issue. If you accept that tags can sometimes be ordered, so that a/b is different than b/a (although both will show up on searches for 'a' and 'b'), then this starts looking more and more like a way to view filesystems as well, for those old enough to want to do that. ... So I agree that some kind of containerization is needed, but not in the form of a/b being different than b/a, but by using virtual folders or saved searches which would effectively act as virtual folders, with specific tags, search terms, object types, even a period of time if you wished. The case of b/a being distinct from a/b is necessary. You may call it a necessary evil, but in any case is is necessary. The question then becomes: Is the alternate method good, and is it good enough to implement despite any user confusion and performance issues that may exist? Perhaps there should be a mode switch, with regular filesystems (USB stick, SD card, /, $HOME, /tmp) being visible only when in ordered mode. The real question (I didn't overlook this!) regarding the concept of virtual folders (or, more specifically, saved searches) is whether or not they are dynamic. That is, does the saved search represent an expression or a value? My above tag idea is only valid, of course, when they are represented in value form. For more power (but more complexity) one would store the search terms, filters, etc. and re-apply them on the fly to a growing list. I'm not sure which of these is more desired. They both have merits. If both work, then a mode switch could be made available. Note that work means scalability for both CPU time and RAM. On the existing hardware, you need to handle 100 thousand files. On something like a regular PC you'll need to handle a million. That means O(log) scaling at worst, for both CPU time and RAM. If you have files in ~/Journal/Music/Bach/Disc1 and ~/Journal/Music/Beethoven/Disc1, you can search for 'Bach', 'Music Bach' as well as 'Bach/Disc1' or 'Music/Bach/Disc1' if you want to be specific. When you insert a USB key with files in a directory called 'Music/Mozart', they appear in the journal as if they were tagged 'Music/Mozart' and you can search for 'Mozart' or 'Music' to find them. When I copy them to my XO, the tags come with, and I have operations to retag groups of files that are the result of a search (which can look very much like groups of files which are in a specific directory). Yep, I think this is a good idea to move files from a hierarchical system to a non hierarchical system (the Journal) and still reuse the information contained in that first organizational system. Absolutely. This is a critical element which we need to make work when we flesh out support for external devices in the next release. This idea is the only solace I have been able to give to the many many people frustrated with the previous behavior of the devices in the Journal. Round trip ability (USB - XO - USB) is important. Losing all the directory info is no good. For the journal to be truly usable, it needs to support pretty much all that we ask of a filesystem. You'll know you're doing OK when you can build joyride out of the journal. (git works, gcc works, etc.) At the end of my pdf, I showed how epiphany creates a seemingly hierarchical bookmark menu. But it is only seemingly. Remember, there where 3 bookmarks tagged education and free software. Because these tags where so popular, they became top-level menus, and inside each of these menus, the same 3 bookmarks lived, in their own section because they shared an extra tag. This is a really powerful structure, and I think it's just the thing we need to make navigating the Journal more pleasurable (for those that really don't like the idea of searching). Getting the thresholds right for the number of items required to use a tag before it becomes top level will be a challenge (it should probably be based on a ratio to total unique tags). Give priority to tags (and anti-tags) which split the set of files most evenly. This greatly reduces search time; it is equivalent to balancing a binary tree. Thanks for sharing this. I think the ideas we're talking about should definitely be added to the list of future goals so we can work them in. It would be a big improvement. That's
