InfoVis:Wiki - User contributions [en]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2008-01-03T17:51:39Z

UE-InfoVis0607 0727197:

== Aufgabenstellung ==

Aufgabe ist das Design einer interaktiven Visualisierungsapplikation zur Darstellung und Exploration (des zeitlichen Verlaufs) von Laborwerten einer Blutuntersuchung. BenutzerInnen, Einsatzzweck, Tasks, etc. sollen von Euch selbst festgelegt und beschrieben werden.

[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe4.html Beschreibung der Aufgabe 4]

=== Beispiele für derartige Datensätze ===

[[Image:20061115_blutuntersuchung.jpg]]

[[Image:20070920_blutuntersuchung.jpg]]

== Application Area ==
The temporal change of laboratory values obtained by blood examinations needs to be analyzed.

=== Data ===
A patients blood can be examined several times. Each time, a certain set of attributes - like cholesterol or glucose - can be evaluated. Every attribute takes a discrete value and has its own unit, for example the unit for cholesterol is mg/dl. So we have 2-dimensional data, with a temporal dimension, that is hierarchically grouped by patient.

The non-critical range of values an attribute can take is known. Therefore each value can be either critical or normal. Each attribute has a lower (which can be 0) and upper boundary defining the range of normal values. Sometimes, no boundaries are specified.

=== Target Group ===
The data needs to be evaluated by physicians or nurses. They basically need to be able to see if the laboratory values are normal or critical. They also need to track changes over time, for instance to see if a certain therapy yields the desired effect. Furthermore it may be interesting to compare specific values and their change over time between a number of patients. It doesn't make sense to compare the different attribute's values to each other, but since physicians and nurses are very busy it is necessary to see them all at once to quickly scan the whole data set for interesting or possibly critical values.

=== Goals ===
To guide our design, we first define use cases we want to support and order them descending by priority (most important first).

==== Evaluate New Blood Examination Values ====
A blood examination has taken place and the user wants to quickly check the results. This can yield to the following:
* Everything is fine. The neither the system nor the user detects something critical. The user can go and make a coffee break or be very cautious and analyze the values in detail.
* The system detects a critical value and presents it accordingly to the user. The user can either draw conclusions immediately or analyze the values in detail.
* The user detects a possibly critical or interesting value, which needs to be analyzed in detail. The possibilities here are manifold: The user may needs to compare different attributes as well as patients or historical values as well as any combination of these. In other words, exploration must be easy and should be encouraged.

==== View Blood Examination History ====
The user can gain more insights from laboratory values when examining them in comparison to historical values. This is part of a detailed analyzation and therefore the system does not need to give an overview of the history of all attributes at once, but rather lets the user choose single or multiple attributes to examine in detail and possibly compare over time.

==== Compare Patients ====
It may be interesting to compare the laboratory values of two or more patients. This can be done for specific laboratory values at a given moment or for a given interval.

== Design ==
[[Image:blood_examination.png]]

The user interface is divided into 4 parts:
=== Patients ===
The user chooses at least one patient to look at. If more than one is chosen, one of them is the ''primary'' patient, which is to be compared with the other patients. By clicking on a patient, it can be made the primary one.

=== Timeline ===
The timeline represents the interval between the first and the last blood examination of the primary patient. Each blood examination is depicted by a vertical line. One of the blood examinations can be selected by dragging the white triangle near its position in the timeline. The selected blood examination is also highlighted by a longer vertical line that also establishes a connection to the ''History View''.

The timeline can also act as a range slider with two handles to reduce the displayed interval in the ''History View'', although this is only necessary if the number of blood examinations exceeds a certain limit.

=== Single Blood Examination View ===
This view displays the examination selected in the timeline. To present the results of a blood examination at a given point in time and make a quick evaluation of all attributes at once easy, we use a 'Parallel Coordinates' visualization. Here, the values of the different attributes are normalized between the specific lower and upper boundaries of each attribute. This helps the user to quickly spot the normalcy of a whole set of laboratory values - the straighter and more centered the line is, the better the blood values are. To make the distinction between critical and normal values clear, the background of the normal range is different from the background of the critical range. This support can be enhanced by adding points to each connection, where its size reflects the criticality of the given value. The point can also turn red, when the value lies outside the non-critical range. When no critical range is specified, the visual distinction should be omitted, the line should be drawn to the center but the value must be highlighted to draw attention and encourage further examination.

The view can be configured to also display a certain number of blood examinations in history, e.g. the last 3 blood examinations before the selected one. The older the examination is, the thinner and more transparent its representing line gets. This gives the visualization a spatial look and supports tracking changes over time.

The view can display more than one patients, where each patient is identified by a unique color. The primary patient is highlighted and displayed above the other patients. As the dates where blood examinations have been conducted can vary between patients, the test results must be selected for each patient. The default values to display may be the values of the latest blood examination. The displayed test can be selected by clicking on a patient thus making her the primary patient and moving the triangle in the timeline to the desired date. Another possibility is to simply click one of the lines representing a blood examination before the selected test. When the selected test of the primary patient is changed, the selected tests of all other patients stay the same, of course.

Attributes can be reordered by drag and drop, to enable the user to place desired attributes side-by-side for easier comparison.

Attributes can also be highlighted to display detailed information about its value, upper and lower boundary for normal values and its midpoint.

Attributes with missing values are highlighted using red color to draw attention.

=== History View ===
When the history of conducted blood examinations needs to be examined, the ''History View'' can be made visible by clicking the disclosure triangle on the left side of each attribute. After clicking the triangle a little animation starts. The bar (in this case with two values) is copied, turned vertical and all the additional values are added from the left and the right side, to make it easier to recognize the now different dimension of the data.

The History View is basically a line graph where the x-axis represents the time selected in the timeline and the y-axis the laboratory values. As in the Single Blood Examination View the non-critical range of values is optically separated from the critical range. In addition, labelled vertical lines partition the y-axes and help determining unlabeled values. Light vertical lines are drawn for each blood examination of the primary patient.

The selected blood examination displayed in the Single Blood Examination View and selected in the timeline is highlighted by a strong line which can be dragged to change the selected blood examination. The actual value of the selected attribute is also displayed.

Lines depicting the values of non-primary patients can be dragged to compare them with the selected blood examination of the primary patient.

=== Visualization Controls ===
The visualization can be modified here. The user can set the number of tests to display in the detail view. Furthermore, the attributes can automatically be sorted by name or criticality.

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2008-01-03T17:49:52Z

UE-InfoVis0607 0727197:

== Aufgabenstellung ==

Aufgabe ist das Design einer interaktiven Visualisierungsapplikation zur Darstellung und Exploration (des zeitlichen Verlaufs) von Laborwerten einer Blutuntersuchung. BenutzerInnen, Einsatzzweck, Tasks, etc. sollen von Euch selbst festgelegt und beschrieben werden.

[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe4.html Beschreibung der Aufgabe 4]

=== Beispiele für derartige Datensätze ===

[[Image:20061115_blutuntersuchung.jpg]]

[[Image:20070920_blutuntersuchung.jpg]]

== Application Area ==
The temporal change of laboratory values obtained by blood examinations needs to be analyzed.

=== Data ===
A patients blood can be examined several times. Each time, a certain set of attributes - like cholesterol or glucose - can be evaluated. Every attribute takes a discrete value and has its own unit, for example the unit for cholesterol is mg/dl. So we have 2-dimensional data, with a temporal dimension, that is hierarchically grouped by patient.

The non-critical range of values an attribute can take is known. Therefore each value can be either critical or normal. Each attribute has a lower (which can be 0) and upper boundary defining the range of normal values. Sometimes, no boundaries are specified.

=== Target Group ===
The data needs to be evaluated by physicians or nurses. They basically need to be able to see if the laboratory values are normal or critical. They also need to track changes over time, for instance to see if a certain therapy yields the desired effect. Furthermore it may be interesting to compare specific values and their change over time between a number of patients. It doesn't make sense to compare the different attribute's values to each other, but since physicians and nurses are very busy it is necessary to see them all at once to quickly scan the whole data set for interesting or possibly critical values.

=== Goals ===
To guide our design, we first define use cases we want to support and order them descending by priority (most important first).

==== Evaluate New Blood Examination Values ====
A blood examination has taken place and the user wants to quickly check the results. This can yield to the following:
* Everything is fine. The neither the system nor the user detects something critical. The user can go and make a coffee break or be very cautious and analyze the values in detail.
* The system detects a critical value and presents it accordingly to the user. The user can either draw conclusions immediately or analyze the values in detail.
* The user detects a possibly critical or interesting value, which needs to be analyzed in detail. The possibilities here are manifold: The user may needs to compare different attributes as well as patients or historical values as well as any combination of these. In other words, exploration must be easy and should be encouraged.

==== View Blood Examination History ====
The user can gain more insights from laboratory values when examining them in comparison to historical values. This is part of a detailed analyzation and therefore the system does not need to give an overview of the history of all attributes at once, but rather lets the user choose single or multiple attributes to examine in detail and possibly compare over time.

==== Compare Patients ====
It may be interesting to compare the laboratory values of two or more patients. This can be done for specific laboratory values at a given moment or for a given interval.

== Design ==
[[Image:blood_examination.png]]

The user interface is divided into 4 parts:
=== Patients ===
The user chooses at least one patient to look at. If more than one is chosen, one of them is the ''primary'' patient, which is to be compared with the other patients. By clicking on a patient, it can be made the primary one.

=== Timeline ===
The timeline represents the interval between the first and the last blood examination of the primary patient. Each blood examination is depicted by a vertical line. One of the blood examinations can be selected by dragging the white triangle near its position in the timeline. The selected blood examination is also highlighted by a longer vertical line that also establishes a connection to the ''History View''.

The timeline can also act as a range slider with two handles to reduce the displayed interval in the ''History View'', although this is only necessary if the number of blood examinations exceeds a certain limit.

=== Single Blood Examination View ===
This view displays the examination selected in the timeline. To present the results of a blood examination at a given point in time and make a quick evaluation of all attributes at once easy, we use a 'Parallel Coordinates' visualization. Here, the values of the different attributes are normalized between the specific lower and upper boundaries of each attribute. This helps the user to quickly spot the normalcy of a whole set of laboratory values - the straighter and more centered the line is, the better the blood values are. To make the distinction between critical and normal values clear, the background of the normal range is different from the background of the critical range. This support can be enhanced by adding points to each connection, where its size reflects the criticality of the given value. The point can also turn red, when the value lies outside the non-critical range. When no critical range is specified, the visual distinction should be omitted, the line should be drawn to the center but the value must be highlighted to draw attention and encourage further examination.

The view can be configured to also display a certain number of blood examinations in history, e.g. the last 3 blood examinations before the selected one. The older the examination is, the thinner and more transparent its representing line gets. This gives the visualization a spatial look and supports tracking changes over time.

The view can display more than one patients, where each patient is identified by a unique color. The primary patient is highlighted and displayed above the other patients. As the dates where blood examinations have been conducted can vary between patients, the test results must be selected for each patient. The default values to display may be the values of the latest blood examination. The displayed test can be selected by clicking on a patient thus making her the primary patient and moving the triangle in the timeline to the desired date. Another possibility is to simply click one of the lines representing a blood examination before the selected test. When the selected test of the primary patient is changed, the selected tests of all other patients stay the same, of course.

Attributes can be reordered by drag and drop, to enable the user to place desired attributes side-by-side for easier comparison.

Attributes can also be highlighted to display detailed information about its value, upper and lower boundary for normal values and its midpoint.

Attributes with missing values are highlighted using red color to draw attention.

=== History View ===
When the history of conducted blood examinations needs to be examined, the ''History View'' can be made visible by clicking the disclosure triangle on the left side of each attribute. After clicking the triangle a little animation starts. The bar (in this case with two values) is copied, turned vertical and all the additional values are added from the left and the right side, to make it easier to understand the now different dimension of the data.

The History View is basically a line graph where the x-axis represents the time selected in the timeline and the y-axis the laboratory values. As in the Single Blood Examination View the non-critical range of values is optically separated from the critical range. In addition, labelled vertical lines partition the y-axes and help determining unlabeled values. Light vertical lines are drawn for each blood examination of the primary patient.

The selected blood examination displayed in the Single Blood Examination View and selected in the timeline is highlighted by a strong line which can be dragged to change the selected blood examination. The actual value of the selected attribute is also displayed.

Lines depicting the values of non-primary patients can be dragged to compare them with the selected blood examination of the primary patient.

=== Visualization Controls ===
The visualization can be modified here. The user can set the number of tests to display in the detail view. Furthermore, the attributes can automatically be sorted by name or criticality.

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2008-01-03T17:40:23Z

UE-InfoVis0607 0727197:

Sollte im History View die X-Achse nicht beschriftet sein? Ich mein es ist klar, dass es sich bei dem markierten um den aktuellen Wert handelt aber zumindest Anfang und Ende der Achso sollten ein Datum haben damit man den ungefähren Zeitramen kennt.

''Diese Daten sind oben in der Timeline angezeigt. Aber wenn du meinst, dass das nicht so optimal ist weil es zu weit weg ist von der Visualisierung, muss ich dir recht geben. Trotzdem bin ich recht zufrieden damit und würde die Daten nur ungern doppelt anzeigen. Ich weiß nicht - hast du vielleicht eine bessere Idee?''

Ok dann macht es Sinn wenn es sich auf die obere Timeline bezieht (war mir nicht ganz klar)

Vielleicht könnte man noch dazuschreiben, dass es eine kleine Animation gibt wenn man den History View öffnet das sich der Balken mit den (in diesem Fall zwei Punkten) nach unten verschiebt, in die vertikale dreht und dann von links und rechts die Werte der vorigen und späteren Messungen dazukommen? (würde vielleicht ein bisschen helfen die andere Dimension klarer zu machen)

''Hmm...das klingt auf jeden Fall sehr gut. Ich bin einverstanden.''

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2008-01-03T16:23:15Z

UE-InfoVis0607 0727197:

Sollte im History View die X-Achse nicht beschriftet sein? Ich mein es ist klar, dass es sich bei dem markierten um den aktuellen Wert handelt aber zumindest Anfang und Ende der Achso sollten ein Datum haben damit man den ungefähren Zeitramen kennt.

Vielleicht könnte man noch dazuschreiben, dass es eine kleine Animation gibt wenn man den History View öffnet das sich der Balken mit den (in diesem Fall zwei Punkten) nach unten verschiebt, in die vertikale dreht und dann von links und rechts die Werte der vorigen und späteren Messungen dazukommen? (würde vielleicht ein bisschen helfen die andere Dimension klarer zu machen)

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2008-01-03T16:19:45Z

UE-InfoVis0607 0727197:

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2008-01-03T16:19:22Z

UE-InfoVis0607 0727197: New page: Sollte im History View die X-Achse nicht beschriftet sein? Ich mein es ist klar das es sich bei dem markierten um den aktuellen Wert handelt aber zumindest Anfang und Ende der Achso sollte...

Sollte im History View die X-Achse nicht beschriftet sein? Ich mein es ist klar das es sich bei dem markierten um den aktuellen Wert handelt aber zumindest Anfang und Ende der Achso sollten ein Datum haben damit man den ungefähren Zeitramen kennt.

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2007-12-22T09:50:21Z

UE-InfoVis0607 0727197:

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 3

2007-12-22T09:12:39Z

UE-InfoVis0607 0727197:

== Poor Graphic ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe3.html Beschreibung der Aufgabe 3]

[[Image:Aussenhandel.jpg]]
Außenhandel Deutschlands mit den Reformländern Mittel- und Osteuropas

== Review ==
=== Highlighting ===
* Data should be highlighted to give them a voice that comes through loudly and clearly, without distraction. Here, the background is massively distracting from the data.
* I'd say the data-ink ratio is only 0.1, as the data covers about 30% of the graphic and is much lighter than the background. The data must be highlighted (e.g. by increasing the color intensity), therefore the background must be de-emphasized, if not removed at all. The data must stand out.
* The supporting component ''in Milliarden DM'' must be emphasized too, because its essential for the understanding of the numbers.
* The actual countries are summarized with ''Reformländer Mittel- und Osteuropas'' which is good, because it reduces data-ink that isn't needed at first. Still, the summary is pretty long.
* The borders and 3D effect of the bars add no value, but boost visual noise.
* Interfering boxes arround the years
* Bad hue difference of the bars
* No additional coding scheme, distracting "Import/Export" text inside the bars of the year 1997

''Nur die 1997er Balken sind beschriftet, die anderen jedoch nicht, was für Verwirrung sorgen kann. Daher wäre ein Zeichenschlüssel (Legende) angebracht.''

=== Organization ===
* The visualization should be organized to lead readers through the contents in a manner that promotes optimal understanding. The organization in this graph is chaotic. What do the numbers mean?
* What does the left, what does the right bar mean? Information that answers these questions scattered in an unorganized way.
* The bars are grouped nicely by year using ''proximity'' and by trading type using ''similarity'' of background colors. However, the colors could be more distinguishing. Furthermore, I believe (but have no scientific material to prove this) that the graph would be easier to interpret, if the ''Import'' and ''Export'' bars would be swapped, so that the smaller bars are on the left side. This would better emphasize the rising character of the trade in general in addition to the fact that, in this chart exports are higher than imports.

''Sehr gute Beobachtungen, mit einer Ausnahme: ich würde nicht behaupten, dass Exporte immer höher sind als Importe. Das mag auf einige Länder Westeuropas durchaus zutreffen, aber im Allgemeinen würde ich das nicht sagen.''

* Most of the elements are prioritized and sequenced correctly: The title on the top center, the bars centered, the years beyond the bars, the volume in the bars, and the actual countries on the bottom. In contrast, the ''in Milliarden DM'' is quite important and must be presented in a more prominent way (but not too prominent - possibly as an under-title). The labels ''Import'' and ''Export'' must also be easier to comprehend, e.g. by placing a legend on the top left side of the graph. Vertical orientation of text should generally be avoided.
* The years are properly sequenced from left to right.
* The accuracy of the numbers seems to high and should be reduced to remove unnecessary details and support clarity.
* Missing base line of the bars

''Ein Element fehlt auch noch in der Grafik: es gibt keine Basis / Grundlinie auf der die Balken stehen, was nach S. Few für vertikale Balken erforderlich ist, denn ansonsten kann der Eindruck entstehen, dass die Balken in der Luft schweben.''

=== Required Text ===
* Everything is here, though it's not always properly communicated, as mentioned above.

== Redesign ==
[[Image:Aussenhandel_redesign.png]]

If it is feasible to change the type of chart, I would recommend to use a line chart, as it is easier to compare the values with this type of representation and the legend can be eliminated by labeling each line.

[[Image:Aussenhandel_redesign2.png]]

==Improvements==

* No visual noice
* Clear, short title
* High data-ink ratio
* Reader sees the stable growth
* No distracting background, all important information on the first view
* Contrast of import/export bars
* Grouped, prioritized data
* Additional data outside the scope

''Das Redesign ist wirklich sehr gut gelungen; auch die Farbwahl ist gut. Allerdings sollte zur besseren Übersicht eine Y-Achse in die Grafik integriert werden. Dabei können durchaus subtil eingesetzte horizontale Gridlines zum Einsatz kommen.''

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 3

2007-12-07T16:49:00Z

UE-InfoVis0607 0727197:

Ich hab mir erlaubt ein paar Zeilen hinzuzufügen.

Die beiden Graphen sind dir sehr gut gelungen, dass Einzige was ich eventuell noch ändern würde, wäre den Abstand zu der Aufzählung der Reformländer etwas zu vergrößern.

Ich bin sogar froh, dass du dir das erlaubst.

Ich weiß aber jetzt nicht welchen Abstand du jetzt meinst? Ah, ich weiß glaub ich schon - die Länder ein Stück weiter runter meinst du. Naja, ich finde, das ist so und so okay.

Bei der Gelegenheit: Kannst du die Tabelle von Aufgabe 2 überarbeiten? Ich hab schon länger ein paar Anmerkungen dazu dort gemacht.

Wie ich gerade sehe haben wir da volle Punkteanzahl bekommen (wenn du willst kann ichs natürlich noch hinzufügen), leider bemerke ich jetzt erst, dass die Bewertung in den Discussion Teil geschrieben wird, darum hab ich auch die Möglichkeit zur Überarbeitung von Aufgabe 1 völlig übersehen. Das tut mir Leid (ich hab mich nur gewundert wieso es bei Aufgabe 0 geblieben ist sonst und nichts mehr geschehn ist), mein Fehler kommt nicht mehr vor.

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 3

2007-12-07T10:19:06Z

UE-InfoVis0607 0727197:

== Poor Graphic ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe3.html Beschreibung der Aufgabe 3]

[[Image:Aussenhandel.jpg]]
Außenhandel Deutschlands mit den Reformländern Mittel- und Osteuropas

== Review ==
=== Highlighting ===
* Data should be highlighted to give them a voice that comes through loudly and clearly, without distraction. Here, the background is massively distracting from the data.
* I'd say the data-ink ratio is only 0.1, as the data covers about 30% of the graphic and is much lighter than the background. The data must be highlighted (e.g. by increasing the color intensity), therefore the background must be de-emphasized, if not removed at all. The data must stand out.
* The supporting component ''in Milliarden DM'' must be emphasized too, because its essential for the understanding of the numbers.
* The actual countries are summarized with ''Reformländer Mittel- und Osteuropas'' which is good, because it reduces data-ink that isn't needed at first. Still, the summary is pretty long.
* The borders and 3D effect of the bars add no value, but boost visual noise.
* Interfering boxes arround the years
* Bad hue difference of the bars

=== Organization ===
* The visualization should be organized to lead readers through the contents in a manner that promotes optimal understanding. The organization in this graph is chaotic. What do the numbers mean?
* What does the left, what does the right bar mean? Information that answers these questions scattered in an unorganized way.
* The bars are grouped nicely by year using ''proximity'' and by trading type using ''similarity'' of background colors. However, the colors could be more distinguishing. Furthermore, I believe (but have no scientific material to prove this) that the graph would be easier to interpret, if the ''Import'' and ''Export'' bars would be swapped, so that the smaller bars are on the left side. This would better emphasize the rising character of the trade in general in addition to the fact that exports are always higher than imports.
* Most of the elements are prioritized and sequenced correctly: The title on the top center, the bars centered, the years beyond the bars, the volume in the bars, and the actual countries on the bottom. In contrast, the ''in Milliarden DM'' is quite important and must be presented in a more prominent way (but not too prominent - possibly as an under-title). The labels ''Import'' and ''Export'' must also be easier to comprehend, e.g. by placing a legend on the top left side of the graph. Vertical orientation of text should generally be avoided.
* The years are properly sequenced from left to right.
* The accuracy of the numbers seems to high and should be reduced to remove unnecessary details and support clarity.

=== Required Text ===
* Everything is here, though it's not always properly communicated, as mentioned above.

== Redesign ==
[[Image:Aussenhandel_redesign.png]]

If it is feasible to change the type of chart, I would recommend to use a line chart, as it is easier to compare the values with this type of representation and the legend can be eliminated by labeling each line.

[[Image:Aussenhandel_redesign2.png]]

==Improvements==

* No visual noice
* Clear, short title
* High data-ink ratio
* Reader sees the stable growth
* No distracting background, all important information on the first view
* Contrast of import/export bars
* Grouped, prioritized data
* Additional data outside the scope

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 3

2007-12-07T10:17:37Z

UE-InfoVis0607 0727197: New page: Ich hab mir erlaubt ein paar Zeilen hinzuzufügen. Die beiden Graphen sind dir sehr gut gelungen, dass Einzige was ich eventuell noch ändern würde, wäre den Abstand zu der Aufzählung ...

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 3

2007-12-07T10:15:46Z

UE-InfoVis0607 0727197:

== Poor Graphic ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe3.html Beschreibung der Aufgabe 3]

[[Image:Aussenhandel.jpg]]
Außenhandel Deutschlands mit den Reformländern Mittel- und Osteuropas

== Review ==
=== Highlighting ===
* Data should be highlighted to give them a voice that comes through loudly and clearly, without distraction. Here, the background is massively distracting from the data.
* I'd say the data-ink ratio is only 0.1, as the data covers about 30% of the graphic and is much lighter than the background. The data must be highlighted (e.g. by increasing the color intensity), therefore the background must be de-emphasized, if not removed at all. The data must stand out.
* The supporting component ''in Milliarden DM'' must be emphasized too, because its essential for the understanding of the numbers.
* The actual countries are summarized with ''Reformländer Mittel- und Osteuropas'' which is good, because it reduces data-ink that isn't needed at first. Still, the summary is pretty long.
* The borders and 3D effect of the bars add no value, but boost visual noise.
* Interfering boxes arround the years
* Bad hue difference of the bars

=== Organization ===
* The visualization should be organized to lead readers through the contents in a manner that promotes optimal understanding. The organization in this graph is chaotic. What do the numbers mean?
* What does the left, what does the right bar mean? Information that answers these questions scattered in an unorganized way.
* The bars are grouped nicely by year using ''proximity'' and by trading type using ''similarity'' of background colors. However, the colors could be more distinguishing. Furthermore, I believe (but have no scientific material to prove this) that the graph would be easier to interpret, if the ''Import'' and ''Export'' bars would be swapped, so that the smaller bars are on the left side. This would better emphasize the rising character of the trade in general in addition to the fact that exports are always higher than imports.
* Most of the elements are prioritized and sequenced correctly: The title on the top center, the bars centered, the years beyond the bars, the volume in the bars, and the actual countries on the bottom. In contrast, the ''in Milliarden DM'' is quite important and must be presented in a more prominent way (but not too prominent - possibly as an under-title). The labels ''Import'' and ''Export'' must also be easier to comprehend, e.g. by placing a legend on the top left side of the graph. Vertical orientation of text should generally be avoided.
* The years are properly sequenced from left to right.
* The accuracy of the numbers seems to high and should be reduced to remove unnecessary details and support clarity.

=== Required Text ===
* Everything is here, though it's not always properly communicated, as mentioned above.

== Redesign ==
[[Image:Aussenhandel_redesign.png]]

If it is feasible to change the type of chart, I would recommend to use a line chart, as it is easier to compare the values with this type of representation and the legend can be eliminated by labeling each line.

[[Image:Aussenhandel_redesign2.png]]

==Improvments==

* No visual noice
* Clear, short title
* High data-ink ratio
* Reader sees the stable growth
* No distracting background, all important information on the first view
* Contrast of import/export bars
* Grouped, prioritized data
* Additional data outside the scope

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 2

2007-11-23T14:52:58Z

UE-InfoVis0607 0727197:

== Aufgabenstellung ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe2.html Beschreibung der Aufgabe 2]

=== Zu beurteilende Tabelle ===

[[Image:cancer-survival.jpg]]

== Kritik ==
* ''White space'' is well used here to direct the readers' eye to scan down the rows.
* White space between the 10 and 15 years is slightly wider than between 5 and 10, and 15 and 20 years, which is good if it conveys some meaning.
* Sometimes white space occurs because of long text in the row header, thus suggesting that the table is grouped, which is not the case. This also disturbs scanning across rows. Therefore, the row header should be made wider.
* When using ''rules'', lines should be kept as thin and light as possible. The rules in the table are too thick and heavy.
* Rules work best with light shades of gray to keep them subtle in comparison to data.
* The ruler on the top of the table seems useless and should be removed (although this depends on the context of use: when objects must be placed close to the table, it is okay to to form a boundary using rules)
* Because of the effective use of white space it is easy to scan down the rows. However, scanning across the rows could be made easier by filling alternating rows with e.g. a light shade of gray.
* The table does contain only 4 subdivisions of survival rates and a far larger number of cancer sites, therefore the rows and columns are wisely arranged. The fact, that we naturally think of time as moving from left to right, rather than top to bottom supports this arrangement.
* The row sequence seems random (to me, at least) and should be arranged in a natural order that conveys meaning to the reader (at least sort alphabetically ascending by cancer site).
* Cancer sites could be grouped in a meaningful way, by simply adding white space between groups.
* Numbers are properly aligned right and text is aligned left, which is good. The decimal point, however, looks odd.
* Column headers should be right aligned, when the column's data is right aligned, thereby informing readers how to scan the data. However, it may also be seen as a 'spanning header' because the columns really consists of 2 sub-columns with omitted header and should therefore be centered. The (quite unusual) descriptive, spanning header 'Relative survival rate, % (SE)' should, according to this rule, also be centered.
* As the rulers form a boundary between the data- and support components the row header 'Cancer' should be pulled outside the table body, above the ruler.
* Percentage signs should appear immediately to the right of every percentage value because it's easy to forget that you're looking at percentages when reading down long columns of numbers. However, I don't think that this rule applies here and the advantage of reducing visual clutter far outweighs the (minimal) risk of forgetting that the numbers are actually percentage.
* The precision of the numbers seems reasonable and are correctly presented with a consistent number of decimals.
* Summary values are completely missing. Row and column summaries could be added, possibly containing average values.
* I don't know what ''SE'' is, but let's assume that it is intended to be compared with the corresponding relative survival rate, and therefore the arrangement is alright. However, comparing with the SEs from other columns could be made easier by:
** Removing the parenthesis, thus reducing visual noise which adds no information but complicates cognition.
** Group the SE values by applying the ''Gestalt'' principle of ''similarity'' and e.g. make the SE values gray (in contrast to the black survival rate value) as it seems less important.

== New table==

[[Image:Table1.JPG]]

== Modifications ==

* White spaces used to scan horizontaly
* More space between the lines
* Less space between SE and '%' values
* Identical space between every year
* Thin rules
* Spanning header centered
* Row sequence sorted alphabetically
* Average value added
* Removed parenthesis form SE
* SE values in light gray, let it look less important
* References at the bottom of the table

== Improvements ==

* The readers are directed to the rows, to see the changing values over the years
* There are no special links between the cancer sites
* The SE values consume less space and don´t distract any more
* Cancer sites seem to be more regulated
* It is easier to read and the relevant information is obtained much faster

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 2

2007-11-23T14:51:53Z

UE-InfoVis0607 0727197:

== Aufgabenstellung ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe2.html Beschreibung der Aufgabe 2]

=== Zu beurteilende Tabelle ===

[[Image:cancer-survival.jpg]]

== Kritik ==
* ''White space'' is well used here to direct the readers' eye to scan down the rows.
* White space between the 10 and 15 years is slightly wider than between 5 and 10, and 15 and 20 years, which is good if it conveys some meaning.
* Sometimes white space occurs because of long text in the row header, thus suggesting that the table is grouped, which is not the case. This also disturbs scanning across rows. Therefore, the row header should be made wider.
* When using ''rules'', lines should be kept as thin and light as possible. The rules in the table are too thick and heavy.
* Rules work best with light shades of gray to keep them subtle in comparison to data.
* The ruler on the top of the table seems useless and should be removed (although this depends on the context of use: when objects must be placed close to the table, it is okay to to form a boundary using rules)
* Because of the effective use of white space it is easy to scan down the rows. However, scanning across the rows could be made easier by filling alternating rows with e.g. a light shade of gray.
* The table does contain only 4 subdivisions of survival rates and a far larger number of cancer sites, therefore the rows and columns are wisely arranged. The fact, that we naturally think of time as moving from left to right, rather than top to bottom supports this arrangement.
* The row sequence seems random (to me, at least) and should be arranged in a natural order that conveys meaning to the reader (at least sort alphabetically ascending by cancer site).
* Cancer sites could be grouped in a meaningful way, by simply adding white space between groups.
* Numbers are properly aligned right and text is aligned left, which is good. The decimal point, however, looks odd.
* Column headers should be right aligned, when the column's data is right aligned, thereby informing readers how to scan the data. However, it may also be seen as a 'spanning header' because the columns really consists of 2 sub-columns with omitted header and should therefore be centered. The (quite unusual) descriptive, spanning header 'Relative survival rate, % (SE)' should, according to this rule, also be centered.
* As the rulers form a boundary between the data- and support components the row header 'Cancer' should be pulled outside the table body, above the ruler.
* Percentage signs should appear immediately to the right of every percentage value because it's easy to forget that you're looking at percentages when reading down long columns of numbers. However, I don't think that this rule applies here and the advantage of reducing visual clutter far outweighs the (minimal) risk of forgetting that the numbers are actually percentage.
* The precision of the numbers seems reasonable and are correctly presented with a consistent number of decimals.
* Summary values are completely missing. Row and column summaries could be added, possibly containing average values.
* I don't know what ''SE'' is, but let's assume that it is intended to be compared with the corresponding relative survival rate, and therefore the arrangement is alright. However, comparing with the SEs from other columns could be made easier by:
** Removing the parenthesis, thus reducing visual noise which adds no information but complicates cognition.
** Group the SE values by applying the ''Gestalt'' principle of ''similarity'' and e.g. make the SE values gray (in contrast to the black survival rate value) as it seems less important.

== New table==

[[Image:Table1.JPG]]

== Modifications ==

* White spaces used to scan horizontaly
* More space between the lines
* Less space between SE and '%' values
* Identical space between every year
* Thin rules
* Spanning header centered
* Row sequence sorted alphabetically
* Average value added
* Removed parenthesis form SE
* SE values in light gray, let it look less important
* References at the bottom of the table

== Improvments ==

* The readers are directed to the rows, to see the changing values over the years
* There are no special links between the cancer sites
* The SE values consume less space and don´t distract any more
* Cancer sites seem to be more regulated
* It is easier to read and the relevant information is obtained much faster

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 2

2007-11-23T13:25:27Z

UE-InfoVis0607 0727197:

== Aufgabenstellung ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe2.html Beschreibung der Aufgabe 2]

=== Zu beurteilende Tabelle ===

[[Image:cancer-survival.jpg]]

== Kritik ==
* ''White space'' is well used here to direct the readers' eye to scan down the rows.
* White space between the 10 and 15 years is slightly wider than between 5 and 10, and 15 and 20 years, which is good if it conveys some meaning.
* Sometimes white space occurs because of long text in the row header, thus suggesting that the table is grouped, which is not the case. This also disturbs scanning across rows. Therefore, the row header should be made wider.
* When using ''rules'', lines should be kept as thin and light as possible. The rules in the table are too thick and heavy.
* Rules work best with light shades of gray to keep them subtle in comparison to data.
* The ruler on the top of the table seems useless and should be removed (although this depends on the context of use: when objects must be placed close to the table, it is okay to to form a boundary using rules)
* Because of the effective use of white space it is easy to scan down the rows. However, scanning across the rows could be made easier by filling alternating rows with e.g. a light shade of gray.
* The table does contain only 4 subdivisions of survival rates and a far larger number of cancer sites, therefore the rows and columns are wisely arranged. The fact, that we naturally think of time as moving from left to right, rather than top to bottom supports this arrangement.
* The row sequence seems random (to me, at least) and should be arranged in a natural order that conveys meaning to the reader (at least sort alphabetically ascending by cancer site).
* Cancer sites could be grouped in a meaningful way, by simply adding white space between groups.
* Numbers are properly aligned right and text is aligned left, which is good. The decimal point, however, looks odd.
* Column headers should be right aligned, when the column's data is right aligned, thereby informing readers how to scan the data. However, it may also be seen as a 'spanning header' because the columns really consists of 2 sub-columns with omitted header and should therefore be centered. The (quite unusual) descriptive, spanning header 'Relative survival rate, % (SE)' should, according to this rule, also be centered.
* As the rulers form a boundary between the data- and support components the row header 'Cancer' should be pulled outside the table body, above the ruler.
* Percentage signs should appear immediately to the right of every percentage value because it's easy to forget that you're looking at percentages when reading down long columns of numbers. However, I don't think that this rule applies here and the advantage of reducing visual clutter far outweighs the (minimal) risk of forgetting that the numbers are actually percentage.
* The precision of the numbers seems reasonable and are correctly presented with a consistent number of decimals.
* Summary values are completely missing. Row and column summaries could be added, possibly containing average values.
* I don't know what ''SE'' is, but let's assume that it is intended to be compared with the corresponding relative survival rate, and therefore the arrangement is alright. However, comparing with the SEs from other columns could be made easier by:
** Removing the parenthesis, thus reducing visual noise which adds no information but complicates cognition.
** Group the SE values by applying the ''Gestalt'' principle of ''similarity'' and e.g. make the SE values gray (in contrast to the black survival rate value) as it seems less important.

==New table==

[[Image:Table1.JPG]]

==Modifications ==

* White spaces used to scan horizontaly
* More space between the lines
* Less space between SE and '%' values
* Identical space between every year
* Thin rules
* Spanning header centered
* Row sequence sorted alphabetically
* Average value added
* Removed parenthesis form SE
* SE values in light gray, let it look less important
* References at the bottom of the table

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 2

2007-11-23T13:22:50Z

UE-InfoVis0607 0727197:

== Aufgabenstellung ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe2.html Beschreibung der Aufgabe 2]

=== Zu beurteilende Tabelle ===

[[Image:cancer-survival.jpg]]

== Kritik ==
* ''White space'' is well used here to direct the readers' eye to scan down the rows.
* White space between the 10 and 15 years is slightly wider than between 5 and 10, and 15 and 20 years, which is good if it conveys some meaning.
* Sometimes white space occurs because of long text in the row header, thus suggesting that the table is grouped, which is not the case. This also disturbs scanning across rows. Therefore, the row header should be made wider.
* When using ''rules'', lines should be kept as thin and light as possible. The rules in the table are too thick and heavy.
* Rules work best with light shades of gray to keep them subtle in comparison to data.
* The ruler on the top of the table seems useless and should be removed (although this depends on the context of use: when objects must be placed close to the table, it is okay to to form a boundary using rules)
* Because of the effective use of white space it is easy to scan down the rows. However, scanning across the rows could be made easier by filling alternating rows with e.g. a light shade of gray.
* The table does contain only 4 subdivisions of survival rates and a far larger number of cancer sites, therefore the rows and columns are wisely arranged. The fact, that we naturally think of time as moving from left to right, rather than top to bottom supports this arrangement.
* The row sequence seems random (to me, at least) and should be arranged in a natural order that conveys meaning to the reader (at least sort alphabetically ascending by cancer site).
* Cancer sites could be grouped in a meaningful way, by simply adding white space between groups.
* Numbers are properly aligned right and text is aligned left, which is good. The decimal point, however, looks odd.
* Column headers should be right aligned, when the column's data is right aligned, thereby informing readers how to scan the data. However, it may also be seen as a 'spanning header' because the columns really consists of 2 sub-columns with omitted header and should therefore be centered. The (quite unusual) descriptive, spanning header 'Relative survival rate, % (SE)' should, according to this rule, also be centered.
* As the rulers form a boundary between the data- and support components the row header 'Cancer' should be pulled outside the table body, above the ruler.
* Percentage signs should appear immediately to the right of every percentage value because it's easy to forget that you're looking at percentages when reading down long columns of numbers. However, I don't think that this rule applies here and the advantage of reducing visual clutter far outweighs the (minimal) risk of forgetting that the numbers are actually percentage.
* The precision of the numbers seems reasonable and are correctly presented with a consistent number of decimals.
* Summary values are completely missing. Row and column summaries could be added, possibly containing average values.
* I don't know what ''SE'' is, but let's assume that it is intended to be compared with the corresponding relative survival rate, and therefore the arrangement is alright. However, comparing with the SEs from other columns could be made easier by:
** Removing the parenthesis, thus reducing visual noise which adds no information but complicates cognition.
** Group the SE values by applying the ''Gestalt'' principle of ''similarity'' and e.g. make the SE values gray (in contrast to the black survival rate value) as it seems less important.

==New table==

[[Image:Table1.JPG]]

==Modifications ==

* White spaces used to scan horizontaly
* More space between the lines
* Same space between every year
* Thin rules
* Spanning header centered
* Row sequence sorted alphabetically
* Average value added
* Removed parenthesis form SE
* Se in light gray, let it look less important

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 2

2007-11-23T10:46:18Z

UE-InfoVis0607 0727197:

== Aufgabenstellung ==
[http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/infovis_ue_aufgabe2.html Beschreibung der Aufgabe 2]

=== Zu beurteilende Tabelle ===

[[Image:cancer-survival.jpg]]

== Kritik ==
* ''White space'' is well used here to direct the readers' eye to scan down the rows.
* White space between the 10 and 15 years is slightly wider than between 5 and 10, and 15 and 20 years, which is good if it conveys some meaning.
* Sometimes white space occurs because of long text in the row header, thus suggesting that the table is grouped, which is not the case. This also disturbs scanning across rows. Therefore, the row header should be made wider.
* When using ''rules'', lines should be kept as thin and light as possible. The rules in the table are too thick and heavy.
* Rules work best with light shades of gray to keep them subtle in comparison to data.
* The ruler on the top of the table seems useless and should be removed (although this depends on the context of use: when objects must be placed close to the table, it is okay to to form a boundary using rules)
* Because of the effective use of white space it is easy to scan down the rows. However, scanning across the rows could be made easier by filling alternating rows with e.g. a light shade of gray.
* The table does contain only 4 subdivisions of survival rates and a far larger number of cancer sites, therefore the rows and columns are wisely arranged. The fact, that we naturally think of time as moving from left to right, rather than top to bottom supports this arrangement.
* The row sequence seems random (to me, at least) and should be arranged in a natural order that conveys meaning to the reader (at least sort alphabetically ascending by cancer site).
* Cancer sites could be grouped in a meaningful way, by simply adding white space between groups.
* Numbers are properly aligned right and text is aligned left, which is good. The decimal point, however, looks odd.
* Column headers should be right aligned, when the column's data is right aligned, thereby informing readers how to scan the data. However, it may also be seen as a 'spanning header' because the columns really consists of 2 sub-columns with omitted header and should therefore be centered. The (quite unusual) descriptive, spanning header 'Relative survival rate, % (SE)' should, according to this rule, also be centered.
* As the rulers form a boundary between the data- and support components the row header 'Cancer' should be pulled outside the table body, above the ruler.
* Percentage signs should appear immediately to the right of every percentage value because it's easy to forget that you're looking at percentages when reading down long columns of numbers. However, I don't think that this rule applies here and the advantage of reducing visual clutter far outweighs the (minimal) risk of forgetting that the numbers are actually percentage.
* The precision of the numbers seems reasonable and are correctly presented with a consistent number of decimals.
* Summary values are completely missing. Row and column summaries could be added, possibly containing average values.
* I don't know what ''SE'' is, but let's assume that it is intended to be compared with the corresponding relative survival rate, and therefore the arrangement is alright. However, comparing with the SEs from other columns could be made easier by:
** Removing the parenthesis, thus reducing visual noise which adds no information but complicates cognition.
** Group the SE values by applying the ''Gestalt'' principle of ''similarity'' and e.g. make the SE values gray (in contrast to the black survival rate value) as it seems less important.

==New table==

[[Image:Table1.JPG]]

== Links ==

* [[Teaching:TUW_-_UE_InfoVis_WS_2007/08|InfoVis:Wiki UE Homepage]]

* [http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html UE InfoVis]

*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01]]

File:Table1.JPG

2007-11-23T10:40:01Z

UE-InfoVis0607 0727197: Version 1 of the cancer table

== Summary ==
Version 1 of the cancer table
== Copyright status ==

== Source ==

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 2

2007-11-22T08:39:54Z

UE-InfoVis0607 0727197: New page: hat jemand eine Ahnung was das SE hinter dem % heißen soll?

hat jemand eine Ahnung was das SE hinter dem % heißen soll?

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - Drag and Drop

2007-11-09T14:57:04Z

UE-InfoVis0607 0727197:

==History==
The first drag & drop implementation for Windows was a shareware program called Aporia by Jeffrey Greenberg in 1988 under Windows 2.0, and later commercialized as WinTools. This program elaborated the single icon on the Macintosh that supported drag & drop, the trash icon. In Aporia/WinTools all icons had functions that could be obtained by double clicking the left mouse button, by clicking on the right mouse button, or by dragging onto one of several functional icons, such as printing, copying, viewing, and other actions. If an icon was double-clicked on and ran a program, the icon changed to indicate that a program was running, and if it was then dragged to the trash, the program was exited.

Subsequently numerous other competitors provided drag & drop desktop replacements to the standard Windows interface including the Norton Desktop, Xerox, NewWave, and Central Point. In Windows 95, Microsoft prevented developers from taking over the desktop and released a drag & drop model of their own.

===References===
[Wikipedia: Drag-and-drop] Drag-and-drop, Wikipedia, 6 November 2007,http://en.wikipedia.org/wiki/Drag_and_drop

==Technical Overview==

A drag and drop transaction consists of the following actions:

*A user presses and holds BTransfer, usually mouse button 2, over a source object starting a drag transaction. The application owning that object is the initiator of the drag. The current pointer is replaced by a drag icon-a picture representing the item being dragged.
*The user moves the pointer. From now until a drop occurs, the drag icon replaces the mouse pointer.
*The user drops the object, usually by releasing the mouse button.

Locations on the screen that can accept drops are drop sites, and the application owning that drop site is the destination or receiver.

The drag icon can be dropped anywhere on the screen. However, only certain widgets have registered themselves as drop sites and are able to process the drop.

The receiver application usually performs some action on the information represented by the dragged icon. The initiator application may also perform some action based on the results of a drag transaction.

A drop can be between applications or within the same application. An application can be both source and destination of a drop, source only, destination only, or not participate in drag and drop at all.

The user can request help about a drop site, if available, by dragging to the drop site, and pressing KHelp (usually F1).

The user can cancel the drag at any time by pressing KCancel, usually Escape.

===References===

[Motif Programmer's Guide] Motif Programmer's Guide, 1994-1996, The Santa Cruz Operation, http://www.s-and-b.ru/syshlp/motif_guide/MotifProgGuide/TOC.html

==Drag & Drop in Information Visualization==

===Command Post of the Future (CPOF)===

[[Image:Cpof_rev2.jpg|150px|thumb|CPOF]]

The United States Army's Command Post of the Future (CPOF) is a C2 software system that allows commanders to maintain topsight over the battlefield; collaborate with superiors, peers and subordinates over live data; and communicate their intent.

All visual elements in CPOF are interactive via drag-and-drop gestures. Users can drag data-elements and annotation from any visualization framework into any other (i.e., from a chart to a table), which reveal different data-attributes in context depending on the visualization used. Most data-elements can be grouped and nested via drag-and-drop to form associations that remain with the data in all of its views.Drag-and-drop composition on live visualizations is CPOF's primary mechanism for editing data values, such as locations on a map or tasks on a schedule (for example, moving an event-icon on a map changes the lat/lon values of that event in the shared repository; moving a task icon on a schedule changes its time-based values in the shared repository).
The results of editing gestures are conveyed in real-time to all observers and users of a visualization; when one user moves an event on a map, for example, that event-icon moves on all maps and shared views, such that all users see its new location immediately. Data inputs from warfighters are conveyed to all collaborators as the "natural" result of a drop-gesture in-situ, requiring no explicit publishing mechanism.

====References====
[Wikipedia: Command Post of the Future] The United States Army's Command Post of the Future (CPOF), Wikipedia, 20 July 2007, http://en.wikipedia.org/wiki/Command_Post_of_the_Future

[General Dynamics C4 System] General Dynamics C4 Systems, 2007,http://www.gdc4s.com/content/detail.cfm?item=2a58f8e2-ef2b-4bb1-9251-42ee4961dd7f

===A Drag-and-Drop Strategy for Labeling Photos===

[[Image:Clipboard01.jpg|150px|thumb|Figure 1. US Map with City Names]]

[[Image:Clipboard03.jpg|150px|thumb|Figure 2. Hyperbolic Tree]]

[[Image:Clipboard02.jpg|150px|thumb|Figure 3. LifeLines Medical Patient History]]

Annotation of photos is a variation on previously explored problems such as annotation on maps in which the challenge is to place city, state, river, or lake labels close to the features. There is a long history of work on this problem, but new possibilities emerge because of the dynamics of the computer screen (Figure 1).
However, annotation is usually seen as an authoring process conducted by specialists and users only chose whether to show or hide annotations. Variations on annotation also come from the placement of labels on markers in information visualization tasks such as in tree structures, such in the hyperbolic tree (Figure 2) or in medical histories, such as LifeLines (Figure 3).

Previous work on annotation focused on writing programs to make label placements that reduced overlaps, but there are many situations in which it is helpful for users to place labels manually, much like post-it notes, on documents, photos, maps, diagrams, webpages, etc. Annotation of paper and electronic documents by hand is also a much-studied topic with continuing innovations.
While many systems allow notes to be placed on a document or object, the demands of annotating personal photo libraries are worthy of special study. We believe that personal photo libraries are a special case because users are concentrating on the photos (and may have a low interested in the underlying technology), are concerned about the social aspects of sharing photos, and are intermittent users. They seek enjoyment and have little patience for form filling or data entry.

====References====
[A Drag-and-Drop Strategy for Labeling Photos] A Drag-and-Drop Strategy for Labeling Photos, Ben Shneiderman, Hyunmo Kang
Dept. of Computer Science, Human-Computer Interaction Laboratory, Institute for Advanced Computer Studies & Institute for Systems Research University of Maryland, 2000, https://drum.umd.edu/dspace/bitstream/1903/1068/2/CS-TR-4129.pdf

===Lookmark===
A 2.5D Web Information Visualization System
[[Image:Clipboard04.jpg|150px|thumb|Lookmark user interface screenshot]]

Lookmarks are thumbnails of existing web pages that can be
arranged within a 2.5-dimensional space, just like documents can be arranged
on a normal desk. The Lookmark system offers the user the opportunity of
taking individual web pages and structuring and managing them within a 2.5-
dimensional space.
In Lookmark both standard devices, mouse and
keyboard, can be used. Mouse handling is limited to single click, double click and
drag-and-drop. The meaning of mouse events depends on the context of the object that
receives the event:
* Thumbnails. With a single mouse click one can add resp. delete the clicked
thumbnail to resp. from the current selection. At the same time the name of the
corresponding web page is displayed in the status bar of the user interface. By
double clicking on a specific thumbnail, one can open the corresponding web page
in the associated Web-browser. By using drag-and-drop one can move a thumbnail
along the horizontal and depth dimension (X- and Z-axis).
* Groups of thumbnails. Thumbnails in a group are handled like single thumbnails.
Groups of thumbnails can be moved simultaneously by dragging the group label.
* Selections. Dragging a thumbnail of a selection moves all selected thumbnails. A
selection can be dissolved by clicking somewhere in the manipulation panel.

====References====
[A 2.5D Web Information Visualization System] Christian Breiteneder, Horst Eidenberger, Geert Fiedler and Markus Raab
Vienna University of Technology, Institute of Software Technology and Interactive Systems, 24.7.2002, http://www.ims.tuwien.ac.at/media/documents/publications/eurasia2002.pdf

File:Clipboard04.jpg

2007-11-09T14:43:11Z

UE-InfoVis0607 0727197: Lookmark user interface screenshot. The user interface consists of a 2D control panel that contains a menu and a media loading progress bar and a 2.5D visualization and interaction panel.

== Summary ==
Lookmark user interface screenshot. The user interface consists of a 2D
control panel that contains a menu and a media loading progress bar and a 2.5D
visualization and interaction panel.
== Copyright status ==
na
== Source ==
http://www.ims.tuwien.ac.at/media/documents/publications/eurasia2002.pdf

File:Clipboard01.jpg

2007-11-09T14:37:49Z

UE-InfoVis0607 0727197:

== Summary ==
Figure 1. US Map with City Names
== Copyright status ==
na
== Source ==
https://drum.umd.edu/dspace/bitstream/1903/1068/2/CS-TR-4129.pdf

File:Clipboard02.jpg

2007-11-09T14:36:15Z

UE-InfoVis0607 0727197: Figure 3. LifeLines Medical Patient History

== Summary ==
Figure 3. LifeLines Medical Patient History
== Copyright status ==
na
== Source ==
https://drum.umd.edu/dspace/bitstream/1903/1068/2/CS-TR-4129.pdf

File:Clipboard03.jpg

2007-11-09T14:35:39Z

UE-InfoVis0607 0727197: Figure 2. Hyperbolic Tree

== Summary ==
Figure 2. Hyperbolic Tree
== Copyright status ==
na
== Source ==
https://drum.umd.edu/dspace/bitstream/1903/1068/2/CS-TR-4129.pdf

File:Clipboard01.jpg

2007-11-09T14:35:03Z

UE-InfoVis0607 0727197: Figure 1. US Map with City Names

== Summary ==
Figure 1. US Map with City Names
== Copyright status ==

== Source ==
https://drum.umd.edu/dspace/bitstream/1903/1068/2/CS-TR-4129.pdf

File:Cpof rev2.jpg

2007-11-09T13:51:42Z

UE-InfoVis0607 0727197: New page: == Summary == == Copyright status == na == Source == http://www.gdc4s.com/content/detail.cfm?item=2a58f8e2-ef2b-4bb1-9251-42ee4961dd7f

== Summary ==

== Copyright status ==
na
== Source ==
http://www.gdc4s.com/content/detail.cfm?item=2a58f8e2-ef2b-4bb1-9251-42ee4961dd7f

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - View Relationships

2007-11-07T18:01:01Z

UE-InfoVis0607 0727197: -

Hä?
Ich hab mir zwar nur den Anfang durchgelesen, aber ich denke das verfehlt das Thema.
Da es ja um das Visual Information-Seeking Mantra geht, würde ich sagen es geht - grob gesagt - um die Relationship zwischen Overview und Detail und eher weniger um 3D Scatterplots. Oder?

Beispiele:

[[Image:google_finance.png]]

[[Image:google_maps.png]]

== - ==

Leider habe ich nichts oder zumindest nichts brauchbares in die Richtung gefunden das hier war der einzige Artikel der das Thema zumindest streift.

== - ==
ja, auch ich finde nichts. hab sogar das "Readings in InfoVis" Buch vor mir liegen - nichts.

wir könnten uns selbst was ausdenken, aber das ist wohl auch nicht sinn der sache.

ausserdem muss es ja nicht um die relationships between views sondern es könnte auch um das viewen von relationships gehen. ich glaube es geht um ersteres.

mal sehen was unser tutor dazu zu sagen hat. ob der wohl die diskussionen hier verfolgt?

== -3 ==

es steht part of „Visual Information Seeking Mantra“ - Overview first then Zoom
and Filter on demand (Shneiderman, 1996)

darum würde ich es auch eher Ersterm zuordnen!

Und ich glaube nicht, dass die Diskusion hier von jemand anderem außer uns mitverfolgt wird.

== - ==

ok hab da was gefunden

http://www.ifs.tuwien.ac.at/~mlanzenberger/teaching/ps/ws07/stuff/2007.10.17.gma.VO01.pdf

Seite 38
Grundlagen methodischen Arbeitens
Informationsvisualisierung
von
Monika Lanzenberger
17. 10. 2007

;)

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - View Relationships

2007-11-07T17:49:46Z

UE-InfoVis0607 0727197: -3

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - View Relationships

2007-11-07T13:34:23Z

UE-InfoVis0607 0727197: -

Teaching talk:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - Drag and Drop

2007-11-07T13:31:13Z

UE-InfoVis0607 0727197:

Ich denke hier sollte Drag and Drop auch im Kontext der Informationsvisualisierung beschrieben werden.

Zum Beispiel:
*Panning mittels DnD wie zB in Google Maps
*Direct Manipulation: Ändern der Visualisierung zugrundeliegenden Daten mittels DnD, zB: verschieben von Aktivitäten in einem Projektplanungstool
*Position eines visuellen Elements ändern (ohne die Daten selbst zu ändern) um die Visualisierung zu manuell zu verändern...hier fällt mir im Moment leider kein konkretes Beispiel ein.

Was meint ihr?

ja sicher, nur was hat Drag & Drop schon viel mit Visualisierung zu tun? Maximal dann wenn ich Informationen interaktiv einblenden/ausblenden/ändern will. Der Ansatz den ich hier gefunden habe ist aber "nur" technischer Natur und sollte auf das Wesentliche gekürzt werden falls wir brauchbare Informationen in die andere Richtung haben.

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - Drag and Drop

2007-11-03T15:23:05Z

UE-InfoVis0607 0727197:

[Motif Programmer's Guide] Motif Programmer's Guide, 1994-1996, The Santa Cruz Operation, http://www.s-and-b.ru/syshlp/motif_guide/MotifProgGuide/TOC.html

==Overview of User Interaction==

A drag and drop transaction consists of the following actions:

1. A user presses and holds BTransfer, usually mouse button 2, over a source object starting a drag transaction. The application owning that object is the initiator of the drag. The current pointer is replaced by a drag icon-a picture representing the item being dragged.
2. The user moves the pointer. From now until a drop occurs, the drag icon replaces the mouse pointer.
3. The user drops the object, usually by releasing the mouse button.

Locations on the screen that can accept drops are drop sites, and the application owning that drop site is the destination or receiver.

The drag icon can be dropped anywhere on the screen. However, only certain widgets have registered themselves as drop sites and are able to process the drop.

The receiver application usually performs some action on the information represented by the dragged icon. The initiator application may also perform some action based on the results of a drag transaction.

A drop can be between applications or within the same application. An application can be both source and destination of a drop, source only, destination only, or not participate in drag and drop at all.

The user can request help about a drop site, if available, by dragging to the drop site, and pressing KHelp (usually F1).

The user can cancel the drag at any time by pressing KCancel, usually Escape.
===Overview of Drag-Over Effects===

The drag icon consists of three parts:

* The source icon is a picture representing the type of the source object, such as text.
* The state icon can be used to show whether or not the object being dragged can be dropped at its current location on the screen.
* The operation icon can be used to show what action should happen when the drop takes place.

In the following illustration, the running figure is the source icon, the arrow in the upper left is the state icon, and the rectangles with the corner folded over indicate a Copy is desired.
[[Image:Runner3.gif|left|Icon]]
These parts can be combined (blended) and attached to each other in different ways. The default blending and attachment are shown in the previous illustration.

Parts of the drag icon may change shape or color as it is being dragged through potential drop sites, providing visual feedback about possible drop sites to the user. These changes are drag-over effects.

Applications can use the default drag icon effects, or provide more sophisticated or custom drag icons. The application or user can customize these drag-over effects in resource files.
====Drag States====

During a drag, there are three states that describe the relationship of a drag icon to what is under it at the time:

Valid drop site
The drag icon is over a drop site on which it can potentially be dropped (this is only a hint; when the drop is actually attempted, further processing may show that the drop cannot actually be done).
Invalid drop site
The drag icon is over a drop site, but it cannot be dropped there.
No drop site
The drag icon is not over a registered drop site.

The default state icon for all three states is the same: an arrow in the upper left corner of the drag icon. Because the icon is the same for all three states, it appears not to change during the drag. The application or the user can provide custom state icons or colors in a resource file.
===Drag Operations===

The user specifies what action is to take place when the drop occurs by pressing certain keys when the drag starts or while the drag is in process:

Shift only
Force a move from the initiator to the receiver client (Move)
Ctrl only
Force a copy from the initiator to the receiver client (Copy)
Shift and Ctrl
Force a link between the initiator and receiver clients (Link)

The operation chosen by the user must be valid for both the drag source and the drop site, or the drop site will be considered invalid.

If the user does not specify an operation, one is chosen by the toolkit. It choses an operation that is valid for both the drag source and drop site. Move is the first choice, Copy is the second, and Link is the third. If the system cannot find a valid operation, the drop site is considered invalid.

The operation icon reflects the operation chosen by the user or by the system. If the operation is changed by the user during the drag, the operation icon changes also.

The operation icon may change as the drag icon moves to different drop sites if the drop sites accept different operations.
==Overview of Drag-Under Effects==

A widget registered as a drop site may change visually as a drag icon passes over it. These visual cues are drag-under effects. The sensitive area of the widget is the part that responds to drag and drop. By default it is the whole widget, but applications can specify that only parts of the widget respond to drag and drop.

Various highlighting styles are possible:

* A border around the sensitive area of the drop site widget. This is the default value.
* The sensitive area of the drop site widget looks pushed out.
* The sensitive area of the drop site widget looks pushed in.
* A special pixmap is displayed within the sensitive area of the drop site widget, overwriting what is normally there.
* No drag-under effects are used for the drop site widget.

Applications can use the default drag-under visual effects, or create more sophisticated or custom effects, such as special animation or sound effects.
==Overview of Drop Effects==

Visual effects also take place during the drop:

* The drag icon appears to sit over the drop site while the processing for the drop is finishing, but the standard cursor is restored and can be used normally.
* The source icon appears to melt into the drop site if the drop is successful.
* The source icon appears to snap back to the source if the drop is unsuccessful.
* A dialog window containing information about a drop site should appear if the user has requested help and the receiver client provides help, otherwise nothing happens.
* The source icon appears to snap back to the source and the previous X cursor returns if Cancel is requested. All drag-under and drag-over effects are removed.

These drop effects cannot be changed by the application or the user.

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - Drag and Drop

2007-11-03T15:18:02Z

UE-InfoVis0607 0727197: New page: ==Overview of User Interaction== A drag and drop transaction consists of the following actions: 1. A user presses and holds BTransfer, usually mouse button 2, over a source object sta...

==Overview of User Interaction==

A drag and drop transaction consists of the following actions:

1. A user presses and holds BTransfer, usually mouse button 2, over a source object starting a drag transaction. The application owning that object is the initiator of the drag. The current pointer is replaced by a drag icon-a picture representing the item being dragged.
2. The user moves the pointer. From now until a drop occurs, the drag icon replaces the mouse pointer.
3. The user drops the object, usually by releasing the mouse button.

Locations on the screen that can accept drops are drop sites, and the application owning that drop site is the destination or receiver.

The drag icon can be dropped anywhere on the screen. However, only certain widgets have registered themselves as drop sites and are able to process the drop.

The receiver application usually performs some action on the information represented by the dragged icon. The initiator application may also perform some action based on the results of a drag transaction.

A drop can be between applications or within the same application. An application can be both source and destination of a drop, source only, destination only, or not participate in drag and drop at all.

The user can request help about a drop site, if available, by dragging to the drop site, and pressing KHelp (usually F1).

The user can cancel the drag at any time by pressing KCancel, usually Escape.
===Overview of Drag-Over Effects===

The drag icon consists of three parts:

* The source icon is a picture representing the type of the source object, such as text.
* The state icon can be used to show whether or not the object being dragged can be dropped at its current location on the screen.
* The operation icon can be used to show what action should happen when the drop takes place.

In the following illustration, the running figure is the source icon, the arrow in the upper left is the state icon, and the rectangles with the corner folded over indicate a Copy is desired.
[[Image:Runner3.gif|left|Icon]]
These parts can be combined (blended) and attached to each other in different ways. The default blending and attachment are shown in the previous illustration.

Parts of the drag icon may change shape or color as it is being dragged through potential drop sites, providing visual feedback about possible drop sites to the user. These changes are drag-over effects.

Applications can use the default drag icon effects, or provide more sophisticated or custom drag icons. The application or user can customize these drag-over effects in resource files.
====Drag States====

During a drag, there are three states that describe the relationship of a drag icon to what is under it at the time:

Valid drop site
The drag icon is over a drop site on which it can potentially be dropped (this is only a hint; when the drop is actually attempted, further processing may show that the drop cannot actually be done).
Invalid drop site
The drag icon is over a drop site, but it cannot be dropped there.
No drop site
The drag icon is not over a registered drop site.

The default state icon for all three states is the same: an arrow in the upper left corner of the drag icon. Because the icon is the same for all three states, it appears not to change during the drag. The application or the user can provide custom state icons or colors in a resource file.
===Drag Operations===

The user specifies what action is to take place when the drop occurs by pressing certain keys when the drag starts or while the drag is in process:

Shift only
Force a move from the initiator to the receiver client (Move)
Ctrl only
Force a copy from the initiator to the receiver client (Copy)
Shift and Ctrl
Force a link between the initiator and receiver clients (Link)

The operation chosen by the user must be valid for both the drag source and the drop site, or the drop site will be considered invalid.

If the user does not specify an operation, one is chosen by the toolkit. It choses an operation that is valid for both the drag source and drop site. Move is the first choice, Copy is the second, and Link is the third. If the system cannot find a valid operation, the drop site is considered invalid.

The operation icon reflects the operation chosen by the user or by the system. If the operation is changed by the user during the drag, the operation icon changes also.

The operation icon may change as the drag icon moves to different drop sites if the drop sites accept different operations.
==Overview of Drag-Under Effects==

A widget registered as a drop site may change visually as a drag icon passes over it. These visual cues are drag-under effects. The sensitive area of the widget is the part that responds to drag and drop. By default it is the whole widget, but applications can specify that only parts of the widget respond to drag and drop.

Various highlighting styles are possible:

* A border around the sensitive area of the drop site widget. This is the default value.
* The sensitive area of the drop site widget looks pushed out.
* The sensitive area of the drop site widget looks pushed in.
* A special pixmap is displayed within the sensitive area of the drop site widget, overwriting what is normally there.
* No drag-under effects are used for the drop site widget.

Applications can use the default drag-under visual effects, or create more sophisticated or custom effects, such as special animation or sound effects.
==Overview of Drop Effects==

Visual effects also take place during the drop:

* The drag icon appears to sit over the drop site while the processing for the drop is finishing, but the standard cursor is restored and can be used normally.
* The source icon appears to melt into the drop site if the drop is successful.
* The source icon appears to snap back to the source if the drop is unsuccessful.
* A dialog window containing information about a drop site should appear if the user has requested help and the receiver client provides help, otherwise nothing happens.
* The source icon appears to snap back to the source and the previous X cursor returns if Cancel is requested. All drag-under and drag-over effects are removed.

These drop effects cannot be changed by the application or the user.

File:Runner3.gif

2007-11-03T15:09:54Z

UE-InfoVis0607 0727197: The running figure is the source icon, the arrow in the upper left is the state icon, and the rectangles with the corner folded over indicate a Copy is desired.

== Summary ==
The running figure is the source icon, the arrow in the upper left is the state icon, and the rectangles with the corner folded over indicate a Copy is desired.
== Copyright status ==
na
== Source ==
http://www.s-and-b.ru/syshlp/motif_guide/MotifProgGuide/graphics/runner3.gif

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - View Relationships

2007-11-03T15:05:11Z

UE-InfoVis0607 0727197:

==View Relationships==
[Drakos and Moore] Nikos Drakos and Ross Moore 1993-1999, translated by Niki Sahling 2002.12.03, Interactive 3D Scatterplots - From High-Dimensional Data to Insight, http://www.vrvis.at/via/resources/DA-NSahling/node2.html

Up to three relationships are shown in the 3D scatterplot per se, this is extended across multiple views by visual cues, i.e. color and motion, and linking and brushing. Relations in the data space can be characterized by their dimensionality. A two-dimensional constraint means that an attribute ''a_2'' is dependent of one other attribute ''a_1'': ''f{(a_1,a_2)}=0''. This is a simple constraint which can be shown in every 2D diagram. A 1D constraint in 3D space ''f{(a_1,a_2,a_3)}=0'' forms a surface in 3D space. The mapping to a 2D visualization may result in a view where the characteristics of the higher-dimensional relation are not visible anymore - the viewer may not find them. Obviously ''n''D relations can be directly shown in ''n''D space, and only with strong limitation in (n-1)-dimensional visualization.

With common 2D techniques, the ability to show relations is restricted to 2D, but multiple views and linking can provide a substitution. With 2D scatterplot-matrices linking supports exploration of ''n''D relations, but it can not establish a 3D impression of relations. With 3D scatterplots relations up to the third dimension can be shown, and with linking, the possibilities are even extended. Of course, the extension from 2D to 3D looks small under the circumstances of ''n''D data and ''n'' grows up to 20 or 25. But the higher the dimensionality of the relation is, the less is its commonness and the benefit from its interpretation. It is harder to interpret such relations and does not support insight as high-dimensional objects are hard to grasp.

An attribute which shows dependencies to a combination of two others (a 3D surface or similar structure) will appear as a 3D structure in the 3D scatterplot. '''Figure 1''' shows an example of such a structure, the relation is shown from different viewpoints of a three-dimensional representation. The interpretation is also rather straightforward as the user can see the 3D structure and analyze it. This is an obvious advantage to a 2D visualization, because a 3D surface is difficult to find in 2D space.

[[Image:Img75.png|center|'''Figure 1''' pressure (green), absolute-pressure (red), and velocity (blue) result in a surface in 3D (shown from different viewpoints). Obviously the relation between pressure and absolute-pressure is not linear (shown in the right plot).]]
'''Figure 1:'''
pressure (green), absolute-pressure (red), and velocity (blue) result in a surface in 3D (shown from different viewpoints). Obviously the relation between pressure and absolute-pressure is not linear (shown in the right plot).

This can be further extended, if the 3D structure is not clear and outliers are more common, brushing and linking can show that there is another parameter that influences the relation. Brushing the outliers and isolating them from the assumed relation can show another dependency in a linked view. This can be continued, but the relation is getting harder to understand with every additional dimension which is not shown in the same view.

Linking and brushing in multiple views is a useful tool to analyze relations, because the human perception system recognizes color highlighting very efficiently. Color can be used as a visual cue, not only with highlighting, if the same attribute is mapped to the color value in different views, the affiliations can be perceived across multiple views. Another visual cue which works in the described environment is motion. The 3D rotation of the scatterplot moves the data point with different speed according to the position (front or rear), so neighbors are moving with similar speed which can be easily detected. This cue also works beyond different views, if the rotation is coupled, and the movements are smooth.

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1 - View Relationships

2007-11-03T14:58:00Z

UE-InfoVis0607 0727197: New page: ==View Relationships== Up to three relationships are shown in the 3D scatterplot per se, this is extended across multiple views by visual cues, i.e. color and motion, and linking and b...

==View Relationships==

Up to three relationships are shown in the 3D scatterplot per se, this is extended across multiple views by visual cues, i.e. color and motion, and linking and brushing. Relations in the data space can be characterized by their dimensionality. A two-dimensional constraint means that an attribute ''a_2'' is dependent of one other attribute ''a_1'': ''f{(a_1,a_2)}=0''. This is a simple constraint which can be shown in every 2D diagram. A 1D constraint in 3D space ''f{(a_1,a_2,a_3)}=0'' forms a surface in 3D space. The mapping to a 2D visualization may result in a view where the characteristics of the higher-dimensional relation are not visible anymore - the viewer may not find them. Obviously ''n''D relations can be directly shown in ''n''D space, and only with strong limitation in (n-1)-dimensional visualization.

With common 2D techniques, the ability to show relations is restricted to 2D, but multiple views and linking can provide a substitution. With 2D scatterplot-matrices linking supports exploration of ''n''D relations, but it can not establish a 3D impression of relations. With 3D scatterplots relations up to the third dimension can be shown, and with linking, the possibilities are even extended. Of course, the extension from 2D to 3D looks small under the circumstances of ''n''D data and ''n'' grows up to 20 or 25. But the higher the dimensionality of the relation is, the less is its commonness and the benefit from its interpretation. It is harder to interpret such relations and does not support insight as high-dimensional objects are hard to grasp.

An attribute which shows dependencies to a combination of two others (a 3D surface or similar structure) will appear as a 3D structure in the 3D scatterplot. '''Figure 1''' shows an example of such a structure, the relation is shown from different viewpoints of a three-dimensional representation. The interpretation is also rather straightforward as the user can see the 3D structure and analyze it. This is an obvious advantage to a 2D visualization, because a 3D surface is difficult to find in 2D space.

[[Image:Img75.png|center|'''Figure 1''' pressure (green), absolute-pressure (red), and velocity (blue) result in a surface in 3D (shown from different viewpoints). Obviously the relation between pressure and absolute-pressure is not linear (shown in the right plot).]]
'''Figure 1:'''
pressure (green), absolute-pressure (red), and velocity (blue) result in a surface in 3D (shown from different viewpoints). Obviously the relation between pressure and absolute-pressure is not linear (shown in the right plot).

This can be further extended, if the 3D structure is not clear and outliers are more common, brushing and linking can show that there is another parameter that influences the relation. Brushing the outliers and isolating them from the assumed relation can show another dependency in a linked view. This can be continued, but the relation is getting harder to understand with every additional dimension which is not shown in the same view.

Linking and brushing in multiple views is a useful tool to analyze relations, because the human perception system recognizes color highlighting very efficiently. Color can be used as a visual cue, not only with highlighting, if the same attribute is mapped to the color value in different views, the affiliations can be perceived across multiple views. Another visual cue which works in the described environment is motion. The 3D rotation of the scatterplot moves the data point with different speed according to the position (front or rear), so neighbors are moving with similar speed which can be easily detected. This cue also works beyond different views, if the rotation is coupled, and the movements are smooth.

File:Img75.png

2007-11-03T14:48:10Z

UE-InfoVis0607 0727197: Pressure (green), absolute-pressure (red), and velocity (blue) result in a surface in 3D (shown from different viewpoints). Obviously the relation between pressure and absolute-pressure is not linear (shown in the right plot).

== Summary ==
Pressure (green), absolute-pressure (red), and velocity (blue) result in a surface in 3D (shown from different viewpoints). Obviously the relation between pressure and absolute-pressure is not linear (shown in the right plot).
== Copyright status ==
na
== Source ==
http://www.vrvis.at/via/resources/DA-NSahling/img74.png

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01

2007-10-30T14:56:59Z

UE-InfoVis0607 0727197:

Dies ist die Gruppenseite der '''Gruppe 1''' der Lehrveranstaltung ''UE Informationsvisualisierung WS 07/08''.
== Gruppenmitglieder ==
*[[User:UE-InfoVis0708_0025719|Kaburek, Christian]]
*[[User:UE-InfoVis0607_0304333|Weishapl, Peter]]
*[[User:UE-InfoVis0607_0727197|Eder, Thomas]]
== Aufgaben ==
*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1|Aufgabe 1]]
*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 2|Aufgabe 2]]
*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 3|Aufgabe 3]]
*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4|Aufgabe 4]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-30T14:56:15Z

UE-InfoVis0607 0727197:

Gruppenseite der '''Gruppe 10''' der Lehrveranstaltung
[[Teaching:TUW - UE InfoVis WS 2007/08|UE Informationsvisualisierung WS 07/08]] 
== Gruppenmitglieder ==

== Aufgaben ==
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10 - Aufgabe 1|Aufgabe 1]]

Zurück zu [[Teaching:TUW - UE InfoVis WS 2007/08|InfoVis:Wiki UE Homepage WS 07/08]]

Teaching:TUW - UE InfoVis WS 2007/08

2007-10-30T14:55:44Z

UE-InfoVis0607 0727197:

[[Image:Aigner03infovis ue.gif]] <big>WS 2007/08</big>

'''LVA Nr:''' 188.308 ([http://tuwis.tuwien.ac.at/lva/tuwien/188308 TUWIS++ Seite])

'''LVA Homepage:''' http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html

'''Leitung:''' [[Aigner, Wolfgang|Wolfgang Aigner]] [aigner (at) ifs.tuwien.ac.at] 
'''Tutor:''' [[User:ASchratt|Alexander Schratt]] [alexander.schratt (at) donau-uni.ac.at]

== Gruppen ==

[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01 (Kaburek, Weishapl, Eder)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 02|Gruppe 02 (KOGLER, DUNGEL)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 03|Gruppe 03 (DELPORTE, KLAUSNER)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 04|Gruppe 04 (Autengruber, Frauwallner, Niederreiter)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 05|Gruppe 05 (Petrak, Planinc, Sackl)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 06|Gruppe 06 (Kraicsich, Naber, Sagmeister)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 07|Gruppe 07 (Mihalik, Karaszek, Kaltenecker)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 08|Gruppe 08 (Kamtner, Wolowicz)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 09|Gruppe 09 (Drienovsky, Kremmel, Prohaska)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10|Gruppe 10 ()]] 
== News / Bemerkungen ==
Der An-/Abmeldezeitraum ([http://tuwis.tuwien.ac.at/lva/tuwien/188308 TUWIS++]) für die Übung neigt sich dem Ende zu.
Bitte um die Bildung von Gruppen zu 3 Personen soweit es möglich ist.
Im Moment gibt es einige Gruppen mit nur einem/r TeilnehmerIn. 
-- [[User:Iwolf|Wolfgang Aigner]] 12:08, 26 October 2007 (CEST)

'''Kostenlose Tableau EDU Lizenz verfügbar'''
Tableau ist ein kommerzielles Produkt zur visuellen Datenanalyse.
Für TeilnehmerInnen an der Übung besteht jedoch die Möglichkeit des Downloads einer kostenlosen EDU Lizenz.
Der notwendige Link wird bei Interesse per E-mail zugesandt.
'''Hinweis:''' ''Die Verwendung von Tableau ist für Übungsaufgaben '''NICHT''' erforderlich.'' 
-- [[User:Iwolf|Wolfgang Aigner]] 17:35, 24 October 2007 (CEST)

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-29T09:20:59Z

UE-InfoVis0607 0727197:

Gruppenseite der '''Gruppe 10''' der Lehrveranstaltung
[[Teaching:TUW - UE InfoVis WS 2007/08|UE Informationsvisualisierung WS 07/08]] 
== Gruppenmitglieder ==
[[User:UE-InfoVis0607_0727197|Eder, Thomas]]
== Aufgaben ==
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10 - Aufgabe 1|Aufgabe 1]]

Zurück zu [[Teaching:TUW - UE InfoVis WS 2007/08|InfoVis:Wiki UE Homepage WS 07/08]]

Teaching:TUW - UE InfoVis WS 2007/08

2007-10-29T09:19:38Z

UE-InfoVis0607 0727197: Gruppe 10

[[Image:Aigner03infovis ue.gif]] <big>WS 2007/08</big>

'''LVA Nr:''' 188.308 ([http://tuwis.tuwien.ac.at/lva/tuwien/188308 TUWIS++ Seite])

'''LVA Homepage:''' http://ieg.ifs.tuwien.ac.at/~aigner/teaching/infovis_ue/index.html

'''Leitung:''' [[Aigner, Wolfgang|Wolfgang Aigner]] [aigner (at) ifs.tuwien.ac.at] 
'''Tutor:''' [[User:ASchratt|Alexander Schratt]] [alexander.schratt (at) donau-uni.ac.at]

== Gruppen ==

[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01|Gruppe 01 (Kaburek, Weishapl)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 02|Gruppe 02 (KOGLER, DUNGEL)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 03|Gruppe 03 (DELPORTE, KLAUSNER)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 04|Gruppe 04 (Autengruber, Frauwallner, Kamtner, Niederreiter)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 05|Gruppe 05 (Petrak, Planinc, Sackl)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 06|Gruppe 06 (Kraicsich, Naber, Sagmeister)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 07|Gruppe 07 (Mihalik, Karaszek, Kaltenecker)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 09|Gruppe 09 (Drienovsky, Kremmel, Prohaska)]] 
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10|Gruppe 10 (Eder)]] 
== News / Bemerkungen ==
Der An-/Abmeldezeitraum ([http://tuwis.tuwien.ac.at/lva/tuwien/188308 TUWIS++]) für die Übung neigt sich dem Ende zu.
Bitte um die Bildung von Gruppen zu 3 Personen soweit es möglich ist.
Im Moment gibt es einige Gruppen mit nur einem/r TeilnehmerIn. 
-- [[User:Iwolf|Wolfgang Aigner]] 12:08, 26 October 2007 (CEST)

'''Kostenlose Tableau EDU Lizenz verfügbar'''
Tableau ist ein kommerzielles Produkt zur visuellen Datenanalyse.
Für TeilnehmerInnen an der Übung besteht jedoch die Möglichkeit des Downloads einer kostenlosen EDU Lizenz.
Der notwendige Link wird bei Interesse per E-mail zugesandt.
'''Hinweis:''' ''Die Verwendung von Tableau ist für Übungsaufgaben '''NICHT''' erforderlich.'' 
-- [[User:Iwolf|Wolfgang Aigner]] 17:35, 24 October 2007 (CEST)

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-29T09:18:20Z

UE-InfoVis0607 0727197:

Gruppenseite der '''Gruppe 10''' der Lehrveranstaltung
[[Teaching:TUW - UE InfoVis WS 2007/08|UE Informationsvisualisierung WS 07/08]] 
== Gruppenmitglieder ==
[[User:UE-InfoVis0607_0727197|Eder, Thomas]]
== Aufgaben ==
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1|Aufgabe 1]]

Zurück zu [[Teaching:TUW - UE InfoVis WS 2007/08|InfoVis:Wiki UE Homepage WS 07/08]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-29T09:15:57Z

UE-InfoVis0607 0727197:

Gruppenseite der '''Gruppe 10''' der Lehrveranstaltung
[[Teaching:TUW - UE InfoVis WS 2007/08|UE Informationsvisualisierung WS 07/08]] .
== Gruppenmitglieder ==
[[User:UE-InfoVis0607_0727197|Eder, Thomas]]
== Aufgaben ==
[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1|Aufgabe 1]]

Zurück zu [[Teaching:TUW - UE InfoVis WS 2007/08|InfoVis:Wiki UE Homepage WS 07/08]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-29T09:14:30Z

UE-InfoVis0607 0727197:

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-29T09:13:20Z

UE-InfoVis0607 0727197:

Dies ist die Gruppenseite der '''Gruppe 10''' der Lehrveranstaltung
[[Teaching:TUW - UE InfoVis WS 2007/08|UE Informationsvisualisierung WS 07/08]] .
== Gruppenmitglieder ==
[[User:UE-InfoVis0607_0727197|Eder, Thomas]]
== Aufgaben ==
*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1|Aufgabe 1]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-29T09:12:02Z

UE-InfoVis0607 0727197:

Dies ist die Gruppenseite der '''Gruppe 10''' der Lehrveranstaltung
[[Teaching:TUW - UE InfoVis WS 2007/08|UE Informationsvisualisierung WS 07/08]] .
== Gruppenmitglieder ==
[[User:UE-InfoVis0708_0727197|Eder, Thomas]]
== Aufgaben ==
*[[Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 1|Aufgabe 1]]

Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

2007-10-29T09:09:09Z

UE-InfoVis0607 0727197: Teaching:TUW - UE InfoVis WS 2007/08 - Gruppe 10

User:UE-InfoVis0607 0727197

2007-10-29T09:07:06Z

UE-InfoVis0607 0727197:

Name: '''Eder Thomas'''

Matrikelnummer: '''0727197'''

Studienkennzahl: '''532'''

E-mail Adresse: '''e0727197(at)tuwien.ac.at'''

[[Image:Smal_scrat.jpg|thumb|left|Foto]]

File:Smal scrat.jpg

2007-10-29T09:06:32Z

UE-InfoVis0607 0727197: Scrat

== Summary ==
Scrat
== Copyright status ==

== Source ==

User:UE-InfoVis0607 0727197

2007-10-29T08:50:42Z

UE-InfoVis0607 0727197: New page: Eder Thomas # Foto Matrikelnummer: 0727197 Studienkennzahl: 532 E-mail Adresse: e0727197(at)tuwien.ac.at

Eder Thomas
# Foto
Matrikelnummer: 0727197

Studienkennzahl: 532

E-mail Adresse: e0727197(at)tuwien.ac.at