[sugar] Ideas for Journal: How epiphany browser manages bookmarks just with tags

[Eduardo H. Silva]

2008/9/19 C. Scott Ananian <cscott at laptop.org>:
> On Fri, Sep 19, 2008 at 2:31 PM, Eduardo H. Silva <hoboprimate at gmail.com> 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
> (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*
I like this idea, but instead of tagged, it would be metadata to be
shown in the detailed view, just like mime-type and size. These would
be searchable, but not acted or changed upon. They would be used for
power-users, using the above method of leaving the Journal confines,
into /home/olpc or up.

 and *there are special ordered tags* to extend the journal
> into a filesystem browser.

I hope I showed above how tags can be used without being specially
ordered. I envision that the usage of "Music/Beethoven" would be
usefull for power-users who want to drill down directly into a
hierarchy existing in some external device, or above
/home/olpc/Journal . Inside the journal, I still think tags should
rule.

 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.

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.

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

Eduardo