Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!know!sdd.hp.com!usc!apple!agate!shelby!helens!baroque!jim From: jim@baroque.Stanford.EDU (James Helman) Newsgroups: comp.graphics.visualization Subject: Re: info needed Message-ID: Date: 13 Nov 90 19:55:15 GMT References: <1990Nov8.173804.5775@batcomputer.tn.cornell.edu> <1990Nov12.184434.23529@odin.corp.sgi.com> Sender: news@helens.Stanford.EDU Organization: Stanford University Lines: 59 In-reply-to: upson@lavalite.asd.sgi.com's message of 12 Nov 90 18:44:34 GMT Does visual programming work? No, but neither does anything else ;-}. Visual programming advantages. 1) Flexible and extensible systems are easily designed. 2) Modular structure can limit UI visibility and mitigate the "lost-in-a-big-flat-wilderness" or "ten-menus-down-to-twiddle- favorite-knob" user interface problems. 3) It's customizable. Frequently used configurations can be saved and recalled. Visual programming disadvantages. 1) Many scientists and engineers lack familiarity with visual programming. 2) Complex tasks create rat's nests of connections. 3) It's difficult to interact with underlying or intermediate data, especially when an intermediate representation has inherent structure beyond it's drawable geometry.** #1 is a big problem. For many the incentive isn't great enough to warrant the learning effort. And a short term "paradigm" shift can't wait (a la Thomas Kuhn) for all the old school people to die, so you have to make systems look as much like more familiar canned applications as possible. An ideal system could configure itself to look either like a canned tool or an extensible tool depending on the user's needs and preferences. #2 can be mitigated by encapsulating groups. #3 could perhaps be resolved by adding in more sophisticated data structures and communication protocols between the "Viewing" modules and the "Analysis/Extraction" modules. In short, Visual Programming doesn't work completely in current implementations, but it probably could. And it looks better than any alternatives for building general purpose, extensible tools. No doubt some of the special purpose tools, e.g. CFD only, Vol Vis only, FEM only, will get by without extensibility, but a workstation vendor supplied system must have configurability and extensibility as it's hallmark. ** "Visualization" really isn't the right word for the process. We're really trying to facilitate data understanding using visual tools. It's an interactive process with a very high bandwidth channel (the *visual* part) in one direction. And in the other, a low bandwidth, but extremely important channel by which the user explores and interrogates. Both the data set and the representations (geometric and otherwise) need to be accessible to these interrogations. Jim Helman Department of Applied Physics Durand 012 Stanford University FAX: (415) 725-3377 (jim@KAOS.stanford.edu) Work: (415) 723-9127