Re: Small patches



Has anyone considered changing the word 'topics' to 'tags'? Tagging is
a more recognizable word for the same concept that is more in sync
with what most online bookmarking services (del.icio.us, the flock
browser, etc) are using. I think it may help turn a few heads towards
the browser (even though Epiphany was doing it first :)

Britt

On 10/20/05, Peter Harvey <pah06 uow edu au> wrote:
> 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.
>
>
> _______________________________________________
> epiphany-list mailing list
> epiphany-list gnome org
> http://mail.gnome.org/mailman/listinfo/epiphany-list
>



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]