tepickering
commented
4 years ago holy carp! even trying to manage a tenth as many targets between the AORP and observing queue was an enormous hassle. can't even imagine dealing with this...
i give a hearty 👍 to each of @pmilne511's suggestions. in the world of GW event follow-ups, this kind of load should be expected to be the norm and not the exception. there needs to be better operational interaction between the AORP and the observing queue. the current method is way too error-prone. we also need better tools for batch submissions to the AORP as well as batch methods to select from AORP and submit to queue.
bjweiner
dsand
pndaly
pkubanek
pmilne511
srswinde
Monday, Sept 30th was a night full of potential host galaxies of a GW event. This meant that there were 90+ targets in addition to SN/LBV targets. Trying to manage this queue in combination with the non-infrequent system failures led to a hectic night, with subpar efficiency. The multiple kernel panics were a pain, but in this note I mention ideas to improve the utility of the AORP. 1) When a target is sent to the queue (the eye icon), the page returns to default settings. This means that if I have navigated to a page with 3 targets I want to load.....the webpage jumps back to page one/default sorting after each selection. When 90 targets had to be selected, with many on page 9 or 11 or 12.....this led to a LOT of additional clicking. It would be good to preserve the sorting and page number after selecting a target. There can be a default (or reset) button to get back to default. 2) When one uses the upper "next" button to page to the next page, going from page 1 -> 2 leads to a shift....which puts the mouse right over the "logout" button. It makes it too easy to accidentally logout when having to repeatedly (50 times) click from page 1 -> 9 . It would be good to move the logout. button to not be above the "next" button, or to prevent the page jumping when next is clicked. 3) It would be wonderful for the list of records to show if the target is currently in the queue, maybe also showing if it has been observed this session. With a very long list, it is rough to have to keep switching tabs to the web-app page to see if an individual target has been loaded already. Remember that there are 13 pages of targets now and 100 targets were to be loaded tonight. Perhaps there can be a column with a letter or icon showing whether the target is already loaded and/or has been observed.