DEIMOS GUI DAY : Summary and Responses

Lick Observatory

A. C. Phillips (DEIMOS UI Designer)

D. A. Clarke (Dashboard Software Author)


On Dec 16, 1997, a select group of astronomers and scientists was invited to Lick Observatory for a preview and review of the DEIMOS instrument GUI design. The UI was sufficiently complete that a working version using a simulated instrument was available for live demonstrations. During the course of the day, attendees were encouraged to make comments and suggestions, which were collected by various formal and informal means and reviewed following the event.

We feel that the DEIMOS GUI Demo Day went well. We obtained valuable feedback from the attendees, and we hope that the materials and discussion were interesting and valuable to them as well. In general, our conclusions were that the selected audience

  1. liked the overall design philosophy and found the GUI relatively easy to understand and use
  2. had relatively few objections to specific design features and decisions such as layout, colour use, labelling, etc.
  3. offered many good suggestions for extension of the GUI, especially requesting even more ease of use, greater "intelligence" in the UI, and more sophisticated interaction with other Keck systems.
We'd like to thank everyone who took the time to attend and assert their opinions. If you need a review of the top-level GUI design, see Drew's DEIMOS GUI page, whence you can also download the manual in colour PostScript form.

Several distinct areas of effort remain unfinished, and must be completed before the DEIMOS GUI can be delivered:

  1. The CCD subsystem control panel must be designed and implemented (not all DEIMOS CCD keywords are specified yet)
  2. The rotator subsystem interface must be designed and implemented (requires interaction with CARA)
  3. Several related design issues must be resolved regarding the inclusion of non-DEIMOS service access (DCS, guider) in the DEIMOS UI (requires interaction with CARA)
  4. A checklist of minor bugfixes and enhancements must be cleared
  5. Unresolved issues of procedure and interface design for instrument calibration must be resolved, and the calibration UI designed and implemented

The rest of this document is our (Lick's) detailed response to the feedback we received that day. Feedback and commentary fell into several distinct areas:

Apart from grouping into these areas, the commentary is not in any particular order.

Comments/questions are listed below under these six categories, with responses. If the response is "Noted," that means the item has been added to the TODO list for the GUI (unless further explicatory text is appended). "Taken under consideration," means we will investigate, but are not yet willing to promise we can do it.

If our notes indicate that we think a new feature would be difficult to implement, you should estimate the probability of its inclusion at commissioning as having some inverse proportional relation to the level of difficulty :-) If you feel very strongly about a "difficult" or "expensive" feature, we invite you to send mail to us and to Dr Faber, making the case for the general utility and value of the feature. If we completely omitted one of your concerns or comments, let us know; we'll add it to the document.

A summary section appears at the end of this document.

Our thanks to S Faber and R Kibrick for detailed note taking.

Look-n-Feel Comments/Questions

  • Deltas on the Focus Discipline subpanel should be more distinctively labelled. The global delta should be called Global Delta.


  • The UPDATE CCD button on the main panel should be labelled UPDATE THIS EXPOSURE instead, to make it clear that changes will affect the current exposure

    Taken under consideration. That's a long label, posing some real estate problem, but we see why the point was raised and will try to address it.

  • Use serif fonts for greater legibility

    We tried this after the event. Though Tufte's assessment of the relative legibility of serif vs sanserif fonts (that serif is better) is valid for high-resolution printed matter, we find that on limited-resolution video screens the serif fonts look, frankly, awful. Everyone to whom we showed the serif version disliked it. So at this point we disagree, and feel that in the specific environment of an X11 display, sanserif fonts turn out to be more legible.

  • Use colours in the reddish range for greater visibility

    The display is built with "warm" colours partly for this reason. We feel we're already complying with this general guideline, and have tried to minimize the importance of blue/green elements.

  • Use the largest font size that will fit in the boxes

    The entry boxes size themselves according to the font selected, so they are already doing this. We've used the largest fonts we can fit into the real estate.

  • Yellow vs Gold (like the Go button) is not a clearly visible distinction for some viewers

    Noted. We're working on better distinctiveness of "button is active" vs "button is responding to mouse". Also better consistency between the various buttons, menus, etc.

  • Units should be shown, not just quantities.

    Another real estate issue, but one which might be solved by using a small font for the units. Presumably people would only need to peer at them once or twice before becoming comfortable and familiar. On the other hand, small fonts are hard to read and clutter up the display. Units should always be shown on the detail popup panels, in a nice legible font size. It may be sufficient, if the user needs a reminder, to popup the detail panel and take a quick look at the units.

  • SET button on subpanels should have a better name.

    I think subsequent discussion was that SET was the right name for any button causing an immediate move. However, other discussion indicated that immediate move might be a bad idea entirely. At this point we are planning to get rid of immediate moves altogether, which renders some other comments moot as well. Note: this abolition of immediate moves affects only the DEIMOS end-user interface; engineering interfaces of course will continue to offer immediate moves. Also, the LAMPS control should probably retain immediacy.

  • CLEAR DESIRED should say RESET DESIRED instead.


  • The OBJECT keyword blank should be Courier and exactly 68 char in length, to make it clear that input should not execeed this length

    Taken under consideration. This would make this entry blank longer than will fit gracefully in the real estate available. Another option would to truncate the user's input to 68 char, with an informative warning message; or, alternately, to generate COMMENT cards preserving the full text.

  • Can we make text blink?


  • Cursor should change to a stopwatch when "a command has been received and is executing".

    We presume this means a stage move command, and we disagree. The interface is alive and responsive during all stage movements, and it would be misleading to indicate that it was busy. The motion of stages is indicated by their shifting out of position in the light path. Cursor changing to a stopwatch or other "time indicator" should always, and only, mean that the application is busy.

  • Can only the active portion of the CCD mosaic icon light up in colour during exposure?

    Sorry, no. Not worth the effort.

  • It's confusing that the desired value for CCROTYPE is visible, but the desired value for OBSTYPE is not, though they are set using the same menu.

    Noted. We had doubts about this ourselves. We will make the desired value of OBSTYPE visible, preferably in the same box with CCROTYPE. The current value of OBSTYPE is visible below the Expose button.

  • Actual value boxes should not highlight text as if they were active.

    Noted and fixed.

  • Subpanels offering direct moves should have bright scary coloured frames to indicate they are dangerous.

    Moot, see above: subsequent discussion called into question the entire notion of direct moves, and the subpanels will be made "safe".

  • Is the question mark at the end of the constructed object name really enough to mark an anomalous setup?

    Probably not. There was support for turning the entire label red, for example, to draw more attention to the anomaly.

  • The filter/focus panel labels are confusing: it's not clear that the filter names are really buttons and that they select filters, etc.

    Noted. We'll label the buttons more explicitly; also, the panel will no longer do immediate moves (see above).

    Layout Comments and Questions

  • It's misleading for the grating to drop out of the light path when Mirror is selected: light should bounce off the mirror.

    Opinion seemed to be divided on this one. It wouldn't be that hard to make the light deviate and bounce off the mirror, but there doesn't seem to be a strong enough consensus on this one to change the layout.

  • There should be a rectangle at the left end of the light path indicating basic dome and telescope status.

    Not sure how we can package this into the available real estate, but it is a good idea. If the CCD detector temperature meter goes away, as was suggested at one point during discussion, then there is a fair amount of screen space to work with at the left edge.

    General function and use

  • What about engineering use? will there be an engineering GUI with more detail and different functions?

    Yes. Engineers will also be able to cook up their own GUI on the spot.

  • Can desired values be left blank?


  • Want more than one custom readout type.

    Under consideration. We agree that this is a reasonable thing to want. We're thinking about how to provide it as simply as possible. Drew's original plan was a blank into which you can type the name of a file you have edited which describes your custom readout. This still looks like a good approach. Whether we can get "your favourite custom readouts" into the CCROTYPE/OBSTYPE pulldown menu is another matter! It might be too expensive for the general utility of the feature. See Drew's email to De for more detail.

  • How do I select slow/fast (biamped or not) readout?

    We don't know yet. However, the detail CCD subpanel will have all kinds of options like gain adjustment, fast/slow readout, binning, number of amplifiers to use, etc. This panel had not been designed at the time of the review, but we do have a list of most of the controls it should include. Choosing certain readout types, like alignments or focus frames, might cause automatic gain settings for faster readout.

  • Can users be given access to a demo version for training and observation planning?

    Noted. Good question. We discussed the possibility of Web-based access, and the difficulties of distributing a fairly large code package to multiple sites. It's not a simple problem, unfortunately. See Steve Allen's email to De on this subject for some of the grisly details, security considerations, etc.

  • Can I create setups in advance?

    Yes. A setup is a simple text file. You could edit several of them and bring them all along for your run. By commissioning time, we will know the exact format of these files and will publish samples on the DEIMOS Web pages.

  • Can I extract setup from an existing FITS header?

    Noted. We have always intended to support this, and De plans to implement it in the next release of Dashboard.

  • Dither patterns shouldn't be hardwired. The user will want to create them.


  • I want to be able to plot seeing over time (DCS data) and snapshot the plot to a file.

    We can provide a detailed subpanel for DCS data, one of whose options could be a pushbutton that popped up such a plot. The snapshot, however, is currently PostScript. Do users want a data snapshot instead/as well? However, this functionality really belongs on the Guider GUI, see below. We don't think that the DEIMOS UI is an appropriate place for it.

  • What we really need is a subpanel enabling the user to specify parameters to be plotted.

    Like a watered-down version of the engineering interface? We can probably provide this. De thinks that a subpanel offering the user the option to plot one or more of (perhaps) a set of supported keywords would not be difficult to construct. Taken under consideration.

  • We need a COMMENTS box for entering COMMENT cards. It should permit multi-line editing.


  • Want to set keywords WANTRA WANTDEC from DCS, if we are not allowed to set TARGRA and TARGDEC.

    If we can see DCS service, we can see/set any of its keywords. The problem with TARGRA and TARGDEC (and MOVETEL) is a procedural/political one. These two WANT keywords were proposed as a workaround; the observer could set these "intentions" and another keyword could be set by the OA to confirm them and initiate the move. This is not strictly speaking a GUI issue, except that if these keywords existed then it would be nice to see them on the DEIMOS main panel. This should be discussed with the DCS maintainers, as we can't add keywords to that service; it belongs to CARA. Do we also require WANTAZ and WANTEL? How about WANTPA?

  • The STOP exposure button should pop up a menu with three choices:
    1. Readout Now
    2. Abort/Discard Exposure
    3. Resume Exposure
    instead of the current method of label changes, which is insufficiently solicitous of the image's safety.

    Noted. Only one test user disagrees strongly. We will probably go ahead and implement this. However, we see no point in having an "are you sure" mechanism of this kind if Abort is requested during the Erase cycle. This menu should only appear if there is an exposure to be saved.

    Ease of Use, Intelligence

  • Direct moves should be disabled during exposure

    Moot. They will be disabled altogether (see above).

  • If I pick the longslit from the mask menu, the CCDROTYPE should automatically change.

    Taken under consideration. There are other dependencies which could/should be enforced likewise, and it's a good idea. However, there's potential conflict with the Custom readout types, so we'd have to resolve that problem before promising the feature.

  • If the interface is idle for too long (not exposing, no activity) some kind of alarm ought to go off to wake up the observer.

    Taken under consideration. If this is easy to do, it's a good idea (says De; Drew disagrees). If it's expensive, it won't happen without a directive from the instrument PI.

  • There should be an audible alarm when all the stages have stopped moving and we're ready to expose.

    Taken under consideration. It's somewhat difficult to figure out how to do this as described, we'll give it some more thought. If what is really meant is "sound an alarm when light is reaching the CCD", that's much easier, almost trivial. But do we want the application to be that noisy?

  • Want to provide multiple setups (mega-scripts) so that a whole sequence of observations can be automated.

    Taken under consideration. We think it's a great idea, just not sure exactly how we will implement. Mega-scripts (for calibration, for example) might be implemented in a separate interface (see below).

  • Want a subpanel for calibration activities, offering canned calibration scripts.

    Nice idea, but another attendee said:

  • Calibration tools should be a separate application altogether.

    So we'll have to think some more about whether calibration activity should be accessible from the stock GUI. Taken under consideration.

  • Saved setups should save telescope position, PA, guide star coords and so forth, so observer can easily reproduce an observation.

    Noted. Strong agreement. This request is less simple than it sounds (Drew has concerns about RA-Dec vs alt-az coordinates, acquisition of guide stars during daylight, etc). "Reacquiring" a position means different things to different observers. There are also issues of demarcation here (OA has DCS control by tradition). But we'll implement this as best we can within these kinds of constraints.


  • Should be a separate window, showing focus, filter, exposure time, co-adds, image manipulations in force.

    Like a subpanel? But another attendee said:

  • Should be a separate stripped-down copy of the GUI, very simple, dedicated to TV control.

    The issues around the Keck TV Guider, its status, and the politics of who controls the guider, are too deep for us to address here. S. Faber undertook to find out the current status of the project and to encourage Keck to hold a review for the GUI. We should wait to hear the outcome of this effort before making decisions about the inclusion of guider interface components in the DEIMOS GUI. (Drew Phillips) (De Clarke)
    UCO/Lick Observatory
    University of California
    Santa Cruz, CA 95064
    Fax: +1 408 454 9863