EPICS Home

Experimental Physics and Industrial Control System


 
1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019 
<== Date ==> <== Thread ==>

Subject: Re: Design strategies for CSS BOY screens
From: "Pearson, Matthew R." <pearsonmr@ornl.gov>
To: "tom.cobb@diamond.ac.uk" <tom.cobb@diamond.ac.uk>
Cc: "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Thu, 19 Dec 2013 09:51:02 -0500
Hi Tom,

We're just starting to deploy CSS BOY screens on a few beamlines here at the SNS. On the beamlines we are re-commissioning under EPICS we have started out by developing standalone BOY screens for each device, e.g. a lakeshore controller, or a motor. Then build up more complete 'component' screens from using grouping/linking containers and perhaps the occasional script to build repetitive screens. To get to each component there will be a top level 'synoptic', not too dissimilar from the ones you have at Diamond. These will be the engineering screens for use by controls and expert users/scientists. 

In parallel we are developing more scientific type screens geared towards a particular type of experiment. These are more similar to the GDA type screens at Diamond. These will be the screens which will see most use. The engineering screens will be there for commissioning, setup and debugging.

For the engineering device screens we have a multi-layer approach, typically with a top level read only display, with buttons to drill down to screens that allow changes and display detailed information. For example, we did a new set of motor record screens, in the traditional style (top level, with buttons to open each subset of fields grouped by 'motion', 'calibration' etc.) The buttons replace the current screen, and then the users have to press 'back' to get back to the top level screen. This avoids having too many tabs open at once. However, the choice to use new window or new tabs can be beamline specific to some extent, at least in the beamline specific screens. The users also have the option of right-clicking and opening in the way they want. As you mention, it's also possible to open additional CSS windows, or display different tabs in parallel.

For the some of the device specific screens I was able to make use the MEDM converted screens. But in some cases I have found that either the layout is not ideal, or the colors are messed up, or don't match the default (which is not MEDM grey). So typically we do new screens from scratch, which is not a large amount of work for one device (eg. the motor record, or a particular temperature controller). And using the BOY editor is easy enough.


> Another simple solution would be to use tabs, default action is open in current tab, with an option to open in a new tab. This solves the mess of windows, but all our EDM screens are different sizes, so if we assume a large central area for the current BOY screen, then small screens with only a couple of widgets on them mean rather a lot of wasted space.
> 

If the users need to see multiple different screens open at the same time, on the same display, it might be worth creating a custom screen for that application. Otherwise, for ad-hoc set ups just displaying multiple tabs, or opening multiple CSS windows might be the way to go. Having a lot of wasted space on the screen for a particular device is ok as long you won't need to leave it open, because you're just opening the screen, setting something, then going back to the previous screen.

> So how have other sites designed their BOY screens? Are most of your opi screens similar sizes?

We have lots of different sizes. It's mainly device specific, and each device can have multiple screens with differing levels of detail.

> Do you make use of the various different tear off tabs that eclipse offers you? Do you open multiple windows on multiple workspaces? Do you try to manage how the users perspective should look, or do you leave it to the users to dock their windows where they like?

For non-expert users they will just use a static screen for an experiment (GDA-like). For expert users, some of this is TBD. At the moment we are just giving them the option to do whatever they want. 

> 
> Any feedback/screenshots gratefully received, anything that helps us get better at GUI design has got to be a good thing!
> 

One question I have is how best to share BOY design work. We've created quite a few new sets of screens here, and it would be nice to share them if people are interested. Here are some of the screens we did from scratch (default BOY color scheme):

motor record
lakeshore 336
Agilent E3633A
Sens-Tech HV PSU
Partlow 1800 series controller
TDK Lambda PSU
autosave screens

plus a load of beamline specific or SNS screens (eg. neutron beam choppers).

Cheers,
Matt




Replies:
RE: Design strategies for CSS BOY screens tom.cobb
References:
Design strategies for CSS BOY screens tom.cobb

Navigate by Date:
Prev: RE: areaDetector driver for Point Grey FlyCapture2 SDK? tom.cobb
Next: RE : Design strategies for CSS BOY screens Touchard Dominique
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019 
Navigate by Thread:
Prev: RE: Design strategies for CSS BOY screens kathryn.baker
Next: RE: Design strategies for CSS BOY screens tom.cobb
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019