When: 7th April 2005
Where: B1, Daresbury Laboratory
Who:
Chris Morris (PIMS project manager) (CM)
Ed Daniels (PIMS user interface designer) (ED)
Geoff Battye (by telephone, MOSFLM interface programmer) (GB)
Peter Briggs (CCP4i programmer) (PJB)
GB's email used as a starting point for the discussions, which were divided into two areas: firstly defining a common icon library for CCP4 applications, and secondly defining a standard for the look and feel for the applications.
GB started by saying that in his email message he had listed different groups of objects, actions and so on which could be usefully represented by icons that could be shared across different applications. A set of well-designed and good-looking icons make a good impression on the user.
It was noted that CCP4MG has its own set of icons however Coot doesn't use any - it has text labels only. [PJB - CCP4i doesn't use icons either.]
CM suggested that harmonisation is desirable and we could start by unilaterally using existing icons from CCP4MG. GB commented that he would be happy to do this provided that they are of sufficiently high quality, and stated the importance of using the best designed icons possible. He then suggested the possibility of hiring a graphic designer to create an icon set. CM said that there is a choice of 2 or 3 consultants who are preferred suppliers to Daresbury, and there followed some discussion of potential costs. It was suggested that it would be of the order of several thousands of pounds. Costs could be cut by using non-professionals (i.e. students).
PB asked if we knew what we need icons of. CM suggested that the mmCIF dictionary could be used as a starting point for possible data items that we might want to manipulate. GB commented that icons could be used for concepts that are useful across all applications, namely
CM noted that within e.g. OpenOffice, icons are used within toolbars, and that there are already existing icon sets and style guides availabel (e.g. Mozilla skins) - the point being that there are plenty of free icon sets available.
GB made two comments: 1) icons could be created by combining symbols for generic operations (for example a "+" symbol to indicate adding something) together with crystallographic object icons. 2) He clarified that graphic designer involvement should be further down the line once we have a good idea of what we actually need.
CM brought another idea, of using a spectrum of colours to distinguish between applications that deal with different parts of the struture determination process (from crystallisation to deposition) and asked what others thought about it. GB wasn't keen on the idea - he commented that generally it is a bad idea to use colour as a discriminator as this causes problems for people with colourblindness, and also he felt that it would probably look rather horrible. He suggested that we should instead use an icon-based approach, with a single icon to represent each application in the same way as Windows applications. These could be colour-coded (for example to distinguish "families" of applications) but colour shouldn't be the key distinguisher.
ED commented that he was also unconvinced by the original idea and CM said he would now abandon it, especially as it requires collaboration from many others and it would be difficult to get buy in from them if he couldn't convince them that it's a good idea.
One suggestion was that the icons should also always appear on modal boxes (e.g. dialogues).
There was some discussion about different paradigms of working, and a contrast between data driven approaches (where the user chooses a data object and selects from possible actions associated with it) and a task driven approach (where the user selects an action to perform, and them selects the data to use in the task). Another point is whether there is genuine uniformity of concepts across all applications in this area - for example, CCP4MG has a concept of a "crystal" (and an icon to represent it) but the same term has different meanings in other parts of the process (for example, a physical crystal inside a drop in a crystallisation experiment, or a "notional" crystal that is solved by a scientist). Where concepts differ they need to be represented by different icons.
The initial question was whether to opt for a "native" look and feel (LNF) for all applications as opposed to some other standard that we could adopt.
GB's preference is for native LNF. ED commented that this might be difficult to achieve given the variation in languages for different applications (Tcl, Java etc). CM voiced a concern that if achieving native LNF incurs a significant developmental overhead (e.g. three months programming time) then it might be difficult for future projects to convince a funding body that this is a worthwhile use of money.
GB acknowledged this and suggested that native LNF should be an ideal, and that 95% of the way there would be good enough. He also noted that Tcl already does a lot of the work in giving a native LNF, and that Linux gives the poorest match (probably because there has been so much divergence in terms of different window managers, that there is no single LNF to aim for). There is ongoing work on supporting native LNF in the next version of Tcl/Tk, with the idea of a "theming engine". CM commented that Java also provides for native LNF.
ED suggested that he preferred using our own consistent LNF rather the native look, in order to reduce the learning curve across all applications. However GB commented that enforcing a consistent non-native LNF could be a technically difficult problem, if we end up fighting against the existing toolkits.
CM suggested that the CCP4 Executive committee could be called upon to enforce the use of LNF guidelines. He also talked about having a style guide that dealt with issues such as common keyboard bindings (e.g. the use of tab & enter can be different in Windows as opposed to Motif applications). GB asked if there are any existing guidelines - CM suggested looking at those for the Java LNF.
CM suggested that these summary notes be circulated to Liz (Potterton) and Paul (Emsley) and then proposed as an item at the next CCP4 Working Group 2 meeting.
GB suggested that we have short discussion documents - or a Wiki, or similar - to look at the two areas discussed at this meeting, namely:
These documents could be used to determine the scope of the guidelines e.g. at the level of individual widgets, or application-wide.
CM proposed that GB publish his icons as a starting point. GB agreed and further commented that the MOSFLM gui has been designed with native look and feel, and so could be used as an example of the pros and cons of taking this approach.