Re: Re: Find bookmarks comments

El lun, 25-08-2003 a las 18:00, Tommi Komulainen escribió:

> 
> > > Similarly in epiphany when you start the search, the topic pane
> > > automatically switches to 'All' and also shows the search results in a
> > > flat list (not that there's any hierarchy there at all) in the bookmark
> > > pane.
> > 
> > We don't have the 'All' category. We could add it, but I don't lie the
> > idea. We could select the root folder, but I don't see why.
> > 
> > What that done in Epiphany for some usability reason? or was it just
> > easier for them to implement it that way?
> 
> I think it makes sense.  You just want to find the bookmark, but can't
> remember where you put it.  Limiting the search in a subtree/topic
> considerably hinders your ability to find the bookmark; if you forget to
> click All/root/whatever (annoying extra step) before starting to type,
> you actually wouldn't find the bookmark (bad results) even if it does
> exist.
> 
> Much better to just include all bookmarks in the search.  

Ok. Let's assume that we want to include all bookmarks in the search.
What about hiding the left pane when a search starts? It is useless
anyway when searching and that way there would not be any inconsistency
in the screen[1]. 

I would be happy with that solution.

[1] The inconsistency that I'm talking about is that the right pane
could have bookmarks which are not children (nor descendants) of the
bookmark selected in the left pane.

> If (a big if)
> there are lots of results for a given search string, then you might want
> to limit the search in a subtree, but only after you've seen the results
> for the whole tree. And even then, I think, it's much more likely that
> you'd just continue typing a little bit more since your hands are
> already on the keyboard.

Actually, I think searching the whole tree makes always sense. Except
maybe for very large sets of bookmarks, but we don't try to address that
case (you'd need a database). 

> So, in my opinion, the search should start from root recursively, the
> results should be shown as a flat list in the bookmarks pane, and the
> folder pane remains unaffected.
> 
> 
> > > Considering the existing examples, I don't think there'd be much
> > > confusion having the treeview switch from hierarchic to flat list when
> > > showing search results.
> > 
> > I will not be confused. When I considered it I thought  that it was
> > wrong to change the meaning of the treeview while the user types in
> > another control. Anyway, we will do it that way it you want. 
> 
> Well, I'd just like it to be comfortable and efficient to use and I just
> don't think a separate dialog is such.  Considering that mozilla is
> behaving that way as well, we can always blame their UI team if it
> doesn't work out.  I think they even get paid for doing this stuff ;)
> 

Ok.

> 
> > > Well, I was thinking about having the autocompletion window show the
> > > results in a similar way to the bookmarks find dialog.  That is,
> > > emphasize the page titles instead of the URLs.  But I don't know if
> > > that's going to work well in practice.
> > 
> > I would consider a bug if the autocompletion list did not show the urls
> > clearly, because it's autocompleting an url.
> 
> I know, and that's kind of the problem.  You're typing an URL, but it's
> usually the title that's more interesting.  But OTOH you can't just
> throw away the URL or the autocompletion won't be making any sense
> anymore.
> 
> 
> > The titles of the page (or bookmark) are already shown in the right
> > column, I think that's enough. How could we emphasize them more without
> > hiding the url?
> 
> That's the question, really, and I don't think I have an answer.  It
> might help if there was more of the title shown.  The URL part of the
> autocompletion list could also stop showing the common prefix, it's just
> wasting space.  Instead show more of the part that differs.

That's an interesting idea, but I'm not sure if it would look right in
practice. Maybe justifying the URL to the left instead of to the right?
I don't know if this would be possible without writing a custom
cellrenderer.

In galeon 1 the list was wider than the location entry. I think you had
to set a gconf option for this. It extended to the right side of the
screen.

> But like I said, I don't really know what to do with it.  I find the
> tab-completion useful for completing URLs I already know, but the
> autocompletion window really isn't much of a help.  But that's just me.
> 

I use it a lot now, instead of tab completion. Actually, I miss it when
using bash.

> 
> > <offtopic>
> > BTW: I plan to add an UI to make more easy to add a bookmark to several
> > categories, like in Epiphany. That's what aliases are for.
> > </offtopic>
> 
> Indeed.  I'm thinking you don't even need to mention aliases explicitly
> in the UI.  When copying bookmarks, make them aliases instead.  

No, that would be very confusing: Imagine that I have a bookmark and I
want to create another one very similar to it. I would copy it and
modify the copy. If we make an alias directly you could not do this.

> When
> removing a bookmark that has aliases, 'promote' one of the remaining
> aliases to be the bookmark, etc.  

I'm already implementing this now.

> When modifying a bookmark with
> aliases, ask if the changes affect this instance only, or all of them
> (compare to recurring events in Palm Pilot/Evolution.)

I need to think about this. I don't think it is needed if you don't
remove the ability to copy bookmarks.

-- 
Ricardo Fernández Pascual
[email protected]
Murcia. España.




-------------------------------------------------------
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines
at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0