A lot of information is required from the user to make up a request for robot service. The method provided by the Web software to allow users to make choices or enter text is the HTML form, which provides screen widgets enabling several different methods of selecting or entering information: single and multiple line text input, tick boxes, radio button groups, select lists, pull-down select lists and regular buttons. An example of a simple form is the Google search engine home page (Google n.d. b). It provides a single line text entry field for the user to enter the search terms, two buttons to execute the search and two radio buttons to select the scope of the search – the whole Web or pages within the user's own country. It is an example of a clean and simple Web form with not too many input fields and buttons to make the form appear complicated. In addition, the buttons and radio buttons can be ignored by the user, since the form uses reasonable defaults if the user simply enters text in the search terms field and presses the enter key. An example of a complicated search form is the Oxford University Press journal search
system (Oxford University Press n.d.), containing several text boxes, radio buttons, drop down lists and a multiple select list. So complicated is the system that it links to an extensive help page on how to use it, however, the system is designed for researchers performing precise journal queries – a task where a certain level of complexity is accepted in order to provide a high degree of control to the user. A small survey of shopping and news Web sites in 2009 reveals the common aspect of an independent search facility, but all those surveyed implemented the same simple usage method as the Google example, with just one text input box to be filled in. It appears commonplace to have a search system on such Web sites, but one which performs any data manipulation and search intelligence without the need for further user input. Keeping it simple for the user reduces user control, but at least avoids the situation where the usage is so complicated it prevents some from interacting with it at all, such as with the VCR clock problem.
The request constructor interface must support novice users wanting basic observations – presenting them with easy to understand point and click options. It should also be able to support amateur astronomers wanting to specify all the details themselves. It should ask questions of the user in an intelligent order, omitting later questions made irrelevant by earlier ones, and for all users, all options and input fields should be presented using the most appropriate and user-friendly widget made available by HTML.
It is important for good usability to not overwhelm the user with too many form inputs on a single page, and also to select the most appropriate data input widget for each question the Web site asks. In order to not flood the user with options and also to implement the intelligent selection of questions, the Web pages for submitting a job are split into different sections using a wizard-like interface which guides the user through
the different sections if they are relevant.
The three parts of the interface presented to all users guide the user through the process of constructing a request. A summary page of the request so far is presented immediately to the user and shows all the possible fields, split into the three sections. However, only the first section offers the user the option to change any parameters – the first section is entitled “What to observe”. By entering this section the user is first presented with a list of categories of stellar objects to choose from. The categories are: Constellations, the moon and planets, well known galaxies and nebulae, Messier objects (Students for the Exploration and Development of Space 2008), catalogue objects from the SAO (SAO Staff 1966), NGC (Sulentic & Tifft 1973) or IC (Dreyer 1895) catalogues and finally, manually entered co-ordinates. For each category the user is taken to a new page with a specific method of entering an object choice relevant to that category. For example, the solar system body option presents a list of the known bodies in the solar system starting with the moon, and then the planets. The user simply needs to click on the object they wish to observe. The Smithsonian Astrophysical Observatory (SAO) catalogue option takes the user to a page with just a text-entry field on it, in which the user is expected to enter an SAO catalogue number. This page need not offer lots of help or display the list of SAO objects (which would be very difficult as it contains over a quarter of a million objects), as if a user decided to select their object by its SAO number they are most likely a user who knows exactly what they want to observe. They are very likely to be an amateur astronomer who already possesses SAO catalogue information and would not need to be hampered by any Web pages attempting to be helpful – all they require is to supply the SAO identification number to the Web site.
simple such as the selection of the Moon, and some complex such as the entry of astronomical right-ascension and declination co-ordinates. Novice users can point and click on friendly object names they will recognise, and amateur astronomers have all the options through to entering co-ordinates manually.
Once the user has selected an object to observe they are taken back to the summary page, this time with the first section filled in with their target object. In addition, from the choice of object supplied, the system guesses at the camera to be used for the observation. For example, if the user selected a constellation, the wide field
Figure 14: Request builder Web page flow diagram
Main request builder summ ary
Part 2 – selec t a telesc ope
Part 3 – fill in other Details: exposure tim e,
filter selec tion
If all other sec tions are c om plete, submit request
Each box represents one Web page. Part 2 is only available after part 1 has been visited. Part 3 is available after part 2 has been visited. The option to submit a request becomes available after all the other parts have been visited. Once any part becomes available it can be visited as many times as the user wishes and in any order.
Part 1 – selec t a target objec t type
Selec t a... Messier objec t
Selec t a... c onstellation
Selec t a... well known galaxy,
nebula or c luster Selec t a... moon or planet
Selec t a... SAO c atalogue objec t
Selec t a... NGC c atalogue objec t
Selec t a... IC c atalogue objec t
Input direc t RA/DEC c o-ordinates
constellation camera will be selected; if the user selected a galaxy the main telescope camera will be selected. At this point the user can either accept the system's choice of camera by entering section three, or they can override the system's choice by entering section two and selecting a camera manually.
Back at the summary page, whether the user did or did not manually choose a camera, the only section left to fill in is the extra details section. Within this section the user can enter an exposure duration, select whether the image should have a dark frame applied, select a filter or a combination of filters to acquire a colour image and they can enter a comment about the job. While these options might at first seem complicated, only exposure duration and filter selection actually require the user's attention. Help is provided on the page with recommendations for exposure time, and the filter selection
must be done by the user because there is no way for the system to guess what might be appropriate. It does however limit the available filter choices to the only ones available since the available filters depends on which camera is selected – it can do this because the user has already selected a camera in a previous section and that information was stored by the Web application. One final return to the summary page shows the complete request, at which point a new option appears – to submit the request to the robot.
There is a fourth section to the job request interface which is only shown to administrators of the site. This part allows particular users to set parameters for the request which should not be available to all users, for example the immediate flag, which instructs the scheduler to pass the request to the robot before any other request as long as the job is physically possible. If all users were allowed to set this flag, inevitably some of them would, and would gain an unfair advantage over those who did not. Other fields in this section allow administrators to indicate to the scheduler a desired time for the observation to be made, the number of images which should be taken for the job including the interval between those images, and a free-form text field for engineering purposes. This is a particularly interesting field for the system developers because any textual data can be placed in it, and it will be transmitted all the way through the system to the robot itself and back. Any part of the system can scan the engineering field for specific instructions and act accordingly, allowing the system developers to invoke specific behaviour per job, or to test new code and behaviour, whist still running the normal system code for regular jobs. This saves telescope observing time by eliminating start-up, initialisation and shut-down time for new software tests.
The page-based nature of the Web is used to the interface's benefit on the pages that deal with creating a job request. The process is split into sections, with one or more Web
pages making up each section. The data entered into each page is submitted as an HTML form back to the Web server when the user clicks on the “save” button – this enables the system to check the validity of the input and query the user if there are any problems, but also the system saves the input in a temporary area until all sections have been filled in satisfactorily, and the user submits the request. Because further pages of the request submission process can refer to the answers provided earlier, they can tailor their questions to match, eliminating any which have become irrelevant. The request constructor pages also enforce the security considerations involved with creating a request for service. Each time data is submitted from one of the pages it is checked before being saved, for example, the SAO entry is a free-form text box expecting a number – if something other than a number, or an invalid number for the SAO catalogue is entered then the system will not save the input. Other fields are checked to steer users into generating better requests in order to avoid wasting user and telescope time. For example, when the Moon is selected as the target object and the main telescope is selected to take the image, the section of the request constructor dealing with exposure times will enforce a much lower limit for the maximum exposure time because higher values will almost certainly saturate the camera and produce useless images.