Topic: wftk -- User interface mockup

One caveat right at the outset. The user interface is separate from the workflow engine. I'm doing this UI mockup as a set of Perl CGI scripts because Perl runs everywhere (well, almost). Makes things easier to work with. It's important to realize, however, that the basic UI can be reimplemented for some other platform with no loss of generality, so to speak. Since Galactic is running IIS, it will make a lot of sense to implement a user interface as a set of ASPs using cookies and the whole IIS bag of tricks. And if you're running some other server and you don't like Perl, or you think that Basic user authentication is too much security exposure, or whatever, it should be simple to write a UI which uses whatever you have available.

The mockup is written in Perl/CGI. It requires frames and uses a couple of graphics just to spruce things up. The navigation menu on the left-hand side is the first frame. This should be considered configurable, both by preference and by user permission level, so that not all users would have the full range of administration menus, for instance. The bulk of the screen is whatever you're actually doing, of course.

There are some things I'm realizing, of course, while working through this. Here are some nuggets of wisdom I'm gleaning.

• Data elicitation forms
  Forms for elicitation of data can be generated automatically, but autogenerated forms are typically not very pretty or easy to work with. It'd be nice to have some way of specifying forms, available choices for select boxes, and so on. The logical place for this information is in the definition of the data item in question. So the <data> tag will need some extension in this regard.
• Assumed browser functionality
  I find myself constantly trying to balance the need to provide complex editing functionality and at the same time attempt to make the UI executable on a lowest-common-denominator browser. Thus I'm avoiding Javascript entirely, for instance, putting everything onto the server. This may not be the best way to work things, as it certainly makes for more traffic between client and server. So as we get into this further I think it'll be clearer how sound the decision is to avoid Javascript, for instance. For the time being I'm doing everything in plain ol' HTML.