Software Architectures

From Visualization Sp06

Lecture on Feb 14, 2006

Slides

Readings

  • Review Chapter 1: Information Visualization, In Readings in Information Visualization (particularly from page 17 on). Card, et al. (handout given at beginning of the semester)
  • Toolkit Design for Interactive Structured Graphics. Bederson, Meyer & Grosjean. IEEE Transactions on Software Engineering, 30(8), August 2004. (pdf)
  • prefuse: A Toolkit for Interactive Information Visualization. Heer, Card & Landay. ACM CHI 2005. (pdf)

Optional Readings

  • The InfoVis Toolkit. Jean-Daniel Fekete. IEEE InfoVis 2004. (pdf)
  • Past, Present, and Future of User Interface Software Tools. Myers, Hudson, & Pausch. ACM TOCHI, March 2000. (pdf)
  • An Operator Interaction Framework for Visualization Systems. Chi and Riedl. In Proceedings of the Symposium on Information Visualization (InfoVis '98), pp. 63--70. IEEE Press, 1998. (pdf)
  • 2D Graphics Primer (useful for those with little experience in 2D computer graphics)

Demonstrations

Contents

Bryan - Feb 14, 2006 10:21:11 am

I must admit that while preparing for the third assignment, my head was spinning with the number of possible toolkits to use. A balance must always be struck: on the one hand, using a toolkit saves work by doing a lot of the tedious setup work for you, which can be a huge headache especially when designing user interfaces. On the other, flexibility is always lost when confining yourself to someone else's API. Also, when using a pre-written API you're always at the mercy of someone else's opinion of what the best way of doing things is (callback models, graphical primitives, etc). I was very tempted by prefuse and the Infoviz toolkit, but I ultimately decided to go with a web-based program because of the ease of running and testing for others. Nothing to compile, nothing to download--it's a compelling model.

Todd - Feb 14, 2006 11:46:55 am

Regarding monolithic vs. polylithic toolkits, my first reaction was that they had created a false dichotomy. In any object oriented GUI toolkit, there is going to be some usage of inheritance, and some degree of composition. Furthermore, their claim that graphical tools for building GUIs can only exist for polylithic systems, which at first seemed to be a false statement, after all, visual studio provides interactive tools for building MFC applications, where MFC is a prime example of a monolithic system. Of course, what they really meant was that you can't design new components visually within something like MFC, whereas if you had a scene graph, you could interactively combine parts to make new parts. After reading on, it turns out they were actually make a more subtle point; all systems have some polylithic and some monolithic aspects to them, but in reality, each is guided primarily by one or the other as a design philosophy.

Still, I am left with the feeling that the distinction, while clearly existing in any toolkit I have run across, is not inherent. Surely it is possible to have a toolkit that uses both inheritance and composition in a balanced way.

My question is, has anybody ever created such a toolkit, and if not, is there a fundamental reason why not?

Lesliei - Feb 14, 2006 03:55:20 pm

I like Todd's comment -- it seems like one could leverage the advantages of both composition and inheritance. The prefuse paper commented that users like sample code. Perhaps if the toolkit uses an object-oriented paradigm, users would like sample base classes. They could look at the sample child classes, then write their own child classes. That way, they wouldn't have to start from scratch when they're still learning, but they could still implement what they wanted in a (hopefully) clean way right from the start.

Brien - Feb 15, 2006 01:12:23 am

I think what makes Processing great is that it cleanly augments an existing platform. I don't think there's something you can do in Java2D that you can't do in Processing. Reading about Jazz, I learned that there is a Swing node, but not how well it works (kind of an existential argument). I wonder if they even tried to design their calendar app using a traditional Swing layout + Jazz to do the fisheye. I think more emphasis should be put on the compatibility with existing frameworks. The day I can drop Jazz into my Swing app and get an infinite ZUI will be a good day.

Nchentan - Feb 15, 2006 10:10:26 pm

Does anyone aware of a visualization library for C++? Qt and wxWidget support traditional GUI interface, however, they do not have any higher level components. 3D Graphics Engine such as OGRE3D, also support loading XML and some level of customable widgets, but it seems not suitable for 2D application and also the customization is rather limited.

Jheer - Feb 15, 2006 10:27:39 pm

Bryan's comment points out another important aspect of tool choice: the intended audience. How does your choice of tool affect your potential user base? While both Flash, and to a lesser degree, Java applets, can bring more interactivity to a web environment, it is really the common denominator that often drives deployment decisions. HTML/CSS/JavaScript/XML (I hesitate to say 'AJAX') is coming along, but from a developer's point of view (IMHO) has a significant inelegance. That said, much more compelling visualization possibilities are beginning to accrue in standard web technologies, and in the end it is the user experience that really matters. Metacompilation to web technologies from higher-level languages in one interesting possibility, something the folks that designed the Lazslo language (originally designed to be compiled to Flash bytecode) have been looking at. (As an aside, I like Java WebStart as well, which removes compilation and updating issues, while allowing application-level experiences, but perhaps it's too little too late?)

In reponse to Todd and Leslie, indeed, all UI libraries typically involve both inheritance and composition in usage, but the monolithic/polylithic split is made specifically in terms of extensibility. What constitutes a "balanced" approach between inheritance and composition certainly has context-dependent aspects, both in terms of personal preference and the requirements/scope of your intended domain(s). I have tried to navigate some of these issues in the design of prefuse, which uses a compositional model of visual data operators, rendering modules, and interaction components for application building, but also encourages extensibility through inheritance for any of these component types, both through trying to minimize the complexity of the API for extensible modules (making it easier to write any number of extensions) as well as providing numerous base classes and overridable methods to support custom-tailored applications. I also really like Leslie's suggestion about sample code; my own studies of programmers using prefuse has shown this to be a powerful approach -- it gets programmers thinking of the possible extensions from the start, and by providing structured examples within a context of relatively unstructured extension possibilities, can hopefully keep the ceiling higher without unduly raising the threshold.

Nchentan -- you might want to take a look at VTK, it is a C++ 3D vis toolkit popular with many visualization researchers and practitioners. It provides a scenegraph, and also has bindings for working in other languages, such as Java and Python. It might very well be suited for 2D as well.

Raymond - Feb 20, 2006 11:12:03 pm

I agreed with Bryan's comment that indeed it was a hard choice is choosing from all the toolkits available. I personally ended up choosing Prefuse, because of familiarity of Java and easy access to help regarding the toolkit itself. The ZUI feature that came with Piccolo, I think, is very neat and I hope in the future this will be used more often in common applications (Google maps, for example).

In response to Jeff's comment, I agree that user experience is indeed the most important aspect when designing user interfaces (in fact, i'm taking an user interfaces course). In chapter 10 of Donald Norman's book, "Want Human-Centered Development? Reorganize the Company", he talks about how the high-tech industry is at a crossroads today in concerning about designing products with features or technology in mind. Furthermore, he advocates that user experience must be incorpoarted into the design process in order for a product to do well.

IvanTam - Feb 21, 2006 11:16:17 am

In addition to Processing, there are a few software packages that are built on a graphical programming environment to allow for prototyping of interactive visualizations.

The most famous example is the Max/MSP/Jitter programming environment that is popular with the digital art installation community. A free alternative developed by the original creator of the Max programming paradigm is PureData; various add-on packages allow PureData to draw simple OpenGL primitives.

Both of these packages, however, represent the "program" itself graphically as a network flow graph between node called "patches." Thus, the programming environment is, in a way, a visualization of the program itself, allowing many non-traditional programmers to create code.

Yi-Tao - Feb 21, 2006 02:00:39 pm

From my point of view, the web-based toolkits aren't as nice. Sure they're easier since you don't have to download anything, but that usually means less control. As the article by Bederson, Meyer & Grosjean points out, creating toolkits is a complicated process and the decisions lead to constraints on the features of the toolkit.

Most computers come equipped with software to handle HTML/CSS/JavaScript/XML, which explains why they're developing so fast. Of course, the inelegance of web-related languages are apparent. They just don't have the theoretical base of OOP. Having worked as a database designer, the lack of rules in XML is disturbing.

AaronHoover - Feb 21, 2006 03:49:57 pm

Another tool I've run across (and was mentioned in the one of the readings on color) is OpenDX. Like some of the graphical programming paradigms, it constructs a "program" as a series of interconnected graphical components whose behavior and output can be modified. It was originally developed at IBM before it was open-sourced, and appears to have been strictly oriented toward the unix platform. There is a version that runs on Windows (you still need to run an X server), but I can't for the life of me quickly get it to anything useful. I was a little disappointed at apparently high threshold, but I'm wondering if anyone else has ever used it, or could provide a little insight.



[add comment]