Hi,
I just wanted to add my voice in support of Maohai Huang's suggestions:
1. VisAD would be a lot easier to use, and therefore gain much wider
acceptance much more quickly if it provided certain things out of the box,
such as a legend, data point symbols, error bars, etc. You might argue that
VisAD is not meant for 2D applications so much as for 3D. Still, I imagine
many potential users will be casual programmers (i.e., scientists whose job
involves data analysis and visualization, but whose main goal is to
understand science, not the API). Like me, they are looking for a library
that will allow them to do what they need to do quickly and easily,
probably starting with some kind of 2D graph. If VisAD allows them to do
that, through a set of wrappers that hide the complexity (and I'll admit
that JyVisAD goes some way towards doing this - Tom Whitaker's graph/subs
modules do hide a lot of the complexity - but it seems like an
afterthought, rather than an integral, serious part of VisAD development),
then perhaps when it comes time for them to do more serious visualization,
they will have gained familiarity with VisAD enough that they'll be able to
tackle something more complex. By having the learning curve so steep, you
keep out all but the most committed, hard-core Java programmers. Certainly,
VisAD appears to be written to be correct and generic by design. But what's
wrong with putting in a gentle on-ramp?
2. Reading other people's code is certainly a fine way to pick up tricks
and elegant solutions to problems. But it's not the way to learn an API.
The Developer's Guide is full of descriptions of the code, and does have
some info describing the framework, but I wouldn't call it tutorial in
nature. It never really says: "Suppose you want to do X: well, here's what
you need to do, and why - oh, and by the way, don't try this, because
here's what'll happen".
3. I started off wanting to just write a Jython app that would let me do
some fairly simple visualization in 2D. All the people on the list were
certainly extremely helpful, I agree that this is a major selling point.
But the fact that the designers/developers of VisAD seem to be the only
people who can help out is not encouraging, and absolutely not scalable.
Imagine if you had to wait for Larry Wall to get back to you every time you
had a problem with a Perl script.... I finally got it to do what I want
using the Jython graph/subs modules, but it's so slow (taking 10 seconds to
pop up visualization windows), that it's hardly usable. I'm sure I could
optimize it somehow, but it's been so hard to get it to work, that I'm worn
out, and tempted to find another way to do this, perhaps by going to a
CGI-based model. At least with the standard Perl/Python libraries, I know I
can write the routines to draw what I need to, in a day. And I think that's
just too bad, because I can see the power of VisAD - I just don't have the
time to invest in getting to it.
Perl/Python have a mantra: "Simple things should be simple to do, difficult
things should be possible." Part of Perl's success is that it allowed
people to do things quickly and easily, which up till then had been
difficult and time-consuming. Python allows that too, and in a way that is
readable to people other than the original programmer ;). Why can't VisAD
take the same approach?
Just my two cents' worth...
-Frank
At 03:00 AM 11/27/2002, you wrote:
Date: Tue, 26 Nov 2002 17:36:36 -0800 (PST)
From: m huang <qomo@xxxxxxxxx>
Subject: Re: VisAD for general data visualization purposes for general users?
- --- Bill Hibbard <billh@xxxxxxxxxxxxx> wrote:
> Currently
> > core VisAD has been made for 3D visualizations which the current
> > developers are most interested in.
>
> VisAD supports both 3-D and 2-D display techniques. Many
> VisAD applications are purely 2-D.
>
Some of the issues have been addressed in the
"questions on functionalities of VisAD X-Y style 2D plots"
thread. I think most people would agree that it will not be
considered a serious X-Y plotting package if it doesn't
provide *out of the box* a default set of data point symbols,
nor legend, nor log and log-log scale, nor error bars, nor
coordinate grid, not much selection of plotting style (take
a look at JFreeChart) ... I know with some more work VisAD can do
all these and more, but as it stands, the meat of VisAD is 3D.
> > [quote of the evaluation team's conclusion]
>
> other systems. What you say is true in the sense that,
if there is a confusion... I wasn't in the evaluation team.
I didn't write the conclusion. I think much higher of
VisAD than they did ;-)
> > I think what VisAD lacks for dealing with its complexity is 1)
> > wrapper
> > classes for casual users that doesn't demand much sophistication,
> to
> > "make simple tasks easy";
>
> I agree. We are working on them. That's why links to the
> Integrated Data Viewer and VisBio are right at the top of
> the VisAD web page.
I am writing prototype wrappers to simplify X-Y plotting
with VisAD, so that anyone who wants to plot a simple Y-X
figure doesn't have to understand that the data must be passed
from an array to a Set, then to a FlatField, then to a
DataReference, then to the Display. It's crazy.
I haven't looked at VisBio and I don't have a machine good
enough for IDV (requires 512MB RAM reserved for IDV? I only
have 256M in total! And think about the target users of
our system ... could be an astronomer in a small university
of a third world country)
>
> > 2) better documentation for the outsider
> > developers to "make difficult tasks possible." More specifically,
> the
> > documentation should be all accessible from JavaDocs. The
> > documentation
> > of implementations should refer to the relevant design
> documentation.
>
> We have been putting a lot of effort into design documents.
> Linking from the JavaDocs will be a huge job, considering
> the size of VisAD.
Sounds like a good summer job for a graduate student :-)
Rationally I think we all know that good documentation saves
future work, not only in the sense that it clears up the developer's
thought about implementation and saves time in question
answering, but also in the "bandwagon" effect -- if more people
can get into VisAD, there will be more serious contributors to
save your effort, and then even more people will jump in.
Currently there are so many mysterious APIs with no comment or
useless comments, just adding a little more to them would be a
big improvement. I want to say it again -- reading the source
code is NOT the way to figure out the APIs. It's shooting
himself on his feet for anyone developing long term project.
The developers using VisAD shouldn't be expected to do
so. This mailing list is great, but it's not efficient
when the inquirer is novice, both for the asking person and
the answering one. There will be a lot more novices asking
the same question again and again when VisAD becomes more
popular. The search engine of the archive often returns
results which I suspect are obsolete compared with the
current release. Better documentation is the way to go. Some
funding should go to this end in my opinion. It'll be money
well spent.
That being said, thanks for replying. This list a "selling point"
for VisAD.
regards
Maohai Huang (oh, the yahoo address is an anti-spammer if any
one wants to contact me directly please use mh (at] astro
"." ts "." it)
- -----------
PhD, Computational Biologist,
Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
Tel: 617-432-3555 Fax:
617-432-3557 http://llama.med.harvard.edu/~fgibbons
