Growing Bloom: Design of a Visualization of Project Evolution Bloom Diagram is a tool to visualize the evolution of individual participants' code and comment contributions to open source software projects. The design blends techniques such as concentric pie charts, animation, motion trails, and social proxies to produce a compact presentation of the large scale dynamics around software development.

Bernard Kerr, Li-Te Cheng {presenter}, Timothy Sweeney

This work should be of great interest to software engineers, and those interested in understanding work patterns in software engineering. The paper discusses open source software, conceived for the purposes of the visualization as software made out of contributions by many individuals. Using a screenshot of a Sourceforge project page, the presenter talked about how the website supports the discovery of

• in people who are contributing  to the projects

• Activity, people who are interested, participating

• A whole host of statistics about activity

• Which doesn't give you a sense of who is doing what

• Have to go to the email archives and bug reporting system to get a sense of what is going on

• Or the version control

In order to come up with a representation of activity in the project, the representations was analysed from three dimensions.

• Code & Comments

• People and events

• Bloom diagram

How they arrived at the visualization

• Commenter vs coder via counts

• Sort events to arrive at table

• Wrap table around into a circle

• Smooth sectors to form tracks

• Add dots to represent activty: dots move outward with time, and inward with activity, thus bouncing reveals activity

This was followed by a demonstration of the software. Reflecting upon the work, the presenter pointed out that the representation looked at individuals,  not relationships, provided a static backdrop representative of the whole time period instead of a dynamic foreground, and was evaluated only using informal show and tells

Questions:

• The trails are only a section of time, but the backdrop is the complete perspective. Without the time frame, how do you generate that backdrop?
• This is not good for streaming data sets, you might have to cache data for a time frame to get an interesting backdrop
  

• I'm troubled by this presentation. It seems that you've chosen representations that aren't necessarily in support of some task. Every representation conceals and reveals, and I'm wondering what this could be valuable for...
• Definitely didn't try to start with a set of users or requirements, because it was a design activity, short term. Not the most efficient way of showing it, but it is one way of showing it. It may not become something usable, but it is a good prototype for us to explore.
  

• What is it that you're going to learn from doing this?
• Two things: what is going in open source projects, what is the notion of contribution. The infrastructure we create may not be useful for everyone, but it may be part of this. We run an internal ibm source forge, and this is a way for us to understand that activity, and a vehicle for us to converse with our colleagues about how to create better representations

Scalability in System Management GUIs: a designer's nightmare Designing effective interactions and representations of large systems with intricate relationships among components is a formidable challenge. The presented approach addresses these challenges by extensive use of semantic zooming and progressive information disclosure.

Andreas Dieberger {presenter}, Eser Kandogan, Cheryl A. Kieliszewski

 The authors discussed here their experience of designing a monitoring and exploration representation for network systems administrators, and how the requirement to design for one extremely rare use case almost derailed their design solution. This work was done at IBM's Almaden research lab, 

• Goal: to help project division replace their antiquated topology viewer
• System admins sit down every few months and draw a new map
• Not efficient, so make it more efficient
• Representation design challenges for storage environments
• Large -> scalability
• Distributed - how to find things
• Very diverse: different systems, vendors, UIs
• Typical user interfaces are problematic, arcane etc

In the team, only one of the members had storage expertise, which according to the authors was in hindsight probably a good thing. 

• Overall design challenge: represent a highly complex environment
• Show high level and low level information
• Sometimes at same time
• Too much information
• Overall approach: Shift complexity from visual design to interaction design

It was at this point that the authors discussed the boundary use case, defined as a "a rare situation given disproportionately high weight in the design process...". Boundary conditions are are a process issue, which may lead to non-optimal design solutions, as the authors described. 

• Example: large fibre-channel switch
• One special type of switch with 500+ ports
• Requirement: be able to monitor individual ports
• Reality: huge switches get virtualised into smaller, logical switches
• Admins virtualise switches to keep system manageable
• Because only one of us had storage background, we didn't catch it earlier
• Therefore, no real need for showing all the ports
• But we have to, anyway!

Thus, for the authors, the pressure to support that boundary condition, which they couldn't find users for, interfered with their ability to come up with a clean solution. They then described their solution:

• Semantic zoom
• Dynamic grouping
• Selectively enrich visualization through overlays
• Pinning

This was followed by a demo, and the authors reiterated:  "Remember: beware of boundary use cases!"

Questions:

• I didn't see any way of drilling up?
• Well, other than merely retracing our path, it would have been hard to implement that because that is essentially asking the system to "group nodes that are like this one". We didn't have so much analytics running in the background

• Well, I'm going to reinterpret the title of this session slightly, and ask you how you communicated the design of these representations to your users during the design process...
• We didn't actually work off of data collected only during this project: we relied on data and practices and requirements documents that had been collected over the past few years, and although we had only one storage expert, we had connections and frequent dialogue with other storage experts, HCI experts, and other designers, and often met with them to discuss the design.

• About the icons you use  - I have seen red and green colours, are there any problems associated with that. And have you tried using plus and minus signs lik