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 <[EMAIL PROTECTED]> 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 > [email protected] > http://mail.gnome.org/mailman/listinfo/epiphany-list > _______________________________________________ epiphany-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/epiphany-list
