Re: Re: Find bookmarks comments

On Mon, 2003-08-25 at 14:26, Ricardo Fernández Pascual wrote:
> El dom, 24-08-2003 a las 21:38, Tommi Komulainen escribió: 
> > On Fri, 2003-08-22 at 18:55, Ricardo Fernández Pascual wrote:
> > > 
> > > The don't seem connected because they are not connected actually. Except
> > > that the find dialog is accessed form the bm editor menu at the momment.
> > 
> > Hmm..  I suppose I'm missing even bigger picture here then.  Where
> > exactly is this dialog going to be used in?
> 
> I mean that it is not connected, they are just separate dialogs. 
> The dialog that I did was supposed to be used in the sidebar and when
> the user selects "Find" from the editor menu.

Heh, I thought it'd be more natural to use the history search as an
example for bookmarks search...  Both in sidebar, of course.


> > 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.  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.

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 ;)


> > 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.

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.


> > Ah, well..  I guess I was just expecting some prior warning, because
> > it's usually much easier to make even big changes if all you've done so
> > far is just the mockup.  But if commit first, fix later if ever, is the
> > current practice, nevermind me then...
> 
> You are trying to start a flame here, aren't you?

Not really.  I just have this nagging feeling that once you get
something that kind of works committed, there's much less incentive to
fix it properly than if it were well thought out from the start.  Not
talking about you personally, more like talking about myself ;)


> <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.  When
removing a bookmark that has aliases, 'promote' one of the remaining
aliases to be the bookmark, etc.  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.)


-- 
Tommi Komulainen                                 [email protected]
GPG 1024D/68388EE6    6FD6 DD79 EB38 BF6F 3533  09C0 04A8 9871 6838 8EE6

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQA/SjKEBKiYcWg4juYRApEWAJ9wwdJVqBgHsLEIK5FpvuYQd4H59gCdHP3J
KYFkfMe6ntXIjUt4ZatgZ/c=
=uZFs
-----END PGP SIGNATURE-----