
This book defines the emerging field of information visualization and offers the first-ever collection of the classic papers of the discipline, with introductions and analytical discussions of each topic and paper. The authors' intention is to present papers that focus on the use of visualization to discover relationships, using interactive graphics to amplify thought. This book is intended for research professionals in academia and industry; new graduate students and professors who want to begin work in this burgeoning field; professionals involved in financial data analysis, statistics, and information design; scientific data managers; and professionals involved in medical, bioinformatics, and other areas.
Readings in Information Visualization ( http://www.amazon.co.uk/Readings-Information-Visualization-I... ) is a collection of papers covering a wide range of techniques for a wide range of tasks.
Apart from that, it's mostly a matter of picking up interesting ideas wherever you find them. flowingdata.com is nice, same with http://www.informationisbeautiful.net/
Treemaps for space-constrained visualization of hierarchies.
Including the History of Treemap Research at the University of Maryland
Started Dec. 26th, 1998 by Ben Shneiderman
Later updates by Ben Shneiderman and Catherine Plaisant - Last update Sept 2014
A History of Treemap Research at the University of Maryland
During 1990, in response to the common problem of a filled hard disk, I became obsessed with the idea of producing a compact visualization of directory tree structures. Since the 80 Megabyte hard disk in the HCIL was shared by 14 users it was difficult to determine how and where space was used. Finding large files that could be deleted, or even determining which users consumed the largest shares of disk space were difficult tasks.
Tree structured node-link diagrams grew too large to be useful, so I explored ways to show a tree in a space-constrained layout. I rejected strategies that left blank spaces or those that dealt with only fixed levels or fixed branching factors. Showing file size by area coding seemed appealing, but various rectangular, triangular, and circular strategies all had problems. Then while puzzling about this in the faculty lounge, I had the Aha! experience of splitting the screen into rectangles in alternating horizontal and vertical directions as you traverse down the levels. This recursive algorithm seemed attractive, but it took me a few days to convince myself that it would always work and to write a six line algorithm. This algorithm and the initial designs led to the first Technical Report (HCIL TR 91-03) in March 1991 which was published in the ACM Transactions on Graphics in January 1992 (http://www.acm.org/pubs/citations/journals/tog/1992-11-1/p92...). Choosing the right name took probably as long, but the term 'treemap' described the notion of turning a tree into a planar space-filling map.
My initial design simply nested the rectangles, but a more comprehensible design used a border to show the nesting. Finding an effective visualization strategy took only a few months but producing a working piece of software took over a year. Brian Johnson implemented the algorithms and refined the presentation strategies while preserving rapid performance even with 5,000 node hierarchies. The TreeViz application ran on color Macintosh models and led to the widely cited paper (HCIL TR 91-06) jointly authored paper in the October 1991 IEEE Conference on Visualization. This paper was reprinted in Readings in Information Visualization. I think treemaps are a convenient representation that has unmatched utility for certain tasks. The capacity to see tens of thousands of nodes in a fixed space and find large areas or duplicate directories is very powerful. I still use TreeViz for cleaning up my Macintosh. It does take some learning for novices to grasp the tree structure layout in treemaps, but the benefits are great.
PhD student Brian Johnson's implementation added many other interesting features such as zooming, sound (as a redundant or independent code, for example, larger files had a lower pitched sound), hue/saturation control, many border variations, and labeling control. We struggled to deal with the problem of many small files in some directories, but wound up showing only a blackened area that invited closer examination by zooming. We knew that encoding a linear variable such as file size as an area was breaking a graphic design guideline, but the benefits of seeing a large range of file sizes seemed like a compensation. We also knew that visually comparing long narrow rectangles to squarish ones was problematic, but cursoring over the boxes produced the exact file size on the bottom of the display.
[...]
A bit of googling also turns up http://eagereyes.org/blog/2008/fisheye-calendar-at-yahoo.htm... and a PDF of Bederson's paper on Fisheye calendars http://www.lib.umd.edu/drum/bitstream/1903/1201/1/CS-TR-4368...