Argonne National Laboratory

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: Emma Shepherd <Emma.Shepherd@synchrotron.org.au>
To: "tom.cobb@diamond.ac.uk" <tom.cobb@diamond.ac.uk>, "tech-talk@aps.anl.gov" <tech-talk@aps.anl.gov>
Date: Wed, 18 Dec 2013 22:37:10 +0000
Hi Tom,

As you know we're using Qt, not BOY.  However we're going down much the same EDM replacement path at the moment and tackling very similar problems so I thought I'd share our thoughts with you anyway.

Our solution is still very much a work in progress, but we're starting to settle on some design principles.  We've gone for a tabbed display for the beamline synoptic, with one tab per component (e.g. a DCM).  However, we're trying to keep it as flexible as possible so the tabs are 'dockable' and can be moved out into separate windows if desired.  A recent development in the epicsqt framework is to allow window configurations to be saved, so that beamlines can come up with their own customized layout.  It is also possible for layouts to be 'locked' so that users can't mess around with them too much!  We decided this kind of approach was best as it's impossible to satisfy everyone's requirements otherwise...

I completely agree with your point about having multiple copies of EDM windows everywhere and not being able to find anything, it's very frustrating.  In our solution, configuration screens e.g. for the motor record will open up as separate windows, but there is at least a 'Windows' menu in the application so you can see what is open and bring something to the front if it is minimized.

Good luck!  I'd be interested to see what you come up with.

Emma


> -----Original Message-----
> From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-
> bounces@aps.anl.gov] On Behalf Of tom.cobb@diamond.ac.uk
> Sent: Thursday, 19 December 2013 3:38 AM
> To: tech-talk@aps.anl.gov
> Subject: Design strategies for CSS BOY screens
> 
> Hi all,
> 
> We're currently evaluating CSS and BOY as an EDM replacement, and I am
> considering how display screens on beamlines might look in this
> framework.
> 
> Currently we have an EDM "Synoptic" view of the beamline, with icons
> that show the status of each component on the beamline. Clicking on one
> of these icons brings up a summary screen for the objects that make up
> the component (motors, temperatures, diode readings, etc.) These
> summary screens are mainly auto-generated from tags in the EPICS
> database, but a significant minority are manually created. Clicking
> through from one of the summary screens takes you to manually created
> detailed screens for that object.
> 
> All of this means that a typical desktop might look like this:
> http://controls.diamond.ac.uk/downloads/other/files/EDMScreenShot.png
> 
> Multiply this by 4 monitors and 8 Linux workspaces and users have an
> awful lot of screen real estate to get lost in. The main synoptic
> typically gets buried in the background, so the users open another one,
> then you have multiple copies of everything and can never find what
> you're looking for.
> 
> Now the simplistic approach when converting to CSS BOY would be to
> translate every EDM screen into a BOY screen, launched in its own
> window. But then we aren't really solving any problems, we're just
> making BOY look like EDM, and it takes a lot of work to persuade
> eclipse not to put toolbars everywhere...
> 
> 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.
> 
> So how have other sites designed their BOY screens? Are most of your
> opi screens similar sizes? 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?
> 
> Any feedback/screenshots gratefully received, anything that helps us
> get better at GUI design has got to be a good thing!
> 
> Thanks,
> Tom Cobb
> 
> --
> This e-mail and any attachments may contain confidential, copyright and
> or privileged material, and are for the use of the intended addressee
> only. If you are not the intended addressee or an authorised recipient
> of the addressee please notify us of receipt by returning the e-mail
> and do not use, copy, retain, distribute or disclose the information in
> or attached to the e-mail.
> Any opinions expressed within this e-mail are those of the individual
> and not necessarily of Diamond Light Source Ltd.
> Diamond Light Source Ltd. cannot guarantee that this e-mail or any
> attachments are free from viruses and we cannot accept liability for
> any damage which you may sustain as a result of software viruses which
> may be transmitted in or with the message.
> Diamond Light Source Limited (company no. 4375679). Registered in
> England and Wales with its registered office at Diamond House, Harwell
> Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United
> Kingdom
> 
> 
> 
> 



Replies:
RE: Design strategies for CSS BOY screens Sinclair, John William
References:
Design strategies for CSS BOY screens tom.cobb

Navigate by Date:
Prev: RE: Design strategies for CSS BOY screens John Dobbins
Next: RE: Design strategies for CSS BOY screens Emmanuel Mayssat
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 John Dobbins
Next: RE: Design strategies for CSS BOY screens Sinclair, John William
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 
ANJ, 20 Apr 2015 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·