Andreas The attachment worked both times. I would also favor to have it in the search group settings as you have sketched it in your e-mail.
Regarding the database: - The WOK Options are more complex than offered by Bibdesk at the moment. One can choose the database (such as WOK or WOS), then the collection for this database (such as WOS, BIOABS, etc.), and then the edition of the database (such as SCI, SSCI etc.). - Normally the collection has the same name as the database. - If you enter a search term in the web version, the database is set to WOS and collection and edition are not set. This searches all WOS entries. I've tried to mimick this in Bibdesk by also not setting the database collection and edition. The group setting "database" is thus actually the "edition" of the WOK database. I will check if I can re-implement the collection/edition search option by searching all databases of WOK when the user leaves the group setting database empty. Reto On Mar 27, 2014, at 3:17 PM, Fischlin Andreas wrote: > Dear Christiaan, > > I do not believe you understood what I wrote. > > On 27/Mar/2014, at 14:49 , Christiaan Hofman wrote: > > > On Mar 26, 2014, at 11:56, Fischlin Andreas wrote: > >> I am not convinced fall back is the only thing to too. That may be fine for >> a casual user, but a regular user knows which service his/her institution >> has and would therefore profit from being able to set the type of expected >> service in the settings. For those users I also believe that the service not >> being available is more likely to be merely due to an authentication error, >> but I guess the new interface allows to distinguish that case. >> >> To wrap up, my suggestion is if one WOKSearchPremium is not available (and >> any other cause than no subscription could be ruled out), then the fall back >> could be done by testing only the availability of WOLSearchLite service, and >> if WOLSearchLite is available then asking the user, whether she/he wants to >> change the preference accordingly. Actual searches and data retrieval would >> always only be done according to the settings. >> >> Regards, >> Andreas >> > > I don't think this i a good solution. there is no way to revert this, you're > locked in. But your situation can change. > > No, with my solution there would be no locked in. > > > Perhaps we can add a "Lite" option in the search group settings, set by a > check box in the empty space between the database and username, as in the > attached screen shot. > > No, not a good place. My suggested location in my previous mail just below > the 'ISI' radio button is better, because it does relate that Lite checkbox > with the radio button choice "ISI" that it is associated with. I believe your > suggested location would be quite confusing for users and you need to know a > lot to be able to relate this 'Lite' checkbox with the ISI radio button. > Therefore, if a checkbox, then only just below the 'ISI' radio button (as I > have suggested in my previous e-mail). > > I personally would prefer the two radio button solution, i.e. 'ISI' and 'ISI > Lite'. No checkbox. This seems to me to be the clearest solution, from which > I would expect every user to immediately understand it and have a clue what > this option is all about. No additional help needed: > > [cid:[email protected]] > > My suggestions with a "fallback" testing of the Lite service in case the > Premium one fails, would only happen IN ADDITION to the preference setting > with the two radio buttons given above. Therefore no lock in, and you would > get asked as a user that BibDesk would change the settings for you. Next time > you visit above settings dialog window, you would see that BibDesk would have > switched the service from 'ISI' to 'ISI Lite'. But note, IMHO, that feature > would be only nice to have and by no means necessary in any way. I wanted > only to say that in my view that would be the only good place where to such a > fallback algorithm as suggested by Reto would be useful. My main reason being > mostly efficiency reasons. > > My suggestion for the default is however, for backward compatibility reasons, > radio button 'ISI' is default for the factory defined 'Web Of Science SCI' > setting. > > > There is also the question of the database. It seems this son't be used > anymore, but is that what we want? Or would we support restrictions to the > editions to search? This could perhaps also be a space-seprated list of IDs, > and empty or some default value like WOS to search all editions. Though I am > not sure about backward compatibility. > > Andreas > > > Christiaan > > <Screen shot 2014-03-27 at 14.44.02.png> > > >> >> On 26/Mar/2014, at 10:01 , Reto Stöckli wrote: >> >> Sorry, I mean search group settings. However, the automatic fall-back >> solution to WOKSearchlite in the case of an error is also intriguing and I >> will check out that solution first. >> >> Reto >> >> On Mar 25, 2014, at 11:53 PM, Adam R. Maxwell wrote: >> >> >> On Mar 25, 2014, at 15:12 , Christiaan Hofman >> <[email protected]<mailto:[email protected]>> wrote: >> >> >> On Mar 25, 2014, at 20:53, Reto Stöckli wrote: >> >> One more thing. >> >> If you can propagate a flag from the Search GUI (by means of a >> user-accessible button) into BDSKISIGroupServer.m indicating whether the >> user would like to use WOKSearch or WOKSearchLite, then I can also implement >> the WOKSearchLite SOAP decoding. Most users do not have the full WOKSearch >> access since Thomson Reuters charges extra for it since about one year. >> >> Reto >> >> >> I don't think we should do this from the search UI, it messes it up and it's >> not really an individual search setting. If anything, it should be in the UI >> for the search group settings. Though it would need a special UI only for >> this search type, which is annoying. As we're not using the database anymore >> (is that really true, is it not useful anymore?) we may perhaps appropriate >> that for a "Lite" setting? >> >> Agree, this should not be set from the search UI itself. It sounds like it >> should be a separate search group that should be predefined along with the >> basic WoS search, unless there's an error message from SOAP that would tell >> you to fall back to WOKSearchLite transparently. >> >> Adam >> > > ------------------------------------------------------------------------------ > _______________________________________________ > Bibdesk-develop mailing list > [email protected]<mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > > ------------------------------------------------------------------------------ > _______________________________________________ > Bibdesk-develop mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop ------------------------------------------------------------------------------ _______________________________________________ Bibdesk-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
