[Bibdesk-users] Batch Editing of Multiple References (User Interface Gripe)

[Holger Frauenrath]

Hello everybody,

finally, I must admit that I have one minor gripe with the current
BibDesk user interface which has to do with batch editing of multiple
references. Don't get me wrong, this is not a real complaint. In
general, I think that the interface could not be better! And for the
following issue(s), I do not really have any better suggestion. I
would just like to give this as a general user feedback (the "worst
case of a stupid user scenario" if you wish) to the developers.
Perhaps someone can come up with a nice solution.

Let me start with what is good in BibDesk: The grouping mechanism is
perfect (for me). And it is particularly good that one can base it on
the keywords field or the group field etc. to one's liking. In my
case, the issue with the keywords field is, for example, that the
Chemical Abstracts Service puts tons of junk into the keywords field
by default which is, however, not completely irrelevant. Hence, I
would not like to delete it, nor move it to another field because I
would have to do it with every reference in the future. So putting
your own, few "keywords" into the group field, and then having
BibDesk display a subset of your references on the basis of field
groups is ... just amazing! You may laugh, but coming from Endnote
this is really amazing. I mean, it is so obvious to do it exactly the
way it is in BibDesk, it is easy, nice, straightforward, and yet
Endnote miserably fails to provide some functionality like that ...
This is one of the things that made me want to hug the Bibdesk
developers a couple of days ago. :-)

But here is the part that caused me a lot of headache: batch editing
of multiple references and (in particular) adding a field to multiple
references. The background is that I imported my references batch-
wise from Endnote and wanted to add the previously non-existing group
field to these references batch-wise and then put my keywords in it
batch-wise, in order to use the nice grouping feature. I saw that on
could "add a field" to an individual reference in its editor window,
and so I was looking for a way to do this with a batch of files in
one shot.

Before somebody jumps conclusions ... I know now that it is possible
to do it in Bibdesk, and I also know now how to do it. My point is
not the *functionality* of Bibdesk, but that it may be hard to find
it, even if it is obvious to most of you. Let me just describe what I
tried in chronological order to give you an idea of what the problem
is. This has become a long story, so you may want to jump to the end
of it if you are in a hurry:



****** (begin most stupid user scenario)

First, I selected multiple references, and hit Cmd-I, expecting that
I would be able to edit all selected references. Of course, I was
warned that this would open many editing windows. I chose "yes"
nonetheless ... Well, okay, that was not what I wanted.

Next, I put files in a group (just as a test case), I selected the
group and tried to somhow "edit" the references in this group. Why
did I think I could do this? Because, when I looked through the
BibDesk Help for something like batch editing, the documentation has
a topic "group editing". Well, I thought this is what I wanted to do.

Groups can be edited, which will change the relevant field for all
items in the group. In the case of authors, they will be matched
using fuzzy logic, so be sure that you really want to change the
author name for all items in the group!
For authors, you can get more info about the author using the
command "Get Info" (⌘I ) from the "File" menu.
Using the "delete" key to delete an item while a group is selected
will result in the removal of that item from the present group. To
delete the item from the database while a group is selected, use ⌥
-delete. To see the group equivalents for "Edit" menu commands,
hold down the ⌥ key while the "Edit" menu is displayed.

To me, this sounded like what I wanted to do. I must admit that I was
a little bit annoyed about the documentation which (like many bad
examples of documentations) seemed to miss the essential part: if I
look into the help files of an application, I do it with the
intention to find out HOW TO DO something. Many examples of help
files explain THAT you can do something and fail to mention the most
obvious thing: if you want to do it, do step A, step B, step C. And I
thought that the above documentation did the same mistake: it says
"groups can be edited" (cool, that is what I wanted), "... which will
change the relevant field for all items in the group" (yep, exactly
what I need), but then it failed to mention how to do this (well, I
thought, then this must be so obvious that it does not need to be
mentioned) but instead gives a few warnings of what not to do. Only
later, I understood that *I* was wrong; that "group editing" was not
even supposed to do what I wanted to do; and that the documentation
was not so bad, after all, if you understand what "group editing"
means in the first place: only edit the group field of this group (or
the author or keyword field depending on your settings). Oh, well ...

In any case, once I was on the wrong track, I spent almost an hour
trying to find out how this "group editing thing" would work. I
selected the group, and hit Cmd-I (nothing happens except "beep"). I
selected the group, then selected all references in this group, and
hit Cmd-I (many windows open, as above). I double-clicked the group
(sheet opens to warn me that the group field is being edited). I
selected all references and tried to double-click (only one editor
window for the double-clicked reference opens). I Ctrl-clicked on the
group and, likewise, on multiple selected references, and I checked
the respective context menus many, many times. I checked the
"Publication" menu (which would be the first place where I would
expect to find possibilities to "work on" the references) about a
gazillion times whether I had not overlooked something like "edit
field in all selected references" or something like that. I also
checked the "Edit" menu for the same thing (more on that later). I
pressed the Opt key and looked at the menus because the documentation

To see the group equivalents for "Edit" menu commands, hold down
the ⌥ key while the "Edit" menu is displayed.

which again brought me on the wrong track. And I probably hit Cmd-Opt-
I a gazillion times for the same reason only to find that it did not
do what I wanted.

****** (end most stupid user scenario)



OF COURSE, I finally found out that the good old "Database Find &
Replace" does exactly what I want to. OF COURSE, I admit that this is
actually one obvious place to look for this functionality. OF COURSE
I FElT STUPID AFTERWARDS!

Short summary of the long story: There is nothing inherently wrong
with placing this functionality under "Edit -> Find -> Database Find
& Replace". There is neither anything wrong with the *functionality*
itself. The only problem is that, still, it had not been obvious to
me as a new user. BTW, may be I am wrong, but I have a feeling that
the issue/question/request broght up by James Howison may have to do

If not then do others think it would be useful to have Groups work as
a 'persistent filter' so that one can work with Groups just as one
would with totally different files. Interface wise, perhaps the
easiest way to implement that might be to have a "Open Group as
Bibliography (or Library)" feature, so that you could deal with one
group in another window entirely, but still have a 'in-toto' window
behind?

I agree with Christiaan's reply that this would be problematic
because it would "permanently" hide things from you completely. But I
have a feeling that the origin of the request is how to deal with
"working on subsets" of your references and "make batch changes" to
multiple references at once.

The following things are not real feature requests, just some
thoughts for a discussion. Nevertheless, I think that some
improvements may be made to BibDesks behavior in this respect.

- For adding a previously not-existing field to multiple references,
I think "Edit -> Find -> Database Find & Replace is *not* the obvious
place to look for it. At least, it should not be the only place to do
this. I know that there is a fine line between offering several
different paths to do the same thing and bloating your application in
a Microsoftian way. But for this particular issue, perhaps an
additional "Publication" -> "Add Field" would help, which would also
work on multiple selected references.

- Incorporating a "change field", "copy/swap" field, "add prefix"
functionality into BibDesk would probably be desirable (I know that
the AppleScripts already exist)

- Perhaps, Cmd-Opt-I should be the "group equivalent" of Cmd-I and
not do something else (show Document Info). For example, hitting Cmd-
Opt-I might open *one* "batch editor window" for multiple selected
references. This would be the same behavior as hitting Cmd-Opt-I vs.
Cmd-I for a file in the MacOS Finder. This "batch editor window"
should then display only the content of fields with the same content
for all references; all other fields should be blank (but visually
differentiated to make clear they are blank not because they are
empty but because the references contain different content in this
field), and changes to any field should affect all selected references

- Finally, some better way of working with subsets of references
would be nice, because often one does not want to do a "Database Find
& Replace" on your whole library but just a subset. Again, I know
that one could select multiple references, choose "Edit" -> "Find" ->
"Database Find & Replace" and check "only on selected items". But
this seems not so "straightforward" to me. I do not really have a
good idea how to change this, but ... perhaps a solution would be
something along the following lines (as an optional behavior): If one
selects a group of references, commands should only be performed on
that subset (like "Database find and replace", "Add Field", "Change
Field" etc.)



Anyways. Sorry for this heavy email traffic on the list today; I have
no intentions to continue like that. :-) Thanks to everybody for
their patience. A big thank you to Christiaan and the other
contributors for their help and suggestions which have solved most of
my issues. And thanks again to the developers for this really cool
bibliography management tool. After all, all the things I mentioned
today would only make a really good tool even better for me.

Best regards
Holger

__
Eidgenössische Technische Hochschule Zürich (ETH Zürich)
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zürich
Switzerland

Phone: [phone]
Fax: [phone]
Email: ***@mat.ethz.ch
Web: http://www.polychem.mat.ethz.ch/frauenrath/





__
Eidgenössische Technische Hochschule Zürich (ETH Zürich)
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zürich
Switzerland

Phone: [phone]
Fax: [phone]
Email: ***@mat.ethz.ch
Web: http://www.polychem.mat.ethz.ch/frauenrath/

[Adam Maxwell]

[...]

All users with complaints should learn from this example ;).

Post by Holger Frauenrath
But here is the part that caused me a lot of headache: batch editing
of multiple references and (in particular) adding a field to multiple
references. The background is that I imported my references batch-
wise from Endnote and wanted to add the previously non-existing group
field to these references batch-wise and then put my keywords in it
batch-wise, in order to use the nice grouping feature. I saw that on
could "add a field" to an individual reference in its editor window,
and so I was looking for a way to do this with a batch of files in
one shot.

You can also ensure that a group (or other) field will be added to all
of your references in the Defaults preference pane. AppleScript and
the advanced find & replace (as you eventually discovered) are the
best way to initially set these fields.

Post by Holger Frauenrath
First, I selected multiple references, and hit Cmd-I, expecting that
I would be able to edit all selected references. Of course, I was
warned that this would open many editing windows. I chose "yes"
nonetheless ... Well, okay, that was not what I wanted.

We have had many requests for this over the years, but it's
technically not feasible. If we limited the available fields (as
iTunes does), it would work, but the semantics for batch editing of
multiple BibTeX types would be a nightmare.

Post by Holger Frauenrath

Groups can be edited, which will change the relevant field for all
items in the group. In the case of authors, they will be matched
using fuzzy logic, so be sure that you really want to change the
author name for all items in the group!
For authors, you can get more info about the author using the
command "Get Info" (⌘I ) from the "File" menu.
Using the "delete" key to delete an item while a group is selected
will result in the removal of that item from the present group. To
delete the item from the database while a group is selected, use ⌥
-delete. To see the group equivalents for "Edit" menu commands,
hold down the ⌥ key while the "Edit" menu is displayed.

To me, this sounded like what I wanted to do. I must admit that I was
a little bit annoyed about the documentation which (like many bad
examples of documentations) seemed to miss the essential part: if I
look into the help files of an application, I do it with the
intention to find out HOW TO DO something. Many examples of help
files explain THAT you can do something and fail to mention the most
obvious thing: if you want to do it, do step A, step B, step C. And I
thought that the above documentation did the same mistake: it says
"groups can be edited" (cool, that is what I wanted), "... which will
change the relevant field for all items in the group" (yep, exactly
what I need), but then it failed to mention how to do this (well, I
thought, then this must be so obvious that it does not need to be
mentioned) but instead gives a few warnings of what not to do. Only
later, I understood that *I* was wrong; that "group editing" was not
even supposed to do what I wanted to do; and that the documentation
was not so bad, after all, if you understand what "group editing"
means in the first place: only edit the group field of this group (or
the author or keyword field depending on your settings). Oh, well ...

Is the basic problem that "group editing" != "batch editing"? We
strongly encourage user contributions to the documentation, so if you
have changes, we'll be happy to incorporate them. Developers should
not write the documentation, but we're forced to in many cases.

Post by Holger Frauenrath
In any case, once I was on the wrong track, I spent almost an hour
trying to find out how this "group editing thing" would work.

Ouch :(. That's pretty damning for us as UI designers...or maybe as
doc writers.

Post by Holger Frauenrath
I checked the
"Publication" menu (which would be the first place where I would
expect to find possibilities to "work on" the references) about a
gazillion times whether I had not overlooked something like "edit
field in all selected references" or something like that. I also
checked the "Edit" menu for the same thing (more on that later).

[...]

Post by Holger Frauenrath
OF COURSE, I finally found out that the good old "Database Find &
Replace" does exactly what I want to. OF COURSE, I admit that this is
actually one obvious place to look for this functionality. OF COURSE
I FElT STUPID AFTERWARDS!
Short summary of the long story: There is nothing inherently wrong
with placing this functionality under "Edit -> Find -> Database Find
& Replace".

That feature is harder to find than it should be, and not just for
you. We put it under the Edit menu, which has some precedent in other
applications, but perhaps it really belongs under the Publication
menu. Since I habitually use the cmd-shift-f shortcut from
Xcode/TextMate, the menu location isn't an issue.

Post by Holger Frauenrath
- For adding a previously not-existing field to multiple references,
I think "Edit -> Find -> Database Find & Replace is *not* the obvious
place to look for it. At least, it should not be the only place to do
this. I know that there is a fine line between offering several
different paths to do the same thing and bloating your application in
a Microsoftian way. But for this particular issue, perhaps an
additional "Publication" -> "Add Field" would help, which would also
work on multiple selected references.
- Incorporating a "change field", "copy/swap" field, "add prefix"
functionality into BibDesk would probably be desirable (I know that
the AppleScripts already exist)

The find & replace feature was designed to incorporate some of the
functionality of existing AppleScripts, and also allow regular
expressions and macro conversions. I'm not in favor of adding
multiple menu items for the same thing, but moving it to the
Publication menu is definitely an option.

I'm open to renaming the menu item as well, if someone can suggest a
clearer title.

Post by Holger Frauenrath
- Finally, some better way of working with subsets of references
would be nice, because often one does not want to do a "Database Find
& Replace" on your whole library but just a subset. Again, I know
that one could select multiple references, choose "Edit" -> "Find" ->
"Database Find & Replace" and check "only on selected items". But
this seems not so "straightforward" to me. I do not really have a
good idea how to change this, but ... perhaps a solution would be
something along the following lines (as an optional behavior): If one
selects a group of references, commands should only be performed on
that subset (like "Database find and replace", "Add Field", "Change
Field" etc.)

Did you try this? I think find & replace is limited to the currently
selected group. If not, I'd say that's a

[Christiaan Hofman]

[..]

Post by Adam Maxwell

Post by Holger Frauenrath
Short summary of the long story: There is nothing inherently wrong
with placing this functionality under "Edit -> Find -> Database Find
& Replace".

That feature is harder to find than it should be, and not just for
you. We put it under the Edit menu, which has some precedent in other
applications, but perhaps it really belongs under the Publication
menu. Since I habitually use the cmd-shift-f shortcut from
Xcode/TextMate, the menu location isn't an issue.

We could also add an extra top-level Find menu. This may not make it
immediately more obvious as a batch-edit option, but at least it will
reduce the nesting, and thereby the visibility.

Post by Adam Maxwell

Post by Holger Frauenrath
- For adding a previously not-existing field to multiple references,
I think "Edit -> Find -> Database Find & Replace is *not* the obvious
place to look for it. At least, it should not be the only place to do
this. I know that there is a fine line between offering several
different paths to do the same thing and bloating your application in
a Microsoftian way. But for this particular issue, perhaps an
additional "Publication" -> "Add Field" would help, which would also
work on multiple selected references.
- Incorporating a "change field", "copy/swap" field, "add prefix"
functionality into BibDesk would probably be desirable (I know that
the AppleScripts already exist)

The find & replace feature was designed to incorporate some of the
functionality of existing AppleScripts, and also allow regular
expressions and macro conversions. I'm not in favor of adding
multiple menu items for the same thing, but moving it to the
Publication menu is definitely an option.

We could perhaps add other options for batch editing, replacing the
"Overwrite or add this field" check box by a popup with different
options like

find & replace
add
add or set
prepend
prepend or set
append
append or set
copy
swap

Post by Adam Maxwell
I'm open to renaming the menu item as well, if someone can suggest a
clearer title.

Batch Find & Replace

(though I'm not sure about it myself)

Post by Adam Maxwell

Post by Holger Frauenrath
- Finally, some better way of working with subsets of references
would be nice, because often one does not want to do a "Database Find
& Replace" on your whole library but just a subset. Again, I know
that one could select multiple references, choose "Edit" -> "Find" ->
"Database Find & Replace" and check "only on selected items". But
this seems not so "straightforward" to me. I do not really have a
good idea how to change this, but ... perhaps a solution would be
something along the following lines (as an optional behavior): If one
selects a group of references, commands should only be performed on
that subset (like "Database find and replace", "Add Field", "Change
Field" etc.)

Did you try this? I think find & replace is limited to the currently
selected group. If not, I'd say that's a bug.
-- adam

Looking at the code, it works on the displayed (or selected)
publications, so it limits to items in the selected groups.

Christiaan

[Holger Frauenrath]

Post by Adam Maxwell
[...]
All users with complaints should learn from this example ;).

But it is also true that BibDesk makes this easy for me: there are so
many things that I love in BibDesk, that BibDesk just does "right",
and that have annoyed me in EndNote (and also other commercial
software packages for other purposes). The problem is: it is in
particular the many, many small things that just add up; like the
fact that in most dialogs, your last choices are remembered, the
pervasive use of autocompletion in all sorts of dialogs etc. This is
also true for the few bad things: it is rather a matter of a number
of small details which may be hard to describe or find "the" solution
for. This is why I told that whole story of what I tried and why.

Post by Adam Maxwell
You can also ensure that a group (or other) field will be added to all
of your references in the Defaults preference pane. AppleScript and
the advanced find & replace (as you eventually discovered) are the
best way to initially set these fields.

Aha. Thanks for pointing that out. I did not know that.

Post by Adam Maxwell
We have had many requests for this over the years, but it's
technically not feasible. If we limited the available fields (as
iTunes does), it would work, but the semantics for batch editing of
multiple BibTeX types would be a nightmare.

That is a pity. That is really what is needed. Seriously. A
limitation to certain fields would be okay, I guess. I wonder which
application I have already seen a similar interface in ...

Post by Adam Maxwell
Is the basic problem that "group editing" != "batch editing"? We
strongly encourage user contributions to the documentation, so if you
have changes, we'll be happy to incorporate them. Developers should
not write the documentation, but we're forced to in many cases.

Yes, one problem for me was "group editing" != "batch editing", but
also "group editing == editing the content of the group field of a
group" instead of "group editing == editing (making changes to) a
group of references in general" which would be my interpretation of
"group editing. As for writing documentation, I am afraid that I
would not have the time to do it seriously. Also, I think that I
would prefer to see you and the other developers change and improve
BibDesk rather than its documentation. BibDesk is 99% intuitive, even
in my hands ;-). So, with a few improvements the documentation may
not even be necessary. I will have to get back to doing chemistry and
writing papers tomorrow, but I have tried my best to summarize the
little details I think could be improved or at least reconsidered. I
will put them all in a separate email, because it became a very long
text.

Post by Adam Maxwell

Post by Holger Frauenrath
- Finally, some better way of working with subsets of references
would be nice, because often one does not want to do a "Database Find
& Replace" on your whole library but just a subset. Again, I know
that one could select multiple references, choose "Edit" -> "Find" ->
"Database Find & Replace" and check "only on selected items". But
this seems not so "straightforward" to me. I do not really have a
good idea how to change this, but ... perhaps a solution would be
something along the following lines (as an optional behavior): If one
selects a group of references, commands should only be performed on
that subset (like "Database find and replace", "Add Field", "Change
Field" etc.)

Did you try this? I think find & replace is limited to the currently
selected group. If not, I'd say that's a bug.

You are right. Find & Replace only works on the active group. I think
the problem is that this is never stated or shown explicitly. Of
course, it works just fine if you know it. But it is also prone to
mistakes because it is not made obvious: you may easily perform a
find & replace on a subset of your references (the active group)
although you may have intended to do it on the whole library (you
just forgot to choose it). More on that later.

Thanks for your efforts
Holger


__
Eidgenössische Technische Hochschule Zürich (ETH Zürich)
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zürich
Switzerland

Phone: [phone]
Fax: [phone]
Email: ***@mat.ethz.ch
Web: http://www.polychem.mat.ethz.ch/frauenrath/

[Holger Frauenrath]

Post by Adam Maxwell

Post by Holger Frauenrath
Short summary of the long story: There is nothing inherently wrong
with placing this functionality under "Edit -> Find -> Database Find
& Replace".

That feature is harder to find than it should be, and not just for
you. We put it under the Edit menu, which has some precedent in other
applications, but perhaps it really belongs under the Publication
menu. Since I habitually use the cmd-shift-f shortcut from
Xcode/TextMate, the menu location isn't an issue.

[...]

Post by Adam Maxwell
The find & replace feature was designed to incorporate some of the
functionality of existing AppleScripts, and also allow regular
expressions and macro conversions. I'm not in favor of adding
multiple menu items for the same thing, but moving it to the
Publication menu is definitely an option.
I'm open to renaming the menu item as well, if someone can suggest a
clearer title.

Hello everybody,

it took me a while to answer Adam's email because I wanted to try my
best to analyze why certain things turned out to be difficult for me
in the beginning, and make some reasonable suggestions on that basis.

I must admit that I hesitated to send this to the list because I am a
little bit afraid that people would find this whole question and the
following little issues "nitpicking". But as I said in one of my
previous emails, both most of the really cool things in BibDesk and
the few things that may see some improvement are a matter of "the
small things" rather than a "big mistake" of some sort. I do not
believe at all that any of the following things in themselves are
very important or need immediate fixing. But I think that the
combination of some of these things adds up and makes one area of
using Bibdesk more difficult than it should be for new users, and
more complex than necessary even for experienced users. I would
neither claim that everybody has to feel the same about these things
in detail; they are absolutely subjective. And I do not want to claim
to reinvent the wheel. I have not been using BibDesk for very long.
Thus, I may make proposals that are not thought to the end; that have
already been used in previous versions of BibDesk and changed for
good reasons; or that the developers had considered and discarded.
Please, look at the following comments rather as a collection of
individual experiences and observations some of which may help
(others) to come up with an even better interface for BibDesk.

I can only reiterate that BibDesk is one of the best pieces of
software I have encountered in recent years, and it still gets better
the more I find out while using it. It is not that it *will make* my
life easier as I said in an earlier email; it already has.

A big thank you to everybody on the list.

Best wishes, and have a nice weekend,
Holger



------

So, generally speaking, I think that the origin of my "problems" has
been a combination of several different things.

Some of these have to do with the fact that the term "Find" in
context with bibliography management is ambiguous in the sense that
it refers to both "finding references" (i.e., create and display a
subset of your references based on a search term) and "finding/
changing the content of fields"; I think the problem is that the
current implementation (both in terms of name and place of commands
AND in terms of functionality) mixes these things up to a certain
extent.

The others are rather a matter of my expectations - which may be
justified or not. For example, in my eyes, a rather important part of
bibliography management has to do with *manipulating* (not sorting,
grouping, displaying) references, i.e., creating/deleting references,
adding and changing fields etc. And I think that BibDesk has (almost)
all the functionality needed, but it hides the most important parts.
I was expecting commands to manipulate references and fields in the
publication menu (because hat is where you also find "New
reference"), but it is actually buried in the "Database Search &
Replace" interface and in the preferences (the possibility to add a
field).

And then there are a few small things which just have to do with the
actual user interface design which, in my opinion, obscure the actual
power and capabilities of certain commands and interfaces, as is the
case with the very compact "Database Search & Replace.

I will try as good a possible to describe precisely what I mean in
the different areas.



First of all, let me summarize the different interfaces or search
functions:

1. The "Find" command (Cmd-F) which takes you to a search text field
in the main window; default searches the keywords field (if I am not
mistaken; I cannot remember having changed the search field option
before); and displays a subset of your references in the list window
as a result of the search operation.

2. The "Database Search" command (Cmd-Opt-F) which (as far as I can
tell) takes you to the same search text field in the main window; by
default searches the keywords field as well; and also displays a
subset of your references in the list window as a result of the
search operation. So it seems to duplicate the functionality of Cmd-
F; at least I could not find a difference. Please, correct me if I am
wrong.

3. The "Use Selection for Find" command (Cmd-E) which (as far as I
can tell) takes you to the same search text field in the main window
again; also by default searches the keywords field; and again
displays a subset of your references in the list window as a result
of the search operation. As its name implies (I assume) that it is
supposed to work on *only* selected references, I think its behavior
may be rather due to a bug. At least, when I tried it, it did not
work as I expected. What I tried is this: I have 9 references in the
group "Meijer", 3 of which have been published in 2000. If I select
three of these 9 references which have been published in 2000, 2003,
and 2005, then hit Cmd-E and enter 2000 (search field set to any),
then the result is *all three* papers published in 2000 in the group,
not only the one of the three selected references! Did I understand
the command wrong or is this a bug?

4. The "Database Search & Replace" Command (Cmd-Shift-F) which takes
you to a comprehensive and very powerful search & replace dialog with
many options, including regular expressions etc. However, it seems
that the search can *only* look for a string in *one particular*
field (not in *any* field), if I have not overlooked anything. And,
this time, the result of the search operation is a list of all papers
in your library (or the active group) with one reference (the first
hit) being selected; you can jump to the next one with "Next" (Cmd-G).

5. Finally, there are Smart Groups which also have to be considered
to be a part of the search interface. You can enter a textual string
or a more complex combination of several strings with a GUI based
mechanism to create a "saved search". But there seems to be no
connection to the other search interfaces.



Let me summarize what one cannot do with the current implementation.
Please, correct me if I am wrong:

1. One cannot search a complex construct or a regular expression in
*any field* because "Database Search & Replace" as the only place to
enter a complex construct will search only one specific field.

2. More specifically, one cannot perform, for example, a search for a
combination of terms ("polydiacetylenes OR poly(diacetylene)s") in
*any field* for this reason.

3. One cannot perform a search for a combination of terms using a GUI
based mechanism (the one that is used to set up Smart Groups), except
for actually setting up a Smart Group.

4. One cannot search for a more complex construct or a regular
expression and have a subset of the references displayed in the list
window (as for a simple search) as the result of the search operation.

5. One cannot save a search (of any type) as a Smart Group

6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

Of course, not all of these "shortcomings" are worth being
implemented, or even desirable (for example, 3 is absolutely not
important, in my opinion; I just listed it as a matter of completion).



The following things I found unexpected or inconsistent in the whole
interface for batch editing references, including the find & replace
interface in BibDesk:

- What is the differentiation of between "Find" (Cmd-F) and "Database
Search" (Cmd-Opt-F)? What is the difference between their definitions
- I mean, how would you tell what the difference is from the actual
command names? What is the difference in functionality? Why are the
two commands there? If there is any difference, I cannot not see it.

- Is the current behavior of the "Use Selection for Find" (Cmd-E) a
bug or did I misunderstand hoiw to use it or what to use it for?

- I found it strange that the very differently named "Find" and
"Database Search" both take you to the same interface (a search text
field in the main window) whereas the "Database Find &
Replace" (looking similar to "Database Search") takes you to a
different interface.

- I found it odd (unexpected) that the "Find" and "Database Search"
search text field tries to do more than just letting you enter a
search term. For example, it took me quite a while to figure out why
entering "Meijer" in it (the authors of a dozen papers in my library)
gives no results! Of course, I found out the reason is that it
defaulted to the "keywords" field. But you will only see this when
you click on the magnifying glass/triangle in the text field. Most
other applications (e.g., Safari, Firefox) seem to use a magnifying
glass/triangle in the search field only for your last searches, not
for any search options. Unfortunately, I realized that Apple is
inconsistent themselves: iTunes also uses it for options in the same
way as BibDesk. But I don'T think this is a good idea; I find this
behavior unexpected, and the result of the search operation
unpredictable: How would one no which field is searched (without
clicking on the triangle)? How would one see which was one's last
choice (without clicking on the triangle)? I think the simple search
text field in the main window is not a good interface for more
advanced searches.

- I found the name "Database Search & Replace" is misleading because
it is not actually what the command does. To me, the name implies
that I can search for a term (e.g., polydiacetylenes) and have it
replaced with another one (e.g., poly(diacetylene)s) in the
*database*, i.e. in *any field* by default, with the *optional*
behavior to narrow down or focus the search on one particular field.
But this is not what it does. It is currently rather a command to
"Find, Change & Add Fields".

- In particular, this last function ("Add field") is found only in
places which appear to be obscure to me: the Preferences (setting
default fields) and the "Database Search & Replace" command. And I
never expected them there which is why it took me so long to figure
out how to actually add the group field to my references.

- I think it is a shortcoming that the "Find" = "Database Search"
commands will display a subset of your references as the result of
the search operation whereas the "Database Search & Replace" command
does not even offer you this as an option.

- Finally, I only found out in the recent email communication with
Adam that the scope of the "Database Search & Replace" command is
restricted to the currently active group (and the whole library if it
is selected). While this is perfectly alright and consistent, it was
still unexpected (I would not have asked for it otherwise) for the
simple reason that it is at no point explicitly stated when you
initiate a search. I also think that, for the same reason, it may be
prone to provoke user mistakes.



I have the following small issues with the actual design of the
"Database Search & Replace" dialog window. As I said, I think the
whole "Database Search & Replace" interface is very powerful, but
also very compact/complex. Perhaps, a redesign of certain interface
elements would help to make it more intuitive (mostly for new users)
and less prone to lead to user mistakes:

- There are many different UI elements in the dialog window defining
very different things: the target of the search ("which field";
"contains"), the scope of the search ("only selected items"), the
nature of the search string ("Macro", "RegEx", "Text"), as well as
special commands for additional functionality ("add/overwrite
field"). But these elements seem to be scattered all over the place!
As a consequence, one cannot "read" the window easily and understand
at once what can be done. For example "contains" (search target) is
at lower left corner, with no connection to "field" (target) in upper
right corner, and right underneath "Text/RegEx" (nature) which is the
same type of UI elements, but "Macro" (nature) is different. I find
this ... confusing ...

- The scope can explicitly set to the selected references ("Only
Replace in Selected Items" Selection only") but, as stated above, the
fact that the scope is always restricted to the active group is never
stated explicitly.

- I find "Macro" and "regular expression" are too similar choice of
words (I saw that the tool tips explain what they mean, but still).

- Finally, I think that it is inconsistent (incomplete) behavior
that, on one side, one can specify that the field to be searched
"is", "contains", "begins with", etc. the search string; that one can
choose to "add/overwrite" the field; but not to "add as prefix to"
etc. I assume that this may be have historic reasons in the sense
that more and more functionality was added to this interface
sequentially ...



So here are a couple of suggestions I have tried to come up with on
the basis of the above observations. As I said above, these are by no
means feature requests; and others may turn out to be stupid ideas. I
just did not only want to provide with criticism but also come up
with some possible solutions.

1. Perhaps one could introduce *both* a collection of dedicated find
(& replace) commands under "Edit" -> "Find" (no big departure from
current behavior), and a collection of dedicated commands dealing
with manipulation of references and fields under the "Publication"
menu in order to give more importance to these functions in BibDesk.
I think that some of these commands would inevitably duplicate the
functionality of some find commands to a certain extent (but not
really, see below), and I agree that providing to many pathways for
doing the same thing would lead to Microsoft-style bloatware. But I
still think that this would be acceptable (to the degree proposed
below) because, as a user, you want to do both things (find, sort,
organize references; and manipulate references and fields) so that
leaving away, e.g., the Database Search & Replace" (whatever it is
called) from the find menu may confuse other people.

2. I think that a simple "Find" command (under "Edit" -> "Find")
should take you to a search text field in the main window just like
now, but it should at least default to search "any field"! I must say
that I, personally, would completely do away with the search options
here for the reasons mentioned above. I would rather introduce a
button (or whatever) to give the user access to "Advanced Search
Options". But I can see many other people will be happy to use these,
and will complain if the current behavior is changed. Perhaps, one
could rather implement the additional search options in the way the
MacOS Finder does it (hit Cmd-F): an active text field at the top of
the window and then additional search options and possibilities
openly visible in the window itself. I am not sure whether I really
like this feature, though, because it seems to misuse the main
window. In any case, one could perhaps implement an option to save
the current search into a Smart Group.

2. A more advanced "Advanced Find & Replace" command (under "Edit" ->
"Find") should offer you a consistent and comprehensive interface to
find & replace strings in the database, to find references and also
display them, to change specific fields, and also save complex
searches into Smart Groups. The interface of this dialog should
clearly differentiate visually (i) the scope, (ii) the target, (iii)
the search text and its nature, (iv) the kind of replacement and its
nature, and (v) which action to perform. The window should be well-
organized (i.e., in the specified order, in my opinion) so that one
can almost "read" the window and the setup of the search as if it
were a natural text. I have tried to think of a good design as an
example, and this is what I could come up with (make your window wide
enough to display the dashes in one line):

------------------------------------------------------------------------
----------------------------
[ ] Perform search & replace on entire database
[x] Perform search & replace on currently active group
[ ] Perform search & replace only on selected references

[x] Perform search & replace on any field
[ ] Perform search & replace on field [Author]
[etc. ]

[Field contains ] [enter search text] [x] plain text [ ]
BibTeX macro [ ] regular expression
[Field begins with ]
[Entire Field is ]
[etc. ]

[Replace Text with ] [enter new text ] [x] plain text [ ]
BibTeX macro [ ] regular expression
[Replace Field with ]
[Add Prefix to Field]
[etc. ]
-------------
[[Replace]] [[Replace All]] [[Find Previous]] [[Find Next]]
[[Display All]] [[Save Search]]
-------------
------------------------------------------------------------------------
----------------------------

[ ] and [x] are radio buttons with the latter being the default; of
course, previous choices should be remembered, as well as previous
text entries; the other elements are drop-down menus or text fields
(self-explanatory, I think),and [[xxx]] are buttons.

I find it important that the limitation to the active group is made
explicit (of course, chosen as a default), and that one has the
choice to perform the operation on the entire database as well. I
find it important that one has the option to display a subset of your
library as the result of the search operation ("Display All")
consistent with the simple find command. And I think it would be cool
if one could save this complex search into a Smart Group from within
the search interface as well ("save search").

3. The dedicated menu "Publications" (or "References") would do all
things that involve manipulating references or fields. This would
give these activities a better attention. In addition to its current
set of commands dealing with references, it should contain commands
to delete references, find, and manipulate references. The latter
would be commands to find, change, add prefix/suffix to, copy/swap
fields etc. I wonder whether one should group other commands dealing
with the pDF files etc., or with BibTeX specific things (such as
"generate cite key") in another menu, but this is definitely not
really necessary. While I am at it, I would rather call the menu
"References" (and change the names of the commands accordingly)
because, in my opinion, BibDesk deals with references to
publications; but this is a completely unimportant detail.

The copy/swap fields commands should do what is currently done with
AppleScripts. I just assume that incorporation into BibDesk would
have the advantage to do this with the BibDesk typical mixed drop-
down menu/text field based choice of fields rather than a fixed list
of fields.

The other field specific commands (e.g., "Change Field") would then
be specialized commands (shortcuts) the functionality of which would
in part duplicate the functionality of the "Advanced Find & Replace"
command in the sense that the same, consistent interface is used. But
it would set different defaults. For example, a command "Find
References" would take you to the same interface, with essentially
the same (previous) defaults, except that [[Display All]] should be
the default action (button). Analogously, a command "Change Fields"
would take you to the same interface, but with the following defaults:

------------------------------------------------------------------------
----------------------------
[ ] Perform search & replace on entire database
[x] Perform search & replace on currently active group
[ ] Perform search & replace only on selected references

[ ] Perform search & replace on any field
[x] Perform search & replace on field [Author]
[etc. ]

[Entire Field is ] [enter search text] [x] plain text [ ]
BibTeX macro [ ] regular expression
[Field begins with ]
[etc. ]

[Replace Field with ] [enter new text ] [x] plain text [ ]
BibTeX macro [ ] regular expression
[Add Prefix to Field]
[etc. ]
-----------
[[Replace]] [[Replace All]] [[Find Previous]] [[Find Next]]
[[Display All]] [[Save Search]]
-----------
------------------------------------------------------------------------
----------------------------

This could be done analogously for the other commands. I think the
benefit of this approach would be that (i) commands for the
manipulation of references and fields would be in obvious places
(under "Edit" -> "Find", and under "Publication", respectively), (ii)
a consistent interface is used for everything, (ii) a number of
specialized actions would be quickly accessible with simple menu
commands or keyboard shortcuts, (iii) unexperienced users would, in
fact, be guided how to use the complex "Advanced Find & Replace"
interface just by using it.



Finally, I sincerely hope that you will find the above comments
helpful as a user feedback.

Once again, best regards,
Holger

__
Eidgenössische Technische Hochschule Zürich (ETH Zürich)
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zürich
Switzerland

Phone: [phone]
Fax: [phone]
Email: ***@mat.ethz.ch
Web: http://www.polychem.mat.ethz.ch/frauenrath/

[Christiaan Hofman]

[..]

Post by Holger Frauenrath
------
So, generally speaking, I think that the origin of my "problems" has
been a combination of several different things.
Some of these have to do with the fact that the term "Find" in
context with bibliography management is ambiguous in the sense that
it refers to both "finding references" (i.e., create and display a
subset of your references based on a search term) and "finding/
changing the content of fields"; I think the problem is that the
current implementation (both in terms of name and place of commands
AND in terms of functionality) mixes these things up to a certain
extent.
The others are rather a matter of my expectations - which may be
justified or not. For example, in my eyes, a rather important part of
bibliography management has to do with *manipulating* (not sorting,
grouping, displaying) references, i.e., creating/deleting references,
adding and changing fields etc. And I think that BibDesk has (almost)
all the functionality needed, but it hides the most important parts.
I was expecting commands to manipulate references and fields in the
publication menu (because hat is where you also find "New
reference"), but it is actually buried in the "Database Search &
Replace" interface and in the preferences (the possibility to add a
field).
And then there are a few small things which just have to do with the
actual user interface design which, in my opinion, obscure the actual
power and capabilities of certain commands and interfaces, as is the
case with the very compact "Database Search & Replace.
I will try as good a possible to describe precisely what I mean in
the different areas.
First of all, let me summarize the different interfaces or search
1. The "Find" command (Cmd-F) which takes you to a search text field
in the main window; default searches the keywords field (if I am not
mistaken; I cannot remember having changed the search field option
before); and displays a subset of your references in the list window
as a result of the search operation.

I don't think Keywords is the best default field, perhaps it should
be Any Field. (Though for future compatibility, I don't know how to
set this in the defaults, as this field is localized).

Post by Holger Frauenrath
2. The "Database Search" command (Cmd-Opt-F) which (as far as I can
tell) takes you to the same search text field in the main window; by
default searches the keywords field as well; and also displays a
subset of your references in the list window as a result of the
search operation. So it seems to duplicate the functionality of Cmd-
F; at least I could not find a difference. Please, correct me if I am
wrong.

They are not the same. The difference is that Cmd-F, the generic Find
command, is context sensitive (try it with the preview pane
selected), while Cmd-Opt-F is not context sensitive, and selects the
quick search field (note the difference in name, Search as opposed to
Find.)

I actually think that Cmd-F should not select the search field when
the database is selected, but rather do a Database Find & Replace,
being a Find operation as opposed to a Search/Filter operation.

Post by Holger Frauenrath
3. The "Use Selection for Find" command (Cmd-E) which (as far as I
can tell) takes you to the same search text field in the main window
again; also by default searches the keywords field; and again
displays a subset of your references in the list window as a result
of the search operation. As its name implies (I assume) that it is
supposed to work on *only* selected references, I think its behavior
may be rather due to a bug. At least, when I tried it, it did not
work as I expected. What I tried is this: I have 9 references in the
group "Meijer", 3 of which have been published in 2000. If I select
three of these 9 references which have been published in 2000, 2003,
and 2005, then hit Cmd-E and enter 2000 (search field set to any),
then the result is *all three* papers published in 2000 in the group,
not only the one of the three selected references! Did I understand
the command wrong or is this a bug?

You misunderstand what it does. In fact, Cmd-E, like Cmd-F, is a
standard command (look in any iApp's Find menu). The name might be
confusing, but it is the standard Apple menu item title. We try to
implement this as close as possible to the (expected) standard
behavior, which is "fill the Find field with the currently selected
text." We take the selected text from the preview pane, as that is
the main text available, or a currently selected text field.

I think though that we should not select the search field (as this is
not standard behavior.)

Also, like Cmd-F, I think it should use Database Find & Replace
instead of Search when the main list is selected.

Post by Holger Frauenrath
4. The "Database Search & Replace" Command (Cmd-Shift-F) which takes
you to a comprehensive and very powerful search & replace dialog with
many options, including regular expressions etc. However, it seems
that the search can *only* look for a string in *one particular*
field (not in *any* field), if I have not overlooked anything. And,
this time, the result of the search operation is a list of all papers
in your library (or the active group) with one reference (the first
hit) being selected; you can jump to the next one with "Next" (Cmd-G).
5. Finally, there are Smart Groups which also have to be considered
to be a part of the search interface. You can enter a textual string
or a more complex combination of several strings with a GUI based
mechanism to create a "saved search". But there seems to be no
connection to the other search interfaces.
Let me summarize what one cannot do with the current implementation.

(be careful with the naming, Find vs Search, which are different
functions)

Post by Holger Frauenrath
1. One cannot search a complex construct or a regular expression in
*any field* because "Database Search & Replace" as the only place to
enter a complex construct will search only one specific field.
2. More specifically, one cannot perform, for example, a search for a
combination of terms ("polydiacetylenes OR poly(diacetylene)s") in
*any field* for this reason.

The Quick Search allows AND and OR using + or | (see Help and ToolTip).

Post by Holger Frauenrath
3. One cannot perform a search for a combination of terms using a GUI
based mechanism (the one that is used to set up Smart Groups), except
for actually setting up a Smart Group.
4. One cannot search for a more complex construct or a regular
expression and have a subset of the references displayed in the list
window (as for a simple search) as the result of the search operation.

See above for AND and OR. Regex would be possible in the quick
search, wether we should is another question.

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has anything
like that. Regex would be possible, but again...

Post by Holger Frauenrath
Of course, not all of these "shortcomings" are worth being
implemented, or even desirable (for example, 3 is absolutely not
important, in my opinion; I just listed it as a matter of completion).
The following things I found unexpected or inconsistent in the whole
interface for batch editing references, including the find & replace
- What is the differentiation of between "Find" (Cmd-F) and "Database
Search" (Cmd-Opt-F)? What is the difference between their definitions
- I mean, how would you tell what the difference is from the actual
command names? What is the difference in functionality? Why are the
two commands there? If there is any difference, I cannot not see it.

See above.

Post by Holger Frauenrath
- Is the current behavior of the "Use Selection for Find" (Cmd-E) a
bug or did I misunderstand hoiw to use it or what to use it for?

See above.

Post by Holger Frauenrath
- I found it strange that the very differently named "Find" and
"Database Search" both take you to the same interface (a search text
field in the main window) whereas the "Database Find &
Replace" (looking similar to "Database Search") takes you to a
different interface.

I agree, as I explained.

Post by Holger Frauenrath
- I found it odd (unexpected) that the "Find" and "Database Search"
search text field tries to do more than just letting you enter a
search term. For example, it took me quite a while to figure out why
entering "Meijer" in it (the authors of a dozen papers in my library)
gives no results! Of course, I found out the reason is that it
defaulted to the "keywords" field. But you will only see this when
you click on the magnifying glass/triangle in the text field. Most
other applications (e.g., Safari, Firefox) seem to use a magnifying
glass/triangle in the search field only for your last searches, not
for any search options. Unfortunately, I realized that Apple is
inconsistent themselves: iTunes also uses it for options in the same
way as BibDesk. But I don'T think this is a good idea; I find this
behavior unexpected, and the result of the search operation
unpredictable: How would one no which field is searched (without
clicking on the triangle)? How would one see which was one's last
choice (without clicking on the triangle)? I think the simple search
text field in the main window is not a good interface for more
advanced searches.

There is no standard, the search menu can be used for any options or
history for searching. What is available there just depends on what
functionality is available and the context. I do think that it is the
right place for search options (where else?) I do agree that Keywords
is not the right default. Also the field to search is shown in the
placeholder, when the search field is not selected.

Post by Holger Frauenrath
- I found the name "Database Search & Replace" is misleading because
it is not actually what the command does. To me, the name implies
that I can search for a term (e.g., polydiacetylenes) and have it
replaced with another one (e.g., poly(diacetylene)s) in the
*database*, i.e. in *any field* by default, with the *optional*
behavior to narrow down or focus the search on one particular field.
But this is not what it does. It is currently rather a command to
"Find, Change & Add Fields".

Database refers to the scope of the /items/ to search, not the
fields. Allowing to find in any field could be possible, I think,
that would be an RFE. I'm not sure if the "Database" is really the
best, but I find it hard to find a better name. Maybe the option to
add a field is not so much covered by this term, but that was
introduced as a request from a user, and was pretty easy to add to
the interface. The main functionality of the panel though is Find &
Replace, so that part of the name is correct.

Post by Holger Frauenrath
- In particular, this last function ("Add field") is found only in
places which appear to be obscure to me: the Preferences (setting
default fields) and the "Database Search & Replace" command. And I
never expected them there which is why it took me so long to figure
out how to actually add the group field to my references.

That's mostly because this functionality came as a by-product of
other (main) functionality. In fact, some uses of batch editing, like
using field groups, did not even occur to me until someone mentioned
it on the user list ;)

We could perhaps add menu items to the Publication menu (or should
this be the Edit menu?) for Add Field / Remove Field / Change Field.
The Add Field item can be context sensitive: in a detail editor add
the field, while with the main window selected it can call the Find
panel with the checkbox selected.

Post by Holger Frauenrath
- I think it is a shortcoming that the "Find" = "Database Search"
commands will display a subset of your references as the result of
the search operation whereas the "Database Search & Replace" command
does not even offer you this as an option.

Maybe the names are a bit misleading, but as for the GUI this is
standard behavior: a Search field filters the item, a Find panel
selects items. In that respect is the naming also appropriate: Search
is normally used for the filter (see eg Mail) and Find for a find
panel. The only problem may be that Find sometimes brings you to the
Search field.

Post by Holger Frauenrath
- Finally, I only found out in the recent email communication with
Adam that the scope of the "Database Search & Replace" command is
restricted to the currently active group (and the whole library if it
is selected). While this is perfectly alright and consistent, it was
still unexpected (I would not have asked for it otherwise) for the
simple reason that it is at no point explicitly stated when you
initiate a search. I also think that, for the same reason, it may be
prone to provoke user mistakes.

I'm not sure where to show this information though. Too much
messages, in particular popups, tend to be annoying and cluttering
rather than helpful. I did change the Help in that respect.

[remarks about Database Find & Replace, see other mail]

Thanks for these remarks. Generally what is obvious for us is far
from that for users, so this feedback is very helpful.

Christiaan

[Adam R. Maxwell]

[...]

Post by Christiaan Hofman

Post by Holger Frauenrath
2. The "Database Search" command (Cmd-Opt-F) which (as far as I can
tell) takes you to the same search text field in the main window; by
default searches the keywords field as well; and also displays a
subset of your references in the list window as a result of the
search operation. So it seems to duplicate the functionality of Cmd-
F; at least I could not find a difference. Please, correct me if I am
wrong.

They are not the same. The difference is that Cmd-F, the generic Find
command, is context sensitive (try it with the preview pane
selected), while Cmd-Opt-F is not context sensitive, and selects the
quick search field (note the difference in name, Search as opposed to
Find.)
I actually think that Cmd-F should not select the search field when
the database is selected, but rather do a Database Find & Replace,
being a Find operation as opposed to a Search/Filter operation.

We do that because that has been a shortcut for the searchfield ever
since BibFinder was removed (anyone remember that?), and it's a much
more common operation than using the find panel.

If no one else uses that shortcut, I won't complain too much, but I
think it's wrong to display the db find panel for an operation that
displays a standard textview find panel in other views (especially
since the db find panel has always had a separate menu item and
shortcut).

Post by Christiaan Hofman

Post by Holger Frauenrath
3. The "Use Selection for Find" command (Cmd-E) which (as far as I
can tell) takes you to the same search text field in the main window
again; also by default searches the keywords field; and again
displays a subset of your references in the list window as a result
of the search operation. As its name implies (I assume) that it is
supposed to work on *only* selected references, I think its behavior
may be rather due to a bug. At least, when I tried it, it did not
work as I expected. What I tried is this: I have 9 references in the
group "Meijer", 3 of which have been published in 2000. If I select
three of these 9 references which have been published in 2000, 2003,
and 2005, then hit Cmd-E and enter 2000 (search field set to any),
then the result is *all three* papers published in 2000 in the group,
not only the one of the three selected references! Did I understand
the command wrong or is this a bug?

You misunderstand what it does. In fact, Cmd-E, like Cmd-F, is a
standard command (look in any iApp's Find menu). The name might be
confusing, but it is the standard Apple menu item title. We try to
implement this as close as possible to the (expected) standard
behavior, which is "fill the Find field with the currently selected
text." We take the selected text from the preview pane, as that is
the main text available, or a currently selected text field.
I think though that we should not select the search field (as this is
not standard behavior.)

Yes, that's a bit unusual.

Post by Christiaan Hofman
Also, like Cmd-F, I think it should use Database Find & Replace
instead of Search when the main list is selected.

That may be misleading; cmd-e is not tied to a specific search/find
function, so it's not a matter of using db find vs the searchfield.
All applicable text fields should use the information from the
system's find pasteboard, and the db find already does use it.

Post by Christiaan Hofman

Post by Holger Frauenrath
4. The "Database Search & Replace" Command (Cmd-Shift-F) which takes
you to a comprehensive and very powerful search & replace dialog with
many options, including regular expressions etc. However, it seems
that the search can *only* look for a string in *one particular*
field (not in *any* field), if I have not overlooked anything. And,
this time, the result of the search operation is a list of all papers
in your library (or the active group) with one reference (the first
hit) being selected; you can jump to the next one with "Next" (Cmd-
G).
5. Finally, there are Smart Groups which also have to be considered
to be a part of the search interface. You can enter a textual string
or a more complex combination of several strings with a GUI based
mechanism to create a "saved search". But there seems to be no
connection to the other search interfaces.
Let me summarize what one cannot do with the current implementation.

(be careful with the naming, Find vs Search, which are different
functions)

Post by Holger Frauenrath
1. One cannot search a complex construct or a regular expression in
*any field* because "Database Search & Replace" as the only place to
enter a complex construct will search only one specific field.
2. More specifically, one cannot perform, for example, a search for a
combination of terms ("polydiacetylenes OR poly(diacetylene)s") in
*any field* for this reason.

The Quick Search allows AND and OR using + or | (see Help and
ToolTip).

That wasn't working for me the other day, but I didn't have time to
look into it.

Post by Christiaan Hofman

Post by Holger Frauenrath
3. One cannot perform a search for a combination of terms using a GUI
based mechanism (the one that is used to set up Smart Groups), except
for actually setting up a Smart Group.
4. One cannot search for a more complex construct or a regular
expression and have a subset of the references displayed in the list
window (as for a simple search) as the result of the search
operation.

See above for AND and OR. Regex would be possible in the quick
search, wether we should is another question.

-1 from me. We've been over that before.

Post by Christiaan Hofman

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has anything
like that. Regex would be possible, but again...

And how often would this be used, anyway? 99% of my searches use the
quicksearch field (I do use the Boolean operators), and I can't really
imagine needing a regex in a smart group. Besides, isn't the current
complexity part of the underlying problem?

Post by Christiaan Hofman

Post by Holger Frauenrath
- I found it odd (unexpected) that the "Find" and "Database Search"
search text field tries to do more than just letting you enter a
search term. For example, it took me quite a while to figure out why
entering "Meijer" in it (the authors of a dozen papers in my library)
gives no results! Of course, I found out the reason is that it
defaulted to the "keywords" field. But you will only see this when
you click on the magnifying glass/triangle in the text field. Most
other applications (e.g., Safari, Firefox) seem to use a magnifying
glass/triangle in the search field only for your last searches, not
for any search options. Unfortunately, I realized that Apple is
inconsistent themselves: iTunes also uses it for options in the same
way as BibDesk. But I don'T think this is a good idea; I find this
behavior unexpected, and the result of the search operation
unpredictable: How would one no which field is searched (without
clicking on the triangle)? How would one see which was one's last
choice (without clicking on the triangle)? I think the simple search
text field in the main window is not a good interface for more
advanced searches.

There is no standard, the search menu can be used for any options or
history for searching. What is available there just depends on what
functionality is available and the context. I do think that it is the
right place for search options (where else?) I do agree that Keywords
is not the right default. Also the field to search is shown in the
placeholder, when the search field is not selected.

I believe it used to be more common for applications to allow
searching specific fields with a searchfield menu (didn't Mail do
this?). Mail and Finder don't do this because they use Spotlight and
display rankings. I've considered switching to a SearchKit-based
solution for BibDesk, which would allow Booleans and just display a
ranked list of items, but we haven't discussed that.

Post by Christiaan Hofman

Post by Holger Frauenrath
- I found the name "Database Search & Replace" is misleading because
it is not actually what the command does. To me, the name implies
that I can search for a term (e.g., polydiacetylenes) and have it
replaced with another one (e.g., poly(diacetylene)s) in the
*database*, i.e. in *any field* by default, with the *optional*
behavior to narrow down or focus the search on one particular field.
But this is not what it does. It is currently rather a command to
"Find, Change & Add Fields".

Database refers to the scope of the /items/ to search, not the
fields. Allowing to find in any field could be possible, I think,
that would be an RFE. I'm not sure if the "Database" is really the
best, but I find it hard to find a better name. Maybe the option to
add a field is not so much covered by this term, but that was
introduced as a request from a user, and was pretty easy to add to
the interface. The main functionality of the panel though is Find &
Replace, so that part of the name is correct.

The overall functionality of the panel was intended to be batch edit;
finding and highlighting items is an afterthought. I originally added
it at Alex's request, I think, since there were some things that are
easier to do within BibDesk than with AppleScript or a text editor.

There's no reason to use that panel for searching, since it's less
flexible than the searchfield (except for regexes), and there's also
no reason for using it to edit a single item, since we have an editor
window for that purpose.

Post by Christiaan Hofman

Post by Holger Frauenrath
- In particular, this last function ("Add field") is found only in
places which appear to be obscure to me: the Preferences (setting
default fields) and the "Database Search & Replace" command. And I
never expected them there which is why it took me so long to figure
out how to actually add the group field to my references.

That's mostly because this functionality came as a by-product of
other (main) functionality. In fact, some uses of batch editing, like
using field groups, did not even occur to me until someone mentioned
it on the user list ;)
We could perhaps add menu items to the Publication menu (or should
this be the Edit menu?) for Add Field / Remove Field / Change Field.
The Add Field item can be context sensitive: in a detail editor add
the field, while with the main window selected it can call the Find
panel with the checkbox selected.

I think that would be confusing. No one would notice the checkbox
difference, and it could lead to unexpected behavior (if you use Add
Field to call the find panel and then hit cmd-f, does that checkbox
get unchecked?).

Post by Christiaan Hofman

Post by Holger Frauenrath
- Finally, I only found out in the recent email communication with
Adam that the scope of the "Database Search & Replace" command is
restricted to the currently active group (and the whole library if it
is selected). While this is perfectly alright and consistent, it was
still unexpected (I would not have asked for it otherwise) for the
simple reason that it is at no point explicitly stated when you
initiate a search. I also think that, for the same reason, it may be
prone to provoke user mistakes.

I'm not sure where to show this information though. Too much
messages, in particular popups, tend to be annoying and cluttering
rather than helpful. I did change the Help in that respect.

I thought this was obvious, actually, from a consistency standpoint.
The "database" word is misleading in that respect, though.

Post by Christiaan Hofman
Thanks for these remarks. Generally what is obvious for us is far
from that for users, so this feedback is very helpful.

Indeed. New users in particular have different views, and we need to
keep BibDesk transparent enough that someone can use it immediately.

-- adam

[Christiaan Hofman]

Post by Adam R. Maxwell
[...]

Post by Christiaan Hofman

Post by Holger Frauenrath
2. The "Database Search" command (Cmd-Opt-F) which (as far as I can
tell) takes you to the same search text field in the main window; by
default searches the keywords field as well; and also displays a
subset of your references in the list window as a result of the
search operation. So it seems to duplicate the functionality of Cmd-
F; at least I could not find a difference. Please, correct me if I am
wrong.

They are not the same. The difference is that Cmd-F, the generic Find
command, is context sensitive (try it with the preview pane
selected), while Cmd-Opt-F is not context sensitive, and selects the
quick search field (note the difference in name, Search as opposed to
Find.)
I actually think that Cmd-F should not select the search field when
the database is selected, but rather do a Database Find & Replace,
being a Find operation as opposed to a Search/Filter operation.

We do that because that has been a shortcut for the searchfield ever
since BibFinder was removed (anyone remember that?), and it's a much
more common operation than using the find panel.

I know

Post by Adam R. Maxwell
If no one else uses that shortcut, I won't complain too much, but I
think it's wrong to display the db find panel for an operation that
displays a standard textview find panel in other views (especially
since the db find panel has always had a separate menu item and
shortcut).

I disagree. Find is an action that calls a Find panel (it is bound to
performFindPanelAction). The search field is not a find panel, so
selecting that is inconsistent, so I think we should not do that.
Also the search field has its own shortcut, which is consistent with
Apple apps. The DB F&R panel is close to a Find & Replace panel for
the database, that's why I think it is the appropriate thing to show
here. However we could also follow xcode and show the textview Find
panel. Not very useful, but it is completely consistent.

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
3. The "Use Selection for Find" command (Cmd-E) which (as far as I
can tell) takes you to the same search text field in the main window
again; also by default searches the keywords field; and again
displays a subset of your references in the list window as a result
of the search operation. As its name implies (I assume) that it is
supposed to work on *only* selected references, I think its behavior
may be rather due to a bug. At least, when I tried it, it did not
work as I expected. What I tried is this: I have 9 references in the
group "Meijer", 3 of which have been published in 2000. If I select
three of these 9 references which have been published in 2000, 2003,
and 2005, then hit Cmd-E and enter 2000 (search field set to any),
then the result is *all three* papers published in 2000 in the group,
not only the one of the three selected references! Did I understand
the command wrong or is this a bug?

You misunderstand what it does. In fact, Cmd-E, like Cmd-F, is a
standard command (look in any iApp's Find menu). The name might be
confusing, but it is the standard Apple menu item title. We try to
implement this as close as possible to the (expected) standard
behavior, which is "fill the Find field with the currently selected
text." We take the selected text from the preview pane, as that is
the main text available, or a currently selected text field.
I think though that we should not select the search field (as this is
not standard behavior.)

Yes, that's a bit unusual.

Post by Christiaan Hofman
Also, like Cmd-F, I think it should use Database Find & Replace
instead of Search when the main list is selected.

That may be misleading; cmd-e is not tied to a specific search/find
function, so it's not a matter of using db find vs the searchfield.
All applicable text fields should use the information from the
system's find pasteboard, and the db find already does use it.

Post by Christiaan Hofman

Post by Holger Frauenrath
4. The "Database Search & Replace" Command (Cmd-Shift-F) which takes
you to a comprehensive and very powerful search & replace dialog with
many options, including regular expressions etc. However, it seems
that the search can *only* look for a string in *one particular*
field (not in *any* field), if I have not overlooked anything. And,
this time, the result of the search operation is a list of all papers
in your library (or the active group) with one reference (the first
hit) being selected; you can jump to the next one with "Next" (Cmd-
G).
5. Finally, there are Smart Groups which also have to be considered
to be a part of the search interface. You can enter a textual string
or a more complex combination of several strings with a GUI based
mechanism to create a "saved search". But there seems to be no
connection to the other search interfaces.
Let me summarize what one cannot do with the current implementation.

(be careful with the naming, Find vs Search, which are different
functions)

Post by Holger Frauenrath
1. One cannot search a complex construct or a regular expression in
*any field* because "Database Search & Replace" as the only place to
enter a complex construct will search only one specific field.
2. More specifically, one cannot perform, for example, a search for a
combination of terms ("polydiacetylenes OR poly(diacetylene)s") in
*any field* for this reason.

The Quick Search allows AND and OR using + or | (see Help and
ToolTip).

That wasn't working for me the other day, but I didn't have time to
look into it.

Haven't noticed any problem.

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
3. One cannot perform a search for a combination of terms using a GUI
based mechanism (the one that is used to set up Smart Groups), except
for actually setting up a Smart Group.
4. One cannot search for a more complex construct or a regular
expression and have a subset of the references displayed in the list
window (as for a simple search) as the result of the search
operation.

See above for AND and OR. Regex would be possible in the quick
search, wether we should is another question.

-1 from me. We've been over that before.

Agreed, just noticed it as technically possible (unlike conversion to
smart groups).

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has anything
like that. Regex would be possible, but again...

And how often would this be used, anyway? 99% of my searches use the
quicksearch field (I do use the Boolean operators), and I can't really
imagine needing a regex in a smart group. Besides, isn't the current
complexity part of the underlying problem?

Agreed. Regexes in F&R are much more useful. I've also never used the
regex option in xcode's search field.

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
- I found it odd (unexpected) that the "Find" and "Database Search"
search text field tries to do more than just letting you enter a
search term. For example, it took me quite a while to figure out why
entering "Meijer" in it (the authors of a dozen papers in my
library)
gives no results! Of course, I found out the reason is that it
defaulted to the "keywords" field. But you will only see this when
you click on the magnifying glass/triangle in the text field. Most
other applications (e.g., Safari, Firefox) seem to use a magnifying
glass/triangle in the search field only for your last searches, not
for any search options. Unfortunately, I realized that Apple is
inconsistent themselves: iTunes also uses it for options in the same
way as BibDesk. But I don'T think this is a good idea; I find this
behavior unexpected, and the result of the search operation
unpredictable: How would one no which field is searched (without
clicking on the triangle)? How would one see which was one's last
choice (without clicking on the triangle)? I think the simple search
text field in the main window is not a good interface for more
advanced searches.

There is no standard, the search menu can be used for any options or
history for searching. What is available there just depends on what
functionality is available and the context. I do think that it is the
right place for search options (where else?) I do agree that Keywords
is not the right default. Also the field to search is shown in the
placeholder, when the search field is not selected.

I believe it used to be more common for applications to allow
searching specific fields with a searchfield menu (didn't Mail do
this?). Mail and Finder don't do this because they use Spotlight and
display rankings. I've considered switching to a SearchKit-based
solution for BibDesk, which would allow Booleans and just display a
ranked list of items, but we haven't discussed that.

Post by Christiaan Hofman

Post by Holger Frauenrath
- I found the name "Database Search & Replace" is misleading because
it is not actually what the command does. To me, the name implies
that I can search for a term (e.g., polydiacetylenes) and have it
replaced with another one (e.g., poly(diacetylene)s) in the
*database*, i.e. in *any field* by default, with the *optional*
behavior to narrow down or focus the search on one particular field.
But this is not what it does. It is currently rather a command to
"Find, Change & Add Fields".

Database refers to the scope of the /items/ to search, not the
fields. Allowing to find in any field could be possible, I think,
that would be an RFE. I'm not sure if the "Database" is really the
best, but I find it hard to find a better name. Maybe the option to
add a field is not so much covered by this term, but that was
introduced as a request from a user, and was pretty easy to add to
the interface. The main functionality of the panel though is Find &
Replace, so that part of the name is correct.

The overall functionality of the panel was intended to be batch edit;
finding and highlighting items is an afterthought. I originally added
it at Alex's request, I think, since there were some things that are
easier to do within BibDesk than with AppleScript or a text editor.
There's no reason to use that panel for searching, since it's less
flexible than the searchfield (except for regexes), and there's also
no reason for using it to edit a single item, since we have an editor
window for that purpose.

Post by Christiaan Hofman

Post by Holger Frauenrath
- In particular, this last function ("Add field") is found only in
places which appear to be obscure to me: the Preferences (setting
default fields) and the "Database Search & Replace" command. And I
never expected them there which is why it took me so long to figure
out how to actually add the group field to my references.

That's mostly because this functionality came as a by-product of
other (main) functionality. In fact, some uses of batch editing, like
using field groups, did not even occur to me until someone mentioned
it on the user list ;)
We could perhaps add menu items to the Publication menu (or should
this be the Edit menu?) for Add Field / Remove Field / Change Field.
The Add Field item can be context sensitive: in a detail editor add
the field, while with the main window selected it can call the Find
panel with the checkbox selected.

I think that would be confusing. No one would notice the checkbox
difference, and it could lead to unexpected behavior (if you use Add
Field to call the find panel and then hit cmd-f, does that checkbox
get unchecked?).

Post by Christiaan Hofman

Post by Holger Frauenrath
- Finally, I only found out in the recent email communication with
Adam that the scope of the "Database Search & Replace" command is
restricted to the currently active group (and the whole library if it
is selected). While this is perfectly alright and consistent, it was
still unexpected (I would not have asked for it otherwise) for the
simple reason that it is at no point explicitly stated when you
initiate a search. I also think that, for the same reason, it may be
prone to provoke user mistakes.

I'm not sure where to show this information though. Too much
messages, in particular popups, tend to be annoying and cluttering
rather than helpful. I did change the Help in that respect.

I thought this was obvious, actually, from a consistency standpoint.
The "database" word is misleading in that respect, though.

I had the same idea. Also "all publications" would not make sense:
how do you find & select an item that is not shown?

Post by Adam R. Maxwell

Post by Christiaan Hofman
Thanks for these remarks. Generally what is obvious for us is far
from that for users, so this feedback is very helpful.

Indeed. New users in particular have different views, and we need to
keep BibDesk transparent enough that someone can use it immediately.
-- adam

Christiaan

[Adam R. Maxwell]

Post by Holger Frauenrath

Post by Adam R. Maxwell

Post by Christiaan Hofman
I actually think that Cmd-F should not select the search field when
the database is selected, but rather do a Database Find & Replace,
being a Find operation as opposed to a Search/Filter operation.

We do that because that has been a shortcut for the searchfield ever
since BibFinder was removed (anyone remember that?), and it's a much
more common operation than using the find panel.

I know

Post by Adam R. Maxwell
If no one else uses that shortcut, I won't complain too much, but I
think it's wrong to display the db find panel for an operation that
displays a standard textview find panel in other views (especially
since the db find panel has always had a separate menu item and
shortcut).

I disagree. Find is an action that calls a Find panel (it is bound to
performFindPanelAction). The search field is not a find panel, so
selecting that is inconsistent, so I think we should not do that.
Also the search field has its own shortcut, which is consistent with
Apple apps. The DB F&R panel is close to a Find & Replace panel for
the database, that's why I think it is the appropriate thing to show
here. However we could also follow xcode and show the textview Find
panel. Not very useful, but it is completely consistent.

I don't have a big problem with disabling the searchfield selection on
cmd-f. I don't think it's appropriate to show a different find panel
for the same menu command; I'd prefer to be consistent by either
showing the NSTextView find panel (or just beeping).

Post by Holger Frauenrath

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has anything
like that. Regex would be possible, but again...

And how often would this be used, anyway? 99% of my searches use the
quicksearch field (I do use the Boolean operators), and I can't really
imagine needing a regex in a smart group. Besides, isn't the current
complexity part of the underlying problem?

Agreed. Regexes in F&R are much more useful. I've also never used the
regex option in xcode's search field.

I think I used a regex once in Xcode's searchfield, but it's too much
of a pain. Also, in response to some point of Holger's that I can't
be bothered to find now ;), the regex find and replace allows you to
do prefix/suffix replacement and other very sophisticated things via
regex grouping and backreferences (you can even have named subpatterns).

-- adam

[Holger Frauenrath]

Post by Adam R. Maxwell
We do that because that has been a shortcut for the searchfield ever
since BibFinder was removed (anyone remember that?), and it's a much
more common operation than using the find panel.

That would be fine with me. I think the differentiation could be
(similar to how it is now) a simple "Find" vs. a more advanced
"Advanced Find & Replace" ...

Post by Adam R. Maxwell

Post by Christiaan Hofman
See above for AND and OR. Regex would be possible in the quick
search, wether we should is another question.

-1 from me. We've been over that before.

I agree. See my previous email.

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has anything
like that. Regex would be possible, but again...

And how often would this be used, anyway? 99% of my searches use the
quicksearch field (I do use the Boolean operators), and I can't really
imagine needing a regex in a smart group. Besides, isn't the current
complexity part of the underlying problem?

Again, I agree. See my previous email. Just to make it clear: my
point would not be that one cannot do regular expressions in Smart
Groups ... but what I would find useful is being able to save
searches (from whichever interface) into Smart Groups in order to
have a closer connection between these. Let's say I do a search
(complex or not) and find the results useful for being used as a
Smart Group ... I have to do it over again, and with a different
interface.

Post by Adam R. Maxwell
The overall functionality of the panel was intended to be batch edit;
finding and highlighting items is an afterthought. I originally added
it at Alex's request, I think, since there were some things that are
easier to do within BibDesk than with AppleScript or a text editor.
There's no reason to use that panel for searching, since it's less
flexible than the searchfield (except for regexes), and there's also
no reason for using it to edit a single item, since we have an editor
window for that purpose.

But it could do these things and provide a consistent interface for
many things IF it is well-organized. See my previous email. The
problem is (I think) that currently it does some things in different
areas and leaves away others.

Post by Adam R. Maxwell

Post by Christiaan Hofman
We could perhaps add menu items to the Publication menu (or should
this be the Edit menu?) for Add Field / Remove Field / Change Field.
The Add Field item can be context sensitive: in a detail editor add
the field, while with the main window selected it can call the Find
panel with the checkbox selected.

I think that would be confusing. No one would notice the checkbox
difference, and it could lead to unexpected behavior (if you use Add
Field to call the find panel and then hit cmd-f, does that checkbox
get unchecked?).

Of course, I would not want to insist on my suggested behavior. But,
again, at least if you select, e.g., a "Replace Field" command, you
should expect the appropriate check box being checked. As to what
happens when the wondow is open, and you hit Cmd-F ... you may be
right. But ... the check box (add or overwrite field) being checked
problem already exists now, doesn't it?

Post by Adam R. Maxwell

Post by Christiaan Hofman
I'm not sure where to show this information though. Too much
messages, in particular popups, tend to be annoying and cluttering
rather than helpful. I did change the Help in that respect.

I thought this was obvious, actually, from a consistency standpoint.
The "database" word is misleading in that respect, though.

See my suggested rearrangements in the dialog window.

Post by Adam R. Maxwell

Post by Christiaan Hofman
Thanks for these remarks. Generally what is obvious for us is far
from that for users, so this feedback is very helpful.

Indeed. New users in particular have different views, and we need to
keep BibDesk transparent enough that someone can use it immediately.

AS to Chrisian, thanks for listening. The polished state and power of
BibDesk shows that all of you seem to have listened a lot o users'
feedback. Thanks guys.

Have a good night.
Holger

[Adam R. Maxwell]

Post by Holger Frauenrath

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has anything
like that. Regex would be possible, but again...

And how often would this be used, anyway? 99% of my searches use the
quicksearch field (I do use the Boolean operators), and I can't really
imagine needing a regex in a smart group. Besides, isn't the current
complexity part of the underlying problem?

Again, I agree. See my previous email. Just to make it clear: my
point would not be that one cannot do regular expressions in Smart
Groups ... but what I would find useful is being able to save
searches (from whichever interface) into Smart Groups in order to
have a closer connection between these. Let's say I do a search
(complex or not) and find the results useful for being used as a
Smart Group ... I have to do it over again, and with a different
interface.

It's possible to do that, but would require a new type of group, and
those groups would not be editable with the present smart group
interface. To unify them, we'd have to use search predicates, but
there's no UI for those until Leopard (see <http://www.dekorte.com/blog/blog.cgi?do=item&id=2345

Post by Holger Frauenrath
for instance).

Post by Adam R. Maxwell
The overall functionality of the panel was intended to be batch edit;
finding and highlighting items is an afterthought. I originally added
it at Alex's request, I think, since there were some things that are
easier to do within BibDesk than with AppleScript or a text editor.
There's no reason to use that panel for searching, since it's less
flexible than the searchfield (except for regexes), and there's also
no reason for using it to edit a single item, since we have an editor
window for that purpose.

But it could do these things and provide a consistent interface for
many things IF it is well-organized. See my previous email. The
problem is (I think) that currently it does some things in different
areas and leaves away others.

It does exactly what it was designed to do; I'd argue that the problem
is that it's capable of doing too much, and that is not immediately
clear.

The highlighting of matched items using the find panel is an
incidental feature, as this was not intended to be a search
interface. As an illustration, I occasionally use my Kleins <http://www.jharlen.com/kleind2139ne.html

Post by Holger Frauenrath
for driving nails, but I'm not going to lobby Klein to put a hammer

head or claw on them.

Post by Holger Frauenrath

Post by Adam R. Maxwell

Post by Christiaan Hofman
We could perhaps add menu items to the Publication menu (or should
this be the Edit menu?) for Add Field / Remove Field / Change Field.
The Add Field item can be context sensitive: in a detail editor add
the field, while with the main window selected it can call the Find
panel with the checkbox selected.

I think that would be confusing. No one would notice the checkbox
difference, and it could lead to unexpected behavior (if you use Add
Field to call the find panel and then hit cmd-f, does that checkbox
get unchecked?).

Of course, I would not want to insist on my suggested behavior. But,
again, at least if you select, e.g., a "Replace Field" command, you
should expect the appropriate check box being checked. As to what
happens when the wondow is open, and you hit Cmd-F ... you may be
right. But ... the check box (add or overwrite field) being checked
problem already exists now, doesn't it?

I would prefer to break functionality out into manageable UI
components, with separate panels for each common, discrete operation.
We just need to determine what those are. Each menu item then gets
its own UI elements, so there's no confusion of multiple menu items
showing the same thing, and some of the clutter can be removed from
the current find panel.

On the other hand, we need to leave some functionality out, and say
"use AppleScript" for those functions. I don't even remember the last
time I used the find & replace feature, and I would guess that most
users don't touch it after their bib file is in a manageable form.
Adding complex UI for stuff that's seldom (if ever) used is a bad idea.

Post by Holger Frauenrath

Post by Adam R. Maxwell

Post by Christiaan Hofman
Thanks for these remarks. Generally what is obvious for us is far
from that for users, so this feedback is very helpful.

Indeed. New users in particular have different views, and we need to
keep BibDesk transparent enough that someone can use it immediately.

AS to Chrisian, thanks for listening. The polished state and power of
BibDesk shows that all of you seem to have listened a lot o users'
feedback. Thanks guys.

Brent Simmons has some good comments on feature requests <http://inessential.com/?comments=1&postid=3291

Post by Holger Frauenrath
. One problem we've run into (in my opinion) is that we've listened

to /too many/ feature requests, and added a lot of "just one more
thing" features to the app, or made snap modifications that sometimes
don't fit. BibDesk has become a very powerful tool, but sometimes
users end up making easy tasks hard, because the first tool they found
would only work with some weird gyrations.


-- adam

[Christiaan Hofman]

Post by Adam R. Maxwell

Post by Holger Frauenrath

Post by Adam R. Maxwell

Post by Christiaan Hofman

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has
anything
like that. Regex would be possible, but again...

And how often would this be used, anyway? 99% of my searches use the
quicksearch field (I do use the Boolean operators), and I can't really
imagine needing a regex in a smart group. Besides, isn't the current
complexity part of the underlying problem?

Again, I agree. See my previous email. Just to make it clear: my
point would not be that one cannot do regular expressions in Smart
Groups ... but what I would find useful is being able to save
searches (from whichever interface) into Smart Groups in order to
have a closer connection between these. Let's say I do a search
(complex or not) and find the results useful for being used as a
Smart Group ... I have to do it over again, and with a different
interface.

It's possible to do that, but would require a new type of group, and
those groups would not be editable with the present smart group
interface. To unify them, we'd have to use search predicates, but
there's no UI for those until Leopard (see <http://www.dekorte.com/
blog/blog.cgi?do=item&id=2345

I wonder if this would allow unifying them. Generally, you need
nested groups of conditions/predicates (brackets), which would lead
to a pretty complex editing interface. I expect more an interface
similar to our smart group interface, with a single choice of And or Or.

Christiaan

[Holger Frauenrath]

Post by Adam R. Maxwell

Post by Holger Frauenrath
But it could do these things and provide a consistent interface for
many things IF it is well-organized. See my previous email. The
problem is (I think) that currently it does some things in different
areas and leaves away others.

It does exactly what it was designed to do; I'd argue that the problem
is that it's capable of doing too much, and that is not immediately
clear.

[...]

Post by Adam R. Maxwell
I would prefer to break functionality out into manageable UI
components, with separate panels for each common, discrete operation.
We just need to determine what those are. Each menu item then gets
its own UI elements, so there's no confusion of multiple menu items
showing the same thing, and some of the clutter can be removed from
the current find panel.
On the other hand, we need to leave some functionality out, and say
"use AppleScript" for those functions. I don't even remember the last
time I used the find & replace feature, and I would guess that most
users don't touch it after their bib file is in a manageable form.
Adding complex UI for stuff that's seldom (if ever) used is a bad idea.

Well, that is true, but only to a certain extent. For example, some
things that I will keep doing [after having completed the move from
Endnote to Bibdesk] in the context of importing all my references
from Scifinder (Chemical Abstracts Database) is: add a few keywords
to the group field of freshly imported references (which I use for
grouping because there is all that junk in the keywords field put in
by SciFinder) ["Add Field", "Change Field"], and weed out weird
markup for special characters in titles and abstracts [Find & Replace
in any field"].

I would not mind breaking up functionality into simple, specialized
operations, as you suggested. Either that way or doing it in a
comprehensive way which would have to be very well organized.
Probably, your idea is easier to deal with.

Post by Adam R. Maxwell
Brent Simmons has some good comments on feature requests <http://
inessential.com/?comments=1&postid=3291.
One problem we've run into (in my opinion) is that we've listened
to /too many/ feature requests, and added a lot of "just one more
thing" features to the app, or made snap modifications that sometimes
don't fit. BibDesk has become a very powerful tool, but sometimes
users end up making easy tasks hard, because the first tool they found
would only work with some weird gyrations.

I wholeheartedly agree. BTW, this is particularly true for people
like me who come from Endnote which requires you to do all sorts of
funny things for simple operations. I have already described the way
I look at user suggestions (like my own) in my reply to Christiaan.
In this sense: thanks for listening.

Best wishes
Holger


__
Eidgenössische Technische Hochschule Zürich (ETH Zürich)
Department of Materials
Wolfgang-Pauli-Str. 10, HCI H515
CH-8093 Zürich
Switzerland

Phone: [phone]
Fax: [phone]
Email: ***@mat.ethz.ch
Web: http://www.polychem.mat.ethz.ch/frauenrath/

[Holger Frauenrath]

[...]

Post by Christiaan Hofman

Post by Holger Frauenrath
2. The "Database Search" command (Cmd-Opt-F) which (as far as I can
tell) takes you to the same search text field in the main window; by
default searches the keywords field as well; and also displays a
subset of your references in the list window as a result of the
search operation. So it seems to duplicate the functionality of Cmd-
F; at least I could not find a difference. Please, correct me if I am
wrong.

They are not the same. The difference is that Cmd-F, the generic Find
command, is context sensitive (try it with the preview pane
selected), while Cmd-Opt-F is not context sensitive, and selects the
quick search field (note the difference in name, Search as opposed to
Find.)
I actually think that Cmd-F should not select the search field when
the database is selected, but rather do a Database Find & Replace,
being a Find operation as opposed to a Search/Filter operation.

Oh, wow. Of course, I had not noticed that difference. I would tend
to agree with your proposal as it would make things more consistent.

Post by Christiaan Hofman

Post by Holger Frauenrath
3. The "Use Selection for Find" command (Cmd-E) which (as far as I
can tell) takes you to the same search text field

[...]

Post by Christiaan Hofman
You misunderstand what it does. In fact, Cmd-E, like Cmd-F, is a
standard command (look in any iApp's Find menu). The name might be
confusing, but it is the standard Apple menu item title. We try to
implement this as close as possible to the (expected) standard
behavior, which is "fill the Find field with the currently selected
text." We take the selected text from the preview pane, as that is
the main text available, or a currently selected text field.

Another wow. I did not know that. Whether it is useful is another
question because Cmd-E == Cmd-C-F-V. But it does not hurt either, so
one should stick to the standard behavior as good as possible, I guess.

Post by Christiaan Hofman
I think though that we should not select the search field (as this is
not standard behavior.)
Also, like Cmd-F, I think it should use Database Find & Replace
instead of Search when the main list is selected.

I would agree.

Post by Christiaan Hofman
See above for AND and OR. Regex would be possible in the quick
search, wether we should is another question.

I agree, I don't think it woul be useful. I just listed this as a
matter of completion. I just wanted to make clear that there are
three different search interfaces with different possiblities

Post by Christiaan Hofman

Post by Holger Frauenrath
5. One cannot save a search (of any type) as a Smart Group
6. One cannot set up Smart Groups using regular expressions or other
more complex search syntax (e.g., "(A and B) or C")

5 & 6 are related. Because of 6, not any search filter term can be
translated to a Smart Group. 6 would be very hard to implement in a
GUI, I haven't seen a single app with smart groups that has anything
like that. Regex would be possible, but again...

Again, my point is not that more complex search behavior should be
implemented, in particular not in a GUI based fashion. But what I
would generally find useful (see my actual suggestions) is a closer
relation between searches and Smart Groups. I think it would be
useful to do a search (simple or advanced, if possible also including
regular expressions) and save it into a Smart Group if one likes the
result. A double-click on this Smart Group would then open the
respective search interface again.

Post by Christiaan Hofman

Post by Holger Frauenrath
- I found it odd (unexpected) that the "Find" and "Database Search"
search text field tries to do more than just letting you enter a
search term.

[...]

Post by Christiaan Hofman
There is no standard, the search menu can be used for any options or
history for searching. What is available there just depends on what
functionality is available and the context. I do think that it is the
right place for search options (where else?) I do agree that Keywords
is not the right default. Also the field to search is shown in the
placeholder, when the search field is not selected.¨

Changing the default would definitely help. But as I said in my last
email, I still think that a simple find hould do a no-frills find,
and then there could be a button to a more advanced find interface ...

Post by Christiaan Hofman
Database refers to the scope of the /items/ to search, not the
fields. Allowing to find in any field could be possible, I think,
that would be an RFE. I'm not sure if the "Database" is really the
best, but I find it hard to find a better name. Maybe the option to
add a field is not so much covered by this term, but that was
introduced as a request from a user, and was pretty easy to add to
the interface. The main functionality of the panel though is Find &
Replace, so that part of the name is correct.

As I suggested earlier, I would call it "Advanced Find & Replace".
When it is accessed from "Edit" -> "Find" -> "Advanced Find &
Replace", the appropriate defaults should be set. The fact that it
can also change/add/replace fields is not a problem in itself. But
this functionlity should then also be comprehensive (inlude "add as
prefix" etc.). When Accessed from "Publication" -> Change Field" or
"Add Field", the appropriate defaults would again be set (see my
previous example). The most important part of my suggestion (from my
own perspective) is that the Find & Replace dialog should be re-
organized to be better "readable".

Post by Christiaan Hofman

Post by Holger Frauenrath
- In particular, this last function ("Add field") is found only in
places which appear to be obscure to me: the Preferences (setting
default fields) and the "Database Search & Replace" command. And I
never expected them there which is why it took me so long to figure
out how to actually add the group field to my references.

That's mostly because this functionality came as a by-product of
other (main) functionality. In fact, some uses of batch editing, like
using field groups, did not even occur to me until someone mentioned
it on the user list ;)
We could perhaps add menu items to the Publication menu (or should
this be the Edit menu?) for Add Field / Remove Field / Change Field.
The Add Field item can be context sensitive: in a detail editor add
the field, while with the main window selected it can call the Find
panel with the checkbox selected.

I would strongly support the first part. The context sensitive part,
I don't know. As i just said, I think that the same interface may be
accessed from the different places, just the defaults being
different. I do not think that this would be too confusing IF the
dialog is well-structured: after all, if you choose "change fied" or
"replace field" or whatever, you should expect "replace field" being
set as a default ...

Post by Christiaan Hofman

Post by Holger Frauenrath
- I think it is a shortcoming that the "Find" = "Database Search"
commands will display a subset of your references as the result of
the search operation whereas the "Database Search & Replace" command
does not even offer you this as an option.

Maybe the names are a bit misleading, but as for the GUI this is
standard behavior: a Search field filters the item, a Find panel
selects items. In that respect is the naming also appropriate: Search
is normally used for the filter (see eg Mail) and Find for a find
panel. The only problem may be that Find sometimes brings you to the
Search field.

Aha. I was not aware of this distinction. In this specific case, I
must admit that I do not like it (and sticking to this behavior)
either. Of course, one can define two terms to be different but it
only makes sense to use them this way if this is widely accepted. And
in my everyday language, the only difference between search and find
is that the latter sound more positive because it implies a
successful search. :-) Why not call it "Filter" or "Display
Subset" ... anyways.

The more important part is that I would find it useful to also use
more complex searches to display a subset. As suggested, a simple
"Display all" button in the find & replace dialog would do that job.

Post by Christiaan Hofman

Post by Holger Frauenrath
- Finally, I only found out in the recent email communication with
Adam that the scope of the "Database Search & Replace" command is
restricted to the currently active group (and the whole library if it
is selected). While this is perfectly alright and consistent, it was
still unexpected (I would not have asked for it otherwise) for the
simple reason that it is at no point explicitly stated when you
initiate a search. I also think that, for the same reason, it may be
prone to provoke user mistakes.

I'm not sure where to show this information though. Too much
messages, in particular popups, tend to be annoying and cluttering
rather than helpful. I did change the Help in that respect.

Oh, I agree! Please, no popu and other warnings. As suggested (see my
example window) it could be part of the Find & Replace dialog itself,
though. Restricting the scope to the selected references is already
there ...


Thanks for listening.
Holger

[Christiaan Hofman]

[...]

Post by Holger Frauenrath
Again, my point is not that more complex search behavior should be
implemented, in particular not in a GUI based fashion. But what I
would generally find useful (see my actual suggestions) is a closer
relation between searches and Smart Groups. I think it would be
useful to do a search (simple or advanced, if possible also including
regular expressions) and save it into a Smart Group if one likes the
result. A double-click on this Smart Group would then open the
respective search interface again.

I would find it awkward to link the DB F&R panel and smart groups.
Smart groups are much closer to the Search field, as they filter the
items in the database. The panel only selects matches one by one,
which makes it much less useful for searching (as Adam also noted).
Also filtering items by a panel makes no sense to me. The panel is an
independent window, so it should not hide items in another window. If
items are hidden there should be a clear indication for this, e.g. a
selected group or a filter string. The find panel can be hidden. The
search field is inside the window, that's why it can do that. This is
all standard behavior of find panels.

Post by Holger Frauenrath
[...]

Post by Christiaan Hofman
There is no standard, the search menu can be used for any options or
history for searching. What is available there just depends on what
functionality is available and the context. I do think that it is the
right place for search options (where else?) I do agree that Keywords
is not the right default. Also the field to search is shown in the
placeholder, when the search field is not selected.š

Changing the default would definitely help. But as I said in my last
email, I still think that a simple find hould do a no-frills find,
and then there could be a button to a more advanced find interface ...

I don't see a need for an extra interface. As I explained above it
certainly could not be in another window. The search options just add
functionality, which users can ignore if they choose so.

Post by Holger Frauenrath

Post by Christiaan Hofman
Database refers to the scope of the /items/ to search, not the
fields. Allowing to find in any field could be possible, I think,
that would be an RFE. I'm not sure if the "Database" is really the
best, but I find it hard to find a better name. Maybe the option to
add a field is not so much covered by this term, but that was
introduced as a request from a user, and was pretty easy to add to
the interface. The main functionality of the panel though is Find &
Replace, so that part of the name is correct.

As I suggested earlier, I would call it "Advanced Find & Replace".

Advanced Find & Replace suggests a Simple Find & replace, which we do
not have. We have a Simple Search. And the simpler text Find panel is
a different functionality, as it does not work on the items in the
database but on a text view.

Post by Holger Frauenrath
When it is accessed from "Edit" -> "Find" -> "Advanced Find &
Replace", the appropriate defaults should be set.

That would loose the previous edits (even when the pabnel was already
open). Therefore not a good idea.

Post by Holger Frauenrath

Post by Christiaan Hofman

Post by Holger Frauenrath
- In particular, this last function ("Add field") is found only in
places which appear to be obscure to me: the Preferences (setting
default fields) and the "Database Search & Replace" command. And I
never expected them there which is why it took me so long to figure
out how to actually add the group field to my references.

That's mostly because this functionality came as a by-product of
other (main) functionality. In fact, some uses of batch editing, like
using field groups, did not even occur to me until someone mentioned
it on the user list ;)
We could perhaps add menu items to the Publication menu (or should
this be the Edit menu?) for Add Field / Remove Field / Change Field.
The Add Field item can be context sensitive: in a detail editor add
the field, while with the main window selected it can call the Find
panel with the checkbox selected.

I would strongly support the first part. The context sensitive part,
I don't know. As i just said, I think that the same interface may be
accessed from the different places, just the defaults being
different. I do not think that this would be too confusing IF the
dialog is well-structured: after all, if you choose "change fied" or
"replace field" or whatever, you should expect "replace field" being
set as a default ...

I do think Adams remark is relevant, and the biggest obstacle to this
proposal. See also my previous remark.

Post by Holger Frauenrath

Post by Christiaan Hofman

Post by Holger Frauenrath
- I think it is a shortcoming that the "Find" = "Database Search"
commands will display a subset of your references as the result of
the search operation whereas the "Database Search & Replace" command
does not even offer you this as an option.

Maybe the names are a bit misleading, but as for the GUI this is
standard behavior: a Search field filters the item, a Find panel
selects items. In that respect is the naming also appropriate: Search
is normally used for the filter (see eg Mail) and Find for a find
panel. The only problem may be that Find sometimes brings you to the
Search field.

Aha. I was not aware of this distinction. In this specific case, I
must admit that I do not like it (and sticking to this behavior)
either. Of course, one can define two terms to be different but it
only makes sense to use them this way if this is widely accepted. And
in my everyday language, the only difference between search and find
is that the latter sound more positive because it implies a
successful search. :-) Why not call it "Filter" or "Display
Subset" ... anyways.

To call it Search /is/ standard in Apple apps, see e.g. Mail,
iTunes, ... Also the label in the toolbar is Search.

Post by Holger Frauenrath
The more important part is that I would find it useful to also use
more complex searches to display a subset. As suggested, a simple
"Display all" button in the find & replace dialog would do that job.

See my remark above, this is not a good idea.

Post by Holger Frauenrath

Post by Christiaan Hofman

Post by Holger Frauenrath
- Finally, I only found out in the recent email communication with
Adam that the scope of the "Database Search & Replace" command is
restricted to the currently active group (and the whole library if it
is selected). While this is perfectly alright and consistent, it was
still unexpected (I would not have asked for it otherwise) for the
simple reason that it is at no point explicitly stated when you
initiate a search. I also think that, for the same reason, it may be
prone to provoke user mistakes.

I'm not sure where to show this information though. Too much
messages, in particular popups, tend to be annoying and cluttering
rather than helpful. I did change the Help in that respect.

Oh, I agree! Please, no popu and other warnings. As suggested (see my
example window) it could be part of the Find & Replace dialog itself,
though. Restricting the scope to the selected references is already
there ...
Thanks for listening.
Holger

A possible option is to replace the check box by 2 radio buttons.
Also we can group the search options below the text fields the way
Xcode does (see attached screenshot.) though I know Adam doesn't like
the boxes.

Christiaan

[Adam R. Maxwell]

Post by Christiaan Hofman
A possible option is to replace the check box by 2 radio buttons.
Also we can group the search options below the text fields the way
Xcode does (see attached screenshot.) though I know Adam doesn't
like the boxes.

Hey now, I don't mind boxes. I think Mike doesn't like boxes ;).

adam

[Holger Frauenrath]

Post by Christiaan Hofman
I would find it awkward to link the DB F&R panel and smart groups.
Smart groups are much closer to the Search field, as they filter
the items in the database. The panel only selects matches one by
one, which makes it much less useful for searching (as Adam also
noted). Also filtering items by a panel makes no sense to me. The
panel is an independent window, so it should not hide items in
another window. If items are hidden there should be a clear
indication for this, e.g. a selected group or a filter string. The
find panel can be hidden. The search field is inside the window,
that's why it can do that. This is all standard behavior of find
panels.

Hi Christian,

things like these are precisely why I would refrain from making
actual "feature requests" and find a discussion like this one on the
mailing list the appropriate way of dealing with these things. I have
no idea whether implementing any of the suggestions would be possible
at all, or "easy" to do, or require a "hacked solution etc. I am
happy as long as I have the feeling (which I do) that you (the
developers) take the actual issues brought up (not the particular
suggestions) serious and consider it to some degree in the future
development of BibDesk.

I agree or can accept most of the points you made in your email.

Post by Christiaan Hofman
Advanced Find & Replace suggests a Simple Find & replace

I just tried to come up with a better name (because Adam had asked
for it). I, personally, wouldn't say that "Advanced Find & Replace
suggests a Simple Find & replace", but, well, other people may see it
your way and therefore hate that name.

Post by Christiaan Hofman

Post by Holger Frauenrath
Aha. I was not aware of this distinction. In this specific case, I
must admit that I do not like it (and sticking to this behavior)
either. Of course, one can define two terms to be different but it
only makes sense to use them this way if this is widely accepted. And
in my everyday language, the only difference between search and find
is that the latter sound more positive because it implies a
successful search. :-) Why not call it "Filter" or "Display
Subset" ... anyways.

To call it Search /is/ standard in Apple apps, see e.g. Mail,
iTunes, ... Also the label in the toolbar is Search.

I understood that when you explained that distinction the first time.
My point is just that sometimes it does not really matter (to me, as
a user) what Apple defines as a standard (to you, in guidelines for
developers), even when it is used consistently. In my language, the
difference (I mean THAT difference) between search and find did not
exist, and I never concluded from the behavior of other apps that
search = filter, and find = find items. Until you told me, that
*appeared* to me as inconsistent behavior. I would guess that I am
not the only one. Of course, now that I know that this
differentiation exists, I will expect commands to behave like this
according to their names in the future ...

Post by Christiaan Hofman
A possible option is to replace the check box by 2 radio buttons.
Also we can group the search options below the text fields the way
Xcode does (see attached screenshot.) though I know Adam doesn't
like the boxes.

I like your rearranged F&R dialog a lot! I assume that both BibTeX
macro and regular expressions are the alternative choices for textual
(BTW, I did not know whether it would make sense to allow a string to
beBibTeX macro AND a regular expression ... I assumed not ...)!?

Just one little question: would it not make sense to include the
choice "active group" (and select it by default) as alternative to
"entire file" and "selected items", just to make it obvious?

Holger

[Christiaan Hofman]

[...]

Post by Christiaan Hofman
A possible option is to replace the check box by 2 radio buttons.

Post by Christiaan Hofman
Also we can group the search options below the text fields the way
Xcode does (see attached screenshot.) though I know Adam doesn't
like the boxes.

I like your rearranged F&R dialog a lot! I assume that both BibTeX
macro and regular expressions are the alternative choices for textual
(BTW, I did not know whether it would make sense to allow a string to
beBibTeX macro AND a regular expression ... I assumed not ...)!?
Just one little question: would it not make sense to include the
choice "active group" (and select it by default) as alternative to
"entire file" and "selected items", just to make it obvious?
Holger

To avoid confusion: that was a screenshot of Xcode's find panel (for those
who do not have that program), /not/ my proposal for BibDesk. To see my
proposal, download todays nightly. Instead of "entire file" it lists "shown
items", I am open for alternative names. The fact that this is the current
group is in a tool-tip (though I don't think that made it into the nightly.)
I already explained why we don't offer the choice for the entire database;
you can achieve this by selecting the Library group.

Christiaan

[Holger Frauenrath]

Post by Holger Frauenrath
Holger
To avoid confusion: that was a screenshot of Xcode's find panel
(for those who do not have that program), /not/ my proposal for
BibDesk. To see my proposal, download todays nightly. Instead of
"entire file" it lists "shown items", I am open for alternative
names. The fact that this is the current group is in a tool-tip
(though I don't think that made it into the nightly.) I already
explained why we don't offer the choice for the entire database;
you can achieve this by selecting the Library group.
Christiaan

Aha. Sorry to be the source of confusion.

Regards
Holger

[Alexander H. Montgomery]

Post by Holger Frauenrath
[...]

Post by Christiaan Hofman
A possible option is to replace the check box by 2 radio buttons.
Also we can group the search options below the text fields the way
Xcode does (see attached screenshot.) though I know Adam doesn't
like the boxes.

I like your rearranged F&R dialog a lot! I assume that both BibTeX
macro and regular expressions are the alternative choices for textual
(BTW, I did not know whether it would make sense to allow a string to
beBibTeX macro AND a regular expression ... I assumed not ...)!?
Just one little question: would it not make sense to include the
choice "active group" (and select it by default) as alternative to
"entire file" and "selected items", just to make it obvious?
Holger
To avoid confusion: that was a screenshot of Xcode's find panel
(for those who do not have that program), /not/ my proposal for
BibDesk. To see my proposal, download todays nightly. Instead of
"entire file" it lists "shown items", I am open for alternative
names. The fact that this is the current group is in a tool-tip
(though I don't think that made it into the nightly.) I already
explained why we don't offer the choice for the entire database;
you can achieve this by selecting the Library group.

Looks clean to me. Two comments:

First, what does "wrap around" mean, if anything, in this context?

Second, do the "Starts With/Contains/..." still apply if regular
expressions are used? If not, it could be one drop-down instead of two.

Contains
Starts With
Whole Field
Ends With
Regular Expression

-AHM

[Christiaan Hofman]

Post by Alexander H. Montgomery

Post by Holger Frauenrath
[...]

Post by Christiaan Hofman
A possible option is to replace the check box by 2 radio buttons.
Also we can group the search options below the text fields the way
Xcode does (see attached screenshot.) though I know Adam doesn't
like the boxes.

I like your rearranged F&R dialog a lot! I assume that both BibTeX
macro and regular expressions are the alternative choices for textual
(BTW, I did not know whether it would make sense to allow a string to
beBibTeX macro AND a regular expression ... I assumed not ...)!?
Just one little question: would it not make sense to include the
choice "active group" (and select it by default) as alternative to
"entire file" and "selected items", just to make it obvious?
Holger
To avoid confusion: that was a screenshot of Xcode's find panel
(for those who do not have that program), /not/ my proposal for
BibDesk. To see my proposal, download todays nightly. Instead of
"entire file" it lists "shown items", I am open for alternative
names. The fact that this is the current group is in a tool-tip
(though I don't think that made it into the nightly.) I already
explained why we don't offer the choice for the entire database;
you can achieve this by selecting the Library group.

First, what does "wrap around" mean, if anything, in this context?

It means that Find (next and previous) will do a circular search, that is,
after finding the last match it goes back to the first match (or v.v.).
Without that selected, it beeps at the end of the matches.

Second, do the "Starts With/Contains/..." still apply if regular

Post by Alexander H. Montgomery
expressions are used? If not, it could be one drop-down instead of two.
Contains
Starts With
Whole Field
Ends With
Regular Expression
-AHM

It does work with make a difference with regular expresses. We add some
standard regexes when something else but Contains is chosen.

Christiaan