Re: visad-list-digest V1 #146


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...


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.

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

  • 2002 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the visad archives: