Hi all, Despite what Christiaan said, I insist that what I suggested would be a good solution. Christiaan seems still not to understand what I suggested. A clear user interface is generally helping the implementation and the implementation should never dominate the UI. As I explained earlier, the user model is what counts at the UI level. The implementation has to follow that.
This means, in the user model of BibDesk we have "Search Group Settings" (SGS) that are identified by a name. The name does not really matter much except that it should the user help to quickly identify the SGS. Each SGS has associated a set of parameters. One is the server and then some server settings. The web services we are talking about here are for WOS or WOK. (The mess Christiaan is mentioning we have "thanks" to Thomson Reuters, who can never decide what they want to call their services. I suggest to use WOK, since from all what I know, this is the most appropriate term to use since about a year.) BibDesk comes with some predefined SGS, one of them giving access to WOK searches authenticating via IP#. Any "Server Settings" associated with a SGS accessing these so-called web services from Thomson Reuters are currently only accessible by using the server setting 'ISI', which corresponds to what Thomson Reuters calls the 'WOKSearchPremium' web service or a bit more abbreviated 'WOKSearch'. The lite variant of that is called by Thomson Reuters 'WOKSearchLite'. From the user model there is nothing more to be added and I can not see why any implementation issue would interfere with this user model. The dialog to view or edit SGS's we are talking about here should fully support this user model. Since you can only make WOK searches either using the WOKSearchPremium or the WOKSearchLite service, but never both at the same time, radio button choice is the best thing you can do in any GUI (exclusive or). A checkbox (boolean) is messy, since you can use that checkbox in combination with any other radio button choice. However, as I showed above, any other combination than with the radio button 'ISI' makes no sense. If you have a checkbox you confuse only the user model, since in general the use of a checkbox together with a set of radio buttons implies always you can make any combination. Finally, it is a little detail how to label the radio buttons. I tried to stick to previous labels, i.e. 'ISI' and added accordingly 'ISI Lite'. I admit that can be questioned and one could argue, it might be better to rename radio button 'ISI' to 'WOK' and have then as the new radio button 'WOK Lite'. I could live with both solutions. Therefore only the radio button choices I suggested make fully sense and are really convincing. I also see not why there should follow from this dialog design any implementation problems, since the dialog is factually modal. I can see that only when you mix implementational details with a GUI design and let the implementation spill into the user model and make that visible at the GUI level. This is never a good idea and only causes user troubles. Good programing can and should IMHO avoid that. Cheers, Andreas On 27/Mar/2014, at 22:43 , Christiaan Hofman wrote: On Mar 27, 2014, at 16:56, Reto Stöckli wrote: How about using the Database field in the search group settings? one can enter either nothing, Premium or Lite? Which is really what it does. Changing Database (subsetting) and changing output style. If you use the WOKSearch Premium, you access a bigger set of the database than when you search WOKSearch Lite. It's not just the number of output fields, it is also the number of retrievals per search. Reto I am a bit hesitant with this. It is probably the quickest and easiest to implement, but it does not really feel like a database setting (i.e. a choice of database). So this would be very counter intuitive. And then there's the conflict with the old way, so backwards compatibility problems. Christiaan ------------------------------------------------------------------------------ _______________________________________________ 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
