On Mar 28, 2014, at 4:56, Fischlin Andreas wrote: > 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.
I do understand. I just see it differently, and most definitely the implementation conflicts with this way of seeing it. > 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.) But their web pages seems to say Web of Science, not Web of Knowledge, even if their domain name is webofknowledge.com. And is it WoK, WoS, or WOK, WOS? > 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. But it does. The radio button selects what type of server to use. And the premium and lite version use the same type of server in its implementation. Whether it then uses the premium or lite version is a choice that depends on an option. In both cases you're choosing using the WoK server. Then it is a choice as to how it connects to the server, or if oyu like what type of search you do., I.e. through the premium or lite channel. That's an option of the WoK search group, not a type of search group, as I see it. > 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. > That's false. The check box is only there for the ISI group. Just as the address field is only there for the z39.50 group. > 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 > You see premium and lite as two basically completely unrelated types of search servers. I see it as the same type of search servers, but with an extra option telling it how to search. Just like for Zoom you have to say which server address to use, here you have to say whether to use the premium or lite channel. So it's a subchoice. I don think that makes sense for most users, they know they want to search WOK, they won't see WOK and WOK Lite as two different types of search servers. Quite frankly, I think WOK and WOK Lite are much more the same than, say, Library of Congress and Harvard. The latter are the same type (zoom), wo why not the former? I think that absolutely makes sense. The different choices for the radio buttons describe completely different protocols for the servers, i.e. completely different types of servers. That is also directly associated with the implementation: we use completely different server classes for the different types. The WOK servers are basically the same protocol, they just use some different settings (like the address.) They (will) also use the same server class in the implementation. Christiaan > > 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 > Bibdesk-develop@lists.sourceforge.net<mailto:Bibdesk-develop@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bibdesk-develop mailing list > Bibdesk-develop@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bibdesk-develop Christiaan
------------------------------------------------------------------------------
_______________________________________________ Bibdesk-develop mailing list Bibdesk-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
