Rich GUI dilemma - web or desktop application?

I'm planning additional visualization tools for diagnostic system. The have "additional" role - because will be scarcely used only by expert users. It's a kind of fancy interactive scatter plot with plenty of displaying options including simple data transformations.

Primarily I thought about it as a desktop application. But I when I get initial requirements it seemed that there is no much functionalities and it could be written as module of already existing web application for data gathering.
I have to gather more details , because now I have to guess future boundaries of that part of the system.

The basic pros and cons array:

	Pros	Cons
Web application	- its web application so you need only web browser (maybe Java or Flash runtime automatically downloaded by browser)- easy deploying - better (seamless) integration with the rest of the (web) system	- possibly low client performance depending on used technology
Desktop application	- established for rich GUI - more computational power to use on client side (really?) - targeted for more functionality "richness"	- target client system dependence (but I know that 99% of users uses Windows platform) - loose integration with the rest of web based system (deployment architecture allows it)

Reviewed technologies and solutions:

• Java desktop app
• Java applet
• GWT application
• YUI components
• flash components

Final choice depends on the range of features, and final users preferences. Web version seems more performance constrained - but there are many technological solutions that make that choice as good as its desktop counterpart. At that point there are very little differences between web or desktop deployment outcomes. Nowadays buzz is "web is the future". I have to make my choice based on economic assumptions.

The best programming language 2 - Simple case tale

The University needed temporary solution for generating list of quiz questions, chosen randomly from data prepared in structured text file. The scope of application was nothing comparing to "Enterprise Systems", so I treated it as a kind of entertaining enterprise.

The core characteristics were:

• simple logic
• UI forms for getting parameters from user
• printable or saveable formatted questions list
• low burden installation and use (get it on pendrive or download ready to use).
• main constraints: short time and possibly low cost.

I started looking for similar open source products, but not found needed functionality. So when I checked myself for Not Invented Here syndrome, I started thinking about custom solution.

There were many ways of implementation. I thought about preparing windows exe file with included required dependencies (no installing additional Java, .Net, Python or other runtime).
I started playing in "prototyping with Python"- it was fun and things were going smoothly. But I stopped before making UI. Plain old console was "too lame" for final users, so I planned GUI with TkInter included by default in python installation to avoid porting to windows executable problems.

I get core set of functionalities, but user interface still was barely specified. Then I get many additional requests about "last minute" changes in UI forms (and probably not the last). The second "economic" option was to implement the whole application in Java Script and HTML running under web browser. Every computer has web browser suitable to run that kind of application so there are almost no installation and portability issues. Implementation time should be short too. To speed up things I have changed data format from flat file of records into JSON structure. Porting logic was fast too. The most time took me making forms working.

First version was not so fancy and needed some GUI tweaking like formatting, changing labels and headers. In a case of any further UI changes other people knowing HTML could make fixes instantly. The extra feature was possibility of "deploying" the little application on a web server as HTML page. Saving result to file wasn't working directly. Making it really automatic needed interacting with browser security policies for access to local file system. We decided that it will be still usable if user use copy-paste technique, and place formatted result in external text editor. The default usage was printing questions on paper so nobody saw problem there.

Everything is working as designed, and shows that web browser should be treaded as good platform for small applications. Sometimes little prototyping gives better insight on a whole system.