Why a Browser-Based GUI? - The Time Bandit

Visit the High Level Logic (HLL) Website
— Home of XPL (eXtensible Process Language)
It's like XML, but you can store source code in it.
Since the first experimental prototyping in 2007, HLL has had a browser-based GUI. It's been the most time-consuming part of development. One the one hand, there are lots of different devices out there, not just your desktop, but smart phones and PDAs and the like - in a variety of models from a variety of manufacturers with a variety of technology used. How many of those devices have browsers? Well - most. All that I own. So, I figure if I have a nice cross-browser GUI, it covers a lot of ground.

I've also done lots of interesting experimentation with SVG (Scalable Vector Graphics), which I think it great. SVG is a standard. Support is directly in the browser itself. You build SVG graphics using XML coding. Several browsers are getting close to implementing animation, which will simplify programming for (for example) the graphical robot tracking frame.

On the other hand, I must say it's been a bit painful. Especially when you're trying to do interesting things in the browser, cross-browser applications are not simple, especially if you're including MSIE. Each browser supports what its developers decide to support, and require programming applications to correspond with the functional support available. A working javascript function doesn't necessary work in all browsers. Sometimes you can discover just the right coding so that it will. Sometimes you are forced to detect browser type and support differently built functions depending on what the user is running. It's not like there's perfect up-to-date documentation for each either. Experimentation is required and sometimes you need to google around looking for someone who has posted about a similar problem and find a suggestion for solving it. (Although - if you've been around the block 20 times on all of this - I suspect it's easier.)

Microsoft hasn't been so good at supporting established public standards. It's full of exceptions. Everyone who, for example, has built a cross-browser AJAX function knows that. They are miles behind in support for SVG. There is a plug-in from Adobe that works, but it requires the plug-in to run, and Adobe no longer supports it - so it's apparently not destined to support things like animation. Microsoft has said they'll work on it themselves, but who knows? ↓

(Turns out, somebody did know. MSIE support for SVG announced for the upcoming IE9. See comments below article for more information and links to SVG status charts for browsers.)

The SVG element is but one feature in a particular application. But I think it's an interesting one, and with care, the HLL GUI can provide out-of-the-box support that will help other applications get up and running nicely. I've implemented two different ways of pushing content to the browser and - among other things - that drives graphics animation (think of a circle moving around through "rooms" tracking the movement of a running robot). Microsoft's lack of support for animation seems a longer term problem (perhaps), while Firefox is closer to doing it. Opera is in the lead. To create smooth movement, I'm currently using dhtml. Perhaps something in that code might even turn out to be re-usable.

When I committed to open-sourcing HLL, I decided to move development from MSIE to Firefox as well as implementing a URLConnection push to the browser, replacing a very nice Multicasting version. The latter decision was based on two things. The multicasting version only worked within a LAN and required a policy and modification of the Java security file to implement the policy. Having some experience searching for open-source code myself, it seems to me that the first offering one encounters must be as simple to install and run as possible. Download - click run - not start fooling around with your Java security file. And I have no statistics on the percent of Java programmers who find it easy to create a new security policy. That could be a stopper for many. The URLConnection doesn't even require opening a port and it works from any machine anywhere without any installations or modifications or plug-ins on the client. It just works (although not as nicely as Multicasting at this point). (Note also: the Java EE version will likely use JMS.)

Firefox is of course, a very popular browser. But I also considered the state of their support for SVG. As mentioned, they are behind Opera. It seems to me that playing to the most advanced doesn't really help me build something that most browsers can run. Given that Opera is currently more advanced in their support for SVG, one can proceed with the idea that if it works on Firefox, it will probably work in Opera (even if it takes a little tinkering). Of course, then there's MSIE. Since I already have experience with MSIE, I'm familiar with the limitations of the Adobe plug-in. For MSIE, the application will need to detect browser and reload the frame with the customized MSIE page. Since I built first with MSIE, I'm just a hop, skip, and jump from completing that task when the time comes. (Will be great if I don't need to.) With tinkering, the dhtml smoothing function should work for MSIE as well.

Now here's the painful thing. I'm at the beginning of this project, coding everything myself, while getting the open-source project up and running and now - to keep my schedule - I need to start "marketing" the project and trying to draw some interest. There are now 11 issues posted in the issue tracking system, each of which will enhance HLL considerably on completion. This browser stuff has taken up a lot of my time for adaptations more than gains.

Of course there are frameworks. But I'm spread pretty thin. I've nothing against learning new frameworks - believe me. I'm asking people to learn about mine. It's partly just a matter of time, but also consideration for simplifying the original offering. "Just download and try my code. It's easy." instead of "download, install, learn to use 14 other different packages" kind of thing. (I'm thinking about how to handle this in the future - because there's a lot of good stuff out there that would be useful as add-ons ... I'll likely write about some of them in this blog later) As for time and using a cross-browser framework, no one person can know everything. I don't know at this point - perhaps in hindsight, the time might have been better spent learning a framework rather than doing everything myself ... but the results always seem just one more solution away.

Anyway - the Firefox version seems to be working now, for the most part. I still need to get the dhtml for smooth movement working in context. Then I can get back to enhancing the Java .... HLL itself ... which should produce gain much more quickly. Of course, now I do have a new list of things to do - since my schedule says the open-source project should be underway.