Slashdot Mirror
Drawing Graphs on Your Browser?
Pieroxy queries: "I recently had a look at various ways to draw a graph (lines, bar chart, pie chart...) for a web-based enterprise application. As we need some interactivity, the GIF image generated on the server-side is not an option. Here is the list of technologies I can think of: Flash is probably over kill and a closed technology. Java is very flexible but slow (to start and run). SVG (discussed here) still requires a plugin. VML is supported only on IE5+, but it is natively supported. Which one of these technologies is the more flexible and interactive? Is it reasonable to require a plugin from the end users of our enterprise application? Is IE5+ a wide enough target for an enterprise application?"
If you can get away with just bar charts, take several gifs/jpegs/pngs that are just single colour pixels and have your server-side program fiddle with the heights and widths to draw your bar chart without having the server generate an actual image file.
Internet Explorer 5 and above are very widely-used. However, they are still flawed browsers and, due to the announcement that these browsers will no longer be updated as standalone applications, many people may switch to another browser. Also, those using a Unix-based platform (read: GNU/Linux) no longer have any viable way of using Internet Explorer. If it is not easy to change back and forth, the already limited audience VML will reach even less as time goes on.
As an opinion only, if SVG is an option, it may be best in the long run. Assuming it is not easy to acrobatically jump from one option to the next (if that was possible, you could serve VML to IE 5.5+ and SVG to Mozilla, and some raster format for any other browsers), SVG holds the best promise. SVG is already supported as a plug-in (much like flash). It is about to be tested as a native part of the Mozilla browser. Over time, compatibility will actually improve--not something Java or VML can say easily. Also, as compatibility improves, simple scripting can make the charts interactive or real-time (or other neat fancy stuff).
2) No. If it doesn't work on (at least) Netscape/Mozilla then you're excluding too many people (unless you know something about your target audience that I don't).
Surely you can do something with DHTML/Javascript to dynamically resize bar charts...
I've recently had to do something very similar, well okay almost identical. Interactive graphs of various types and of various data sets from a Web Based interface.
:)
We have larges amounts of data which is very hard to interperate by a human in something like a spreadsheet. The only really feasable way to do it was graphs. Of course with the amount of data we had transmitting it to the client to do client side rendering (ie Java) is also out of the question.
In the end we settled on JPGraph with an interactive interface built using PHP. So a wizard style interface to choose the type of graph, what data to graph, how to group the data, and finally the outputted graph with the option to change all the settings.
With good indexed data making PHP generated graphs with JPGraph interactive is quite painless and very powerful.
Just one suggestion, make sure you have a way for people to save the settings of the graphs they make so they can pull em later, keeps the PHBs happy
I'm me. I think.
.. and that interactivity is hard to achieve in a web browser, maybe this application doesn't belong in a web browser. Just a hunch.
The MING library can generate SWF from PHP et. al.
I've been pleasantly surprised by Flash MX, actionscript is a fully featured programming language that runs across all the platforms Flash is ported to. You can pass variables from your html page, so your graphing application should be writable as 1 single 'movie' that accepts data, rather than writing a new one every time you need to draw a graph.
The only problem is that the tutorials and manuals are aimed purely at designers, not at programmers, so the concept of a variable is given a 20 page explanation whereas the syntax of the more complex commands is glossed over in a 'do this and it works, you probably don't need to mess with it' manner.
A pizza of radius z and thickness a has a volume of pi z z a
If you want the interactivity, you should at least try an optimized pared down applet. It's true that most applets are slow, but it is frequently also true that they are written badly and/or contain heaps of additional libraries that they need to download. Use as much of java's built-in code as you can with the possible exception of the GUI library.
Look at lightweight graphical libraries like lwvcl (commercial) or thinlet (LGPL) for the controls. The zaval people even have a charting library for their lwvcl system. (I have never used the lwvcl library, it just looks cool - try their online demo. Thinlet packs amazing capabilities into a very small package.)
If you need to display 15 graphs at a time with limited interaction, then this may not be the way to go, but if you need to display one at a time with very rich interaction, this might be the ticket.
dhk
Corda might do what you need. It will output the images in Flash, JPG, PNG, GIF, SVG and others. I believe it uses XML files to generate the graphs. I'm sure I'm missing a lot of the other things that it can do, but it's worth taking a look. Oh, and unfortunately it's not free, but it might be worth it if it does what you need.
Note: I do not work for this company. I have seen the results of using their product. We use it where I work and everyone seems to like what it can do.
I once wrote a piece of javascript that would do this client side. It was for a corporate intranet, so I knew which version of which browser was going to be used.
.js file can be cached, so only the data has to be sent, measuring a large multicolor pie graph in bytes rather Kbytes.
The idea was simple: I created a table with every cell one pixel large, and set the colors accordingly to the input for the frame. It started out as a simple line graph, but in the end it could do bar and pies too.
This should be doable crossbrowser now that JS has stabilized enough between IE and Moz. If implemented right, it can really do with much lower bandwidth than pictures (which was the main requirement then): the
the pun is mightier than the sword
There were a few options that I rejected:
- Flash - probably extremely good at this sort of thing, as vector graphics and user interaction are its big target. However, we have no in-house expertise, and the end-users will all be professionals who may very well not have Flash installed (and furthermore, their firewall may not even give them HTTP access to download it)
- SVG - Great! It's W3C approved, as opposed to the officially deprecated VML! Whoop-de-fucking-doo. When our clients complain that our application doesn't work, I'll point them to the W3C spec and have the warm glow of righteousness as all of the lawyers' letters demanding refunds come in.
- Java - Well, it can handle drawing and events just fine, we have in-house expertise, but the whole point we're doing this through the browser is to avoid having to write an application from scratch in the first place. Now calling it an "applet" and changing main() to start() doesn't alter the fact that IMO writing user interfaces in Java sucks my grandma's clit.
So, VML. We have the luxury of knowing that the standard desktop is Windows running IE. I suspect that at least 95% of your target desktops (you did say enterprise, right?) will be IE too. Furthermore, if they're running Windows then you know that even if they are running, say Mozilla, that they have IE to hand.At the risk of posting flamebait, do you really have to worry about the possibility of end users running a non-MS operating system? Almost certainly not. Even the few that use Macs can presumably view VML. So go with VML and mandate the use of IE.
Unless, of course, you do wish to use Flash and have the expertise - although I still think you'll run into issues of people not having installed the plugin.
I wonder how quickly a browser could re-flow a document that included an 800X600 cell table...My guess is "painfully", but it's almost worth writing the concept code to find out - time to write some PHP (I'm buggered if I'm going to write it by hand)