InfoVis:Wiki - User contributions [en]

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

2008-01-04T13:19:38Z

UE-InfoVis0607 0304333:

== 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_examination1.png]]
[[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]]

File:Blood examination1.png

2008-01-04T13:12:49Z

UE-InfoVis0607 0304333: New page: == Summary == == Copyright status == == Source ==

== Summary ==

== Copyright status ==

== Source ==

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

2008-01-03T16:52:14Z

UE-InfoVis0607 0304333:

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?''

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:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 3

2008-01-02T19:01:30Z

UE-InfoVis0607 0304333: Betonung: in this chart

== 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 exports are higher than imports in this chart.

''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:TUW - UE InfoVis WS 2007/08 - Gruppe 01 - Aufgabe 4

2008-01-02T18:55:55Z

UE-InfoVis0607 0304333: erste version

== 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. The History View is then displayed immediately beneath the attribute.

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]]

File:Blood examination.png

2008-01-02T18:47:33Z

UE-InfoVis0607 0304333: New page: == Summary == == Copyright status == == Source ==

== Summary ==

== Copyright status ==

== Source ==

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

2007-12-07T17:59:09Z

UE-InfoVis0607 0304333:

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.

ähm. ja, also was solls. mehr punkte kann man nicht bekommen. ich hätts noch strenger benotet :D
(die benotung scheint gerade erst gekommen zu sein)

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

2007-12-07T17:56:57Z

UE-InfoVis0607 0304333:

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

2007-12-07T12:09:19Z

UE-InfoVis0607 0304333:

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

2007-12-07T12:05:44Z

UE-InfoVis0607 0304333:

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

2007-11-29T11:48:00Z

UE-InfoVis0607 0304333:

== 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.

=== 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]]
== 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:Aussenhandel redesign2.png

2007-11-29T11:47:06Z

UE-InfoVis0607 0304333: New page: == Summary == == Copyright status == == Source ==

== Summary ==

== Copyright status ==

== Source ==

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

2007-11-29T10:35:52Z

UE-InfoVis0607 0304333:

File:Aussenhandel redesign.png

2007-11-29T10:33:14Z

UE-InfoVis0607 0304333: New page: == Summary == == Copyright status == == Source ==

== Summary ==

== Copyright status ==

== Source ==

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

2007-11-28T18:37:11Z

UE-InfoVis0607 0304333: Wiederherstellung der ursprünglichen Version

== Bewertung ==

'''Punkte: 6 von 10'''

'''Begründung:'''

''View Relationships:''

*Insgesamt wenig eigener Text
*Bei den beiden Definitionen und Beschreibungen handelt es sich um Zitate. Müssen entsprechend formatiert werden. Alle 1:1 übernommene Textpassagen als Zitate kennzeichnen.
*nur eine Quelle als Referenz
*Bilder: Quellenangaben (source) fehlen auf folgenden Image-Seiten:
*''Omniplan'' > selber erstellt?
*''Google maps''
*''Google finance''

*ein Screenshot einer CAD / 3D-Modellier- bzw. Animationsumgebung wäre gut gewesen, da auch im Text erwähnt und klassisches Beispiel für diese Art der Darstellung

*Grundsätzlich ist die vorliegende Beschreibung eigentlich eine Themenverfehlung. Was hier beschrieben wurde, ist die Beziehung von ganzen „Views“ untereinander. Im „Visual Information Seeking Mantra“ ist mit „View Relationships“ oder „Relate“ allerdings die Darstellung der Beziehungen zwischen verschiedenen Datenelementen gemeint (auch innerhalb eines Views) – siehe: http://www2.sims.berkeley.edu/courses/is247/f05/readings/Shneiderman_EyesHaveIt_VL96.pdf

''Drag & Drop''

*Insgesamt wenig eigener Text
*keine Kurzdefinition des Begriffs am Beginn der Seite
*Gute Beschreibung, allerdings zahlreiche Zitate 1:1 übernommen - bitte als solche formatieren!
*References am Ende des Artikels auflisten anstatt bei jedem Punkt
*es wird bei jedem Punkt immer nur aus einer Quelle zitiert!
*Bilder: auf den Image-Seiten bei Angabe der Source die Zitate vervollständigen (nicht nur Hyperlinks angeben)

'''''Ihr habt die Möglichkeit, die angegebenen Dinge noch bis einschließlich 02.12.2007 zu verbessern - dann wird natürlich eure Punkteanzahl aufgewertet!'''''

-- [[User:ASchratt|Alexander Schratt]] 17:32, 23 November 2007 (CEST)

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

2007-11-28T14:57:01Z

UE-InfoVis0607 0304333:

== Bewertung ==

'''Punkte: 6 von 10'''

'''Begründung:'''

''View Relationships:''

*Insgesamt wenig eigener Text
'''Der gesamte Text ist selbst geschrieben. Zugegeben, es ist eine Zusammenfassung - aber kein Copy-Paste!'''

http://www.ifs.tuwien.ac.at/~silvia/wien/gwa/ws05/articles/Baldonado-AVI2000.pdf ==> vgl. Abstract 
(teilweise wurde 1:1 übernommen; das sollte entsprechend gekennzeichnet sein)

-- [[User:ASchratt|Alexander Schratt]] 17:00, 26 November 2007 (CEST)

*Bei den beiden Definitionen und Beschreibungen handelt es sich um Zitate. Müssen entsprechend formatiert werden. Alle 1:1 übernommene Textpassagen als Zitate kennzeichnen.
'''Es ist eine Zusammenfassung mit entsprechend eigenen Formulierungen. Die einzigen Sätze, die 1:1 übernommen wurden sind die Design Rules. Die habe ich jetzt gekennzeichnet.'''

vgl. meinen Kommentar weiter oben

-- [[User:ASchratt|Alexander Schratt]] 17:00, 26 November 2007 (CEST)

*nur eine Quelle als Referenz
'''Ja, es wurde eine Quelle verwendet. Ist das so schlimm? Es war nicht mehr notwendig und nichts vergleichbar gutes zu finden (die Themenverfehlung in Betracht gezogen).'''

Wolfgang Aigner hat in der Angabe zu Aufgabe 1 darauf hingewiesen, dass mehr als eine Quelle 
als Grundlage herangezogen werden soll. Das ist für wissenschaftliches Arbeiten essentiell, 
im Sinne einer kritischen Auseinandersetzung mit Quellen.

-- [[User:ASchratt|Alexander Schratt]] 17:00, 26 November 2007 (CEST)

*Abbildungen: Quellenangaben (source) fehlen auf folgenden Image-Seiten:
'''Alles von mir selbst erstellte Screenshots. Ich habe die Websites verlinkt.'''

Dennoch ist Google maps / finance die Quelle. Formatieren von Web Ressources 
vgl. Punkt 2.5 auf http://www.infovis-wiki.net/index.php/Help:Citation_%26_Bibilography_Format 
Beispiel siehe Punkt 2.5.1 ==> diese Angaben sollten (so weit eruierbar) enthalten sein. 
Verlinkung alleine ist zu wenig.

-- [[User:ASchratt|Alexander Schratt]] 17:00, 26 November 2007 (CEST)

*''Omniplan'' > selber erstellt?
*''Google maps''
*''Google finance''
*ein Screenshot einer CAD / 3D-Modellier- bzw. Animationsumgebung wäre gut gewesen, da auch im Text erwähnt und klassisches Beispiel für diese Art der Darstellung
'''Aber kein Grund Punkte abzuziehen, oder?'''

Dafür dass kein CAD-Screenshot enthalten ist, gibt es keinen Punkteabzug, 
da es Euch grundsätzlich freigestellt ist, welche Abb. ihr hineinstellt.

-- [[User:ASchratt|Alexander Schratt]] 17:00, 26 November 2007 (CEST)

*Grundsätzlich ist die vorliegende Beschreibung eigentlich eine Themenverfehlung. Was hier beschrieben wurde, ist die Beziehung von ganzen „Views“ untereinander. Im „Visual Information Seeking Mantra“ ist mit „View Relationships“ oder „Relate“ allerdings die Darstellung der Beziehungen zwischen verschiedenen Datenelementen gemeint (auch innerhalb eines Views) – siehe: http://www2.sims.berkeley.edu/courses/is247/f05/readings/Shneiderman_EyesHaveIt_VL96.pdf
'''Tja. Da muss ich auch Kritik zurückgeben: "View Relationships" klingt für mich wie "Relationships between Views". Es hätte schon heißen müssen: "Viewing Relationships", oder besser "Relate Task" oder einfach "Relate". Es heißt ja auch "Linking and Brushing", nicht "Link and Brush" (wobei man das mit nichts verwechseln kann). Ausserdem haben wir im Internet nichts zu dem Begriff im Zusammenhang mit Informationsvisualisierung gefunden. Deswegen habe ich mir auch das Shneiderman Buch "Designing The User Interface" ausgeborgt und auch hier (im Kapitel "Information Search and Visualization") nichts zu dem Begriff gefunden. Auch in "Readings in Information Visualization" (im Index) nichts. Ich hoffe das ist verständlich und verhindert Punkteabzug.'''

Dennoch wurde von Ben Shneiderman der Begriff "View Relationships" (vgl. den oben angegebenen Link, S. 5) 
und nicht "Viewing Relationships" eingeführt. Da die Singular Form "View" verwendet wird, 
bedeutet das nicht notwendiger Weise einen Rückschluss auf "Relationships between Views" (Plural).

-- [[User:ASchratt|Alexander Schratt]] 17:00, 26 November 2007 (CEST)

'''''Es wurde der Begriff View Relationships im Kontext eines vollständigen englischen Satzes verwendet. Ist das wirklich so schwer zu einzusehen, dass man das missverstehen kann? Was stimmt an meiner Begründung nicht? Natürlich bedeutet es nicht notwendigerweise diesen Rückschluss, aber wir haben ihn gezogen und ich wollte verständlich machen warum und damit auch helfen dieses Missverständnis vielleicht im nächsten Jahr zu vermeiden. Ausserdem möchte ich bei der Gelegenheit darauf hinweisen, dass 10 Punkte (entspricht damit 0.15 ECTS) lächerlich wenig sind für eine derart strenge Beurteilung und den damit verbundenen hohen Aufwand.'''''

1) Es war in der Angabe klar gekennzeichnet, das "View Relationships" ein Teil 
des "Visual Information Seeking Mantra" von Ben Shneiderman ist. Weiters ist in der Angabe 
der Wiki Eintrag "Visual Information Seeking Mantra" verlinkt. Dort wiederum gibt es 
sowohl Referenzen inkl. Links auf [Sahling, 2002] (http://www.vrvis.at/via/resources/DA-NSahling/masterthesis.html) 
als auch auf den Originalartikel [Shneiderman, 1996] (http://citeseer.ist.psu.edu/409647.html). 
Es sollte nicht zu viel verlangt sein, sich zumindest den Originalartikel von Shneiderman anzusehen, 
wo eine einfache Textsuche nach "view relationships" direkt zu den Beschreibungen führt.
''Unsere Suche nach "View Relationships" hat keine befriedigenden Ergebnisse geliefert. Auch das letztens erwähnte Buch von Shneiderman und das Readings in Information Visualization nicht. Ich plädiere darauf im nächsten Jahr nicht diesen Begriff zu verwenden. Bei den anderen Gruppen wurden auch die Namen der Tasks verwendet und nicht ein Satzteil aus deren Beschreibung. Ach, und bei [Sahling, 2002] geht es auch um multiple views und linking and brushing - diese Arbeit haben wir nämlich schon gefunden.''

2) Natürlich ist es nachvollziehbar, dass der Begriff missverstanden werden kann. 
Wenn aber nicht ganz klar ist, was mit der Angabe gemeint ist, dann wäre es wohl am einfachsten, 
gleich rückzufragen.
''Selbst schuld, ich weiß. Ein wenig Verständnis hätte ich nur gerne. Und ärgern tu ich mich weil ich mich vor allem um eine gute Beschreibung bemüht habe.''

3) Die Punktevergabe bzw. ‑abzüge haben im größten Teil mit den anderen genannten Punkten zu tun. 
Dabei handelt es sich hauptsächlich um Punkte, die recht schnell nachgebessert werden können ‑ 
zudem eröffnen wir die Möglichkeit zur Nachbesserung.

4) Ziel der Übung ist, etwas zu lernen, nicht möglichst wenig für möglichst viele ECTS Punkte tun zu müssen. 
In diesem Jahr fällt zudem die Implementierung eines Prototypen weg, was in den vergangenen Jahren 
noch einen wesentlich höheren Aufwand bedeutet hat. Zudem gibt es keine Präsenzstunden wie in vielen anderen Übungen!
''Verglichen mit Aufgabe 2 war die Aufgabe 1 mehr Aufwand, bringt aber nur halb so viel Punkte. Darum geht es - nicht darum möglichst wenig für möglichst viele ECTS Punkte tun zu müssen. Mir gefällt die LV und ich beschäftige mich gern damit, aber das Preis/Leistungsverhältnis der Aufgabe 1 ist schlecht. Das ist demotivierend und in meinem Fall (wegen des Missverständnisses!) auch ärgerlich.''

-- [[User:ASchratt|Alexander Schratt]] 10:41, 27 November 2007 (CEST)

''Drag & Drop:''

*Insgesamt wenig eigener Text
*keine Kurzdefinition des Begriffs am Beginn der Seite
*Gute Beschreibung, allerdings zahlreiche Zitate 1:1 übernommen - bitte als solche formatieren!
*References am Ende des Artikels auflisten anstatt bei jedem Punkt
*es wird bei jedem Punkt immer nur aus einer Quelle zitiert!
*Abbildungen: auf den Image-Seiten bei Angabe der Source die Zitate vervollständigen (nicht nur Hyperlinks angeben)

'''''Ihr habt die Möglichkeit, die angegebenen Dinge noch bis einschließlich 02.12.2007 zu verbessern - dann wird natürlich eure Punkteanzahl aufgewertet!'''''

-- [[User:ASchratt|Alexander Schratt]] 17:32, 23 November 2007 (CEST)

''Frage: Unser dritter Mann ist untätig. Wir sind de facto nur zu zweit. Ich hoffe, das sind mildernde Umstände für die Benotung?''

Da es für uns nicht möglich ist festzustellen, wer wie viel innerhalb der Gruppe beiträgt, 
kann die Beurteilung für alle Gruppenmitglieder nur einheitlich sein. Bitte weist Euren Kollegen darauf hin, 
dass er seinen Anteil leisten muss.

-- [[User:ASchratt|Alexander Schratt]] 17:00, 26 November 2007 (CEST)

'''''Wieso ist das nicht möglich? Ich sehe in der History ganz genau wer was gemacht hat. Und in den Diskussionen sehe ich, wer mitdiskutiert hat. Ausserdem sage ich es Ihnen, dass unser dritter noch gar nichts gemacht hat ausser seine User Site und er hat auch noch nie auf ein Mail geantwortet. Ich möchte ein Sehr Gut auf diese Übung und soll dafür büßen, dass unser drittes Gruppenmitglied absolut nichts macht? Und er soll dafür ein Sehr Gut bekommen?'''''

1) Die Übung ist halt mal eine Gruppenübung ‑ wenn wir uns die Beiträge eines jeden einzelnen extra ansehen würden, 
dann könnten wir gleich eine Einzelübung machen, was allerdings organisatorisch nicht möglich ist. Zudem kann aus 
der History nicht darauf rückgeschlossen werden, wie groß etwa der Anteil Einzelner an Vorarbeiten (Recherche) ist.

2) Ich benötige den Namen des dritten (mutmaßlich untätigen) Gruppenmitglieds, damit wir ihn anschreiben 
und auffordern können, etwas beizutragen (andernfalls müssen wir der betreffenden Person ein negatives Zeugnis ausstellen). 
Trotzdem bleibt die Gruppenbewertung bestehen.

''Ich habe bis jetzt noch bei jeder Gruppenarbeit schlechte Erfahrungen gemacht. Mich wundert, dass die meisten LV Leiter noch kein System gegen Trittbrettfahrer und für eine faire Benotung haben. Ich würde das so machen (es wurde bei einer Übung schon so gemacht und hat recht gut funktioniert): Am Ende des Semesters darf die Gruppe jedem Mitglied den Anteil der erbrachten Gesamtleistung zuordnen. Wird das nicht gemacht, oder gibt es keine Mehrheit, ist die Standardaufteilung je 1/Anzahl der Mitglieder. Die Punkte der Gruppe werden mit diesem Wert multipliziert * Anzahl der Mitglieder und jeder hat seine Punkteanzahl und damit eine gerechte Note. Oder so ähnlich halt...''

-- [[User:ASchratt|Alexander Schratt]] 11:04, 27 November 2007 (CEST)

Liebe Leute, ich glaube Alexander Schratt hat die Argumente von Seiten der Übungsleitung schon sehr gut erläutert. In die ursprüngliche Bewertung wurde selbstverständlich schon die Tatsache miteinbezogen, dass die Begriffsverwechslung nachvollziehbar ist. Nichts desto trotz müsst ihr aber wohl zugeben, dass ihr euch nicht wirklich mit dem "Visual Information Seeking Mantra" von Ben Shneiderman auseinandergesetzt habt, wodurch auch die andere Thematik erklärbar ist. Dieser Punkt alleine führt aber höchstens zu einem Abzug von nur *einem* Punkt. Die anfangs realtiv niedere Punktezahl ergibt sich aus den klar von Alexander Schratt herausgestrichenen Punkten (Zitatkennzeichnung, Quellenangaben, etc.) und können sehr sehr leicht ausgebessert werden.

Zudem möchte ich auch darauf hinweisen, dass im Rahmen dieser Übung als eine der ganz wenigen (zumindest kenne ich keine anderen LVA's) einerseits wirklich Begründungen für Bewertungen geliefert werden und andererseits auch die Möglichkeit des Nachbesserns besteht. Wir sollten also bei aller (teilweise) verständlichen Kritik die Kirche im Dorf lassen!

Was die generelle Punkteverteilung innerhalb der Übung betrifft, gibt es sicherlich immer wieder Verbesserungspotential, doch ist die Verteilung sicher nicht beliebung und es lässt sich der Aufwand für verschiedene Aufgaben im vorhinein oft nur recht schwer abschätzen.

Die Gruppenproblematik ist ein leidiges Thema, das ich nachvollziehen kann, wofür ich aber noch keine ideale Lösung gefunden habe. Nur gibt es hier aus organisatorischen Gründen keine Möglichkeit auf Einzelarbeiten umzusteigen. Auch die vorgeschlagene gegenseitige Bewertung ist keine ideale Lösung und hat ihre Schwächen. Grundsätzlich ist es ja so, dass es eine ca. einmonatige An-/Abmeldefrist gibt innerhalb der sich die Gruppen zusammenfinden und auch miteinander kommunizieren sollten um sicherzustellen, dass auch wirklich jeder mitmacht. Jeder der nach dieser Frist untätig ist und nichts macht, bekommt ein negatives Zeugnis ausgestellt. Das ist zwar für den Rest der Gruppe nur ein schwacher Trost, aber es gibt hier leider keine anderen Sanktionierungsmöglichkeiten für "Aussteiger". Dennoch wird aber natürlich auch bei der Endbewertung die Tatsache miteinbezogen, wenn während des Semesters Leute ausfallen.

-- [[User:Iwolf|Wolfgang Aigner]] 14:03, 28 November 2007 (CET)

Grrr. Glaubt mir, ich würde mir die Arbeit (der Diskussion) nicht antun und es würde mich bestimmt nicht so Ärgern wenn das stimmen würde (nämlich, dass ich mich mit dem 'Information Visualization Seeking Mantra' nicht auseinandergesetzt habe). Und wie ich das habe!

Ausserdem ist mir die Art, wie mein Feedback quasi als Unsinn angenommen und nicht darauf eingegangen wird (in Bezug auf Themenverfehlung), nicht verständlich.

Die Reaktion auf die Gruppenproblematik - "pech gehabt" - ist schade, unverständlich und leider üblich. Schwächen der vorgeschlagenen Lösung kann ich keine finden, aber bitte.

Fazit: Super LV, aber bitte bitte mehr auf Kritik eingehen. Könnte ja auch für andere nützlich sein.

Übrigens hat mein Kollege gar nichts mit dieser Diskussion zu tun.

-- [[User:UE-InfoVis0607 0304333|Weishapl Peter]] 15:57, 28 November 2007 (CET)

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

2007-11-27T12:12:08Z

UE-InfoVis0607 0304333:

{{Definition|The relationship between views in a multiple view system to form a single conceptual entity.}}

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.

Multiple view system offer a variety of benefits. For example improved user performance, or discovery of unforeseen relationships. In general, they can help in performing ''Visual Information Seeking Tasks'' as defined by Ben Shneiderman in his ''Task by Data Type Taxonomy'' [Shneiderman, 1996], like gaining an overview of a collection, viewing details on demand, or viewing relationships among items.

However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.[Baldonado et al., 2000]

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

[[Image:omniplan.png|150px|thumb|Brushing in OmniPlan]]

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

{{Quotation|Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views|[Baldonado et al., 2000]}}

[[Image:google_maps.png|150px|thumb|Overlapping Views in Google Maps]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

{{Quotation|Use perceptual cues to make relationships among views more apparent to the user.|[Baldonado et al., 2000]}}

[[Image:google_finance.png|150px|thumb|Self Evident Relationship between Overview and Detail in Google Finance]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

{{Quotation|Make the interface for multiple views consistent, and make the states of multiple views consistent.|[Baldonado et al., 2000]}}

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

{{Quotation|Use perceptual techniques to focus the user's attention on the right view at the right time.|[Baldonado et al., 2000]}}

===References===
*[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.
*[Shneiderman, 1996] Ben Shneiderman, The Eyes Have It: A Task by Data Type Taxonomy for Information Visualizations. In ''Proceedings of the IEEE Symposium on Visual Languages'', pages 336-343, Washington. IEEE Computer Society Press, 1996. http://citeseer.ist.psu.edu/409647.html

See also: [[Linking and Brushing]]

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

2007-11-27T11:52:28Z

UE-InfoVis0607 0304333:

File:Google finance.png

2007-11-26T19:55:35Z

UE-InfoVis0607 0304333:

== Summary ==
Google Finance Screenshot

== Copyright status ==

== Source ==
Google Finance (http://finance.google.com) by Google Inc. Accessed on 26th Nov 2007.

File:Google maps.png

2007-11-26T19:54:50Z

UE-InfoVis0607 0304333:

== Summary ==
Google Maps Screenshot
== Copyright status ==

== Source ==
Google Maps (http://maps.google.com) by Google Inc. Accessed on 26th Nov 2007.

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

2007-11-26T19:52:29Z

UE-InfoVis0607 0304333:

{{Definition|The relationship between views in a multiple view system to form a single conceptual entity.}}

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.[Baldonado et al., 2000]

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

[[Image:omniplan.png|150px|thumb|Brushing in OmniPlan]]

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

{{Quotation|Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views|[Baldonado et al., 2000]}}

[[Image:google_maps.png|150px|thumb|Overlapping Views in Google Maps]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

{{Quotation|Use perceptual cues to make relationships among views more apparent to the user.|[Baldonado et al., 2000]}}

[[Image:google_finance.png|150px|thumb|Self Evident Relationship between Overview and Detail in Google Finance]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

{{Quotation|Make the interface for multiple views consistent, and make the states of multiple views consistent.|[Baldonado et al., 2000]}}

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

{{Quotation|Use perceptual techniques to focus the user's attention on the right view at the right time.|[Baldonado et al., 2000]}}

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

See also: [[Linking and Brushing]]

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

2007-11-26T18:48:45Z

UE-InfoVis0607 0304333:

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

2007-11-26T10:33:54Z

UE-InfoVis0607 0304333:

== Bewertung ==

'''Punkte: 6 von 10'''

'''Begründung:'''

''View Relationships:''

*Insgesamt wenig eigener Text
'''Der gesamte Text ist selbst geschrieben. Zugegeben, es ist eine Zusammenfassung - aber kein Copy-Paste!'''
*Bei den beiden Definitionen und Beschreibungen handelt es sich um Zitate. Müssen entsprechend formatiert werden. Alle 1:1 übernommene Textpassagen als Zitate kennzeichnen.
'''Es ist eine Zusammenfassung mit entsprechend eigenen Formulierungen. Die einzigen Sätze, die 1:1 übernommen wurden sind die Design Rules. Die habe ich jetzt gekennzeichnet.'''
*nur eine Quelle als Referenz
'''Ja, es wurde eine Quelle verwendet. Ist das so schlimm? Es war nicht mehr notwendig und nichts vergleichbar gutes zu finden (die Themenverfehlung in Betracht gezogen).'''
*Abbildungen: Quellenangaben (source) fehlen auf folgenden Image-Seiten:
'''Alles von mir selbst erstellte Screenshots. Ich habe die Websites verlinkt.'''
*''Omniplan'' > selber erstellt?
*''Google maps''
*''Google finance''
*ein Screenshot einer CAD / 3D-Modellier- bzw. Animationsumgebung wäre gut gewesen, da auch im Text erwähnt und klassisches Beispiel für diese Art der Darstellung
'''Aber kein Grund Punkte abzuziehen, oder?'''
*Grundsätzlich ist die vorliegende Beschreibung eigentlich eine Themenverfehlung. Was hier beschrieben wurde, ist die Beziehung von ganzen „Views“ untereinander. Im „Visual Information Seeking Mantra“ ist mit „View Relationships“ oder „Relate“ allerdings die Darstellung der Beziehungen zwischen verschiedenen Datenelementen gemeint (auch innerhalb eines Views) – siehe: http://www2.sims.berkeley.edu/courses/is247/f05/readings/Shneiderman_EyesHaveIt_VL96.pdf
'''Tja. Da muss ich auch Kritik zurückgeben: "View Relationships" klingt für mich wie "Relationships between Views". Es hätte schon heißen müssen: "Viewing Relationships", oder besser "Relate Task" oder einfach "Relate". Es heißt ja auch "Linking and Brushing", nicht "Link and Brush" (wobei man das mit nichts verwechseln kann). Ausserdem haben wir im Internet nichts zu dem Begriff im Zusammenhang mit Informationsvisualisierung gefunden. Deswegen habe ich mir auch das Shneiderman Buch "Designing The User Interface" ausgeborgt und auch hier (im Kapitel "Information Search and Visualization") nichts zu dem Begriff gefunden. Auch in "Readings in Information Visualization" (im Index) nichts. Ich hoffe das ist verständlich und verhindert Punkteabzug.'''

''Drag & Drop:''

*Insgesamt wenig eigener Text
*keine Kurzdefinition des Begriffs am Beginn der Seite
*Gute Beschreibung, allerdings zahlreiche Zitate 1:1 übernommen - bitte als solche formatieren!
*References am Ende des Artikels auflisten anstatt bei jedem Punkt
*es wird bei jedem Punkt immer nur aus einer Quelle zitiert!
*Abbildungen: auf den Image-Seiten bei Angabe der Source die Zitate vervollständigen (nicht nur Hyperlinks angeben)

'''''Ihr habt die Möglichkeit, die angegebenen Dinge noch bis einschließlich 02.12.2007 zu verbessern - dann wird natürlich eure Punkteanzahl aufgewertet!'''''
''Frage: Unser dritter Mann ist untätig. Wir sind de facto nur zu zweit. Ich hoffe, das sind mildernde Umstände für die Benotung?''

-- [[User:ASchratt|Alexander Schratt]] 17:32, 23 November 2007 (CEST)

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

2007-11-26T10:26:35Z

UE-InfoVis0607 0304333:

{{Definition|The relationship between views in a multiple view system to form a single conceptual entity.}}

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

[[Image:omniplan.png|150px|thumb|Brushing in OmniPlan]]

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

{{Quotation|Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views|[Baldonado et al., 2000]}}

[[Image:google_maps.png|150px|thumb|Overlapping Views in Google Maps]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

{{Quotation|Use perceptual cues to make relationships among views more apparent to the user.|[Baldonado et al., 2000]}}

[[Image:google_finance.png|150px|thumb|Self Evident Relationship between Overview and Detail in Google Finance]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

{{Quotation|Make the interface for multiple views consistent, and make the states of multiple views consistent.|[Baldonado et al., 2000]}}

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

{{Quotation|Use perceptual techniques to focus the user's attention on the right view at the right time.|[Baldonado et al., 2000]}}

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

See also: [[Linking and Brushing]]

File:Google finance.png

2007-11-26T09:26:33Z

UE-InfoVis0607 0304333:

== Summary ==
Google Finance Screenshot

== Copyright status ==

== Source ==
http://finance.google.com

File:Google maps.png

2007-11-26T09:25:39Z

UE-InfoVis0607 0304333:

== Summary ==
Google Maps Screenshot
== Copyright status ==

== Source ==
http://maps.google.com

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

2007-11-23T21:22:52Z

UE-InfoVis0607 0304333:

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

nein, aber ich würde die tabelle ein bisschen anders machen:
* die abstände zwischen den columns größer machen, damit rsr, % mehr zusammengehörig erscheint.
* die zeilenabstände normal machen, dafür "alternate filling" anwenden. z.B. mit RGB(241,245,250)
...dann kann man rows UND cols gut scannen.
* im titel % SE ohne Klammer, alles grau
* das grau vielleicht dünkler (kann man schlecht lesen wenn man schlecht sieht oder ein schlechtes display hat)

vor allem die ersten beiden punkte finde ich wichtig.

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

2007-11-21T12:33:22Z

UE-InfoVis0607 0304333:

== 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.

== 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-21T12:31:53Z

UE-InfoVis0607 0304333: kritik

== 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.
* The
== 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-21T12:23:57Z

UE-InfoVis0607 0304333:

== 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.
* 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.

== 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 1 - View Relationships

2007-11-09T13:54:48Z

UE-InfoVis0607 0304333:

{{Definition|The relationship between views in a multiple view system to form a single conceptual entity.}}

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

[[Image:omniplan.png|150px|thumb|Brushing in OmniPlan]]

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

''Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views.''

[[Image:google_maps.png|150px|thumb|Overlapping Views in Google Maps]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

''Use perceptual cues to make relationships among views more apparent to the user.''

[[Image:google_finance.png|150px|thumb|Self Evident Relationship between Overview and Detail in Google Finance]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

''Make the interface for multiple views consistent, and make the states of multiple views consistent.''

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

''Use perceptual techniques to focus the user's attention on the right view at the right time.''

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

See also: [[Linking and Brushing]]

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

2007-11-09T13:47:23Z

UE-InfoVis0607 0304333:

{{Definition|The relationship between views in a multiple view system to form a single conceptual entity.}}

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

[[Image:omniplan.png|150px|thumb|Brushing in OmniPlan]]

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

''Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views.''

[[Image:google_maps.png|150px|thumb|Overlapping Views in Google Maps]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

''Use perceptual cues to make relationships among views more apparent to the user.''

[[Image:google_finance.png|150px|thumb|Self Evident Relationship between Overview and Detail in Google Finance]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

''Make the interface for multiple views consistent, and make the states of multiple views consistent.''

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

''Use perceptual techniques to focus the user's attention on the right view at the right time.''

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

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

2007-11-08T18:55:31Z

UE-InfoVis0607 0304333:

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

[[Image:omniplan.png|150px|thumb|Brushing in OmniPlan]]

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

''Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views.''

[[Image:google_maps.png|150px|thumb|Overlapping Views in Google Maps]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

''Use perceptual cues to make relationships among views more apparent to the user.''

[[Image:google_finance.png|150px|thumb|Self Evident Relationship between Overview and Detail in Google Finance]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

''Make the interface for multiple views consistent, and make the states of multiple views consistent.''

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

''Use perceptual techniques to focus the user's attention on the right view at the right time.''

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

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

2007-11-08T12:22:57Z

UE-InfoVis0607 0304333:

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

[[Image:omniplan.png|Brushing in OmniPlan]]

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

''Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views.''

[[Image:google_maps.png]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

''Use perceptual cues to make relationships among views more apparent to the user.''

[[Image:google_finance.png]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

''Make the interface for multiple views consistent, and make the states of multiple views consistent.''

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

''Use perceptual techniques to focus the user's attention on the right view at the right time.''

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

File:Omniplan.png

2007-11-08T12:14:14Z

UE-InfoVis0607 0304333: Omniplan Screenshot.

== Summary ==
Omniplan Screenshot.
== Copyright status ==

== Source ==

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

2007-11-08T12:03:17Z

UE-InfoVis0607 0304333:

A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist, ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

''Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views.''

[[Image:google_maps.png]]

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

''Use perceptual cues to make relationships among views more apparent to the user.''

[[Image:google_finance.png]]

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

''Make the interface for multiple views consistent, and make the states of multiple views consistent.''

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

''Use perceptual techniques to focus the user's attention on the right view at the right time.''

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

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

2007-11-08T11:57:38Z

UE-InfoVis0607 0304333:

==View Relationships==
A multiple view system uses two or more distinct views to support the investigation of a single conceptual entity. Many such systems exist , ranging from computer-aided design (CAD) systems to overview-plus-detail systems that show both and overview for context and a zoomed-in-view for detail.
Multiple view system offer a variety of benefits. For example: improved user performance, discovery of unforeseen relationships, and unification of the desktop.
However, multiple view systems are highly challenging to design, They often use sophisticated coordination mechanisms and layout. In addition, subtle interactions among the many dimensions of the design space complicate design decisions.

===Model===
Multiple view systems are based on three dimensions: ''selection'' of views, ''presentation'' of views, and ''interaction'' among views.

====Definitions====
*A ''single view'' of a conceptual entity is a set of data plus a specification of how to display that data visually.
*Views are ''distinct'' if they allow the user to learn about different aspects of the conceptual entity.
*A ''multiple view system'' uses two or more such distinct views to support the investigation of a given conceptual entity.

====Selection====
The first phase in the design process is to choose a set of views to be used in a coordinated fashion.

====Presentation====
Once a set of views has been chosen, the designer needs to decide how the views will be presented, e.g., sequentially or simultaneously. If the views appear at once, there are many possible combinations of these views on the screen.

====Interaction====
Each view may have independent affordances, e.g., selection or navigation capabilities. There are several common interaction techniques concerning the relationship between multiple views:
*''Navigational Slaving:'' Movements in one view are automatically propagates to other views.
*''Linking:'' Data in one view is connected to data in another view. A specific type of linking is ''brushing'', in which the user highlights items in one view and the corresponding items in another view are highlighted by the system.

Both, slaving and linking are typically governed by a ''coupling function'' that specifies a mapping from objects or navigational position in one view to objects or navigational position in another view.

===Design Rules===

====Space/Time Resource Optimization====
Presenting multiple views sequentially can save display space, but presenting multiple views at once can save time when comparing views, therefore:

''Balance the spatial and temporal costs of presenting multiple views with the spatial and temporal benefits of using the views.''

====Self Evidence====
Perceptual cues can move view registration/alignment from the realm of cognition to the realm of perception, so users can learn more quickly, therefore:

''Use perceptual cues to make relationships among views more apparent to the user.''

====Consistency====
The additional complexity introduced by multiple views must be balanced by ease of learning, which is facilitated by consistency and can make comparisons easier, therefore:

''Make the interface for multiple views consistent, and make the states of multiple views consistent.''

====Attention Management====
When events occur which require the user's attention, perceptual techniques can direct the user to a salient view, therefore:

''Use perceptual techniques to focus the user's attention on the right view at the right time.''

===References===
[Baldonado et al., 2000] Michelle Q. Wang Baldonado, Allison Woodruff, and Allan Kuchinsky.: Guidelines for Using Multiple Views in Information Visualization. ''Advanced Visual Interfaces (AVI2000)'', pages 110–119, Palermo, Italy, May 2000. ACM Press.

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

2007-11-07T20:57:46Z

UE-InfoVis0607 0304333:

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

;)

== - ==

Hmm. Da war ich sogar in der Vorlesung. Aber zu "View Relationships" wurde da nichts gesagt.

Linking & Brushing? Ja, ich denke das ist es!

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

2007-11-07T20:56:27Z

UE-InfoVis0607 0304333: -

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

2007-11-07T15:36:40Z

UE-InfoVis0607 0304333:

File:Google maps.png

2007-11-07T15:35:47Z

UE-InfoVis0607 0304333: Google Maps Screenshot

== Summary ==
Google Maps Screenshot
== Copyright status ==

== Source ==

File:Google finance.png

2007-11-07T15:34:40Z

UE-InfoVis0607 0304333:

== Summary ==
Google Finance Screenshot

== Copyright status ==

== Source ==

File:Google finance.png

2007-11-07T15:28:19Z

UE-InfoVis0607 0304333: New page: == Summary == == Copyright status == == Source ==

== Summary ==

== Copyright status ==

== Source ==

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

2007-11-07T15:24:40Z

UE-InfoVis0607 0304333:

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

2007-11-07T15:23:56Z

UE-InfoVis0607 0304333:

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

2007-11-07T15:10:25Z

UE-InfoVis0607 0304333: ok

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.

== ok ==

ja, du hast recht.

für die paar punkte muss man sich wohl nicht zuviel arbeit antun.

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

2007-11-07T12:22:36Z

UE-InfoVis0607 0304333: Anmerkungen

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

2007-11-07T11:58:04Z

UE-InfoVis0607 0304333: Themenverfehlung?

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

2007-11-02T12:13:59Z

UE-InfoVis0607 0304333:

'''Begründung:'''

Das Foto von Peter Weishapl ist noch nicht in die Userpage eingebaut.

erledigt.

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

2007-11-02T12:13:28Z

UE-InfoVis0607 0304333: done

'''Begründung:'''

Das Foto von Peter Weishapl ist noch nicht in die Userpage eingebaut.

== done ==

erledigt.