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

[Eben Eliason]

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>:
>> 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.

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 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.

>> 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".

Could.  As I mentioned, you can still have virtual folders without the
dynamic component.  You can then find a new object later, and select
"Add to folder > My favorite VF" to apply the necessary tag (or
whatever the implementation may be).

>> 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'm not sure I've wrapped my head around this enough to agree or
disagree.  On one hand, I can see Eduardo's point that something very
very close to this is attainable with normal tags.  I also see Scott's
argument, that normal tags fail, eg:

/A/B/x
/B/A/y

Let x, y represent the sets of objects found at those paths. The main
question, really, is if x and y are the same set.  In a simple tag
system, the answer is yes.  They are both tagged with A and B (which
matches on both "A B" and "B A").  In an ordered system they are not.
Of course, I also ask why you might want this anyway.  The beauty of
tags, as Eduardo mentioned, is that you could browse down first by B
and then by C, or vice versa, as the dynamic menu system illustrated
in Epiphany allows.

Another problem exists when you have:

/One/A/B/x
/Two/A/B/y

Now, clearly in a normal path system, x and y are not the same sets.
But both turn up on searches for A and B.  However, you can also just
as easily modify the search with an additional tag (either "One" or
"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 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.

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).  That's an easy constant for someone to tweak
if they want a really rich menu system (since I assume we'll try to
keep it relatively compact).  It could also be possible to program it
such that the depth of the menu is configurable, but I also think we
might want to follow Epiphany's example and keep it shallow by
default.

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.

- Eben


>>  --scott
>>
>> --
>>  ( http://cscott.net/ )
>>
>
> Eduardo
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>