Well, I'm happy to report Floris saw the light so DIAL will get an XML interface as well. Which means I can gladly forget about the whole YAML business. It also means there are no obstacles to using .Net, so I'll be spending the next three months working with the tools I like best. :)

Now might be a good time to give an overview of what I'm doing. As I said before, I'm working on a GUI for the DIAL genomics database. DIAL is a database that biologists can use for storing and processing DNA microarray data. As I said yesterday, there are currently four ways to interact with the server: perl, command-line, HTML, and YAML (and soon XML will be added to that). The current web interface is unfortunately not very user friendly so it's my job to make a better, wizard-based one.

The difficulty lies in the amount of flexibility it must have and the constraints I must work under. The first constraint is that DIAL is the way it is and besides small things they're not going to change it for me. Additionally, as new functionality gets added to DIAL, it must be as easy as possible to adapt my GUI to it. Using the soon-to-be XML (or the current YAML) interface I can basically "replay" the regular web interface. The data returned by the server is simply a list of all possible options that can be used by the user. The web interface simply displays those options as HTML form controls, where the YAML/XML interface just gives you a list of options. As you send input to the server to set different options, more options can become available. And sometimes there will be data included as well.

The options I get from the server are grouped, and I can discern the grouping based on the names of the options. For instance, all names starting with "Client::form_login" have to do with logging in. It is on this grouping that I plan to base the wizard. At its simplest, a group of options will become one wizard page in my GUI.

Of course, that's not all there's to it. There's more information needed that I won't get from the server because it's not in the currently existing web UI. For example, I divide the options into pages so it'd be nice if every page has a clear and concise title. Since the current UI doesn't use these pages, there's no titles. It can also be the case that a little more thorough restructuring of the options is necessary to make it user friendly; maybe we want to split a group of options into two pages, or combine two groups into one page, or change the order of the pages or the individual options on a page.

To allow for this, I plan to use a two-fold approach. First I will use additional data that will be combined with the data returned by the server that will allow me to define things like titles, page orders, and other transformations that might be needed. It will be possible for the GUI to use more than one set of this kind of "modifier" data; they will be loaded in order with each having the ability to override the settings from the last. This allows for e.g. user-specific settings that complement or override global settings. And second, I will make it possible to specify a custom server control to handle a specific group of options. That way, whenever something needs to be done that falls outside the regular options available for my GUI, it can still be done.

Of course, this is just my preliminary idea. Tomorrow I'm having a meeting which will involve getting some feedback from real users on the system as it currently is, and next week I will join a demonstration of the system at the VUMC in Amsterdam, and I'm sure that will influence the design.

Categories: University
Posted on: 2006-12-05 16:59 UTC.