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.
I'm not usually one to rehash news stories on my blog, but some things are cool enough to make an exception. WPF/E is one of those things.
I for one am wondering how this "Flash-killer" will take on. On the one hand I'm sure it has many compelling features (while I haven't looked very deeply into it, if it's even remotely like the real WPF it has to be better than Flash ActionScript; not that that's hard, though), but on the other hand Flash has an extremely strong foothold in the "rich media on the web" arena. And although alternative browsers are supported by WPF/E, people who use those alternate browsers often do so for reasons that would make it unlikely for them to accept a plugin from MS.
I don't claim to be a psychic, so just like the rest of you all I can do it wait to see how it pans out. But I'm sure it's going to be interesting.
Today was my first "real" day. Sure I'd been over to work last week too, but that was not a full day and I spent a lot of it just getting set up. Plus I worked mainly on my thesis research (as I said before, we're going to continue that a little).
But today I worked a full day, literally nine-to-five, on the DIAL project. I'm still very much in the "how" phase; I'm just trying to figure out how I'll be doing it. Even the implementation platform isn't set in stone yet (I'm trying my best to get them to let me do it in .Net :) ).
One thing that I do know is that I need a way to communicate with the server, and so far that can be done in four ways: via the Perl modules, via a command line interface, via a web interface, and a YAML interface. Since my stuff won't necessarily be running on the main DIAL server the first two are out. A web interface that tries to communicate with a server through another web interface is too weird even for my tastes, so that leaves YAML. A brief look at YAML didn't reveal any problems with this.
Unfortunately, a detailed look reveals more than a few problems! For one thing, good YAML parsers are scarce. Really the only decent ones I could find are for Perl or Python. There is as far as I can tell only one parser for .Net and it doesn't work properly. That means I have two options: roll my own parser, or convince the DIAL guys to give me a different interface.
Since the YAML spec is very hard to read, and YAML in general is extremely hard to parse (it's designed for human-readability, severely compromising machine-readability), writing my own parser wouldn't be fun. The grammar for YAML is context-sensitive, determines scope by indentation, and has far too many ways to do the same thing. I could decide to limit myself to the subset of YAML that the server seems to be using, which makes it slightly more possible, but it's still not my first choice.
That leaves trying to get a different interface. I've briefly looked at the DIAL code, and the YAML generation is pretty much a matter of calling YAML::Dump from the YAML CPAN module. Which to me at least makes it seem like he could pretty easily use the XML::Dumper module instead. Here's to hoping.
Vista style file dialogs for .Net 2.0 is a library that allows you to use the new common file dialogs available in Windows Vista with your .Net 2.0 applications (the regular FileDialog classes will use the old-style dialogs even when you're running in Vista). See here for more details.
I've just uploaded version 1.2 (for those of you keeping track, yes I skipped version 1.1; I used this version myself but never uploaded it).
Here's the changes:
Since I wrote the blogging engine used by this site myself, it lags a bit behind some other blogs in terms of features. I specifically chose to do this though since it allows me ultimate control over the look and functionality of this site, and give it a few unique twists (for example: there are, as far as I know, no off-the-shelf blogging engines that do the AJAX comment loading and calendar that I have here).
I've been working on getting some of the gaps filled. In the past week I've added post categories and more friendly URLs for the individual post pages. Also new is that the calendar now shows the number of posts for that day if you hover over a link (it's rarely more than one, but still). I've also fixed some bugs and improved the code in many places, which should make for a better experience all around.
El Goonish Shive fans will be pleased to know that I have begun work on catching up with the character statistics. I'm hoping to get that done this weekend, before I get swamped in real work again.
Subscribe