Skip to content
Find file
Fetching contributors…
Cannot retrieve contributors at this time
23 lines (13 sloc) 4.27 KB
\chapter{Conclusion and Outlook}
% \section{Results}
In the course of this MSc Thesis, a functioning visualization toolkit has been developed. Unveil.js uses a toolkit-specific abstraction for visualization specification. The evaluation has shown that the results are sufficiently fast. Unveil.js has strengths in object-oriented composition, but weaknesses in supporting interaction due to the characteristics of the HTML5 Canvas element. Moreover, it contributes Data.js, a comprehensive data-manipulation component that can also be utilized in other frameworks (e.g. D3.js).
% \section{Caveats}
% ---------------------------------------------------
Declarative interfaces have been considered a suitable way to approach visualization development in web-based environments~\cite{Protovis09}. Because of the dynamic nature of Javascript and native support for JSON as an established data exchange format, toolkits that favor a declarative interface have been found advantageous over classical imperative programming models.
Within the context of declarative tools, there is a discussion about whether to choose a representation-transparent approach~\cite{D3} or to use a toolkit-specific specification syntax. While an representation-transparent approach improves expressiveness and simplifies debugging, toolkit-specific abstractions are often easier to understand, allow cross-platform deployment and can be optimized independently (because execution is separated from specification). The decision which approach is appropriate for a certain use-case, however, is left to the developer.
Simple visualization tasks can often be accomplished by employing the DOM interface directly. However, for more complex scenarios, employing a toolkit (e.g. Unveil.js or D3.js) could make sense, especially if interaction is needed. If interaction is not a requirement, using the raw Canvas API seems reasonable.
Finally, visualization designers have to decide whether or not to use web-based technology for their particular visualization task. Generally spoken, web-based visualization should be considered if the results are intended for a broader audience. If capabilities are sufficient in terms of data-throughput, rendering performance needs to be evaluated for a particular task. For ad-hoc visualizations which need not to be shared publicly or involve huge amounts of data, using native desktop technology is probably a better choice. An example for this would be medical visualization such as plotting a CT. Given an abstract visualization specification and support for both web and desktop runtime environments, cross-platform deployment would be possible. Unfortunately, in practice production-ready frameworks suitable for cross-platform deployment are not yet available.
\SuperPar Within the last years, web-native technologies have made good progress. Javascript implementations become measurably faster every month. Javascript emerges as a platform and is no longer restricted to the browser environment. Server side implementations, such as Rhino\footnote{} or the ambitious Node.js\footnote{}, are ready for production use.
Considering that browsers have already started to gain hardware acceleration support for graphical operations, it is likely that in the near future web-native technologies with respect to Information Visualization will be on par with traditional graphics programming environments.
However, even if low level interfaces are continuously improved, there is a great demand for higher level interfaces. Tools that have been covered in this thesis are just a start. API's should influence each other in order to create better abstractions. Moreover, the availability of expressive abstractions may influence browser-native API's as well. A prominent example for this is the upcoming ECMAScript 6 Standard. It will contain language constructs adapted from CoffeeScript\footnote{}, a higher-level language that compiles to Javascript and exposes a simpler syntax. In the same way high quality visualization toolkits could influence native graphical interfaces. Every developer is enabled to contribute here, as it is not just up to the specification committee (W3C\footnote{}) how future graphical interfaces will look like.
Jump to Line
Something went wrong with that request. Please try again.