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
Several distinct areas of effort remain unfinished, and must be completed before the DEIMOS GUI can be delivered:
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:
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.
Noted.
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.
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.
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.
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.
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.
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.
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.
Noted.
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.
No.
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.
Sorry, no. Not worth the effort.
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.
Noted and fixed.
Moot, see above: subsequent discussion called into question the entire notion of direct moves, and the subpanels will be made "safe".
Probably not. There was support for turning the entire label red, for example, to draw more attention to the anomaly.
Noted. We'll label the buttons more explicitly; also, the panel will no longer do immediate moves (see above).
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.
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.
Yes. Engineers will also be able to cook up their own GUI on the spot.
No.
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.
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.
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.
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.
Noted. We have always intended to support this, and De plans to implement it in the next release of Dashboard.
Noted.
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.
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.
Noted.
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?
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.
Moot. They will be disabled altogether (see above).
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.
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.
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?
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).
Nice idea, but another attendee said:
So we'll have to think some more about whether calibration activity should be accessible from the stock GUI. Taken under consideration.
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.
Like a subpanel? But another attendee said:
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.
phillips@ucolick.org (Drew Phillips)