Re: Small patches

[Peter Harvey <pah06 uow edu au>]

On Thu, 2005-10-20 at 10:59 +0200, Joachim König-Baltes wrote:
> On Tue, 19 Oct 2005, Reinout van Schouwen wrote:
> 
>  > Hmm, we must be careful with messing around with these "forced"
>  > hierarchies, people who depend on them might not like it very much if
>  > we just go and change their existing bookmark structure for them. If
>  > you can do it in a way that more-or-less preserves that existing
>  > structure, only then I'd say go ahead.
> 
>  > Maybe it would be nice to have an 'Automatic recategorize bookmarks'
>  > function that would replace the "->" topics, find likely duplicates in
>  > different topics and propose to replace them with one bookmark under
>  > multiple topics, match existing bookmarks against topics that would
>  > have been suggested if the bookmark would be added right now, etc. The
>  > function would propose a list of changes at completion which the user
>  > could individually agree with or cancel.
>  >
>  > Just thinking aloud here...
> 
> The hierarchies could be kept if we allowed topics to be attached to
> topics, e.g. marking the 'Linux' topic with 'Unix' and the 'Unix'
> topic with 'OS'. Then a path could simply be mappend to a sequence of 
> topics that are each mapped to the next higher topic.
> 
> We could then either map a bookmark to each topic or even better map
> it only to the last element aka topic in the path. But then the 
> searching would have to be rewritten to take the topic hierarchy into 
> account, e.g. I would expect to find my Linux bookmarks when I type OS 
> in the location bar.
> 
> Joachim

My approach for bookmark management so far has been "don't ask what the
user wants; ask what the user needs". Sounds arrogant I know, but the
results can be nice. For example, I developed the current code by
assuming:
  1. users think of their bookmarks via topics;
  2. users want rapid access to their bookmarks;
  3. users *don't* want to spend time organising/structuring bookmarks.
I used the information provided by [1] and the goal described by [2] to
automate the task of [3].

Before we decide to have 'topics associated with topics' I'd like to see
the instances where the current code really fails the user. The one
failure I can see at the moment is when you have a large number of
topics and it becomes tricky to navigate them all in the topic selector
and bookmark editor. Reinout has very nice ideas for addressing this,
and for further expanding the functions in the topic selector to
automatically suggest *new* topics that should be created.

The less work a user needs to do for organising his bookmarks the
better. I think that means avoiding 'topics associated with topics'
until there really is no other choice.

Regards,
Peter.