RE: Design strategies for CSS BOY screens

[<kathryn.baker@stfc.ac.uk>]

Hi Tom and others,

This was most certainly a timely request. We are just starting out in ISIS, so aren't converting from EDM, but we are using CSS-BOY for our displays at the moment, and have implemented synoptic views. I've put an image on our external website, if it doesn't show when you look, it may just need trying again as it won't be published until later, but should be viewable via http://www.isis.stfc.ac.uk/groups/computing/Research/Research14695.html I believe in time (I'll try and keep checking and if needs be put the image somewhere else, or can email it on request).

We actually have an auto-generated synoptic view, in CSS, based on an XML file. This specifies the type of item to include in which order, and a few other useful things. The synoptic view we have scrolls to allow for the fact that some beamlines are longer than others. Also, clicking on the icons we have used in our synoptic view then loads the next level down, so clicking on a slit set icon open the appropriate opi which displays a bit more information, and the system can go from there to the individual motors. If you aren't at the top level then we have navigation buttons available to help you move through the beamline, or go back up a stage. A lot of good work has been done by the person who has coded this (which wasn't me) to make it adaptable and generic.

I don't know if my description makes sense, and I know that until the screenshot is available it will make even less sense, but I thought our synoptic view combined with other OPIs (we are still agreeing on behaviour for OPIs not part of the synoptic view, and should be able to tell you soon what we do with those components) might be of interest to others.

Kathryn


-----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: 18 December 2013 16:38
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
 




-- 
Scanned by iCritical.