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

[Albert Cahalan]

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