Presenting our visualisation and next steps

With outside Javascript help, the structure of the visualisation has improved and most of the content is now in place. We were happy that we managed to get features such as visualising the main CAN bus connection and the filtering of team responsibilities working.

This project has taught our group many things about managing a information visualisation project, and we got to know new valuable tools and methods. Especially the user involvement parts, both in class and in the Aalto-3 meetings, have been insightful. We could have had a more structured and organised start for our work, however, and would have benefited of some instructions for the conceptual design part of information visualisation.

Presenting our process and work at class resulted, again, in useful feedback and tips for improving the visualisation. Explaining the visualisation’s connectedness to the satellite’s physical structure better seems like a key thing to do. We should definitely test how this problem can be tackled with our intended solution, showing an explanatory video in the beginning of the visualisation.

There were some improvement suggestions that we had recognised already, but hadn’t figured out how to fix them, partly because the limitations of the go.js library – it has features that have caused difficulties in our work, and refining the layout to look exactly like we would like has been surprisingly complicated with the library. The current version of our visualisation spreads out too long vertically, for example, and there seems to be no shortcut to avoid this, without moving away from the go.js.

That said, as a next step it would make most sense to revise and finalise the code by either combining it with other, more powerful libraries, or to continue without any library altogether. As our team doesn’t quite have the skills needed for this, nor the time to learn those skills from scratch, we decided to leave the coding work be for a while. Next we intend to give the code base for the developers inside the Aalto-3 people to see and evaluate, and perhaps with their participation the coding work can advance more efficiently.

We were happy to hear that even though the work isn’t finished, the early versions and the process itself already have been somewhat useful for the team members of Aalto-3. Taking part in testing and proofreading our visualisations has helped them discuss their project across teams, conceptualise it in their minds and understand it in a more holistic manner. This shows how visualisations can have the power to get people talking and guide them to be “on the same page”.

The evolution of our work:

It was nice and inspiring to see the work of other groups as well.

Thank you for the course, both lecturers and classmates!

User involvement

Direct user involvement has been essential when developing the visualization. Our team has been closely involving with the end users- Aalto-3 team starting from learning the needs of the team finally to developing the visualization.

In our joint meetings, Aalto-3 team members were writing directly the comments on our draft version. It has been valuable to learn directly from the team the contents, what is the team working on so we could build upon it the concept and the logic of visualization.

It was very interesting to see how visualization brought Aalto-3 team together to discuss themselves what they are working on- who is doing what in the context of the whole project. There have been some findings for the team itself. For instance, discussions on the payload of the satellites and experiments, that are very crucial for the whole project. The team has been updating the contents, it has helped them to understand what parts may need more attention or clarification, to see if there is any incompatibility. At the same time, it has been quite challenging as the satellite project is ongoing and constantly evolving, thus, the contents are changing.

Discussions with the team brought us some new functions/filters that we haven’t thought of. For instance, a filter to show the connections between the satellite components- ‘’if the team changes one element, what part of the satellite it would affect’’. Also, showing the power budget of the subsystems and the satellite. Visualization has been building up a dialogue on what is needed to know for the whole team. This often comes as a challenge to Aalto-3 team due to big group size, subteam working simultaneously and students changing following the academic year. Thus, it was glad to see that an early prototype is already serving its purpose.

Regular feedback sessions have helped us to refine the concept, contents and to make sure that it meets the needs of the team, supporting the team workflow.

Animating a proto

We decided to use the animation part of the course for testing some of the interactions and transition animations we had previously planned for the visualisation, and testing some general visual possibilities.

Similarly as when making a paper prototype, making this animated proto forced us to think about some aspects we hadn’t thought about before, and also gave some new ideas, such as using opacity as a highlighting effect. Even though the actual animations here are not refined, the proto can provide some overall feeling of how things could be. It’s not clear yet how much of this we’ll end up implementing into the final work – that will depend on how difficult different features are to code, as well as the possibilities of the GoJS library.

GoJS Library

Since our group members don’t have much coding experience and our time for the visualisation is limited, we searched for possible code libraries that could ease the workload for us. GoJS is a JavaScript library that can be used to create different kinds of interactive diagrams. There are ready-made samples for flow charts, organisation charts, timelines, mind maps, network visualisations, decision trees and even floor plans, among many others. For our visualisation, we chose to use one of the most simple diagram formats found in GoJS. There would be many other more fancy-looking dynamic possibilities available the library, such as force directed or user-controlled layouts, but those seem to be unnecessary for our case. After all, our visualisation is depicting an existing physical structure, where too much dynamics, such as allowing the diagram’s parts to be moved around the canvas would most likely be confusing for viewers.

Many samples in Go.js are have a dynamic layout the user can edit, but with our visualisation these kind of affordances could make the whole thing just a mess.

After getting started with GoJS, the library doesn’t seem too difficult to use. The main issue with using a libraries like this, however, is that they don’t always allow freedom in places you’d expect. Simple visual adjustments, such as precisely placing connection lines or resizing margins can be more difficult than without a library. Despite that, it seems that the simplicity and static nature of our visualisation works for our advantage at this point. Even though it will have a lot of components and quite a lot of content in it, the interactions we’re aiming for are pretty basic and hopefully there won’t be anything too difficult for us to handle.

The first coded version of our visualisation has a modest look.

Analysing data and ERD

As a class exercise, today we drew ERDs – Entity-Relation Diagrams of our visualisation’s data. ERDs seems like useful tool, when one has different kinds of data and needs a clearer comprehension of how the data types can be classified and organised, and how the different parts of information are linked to each other. In our case of visualising Aalto 3 satellite, we had already conducted lists and categories of our information in the previous design phases. After getting the hang of what an entity-relation diagram actually is, the task didn’t take us much time. The nature of our visualisation, which describes a physical structure, led to a quite simple diagram, that didn’t teach us that much new of our data, but showed some relations and conceptual possibilities that we hadn’t thought of before. Using this tool could have been more meaningful for our visualisation if done in an earlier phase.

A plus side of the ERD method is that it simplifies the listing of items. Instead of writing the names or even the total number components, we can look at just one entity called “component” and see what information goes under it.

Paper prototyping

Assembling a paper prototype of our Aalto 3 visualisation took some hours, and at first our group thought it was too early for us to even do that phase – after all, we didn’t have completely clear understanding of our subject yet, and weren’t sure how to visualise it. However, the method happened to be somewhat helpful for the design work, as it forced our group to think about the structure of the visualisation in more detail and this helped us understand some of the data better than before. We separated the information we had, the different parts and functions of the satellite, into categories and thought about how to organise them. It felt natural to separate these categories by colour. While planning the paper proto, we also figured out how we could use timing and interactions, maybe even a separate landing page, to create a narrative for our visualisation. We ended up with a structure that somewhat followed the formerly studied Visual Information Design Mantra: overview first, then exploration and filtering of content and more detailed information visible by demand. Even though paper prototypes don’t need to look neat or polished in order to work, we quickly noticed that in our case it was smarter to draw the whole thing into Illustrator and print it, as hand-written texts take a lot more space and with our information structure, a hand-drawn model would have been too large to handle. At the end, our printed prototype looked very nice and depicting things like transition animations or interaction states was easy and clear with it. The actual prototype testing configured in class showed us that we still need to clarify many things in our layout. The biggest issue for us might be that test users had a hard time understanding what our visualisation was actually about – they were missing the fact that the structure they saw formed a satellite, and that it had four different layers. This information is something we had tried to include in an introductory text, but the test revealed that people don’t always read such texts. We agreed to try to fix the problem by showing an image (or video) of the satellite’s four layers first, and relating the visualisation’s colours to these layers. Some other feedback from the test that we are going to implement: - Clearer visual hierarchy between important and less important parts of the visualisation - A legend of categories should reflect the exact highlighting style of components - Filtering of teams should be clearly separated from filtering of components Outside our classroom setting, some other feedback was collected from the Aalto 3 team. They didn’t have as much problems understanding the graph, but were willing to see even more details in it. Wishes from the team: - Power budget of different parts could be interesting to see. Which parts in the cubesat are the most power intensive? - Would be interesting to see how different components are connected, and how changing one component would affect the whole system The Aalto 3 team has different needs for the visualisation than laypeople, and our team will still have to figure out how to combine these needs in a sensible way.

Aalto 3 team members evaluating the visualisation sketch

On top of their suggestions, the team wrote some corrections on the visualisation – this is what we’ll tackle next.

Visualizing space technology network.  Getting to know!

After having chosen the direction, work continues! This time we were going into further refining the project concept by involving the target users (Aalto- 3 project team), learning their needs and further developing our project idea.

To recap, our initial project idea has been to visualize the network of people and different organizations involved in Aalto-3 open source satellite, so as to communicate for a larger audience- ‘What it takes to build the satellite?’

However, after getting involved with Aalto-3 project team, we have learned other areas where information visualization could be of great help for the project team.

Aalto-3 cubesat prototype 

Problem areas identified after getting involved with the team:

Due to different subteams and disciplines working at the same time on different parts of the projects, it is challenging to keep the whole team on the same page.

Hard to have an overview of how changing one component would affect the whole satellite.

High rotation of the team members (highly dependent on the semester terms) frequently requires onboarding of the new members.

Involvement with the target users has opened new angles for the project and helped in designing it in such a way that it has a value for the target group. User involvement has been especially relevant for us, as the topic is very specialized and outside our field of expertise, which simply could lead us in missing out important things, issues that we can address through visualization.

Having learned from the users we decided to drift our focus from visualizing organizational network for the outside stakeholders to visualizing the technical network.

Aalto-3 team has an initial visualization of sub-systems network. Our team in the project is taking it to develop further. The process will take further refining the contents and structure of visualization, building the narrative and translating these contents into a user-friendly dynamic visualization.

Sociograms and network topologies

Social network visualisations, or sociograms, are graphical representations of social structures.

They can be used to describe different kinds of links or interactions between people – social relations, channels of influence, or lines of communication, for example.

Some of the earliest sociograms were developed in 1930s by an American psychiatrist and psychosociologist Jacob Moreno, who analysed choices and social preferences among a group of school children.

Moreno’s sociograms showing children’s preferences about who they’d like to sit next to. Source: Koponen, Hildén and Vapaasalo 2016: Tieto näkyväksi. Aalto-yliopiston taiteiden ja suunnittelun korkeakoulu, Helsinki.

Topologies

Network topology means the arrangement of the elements (links, nodes, etc.) of a network. The following models of network topologies have originally been created to define or describe the arrangement of telecommunication and computer networks, but the same graphic models seem to work well with sociograms as well:

- Point-to-point: the simplest topology, with one link between two endpoints.

- Bus: several nodes are connected to a shared line of interaction or information

- Star: a central hub connecting other nodes, making them indirectly connected

- Tree: a network combining star and bus topologies, with a hierarchy

- Ring: a closed loop of connectivity, where interaction or information can travel to one or two directions

- Partially connected mesh: some nodes are more connected than others

- Fully connected mesh: all nodes are interconnected to each other

Many networks combine these basic forms, forming hybrid topologies. (For example a snowflake topology is a star network of star networks.)

Source: Wikipedia, Network Topology

When visualising social networks, these topologies are quite easily distinguishable from each other and can help us understand the nature of a network.

Even though in common language we often refer to social networks as our natural relations to friends, family and other people, a social network can mean many other things as well: it can be a very temporal social structure linked to a certain situation, for example people working on a project, or forming a sudden bucket brigade to stop a fire. Or, a network can be formed to follow a certain structural model and purpose, like official governments or military squads.

Source: Christakis and Fowler, 2010. Connected. Harper Press, Croydon, UK.

It’s interesting to see what kind of network model we get from visualising the collaboration of Aalto 3 work groups, and whether the shape of the network will reveal us something about how they work.

Edge bundling: decluttering  network visualisations

When large data sets are visualised, they often suffer from visual clutter that obscures the actual information or prevents the user from being able to understand any of it at all. Think of a visualisation of a large network, for example, with thousands of nodes and interlinked edges that overlap and occlude each other. Filtering, sampling and clustering the data could help make sense out of cluttered visualisations to some extent, but there is also a more recent technique for clutter reduction, that’s become growingly popular in information visualisation after the late 2000s. The method is called Hierarchical Edge Bundling (HEB) and it was originally developed by Danny Holten in Eindhoven University of Technology.

Edge bundling is systematical organising of visual elements, and the base idea in it is simple: edges that represent similar information are deformed and grouped into bundles. Avoiding edge crossings and overlapping in a visualisation is an effective way to improve its clarity.

The technique works well with common node-link-network graphs, but also with circular graphs, tree graphs, arch diagrams and parallel coordinates plots. In many cases, it not only removes clutter from a visualisation, but also enables the main patterns of its data to be seen more evidently. Bundling edges also supports the use of other visual means, such as colours and opacities to further highlight certain bundles or their differences compared to each other.

In the following example made by Darkhorse Analytics, migration routes in the US were first bundled and then visualised with small, animated dots. Several iterations of this map can be seen in the company’s blog post: 

There are several ways for how the bundling itself can be formed and calculated – the maths can be based on the illustrative style chosen for the visualisation, but also on an existing geometric structure (such as a grid or a tree structure). Sometimes the bundling algorithms are built to just minimise costs, such as usage of processing power, or amount of ink needed to print the resulting graph.

In today’s dynamic and interactive visualisations, edge bundling is widely in use, and with large data sets that have a lot of interconnections, it can be considered almost as a necessity. However, finding the right way to bundle your data and making it look insightful might demand a lot of time and iterations. If your network visualisation is already rather simple or doesn’t have a lot of long edges and multiple edge crossings, consider whether it will benefit from edge bundling at all.  

Several ready-made algorithms for edge bundling can be found in the D3.js library. See for example, Mike Bostock’s example. 

More about making nicer and cleaner node-link graphs in Kineviz’s blog post here.

See Holten’s original research on Hierarchical Edge Bundling here. 

Project Topic + Scenarios

In this class, we were introduced (or reintroduced) to the process of creating scenarios for design projects. Scenarios are specific “stories” for a typified user or users who will ultimately use the design outcome. The purpose of the exercise is to imagine yourself as a user rather than a designer. By imagining the motivations and tasks that need fulfilling, the designer is able to better account for essential requirements of the design. They can also reveal natural design choices before committing to any by keeping them in a written outline.

The exercise seemed familiar to most of the students but I usually find it useful to review a concept before practicing. Our group initially struggled with writing the scenarios because we still didn’t feel that we had a clear project idea. In the previous class we decided we wanted to do something involving space exploration but had concerns about how to source data and the scope of the project. We spent the majority of class time discussing what we would find fulfilling in a project but also what was possible within the scope of the class.

In order to execute the class assignment, we each devised scenarios for what we liked most about the initial idea and then presented those scenarios to the group. I believe that through this process we communicated to each other the variety of interests within the initial topic. In the end, we chose to take on Viktorija’s project idea of showing the network of organizations and students involved in the development and launch of the Aalto-3 satellite. She is familiar with the project because she is undertaking a minor in Space Science and Technology at Aalto.

The final topic seems to bring together elements from each of our scenarios. We want the project to have relevancy and direct application, we want the data to be manageable and accessible, and for it to contain some aspect of space exploration.

The next steps we’ll undertake will be to learn about the network of actors involved in the project, gather information about the project, interview those stakeholders that are involved in the project to understand what role each actor plays, and begin prototyping.

We left the class satisfied with our direction. The decision-making process was practical and necessary to move forward to the next stage.

Post 3 - Introduction to Visual Information Seeking Mantra 2.0

Our group is going to talk about Visual Information Seeking Mantra. When doing the research, we found a new VISM version called Visual Information Seeking Mantra 2.0. Here is a simple introduction to Visual Information Seeking Mantra 2.0, which helps to understand more about the problems of original VISM and the new VISM, and future development issues.

The original Visual Information Seeking Mantra(VISM) proposed by Shneiderman in 1996 [1], which is a guideline for designers to present visual data to users in an effective way. Later, numbers of analysis and criticisms were made for it. For example, in Beyond Guidelines:

What Can We Learn from the Visual Information Seeking

Mantra? [2] The paper discusses the problems of lacks of scientific validation of VISM. A review and extension of the Visual Information

Seeking Mantra (VISM) [3] introduced an improvement of VISM called VISM 2.0, which is based on previous analysis and criticisms by other literature.

VISM 2.0 has two different parts. One is the User-Centered Development (UCD) process, and the other one is the actual VISM 2.0 part. UCD process also known under the term human-centred design process, consists of Analysis, Design, Evaluation, Implementation and Deployment. The first three phrases,  Analysis, Design, Evaluation, are more important than the last two ones for VISM 2.0. However, well-designed UI concepts do not work without Implementation and Deployment process, so the UCD process has to be five stages. Furthermore, VISM 2.0 is considered as a framework which has to be used during the Design step.

The actual VISM 2.0 part has two task groups as same as the original one. The differences between these two versions are the contents of Main Tasks and Support Tasks. In Main Tasks, Zoom-In and Zoom-Out took the place of Zoom, regarding the paper of B. Craft and P. Cairns [2], which points that zooming-in and zooming-out are different cognitive tasks. Relate is added to the Main tasks and grouped with Detail, composes to be A Multi View, which means different tasks can be shown into one display. Therefore it is possible to integrate multiple data sources simultaneously. Moreover, all Main Tasks are connected to each other that allows users to switch smoothly from different tasks and contribute to dynamic UIs. When it comes to Support Tasks, a new task called Collaboration is added, because consider a large amount of data exist nowadays, the works of data analysis and information search will be more and more collaborative.

VISM 2.0 may solve some of the problems of the original one. However, some criticisms remained. It provides a dynamic framework that supports different data types shown in the display and added a new task of collaboration. On the other hands, it still misses the measurable validation and does not provide any design patterns on how to support the different tasks as well as the original one, which should be considered in the future research [3].

*All the figures are from “A review and extension of the Visual Information Seeking Mantra (VISM)”

[1] B. Shneiderman, “The eyes have it: a task by data type taxonomy

for information visualizations,” in Proceedings 1996 IEEE Symposium

on Visual Languages. IEEE Comput. Soc. Press, 1996, pp. 336–

343. [Online]. Available: http://ieeexplore.ieee.org/xpls/absn all.jsp?

arnumber=545307

[2] B. Craft and P. Cairns, “Beyond Guidelines: What Can

We Learn from the Visual Information Seeking Mantra?” in

Ninth International Conference on Information Visualisation

(IV’05). IEEE, 2005, pp. 110–118. [Online]. Available:

https://ieeexplore.ieee.org/document/1509067

[3] M. Stauffer, R. Ryter, R. Dornberger and D. Hil, “A review and extension of the Visual Information Seeking Mantra (VISM)”, Institute for Information Systems, School of Business, University of Applied Sciences and Arts Northwestern Switzerland, 2016. [Online]. Available: http://www.iiis.org/CDs2016/CD2016Spring/papers/ZA490ND.pdf

Post 2 - Development of the Presentation and Task of Analysis

In this class we came together as a group to decide how to present out topic the “Visual Information-Seeking Mantra”. We had all looked into the subject to some degree after the first class but spent a good chunk of the class time reconciling what we knew about the subject. 

We analyzed three papers, one being the original text in which the concept was presented. From there we discussed the relevancy of the theory and how developments have occurred since it was written in 1996.

This development and critical analysis of the concept has become half of our presentation, as we decided it helps contextualize the work but also reveal where the concept rings true.

For example, many of the user tasks for information retrieval have been supplanted by the computer and phone’s interface. History and extraction concepts are now guaranteed by the device through access to metadata and 3rd-party software, such as Screenshot.

Between now and the next class, in which we will be presenting the topic to the rest of the class in groups, we intend on finishing the presentation and devising ways in which we can include the listeners in the explanation of the concept.

One of the examples we intend on showing is a visualization called Radio Garden. It is an interactive map in which you can listen to various radio stations in real-time throughout the world. While it does not include accommodations for all the user tasks mentioned in Schneiderman’s original paper.

http://radio.garden/

Post 1 - Introduction to the Class and Group Formations

In the first class of DOM E5126 - Dynamic Visualizations we were introduced to the topic of dynamic visualizations, which as I understood it covers data visualizations that are non-static. These visualizations do not have to be interactive but must responsive to real-time or manipulable data.

Upon hearing about the structure of the course, I think some of the students were a bit overwhelmed by the tasks. The majority of the students seem unexperienced in programming but I know that many are currently taking classes in javascript. I for one am not too worried about the technical side. I am more concerned about how to agree upon a project idea that satisfies everyone in my assigned group.

After we were grouped, we chose the topic for our Theory Presentation assignment to be the ‘Visual Information Mantra,’ which revealed to be (after a quick Google search) visual design guidelines that provide a framework for designing Information visualization applications. Whether or not these guidelines have been designed by one person or a group of like-minded thinkers remains to be seen.

Since our group is made up of students from different programs (New Media, Creative Sustainability, Visual Communication Design/Information Design) I expect that we will each bring our own perspectives and motivations to the upcoming group work. I am curious to see what develops and am particularly interested in the iterative testing and refining process that we will undergo with our prototype.