Re: Feature Request: subtopics, bookmarks metadata

[Peter Harvey <pah06 uow edu au>]

On Fri, 2004-04-30 at 02:29, Gerardo Ballabio wrote:
> Hi all,
> I've recently migrated from Galeon to Epiphany (on occasion of my
> migration from Debian stable to testing), and I'm currently facing its
> (in)famous bookmarks system.
> 
> I like it. The "bookmark can belong to multiple topics" feature and the
> search bar are both advancements beyond the traditional hierarchical
> system, in my opinion.
> I have several hundreds of bookmarks (I've an habit -- or is it a
> compulsive syndrome -- of bookmarking everything that catches my
> attention "just in case"), and searching for something down the tree in
> Galeon wasn't always easy.
> 
> However, having that many bookmarks, I feel that the single-level-deep
> hierarchy enforced by Epiphany is also limiting. I must choose between
> having too many bookmarks per topic, or too many topics (or both).
> In a computer scientist's language: that doesn't scale well with the
> number of bookmarks.
> 
> I've conceived a couple of ways to make the Epiphany bookmarks system
> more effective (in my humble opinion, at least):
> 
> 1) topics should be allowed to contain other topics, as well as
> bookmarks.
> 
> That would allow one to build a hierarchy of topics of any depth (and
> (s)he wouldn't be limited to a strict tree structure -- topics may
> belong to multiple topics, or even to each other), while at the same
> time, those who prefer the current single-level hierarchy could just
> leave all topics uncategorized, and everything would be exactly as it is
> now.
> I believe that that would bring us "the best of both worlds", and
> hopefully it wouldn't be too hard to implement.
> 
> Note: for that to work as intended, a topic should _not_ automatically
> contain the bookmarks contained by its subtopics.
> 

Hi all,

I'm not too thrilled with the idea of topics belonging to other topics.
I think it will just encourage people to hack together a hierarchical
bookmark system identical to that found in other browsers. I still think
a hierarchical bookmark system should be provided - I just don't think
allowing the user to specify every nth detail of it is justified or
productive (in the end) for the user.

I was writing a monstrous reply about formal concept analysis, and how
it could be applied here to automatically generate multi-level menus for
the bookmarks. But, in the end, it was overcomplicated and had a few
holes. So I've trashed it and am going to suggest a different method of
automatically generating bookmark hierarchies from the info we already
have. I'm not the first to suggest this (eg. Eric Newman's post
http://mozdev.org/pipermail/epiphany/2003-August/000093.html), but I
think the following may provide a real workable system.

I should say from the outset I like the whole 'topic' system of bookmark
management, and by no means would I see that change. It is so easy to
add bookmarks with Epiphany - just tick a few boxes which apply and I'm
done. I also believe that the system of typing a topic name into the
address bar and being presented with a list should not change. This
seems to be a key feature that the developers like. However, with large
numbers of bookmarks, I'm finding that the bookmark menu (which I use
very often) become unwieldy. I also believe the information which the
user provides by ticking multiple topics is not used.

To achieve what I want, the user must provide a total ordering of the
topics. Note that this is not used for sorting the topics, but is used
in the following algorithm to construct a hierarchical index for
bookmarks. This is the only 'extra' information the user should provide.

The idea behind my algorithm is simple: given a set of bookmarks, try to
find a greedy set cover by looping through all the topics in the order
the user specifies. For each topic (set of bookmarks) which contributes
to the set cover, apply the algorithm recursively until there are no
more covers. The global parameters X and Y define when a covering set is
large enough to warrant the creation of a submenu, a subdivision (block
of bookmarks surrounded by dividers), or otherwise. This is to avoid
creating submenus which contain only one or two items. Sensible defaults
would be X=7 and Y=3, which mean:
 only create a submenu when there are 7 or more items in it; and
 only create a subdivision when there are 3 or more items in it

Anyway, the algorithm in detail is:

procedure BuildMenu
 input: set of bookmarks B
 output: menu M
 global: integers X and Y, with X>=Y
{
  Create a new menu M;
  Set local var B' = B;
  For each topic t, taken in the order specified by the user
  {
    If there exists a bookmark in B' with topic t, and
       there exists a bookmark in B without topic t, then
    {
       Remove from B' any bookmark with topic t;
       Call BuildMenu with the subset of bookmarks in B with topic t;
       If the returned menu has X or more entries, then
          Add the returned menu as a submenu of M;
       Else if the returned menu has Y or more entries, then
          Copy the contents of the menu as a subsection of M;
       Else
          Copy the contents of the menu as a normal entry of M;
    }
  }
  Add remaining entries in B' to the menu M;
  Sort entries in M alphabetically, with
    submenus at the top, followed by subsections, then bookmarks;
  Return M;
}

To give an example, I could have the following bookmarks of homepages
and research websites:

Bookmark          Topics
-----------------------------------------------------------------
Jane                                 People
Jim               Friends,           People
June              Friends,           People
Jack              Friends, Research, People
Jared             Friends, Research, People
John              Friends, Research, People,              Logics
Jill                       Research, People,              Logics
James                      Research, People, Constraints
Joe                        Research, People
LogicWeb                   Research,                      Logics
HypertreeHome              Research,         Constraints
CPAIOR                     Research,         Constraints, Logics
CorkConstraints            Research,         Constraints

Setting X=4, Y=2, and using an ordering of: 
  People > Research > Friends > Logics > Constraints
I get a hierarchical menu of:
 
  People...
    Research...
      Jack     \
      Jared     | these people are my research friends
      John     /
      ======
      Jill     \ and these people do logic
      John     /
      ======
      James    \ and these guys don't really have a category
      Joe      /
    Friends...
      Jack     \
      James     | these people are my research friends
      John     /
      ======
      Jim      \ I keep my normal friends separate
      June     /
    Jane     just someone from somewhere or other

  Research...
    Constraints...
      CorkConstraints \
      CPAIOR           | all my constraints related research
      HypertreeHome    |
      James           /
    Logic...
      LogicWeb \ just general logic links
      CPAIOR   /
      ======
      Jill     \ these are people who do logic 
      John     /
    People...
      Jack     \
      Jared     | these people are my friends
      John     /
      ======
      Jill     \ and these people do logic
      John     /
      ======
      James    \ and these guys don't really have a category
      Joe      /



That's about it - any thoughts? If I have time in the future I may try
implementing this myself (my first attempt at GTK/GNOME programming).

Thanks for reading.

-- 
Peter Harvey.
Mostly Quiet.