Re: Proposal to revamp bookmarks++

[Peter Harvey <pah06 uow edu au>]

On Mon, 2005-11-07 at 22:04 -0500, Adam Hooper wrote:
> The first time I read "Add" I assumed it meant that the topic doesn't
> exist yet. I'd expect the list to have existing topics *without* "Add"
> next to them, plus maybe a bold "New" beside topics which don't exist.

Yeah, I knew that one. Perhaps will place a bold New on the right edge
for topics that are really new. Will change 'Add' to something else.

> Also, clicking in a list to add topics is a bad idea. A common use case
> I have with lists is:
> 
> 1. Click (ANYWHERE) in the list
> 2. Use mouse wheel to scroll down
> 3. Click again to select the entry I really wanted in the first place
> 
> I'd expect (based on the way the rest of GNOME works) that either
> double-clicking or clicking a separate "Add" button would insert the
> topic. For instance, look at the "Select Contacts from Address Book"
> dialog in Evolution.

I agree. If someone has code for a simple cell renderer which shows a
button or button-like widget, please send. It'd be appreciated, because
I want that exact behaviour too.

> >  - It uses semi-colon as a separator (I think this is safe).
> 
> Evolution uses a comma to separate email addresses in a "To:" field;
> maybe we should strive for consistency here?

I think Evolution has the advantage of using <> tags around email
addresses. We have no such luck. I would use comma except that users
*might* have topics with commas in them. If that doesn't sound true, or
we're happy to sacrifice that minority I'll happily use commas. :)

> >  - It allows you to create a topic on the fly.
> 
> Again, in Evolution it's assumed that any email address is valid; you
> don't have to specifically request to create it. Maybe it'd be better to
> just treat nonexistent topics as new ones, so you'd just write a
> comma-separated list and Epiphany would figure out what you mean. (As a
> potential method of visual distinction, existing topics would be
> underlined whereas nonexistent ones wouldn't be.)

I considered the "treat non-existant topics as new ones" idea, but
figured that it's better to force the user to explicitly create a topic.
It is a rare use case (your collection of topics might change once every
10-15 bookmarks?). Typing mistakes are a common occurrence though. I
don't want "Programing" or "Fnu" to be accidentally created as a topic.
I even considered trying to guess what you typed (simple implementation
would be to check for substrings) as a method to deal with the problem.

Comparing to Evolution: imagine Evolution creating a new contact every
time you input an email address. If it contains a typo (and bounces!
remember there's feedback there) you have to go to your contact list to
delete it. I have enough problems with the Evolution To field as it is
to now want to re-implement it.

> In my opinion, alphabetical is far more intuitive.

In my initial tests I felt that I'd prefer "largest first". For users
who tend to arrange their bookmarks into strict topic hierarchies, it
looks almost like a path. For the rest of us who use a pretty loose
topic structure it still often reads like a path.

I'll probably release this as a patch/tarball/deb in a day or two. I
have a couple of other bits of code to reinstate that I ripped out a few
days ago.

Regards,
Peter.