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
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- 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
<2013>
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|