Warning: include_once(/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php): failed to open stream: No such file or directory in /var/www/html/fields/cgp08/local/config.php on line 4

Warning: include_once(): Failed opening '/var/www/html/pmwiki-2.2.86/cookbook/soap4pmwiki/soap4pmwiki.php' for inclusion (include_path='.:/opt/php/lib/php') in /var/www/html/fields/cgp08/local/config.php on line 4

Warning: Cannot modify header information - headers already sent by (output started at /var/www/html/fields/cgp08/local/config.php:4) in /var/www/html/pmwiki-2.2.86/pmwiki.php on line 1250
Computergrafik-Praktikum Sommersemester 2008 - Main - Gruppe Statistik

Dokumentation der Teilkomponente Statistik

von Benjamin Föcke und Quy-Manh Tsan

Diese Dokumentation zeigt die Überlegungen unserer Gruppe auf, die im Rahmen des Projektes "Visualisierung von Immatrikulationsdaten" mit der Teilkomponente Statistik betraut war, genauer der Visualisierung verschiedener studentischer Daten mittels Flex-Charting-Komponenten. Es werden zunächst allgemeine Vorüberlegungen aufgeführt, anschließend die aufgetretenen Schwierigkeiten bei der Umsetzung erläutert und die eingeschlagenen Lösungswege beschrieben, die letztendlich zum vorliegenden Endergebnis geführt haben.


Inhalt:

  1. Allgemeine Vorüberlegungen
  2. Tortendiagramm
  3. Säulendiagramm
  4. Sortierung der Daten
  5. Animation
  6. Fazit


#Allgemeine_Vorüberlegungen

Allgemeine Vorüberlegungen

In den ersten Tagen galt es zunächst, sich einen Überblick über die anzuzeigenden Daten zu verschaffen und dabei zu überdenken, welche Flex-Charting-Komponenten zur Anzeige der entsprechenden Daten auf dem Bildschirm geeignet seien. Hierbei spielte die Überlegung, wie z.B. die Koordinatenachsen belegt werden sollten, eine große Rolle.

Wir wählten letztendlich zwei verschiedene Anzeigearten aus, und zwar:


Andere Statistiken wie z.B. das Blasendiagramm, das Liniendiagramm oder das Balkendiagramm schienen unzweckmäßig, vor allem weil schnell klar wurde, dass beim Einsatz aller Diagramme auf einer Achse stets die Anzahl der Studenten angezeigt werden sollte.
Nach dem Setzen von Filtern im Interface sollte dann noch eine Gruppierung gewählt werden können(z.B. Anzeige nach Semester), die die jeweils andere Achse repräsentieren sollte.
Die Darstellung eines zeitlichen Ablaufs per Liniendiagramm machte nur bei Gruppierung nach Alter Sinn. Auch wenn ein Balkendiagramm ebenso sinnvoll gewesen wäre wie das Säulendiagramm, so erschien es doch in der Ansicht zweckmäßiger, ein Säulendiagramm zu wählen, da Nutzer diese Art der Anzeige gewohnter sind und so an der y-Achse die Anzahl an Studenten angezeigt werden konnte, was uns intuitiver zu sein schien.
Das Tortendiagramm kam als alternative Anzeigemöglichkeit hinzu, da mit dieser Ansicht bestimmte Datenanzeigen plastisch und ästhetisch besser dargestellt werden können.
Unserer Meinung nach ergänzten sich die beiden Diagramme perfekt, der Nutzer könnte seine bevorzugte Anzeigeart wählen und zwischen diesen beliebig hin- und herschalten.

Die grundlegenden Aufbauten der beiden statistischen Anzeigearten wurden innerhalb der ersten Woche fertig gestellt. Hierbei mussten verschiedene Entscheidungen getroffen werden, wobei jeweils berücksichtigt werden musste, zum einen die Darstellung einfach zu halten und für den Standardnutzer verständlich zu belassen, zum anderen möglichst viele Informationen zu repräsentieren. Nachfolgende Beispiele sollen einige dieser Kompromisse und Überlegungen offen legen:

Zunächst war z.B. unklar, wie zwischen den beiden Diagramme gewechselt werden könnte. Anfangs hatte unsere Gruppe Statistik im Hauptinterface neben GoogleMaps und GoogleEarth einen eigenen Tab im Darstellungsfenster. Daher wurde der Wechsel zwischen den Diagrammen mittels eines Akkordeons implementiert. Von dieser Lösung wurde letztlich Abstand genommen, das Tortendiagramm und das Säulendiagramm erhielten jeweils eigene Tabs - dies verbesserte maßgeblich die Übersichtlichkeit und gleichsam die Bedienerfreundlichkeit.

Ein wichtiger Punkt war auch die Darstellung der Unterteilung der studentischen Daten in männlich und weiblich bzw. gesamt. Man entschied sich zunächst dafür, dass die Anzeige unerlässlich sei; daher sollten ab sofort nicht nur die Gesamttrefferdaten, sondern auch die Treffer unterteilt in männlich und weiblich an die View übergeben werden (einschließlich der x-Achse, für die ein eigenes Array übergeben wurde, sollten demzufolge nun 4 statt wie bislang 2 Arrays übergeben werden).
Die Anzeige zwischen männlichen und weiblichen bzw. Gesamtzahl an Studenten wurde besonders kompliziert bei der Darstellung im Säulendiagramm, da seitens Flex hier klare Grenzen gesetzt wurden. Mehr dazu soll im Abschnitt Säulendiagramm erläutert werden.
Beim Tortendiagramm war klar, dass eine Unterteilung eines Kuchenstücks in männliche und weibliche Anteile unsinnig war - die Darstellung wurde hier mittels ToolTip gelöst.

Zu guter Letzt war zu entscheiden, ob lediglich der absolute oder auch der relative Anteil angezeigt werden sollte.
Wir entschieden uns, in den Grafiken selbst den absoluten Anteil anzuzeigen, aber auf eine Anzeige des relativen Wertes mittels ToolTips nicht zu verzichten.

Weitere Probleme ergaben sich in der Programmierung der einzelnen Diagramme, da Flex oftmals unseren Wünschen Grenzen setzte. Diese Details werden in den nachfolgenden Abschnitten genauer dargestellt.


Tortendiagramm


Die Realisierung des Tortendiagramms war zunächst kein größeres Problem.
Flex berechnet und erstellt das Diagramm bei Vorgabe entsprechender Daten weitestgehend selbstständig und dynamisch. Um das Diagramm ansprechender zu gestalten, haben wir hier viel am Style gearbeitet.
So wurden Farben, Linien und Styles definiert, angepasst und anschließend in ein CSS-File ausgelagert.

Der Code zeigt den Aufbau des Tortendiagramms in Flex.

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">	
	<mx:Script>	
		...		
	</mx:Script>	
		...
	<mx:Panel 
		id="panel"
		width="100%" height="100%"		
		layout="absolute">	
		<mx:Legend
    		id="pieChartLegend"
    		dataProvider="{pieChart}"     		
    		height="100%"/>
 
		<mx:PieChart
			id="pieChart"
 			height="100%" width="95%"
 			showDataTips="true"
	   		dataTipFunction="pieChart_dataTipFunction">	   					
			<mx:series>
	            <mx:PieSeries	              
	            	id="pieSeries"
	            	field="valueTotal"	            	
	            	nameField="Name"            
	           		showDataEffect="{effInitial}"	           		
	           		labelFunction="pieChart_labelFunction"	            	
	            	radialStroke="{radial}"	            	
	            	stroke="{pieborder}">                
	           	</mx:PieSeries>
	       	</mx:series>
	   	</mx:PieChart>	
    </mx:Panel>	
	...			    	
</mx:Canvas>


Als besonderer Effekt entstand beispielsweise auch ein Initialeffekt, der bei Übergabe neuer Daten einmalig abgefahren wird und das Tortendiagramm entstehen lässt. Dieser Initialeffekt wird nur bei Übergabe völlig neuer Daten genutzt.
Bei Erneuerung der Daten sollte sich das Tortendiagramm durch Interpolation animierend verändern (siehe Punkt Animation).
Hierbei entstand das Problem, wie es umzusetzen sei, dass der Initialeffekt lediglich ein Mal abgefahren wird und sich danach das Diagramm nur noch per Interpolation verändert. Bei allen Versuchen, den Effekt abzuschalten und danach einen anderen zu nutzen, führten dazu, dass der ressourcentechnisch relativ anspruchsvolle Initialeffekt weiterhin im Hintergrund lief und bei jeder Mausbewegung über dem Tortendiagramm erneut gestartet wurde.
Dieses Problem wurde letztlich erfolgreich durch die Nutzung von so genannten States gelöst, wobei sich der Initialeffekt nach seiner ersten Ausführung im Initial-State quasi selbst eliminiert.
Bei der abschließenden Durchsicht entfernten wir uns dann von der Nutzung von States und fanden einen Weg, wie sich der Initialeffekt quasi selbst eliminierte.

Weiterhin wurde, da eine Unterteilung von männlich und weiblich im Tortendiagramm wie oben bereits erwähnt keinen Sinn macht, eine ToolTip-Funktion geschrieben, die, sobald man mit der Maus über ein Tortenstück fährt, die wichtigsten Daten anzeigt, darunter die Gesamtstudentenzahl sowie die Anzahl der männlichen und weiblichen Studenten. Der ToolTip zeigt sowohl absolute als auch relative Zahlen an.
Im statischen Modus wird nicht nur ein ToolTip mit näheren Informationen zum gewählten Datensatz angezeigt, sobald man die Maus über ein Tortenstück bewegt, sondern zusätzlich springt zur besseren Indikation des ausgewählten Elementes das jeweilige Kuchenstück um einen vorher festgelegten Faktor aus dem Tortendiagramm heraus.
Diese ToolTip-Funktion sollte zunächst nur im statischen Anzeigemodus aktiv, während der Animation jedoch ausgeschaltet sein.
Wir entschieden uns jedoch letzten Endes dafür, den ToolTip auch während der Animationen anzeigen zu lassen, damit der Nutzer sich stets Informationen über jedes Kuchenstück auch während der laufenden animierten Veränderung der Tortenstücke einholen könne.

ToolTip und Indikation des Tortenstücks

Ein Problem war anfangs die Indikation der ausgewählten Tortenstücke als auch der stilistisch ansprechendere Effekt des "Abrückens" aller Tortenstücke um einen gewissen Faktor aus der Mitte.
Es wurde nämlich klar, dass ein statischer Faktor bei unterschiedlichen Datensätzen unterschiedlich intensiv wirkte. Sah das Abrücken der Tortenstücke aus der Mitte um einige wenige Pixel bei 25 Datensätzen noch ästhetisch aus, da die Abstände zwischen den Stücken nur leicht angedeutet wurden, so wirkte dieselbe Zahl an Pixeln als Abstand bei 2 oder 3 Datensätzen schon übertrieben groß.
Wir mussten also einen Algorithmus entwerfen, der das "Herausspringen" und das "Abrücken" von Tortenstücken in Abhängigkeit der Anzahl der vorliegenden Daten vornahm.

Zu Beginn der Entwicklungsphase wurde das Tortendiagramm mit Labels bestückt, die nicht innerhalb der Torte, sondern links und rechts außen angezeigt wurden und mittels Callout-Linien auf das jeweils zugehörige Tortenstück verwiesen. Diese Labels zeigten die grundlegenden Daten an, die der x- und y-Achse im Säulendiagramm entsprechen, also Anzahl an Studenten und die jeweiligen Datengruppierung.

Es stellten sich hierbei mehrere Schwierigkeiten heraus, wie z.B. die Tatsache, dass sich die Labels nicht wie gewünscht formatieren ließen. Flex ließ nicht zu, dass die Labels eingerahmt werden konnten, zudem war eine Links-Ausrichtung nicht möglich - die Schrift in den Labels war stets zur Mitte ausgerichtet.

Die Ausrichtung der Schrift ließ sich durch das Auffüllen von Blanks in Abhängigkeit der Zeichenlänge aushilfsweise regeln, jedoch fand sich keine Lösung für das Einrahmen der Labels. Dies hätte bei wenig Datensätzen auch vernachlässigt werden können, bei mehr als 30 Datensätzen hätte dieser Umstand jedoch zu erheblicher Unübersichtlichkeit geführt.

Nichtsdestotrotz ergab sich in Bezug auf die Labels das größte Problem bei der Animation. Wir stellten fest, dass Flex die Labels während einer Animation verschwinden ließ, um sie erst wieder sichtbar zu machen, wenn das Tortendiagramm fertig aufgebaut war. Während unserer geplanten Animation hätte das dazu geführt, dass die Labels beim stetigen Durchlauf der Daten immer nur für den Bruchteil einer Sekunde zu sehen gewesen wären.

Man könnte demnach während der Animation zwar sehen, wie sich die einzelnen Datensätze durch Interpolation vergrößerten oder verkleinerten, wüsste aber nichts über die Daten, da weder Gruppierung noch Anzahl Studenten angezeigt würden.

Dies ließ uns letztlich den Entschluss fassen, auf die Labels vollständig zu verzichten und stattdessen eine Legende einzufügen und zusätzlich auch während der Animation ToolTips anzeigen zu lassen.
Wir formatierten die Legende so, dass diese in eine Spalte passte - dies war wichtig, damit sich die Legende nicht ggf. mit dem Kuchen überschnitt.

Weiterhin gelang es uns nach langer Arbeit und Tüftelei, eine Funktion und zugehörige Event-Handler zu schreiben, die, sobald man die Maus über ein Legenden-Item bewegte, das zugehörige Tortenstück herausspringen ließ. So war es nun möglich geworden, ein Tortenstück sowohl direkt zu indizieren als auch dieses über die Legende anzusprechen.

Legende und Legenden-EventHandler

Eine der größten Schwierigkeiten in Bezug auf die Anzeige wurde letztendlich die Anzahl der Daten. Nachdem die Daten aus der Datenbank verfügbar waren, wurde das Tortendiagramm gezwungen, bis zu 600 Datensätze (=Tortenstücke!) anzuzeigen. Dies machte keinen Sinn, so dass wir uns entschlossen, die Anzahl der Tortenstücke auf 30 zu begrenzen.

Damit gingen natürlich konsequenterweise 2 Folgen einher:
Zum einen mussten die anzuzeigenden Datensätze ausgewählt werden, zum anderen war klar, dass die Darstellung aller restlichen Daten in einem Tortenstück "Sonstige" aufgeführt werden mussten.

Bei der Wahl der anzuzeigenden Datensätze entschieden wir uns für die 29 größten - demnach relevantesten - Daten. In Feld 30 sollten dann die restlichen Daten zusammengefasst werden, was zu Additionsschleifen und weiteren ausgeklügelten Algorithmen führen sollte.

Da wir also die Daten stets der Größe nach benötigten, legten wir fest, im Tortendiagramm ausschließlich sortierte Datensätze zu nutzen. So wurden die ersten 29 angezeigt und der Rest im Feld Sonstige zusammengefasst, wobei wir für das Feld 30 einen eigenen ToolTip entwarfen, der angab, wie viele und welche Daten in diesem Feld zusammengefasst wurden.

ToolTip beim Feld Sonstige

Eine negative Konsequenz brachte die Sortierung jedoch mit sich: In der Animation wurden alle Datensätze stets neu sortiert - weniger erfreulich daran war, dass bei jedem Datentausch ein Datensatz eine neue Farbe und in der Legende eine neue Position bekam. Die Daten tauschten "im Laufe der Zeit" - also während der Animation - ihre Reihenfolge (je nach Größe der Datensätze). Obwohl wir aufgrund der Zeit dieses Problem nicht mehr lösen konnten, so kompensierten wir es doch mit dem ToolTip, den wir für die Animation integrierten, so dass ein Nutzer auch während der Animation stets prüfen konnte, wo welcher Datensatz angezeigt werden würde.

Tortendiagramm im Animationsmodus


#Säulendiagramm

Säulendiagramm


Die Flex-Charting-Komponenten bieten vier verschieden Typen der Säulendiagramme an. Für unsere Anforderungen haben wir uns erstmal auf zwei beschränkt: Stacked oder Clustered.

Unser erster Ansatz war es, dem Benutzer zwei verschiedene Ansichten zu bieten, zwischen die er wählen konnte. Die erste Ansicht zeigt die gesamte Studentenanzahl und die zweite Ansicht unterteilt diese nach dem Geschlecht. Im letzten Fall würden zwei Säulen angezeigt werden, die nebeneinander stehen. Diese Ansicht lässt sich mich Clustered-Säulendiagramm realisieren.

Der zweite Ansatz besteht darin, alle Informationen in einer Säule darzustellen, indem wir die Säulen, die jeweils die Studentinnen und Studenten repräsentieren, aufeinander stapeln und somit auch die Gesamtzahl angezeigt bekommen. Die Vor- und Nachteile der Säulendiagramme zeigt die folgende Tabelle:

SäulendiagrammVorteileNachteile
Clustered-Vergleich der weiblichen und männlichen Studenten deutlicher zu sehen-Der Wechsel der Ansichten wirkt verwirrend, weil die y-Achse sich der Säulen dynamisch anpasst. Das bedeutet, dass sich die Größe der Säulen nicht wesentlich ändert, sondern nur die Skalierung der y-Achse. Somit könnte es zu einem verfälschten Eindruck kommen
-Implementation mit zwei ColumnChart-Komponenten
Stacked-Alle Angaben in einer Säule
-Implementation mit einer ColumnChart-Komponente
-Vergleich der weiblichen und männlichen Studenten nicht optimal

Da wir die Diagramme noch über die Zeit animieren wollten, haben wir uns für das "Stacked"-Säulendiagramm entschieden. Denn für die Animation müssen die Daten für alle Zeitpunkte im Voraus berechnet werden, um die Ladezeit zu verkürzen. Somit hätte man für das Clustered-Säulendiagramm zwei verschiedene Datensätze gebraucht, das mehr Ladezeit und Speicherplatz beanspruchen würde.

Der Code zeigt den Aufbau eines Balkendiagramms und die Initialisierung der Säulen und der Achsen.

<?xml version="1.0" encoding="utf-8"?>
<mx:Canvas xmlns:mx="http://www.adobe.com/2006/mxml">
	<mx:Script>
		...	
	<mx:Script>
		...
	<mx:HBox width="100%" height="100%" id="hbox">	
		<mx:ColumnChart				 
			gutterBottom="100"
			id="myChart"		
			showDataTips="true" 	
			height="100%"
			dataProvider="{dataSet}"
			width="{(model.queryData.length*breite)+50}"
			type="stacked">	
			<mx:horizontalAxis>  
				<mx:CategoryAxis  
					id="xAchse"
					displayName="{model.filterVO.groupBy}"
					categoryField="Name"
					/>
			</mx:horizontalAxis>
			<mx:verticalAxis>
				<mx:LinearAxis 
					id="yAchse"
					displayName="Studienfälle"
					 minorInterval="100"/>
			</mx:verticalAxis>	
			<mx:horizontalAxisRenderers>
				<mx:AxisRenderer			
					labelRotation="25"
					axis="{xAchse}"  
					/>
			</mx:horizontalAxisRenderers>						
			<mx:series> 
				<mx:ColumnSeries  
					id="mSeries"
					displayName="Männer"
					yField="valueMale"
					xField="Name"
					showDataEffect="{effIn}" >	
						<mx:fill>
							<mx:SolidColor color="#1E90FF"/>
						</mx:fill>							
				</mx:ColumnSeries>					
				<mx:ColumnSeries
					id="fSeries"
					displayName="Frauen"
					yField="valueFemale"
					xField="Name"
					showDataEffect="{effIn}">
						<mx:fill>
							<mx:SolidColor color="#FF0000"/>
						</mx:fill>									
				</mx:ColumnSeries>		
			</mx:series>			
		</mx:ColumnChart>	
	</mx:HBox>
	...			
</mx:Canvas>


Konfiguration
Nachdem wir unsere Wahl getroffen haben, musste nun das Layout bestimmt werden. Die Breite der x-Achse wird durch die Anzahl der Gruppierungselemente dynamisch berechnet. Zusätzlich wird das Diagramm mit einer vertikalen Scrollbar versehen, falls es zu viele Gruppierungselemente gibt. Weiterhin haben wir uns entschieden, dass die Beschriftung der x-Achse etwas schräger angesetzt wird, um die Säulen besser zuzuordnen, weil die Beschreibungen der Gruppierungselemente unregelmäßig lang bzw. kurz sind. Der Text über dem Diagramm gibt dem Benutzer die Auskunft, wie viele Studenten insgesamt nach dem Filtern gefunden wurden und wonach gruppiert wird.

ToolTip
Um den Nachteil des Stacked-Säulendiagrammes aufzuheben, sollten im Tooltip neben den absoluten Zahlen auch die prozentualen Zahlen stehen. Das generiert Flex automatisch. Weiterhin werden die Gruppierung und die Zuordnung der Säule angegeben. Die Randfarbe des Tooltips passt sich hier automatisch dem der Säule an, so dass es eindeutig bleibt.


Das Bild zeigt die Realisierung unserer Ideen.

Säulendiagramm im Erfassungssemester WS 05/06


Sortierung der Daten

Weitere Überlegungen, die sich im Laufe des Projektes ergeben haben, entstanden dem Wunsch, innerhalb der Statistikanzeige die Daten nach dem Attribut Anzahl Studenten sortieren zu können.

Die Daten sollten mittels einer CheckBox, die am oberen Rand des Statistikvisualisierungsfensters platziert werden sollte, auf Mausklick sortiert angezeigt werden können. Es ermöglicht dem Benutzer eine bessere Ansicht, falls dieser sich z.B. für die Studiengänge interessiert, in denen sich die meisten Studenten befinden. Dieses Feature sollte nur dem Säulendiagramm gegeben werden, da sich im Tortendiagramm nur die geordneten Datensätze befinden(s.Tortendiagramm).

Die Implementation einer Sortierungsfunktion im Programmcode stellte soweit kein Problem dar. Es wurde darauf verzichtet, eine Sortierung von männlichen oder weiblichen Zahlen vornehmen zu können, die Sortierung beschränkt sich demnach auf die Gesamtzahl an Studenten.

Der Übergang zwischen den beiden Status wurde wie bei der Animation (siehe dort) mittels Interpolation geregelt und kann in Echtzeit und unmittelbar ohne Verzögerung erfolgen, weil alle Daten nicht noch mal übergeben werden mussten, sondern in der View gleich zwei mal angelegt wurden, wobei die eine sortiert wird.

Sortiertes Säulendiagramm im WS 05/06


Animation


Im Laufe der zweiten Woche des Computergrafikpraktikums entstand die Idee, die einzelnen Datensätze in ihrer zeitlichen Abfolge animiert einsehen zu können, und zwar in der Art, dass eine Animation mittels eines Play-Buttons entweder über alle Winter- oder aber über alle Sommersemester gestartet werden kann.
Die Idee dabei war, alle Semester nacheinander einsehen zu können, wobei sich die Daten in den Statistiken animiert ändern sollen, d.h. die Daten des jeweiligen Semesters verlaufen fließend in die neuen Daten des übernächsten Semesters.

Beim Säulendiagramm bedeutet dies, dass die Säulen entweder anwachsen oder abfallen, beim Tortendiagramm werden die Tortenstücke entsprechend größer oder kleiner.

Um die Animation starten zu können, mussten wir beim Säulendiagramm die jeweiligen Achsen festsetzen. Hätte wir die y-Achse nicht durch das Maximum aller Säulen gesetzt, so hätte diese sich während der Animation dynamisch verändert und die Tendenzen verfälscht. Weiterhin mussten alle Gruppierungselemente der View übergeben werden, da entweder Flex automatisch die Elemente nicht zeigt, dessen Quantität gleich null ist oder es Gruppierungselemente erst zu einem späteren Zeitpunkt gibt. Als Beispiel hätten wir den Abschluss Bachelor bzw. Master, der erst seit dem Wintersemester 1998/1999 existiert.

Der Code zeigt die Methode, die bei der Animation der Säulen aufgerufen wird.

private function animate(target:String):void 
            {	
         		this.yAchse.maximum=model.yMax;
         		this.xAchse.dataProvider=model.abscissas;
            }

Somit können wir das Anwachsen und das Abfallen der Torten und Säulen mit dem Effekt der Interpolation realisieren und die Animation kann beginnen.

Fazit


Die Flex Charting Komponenten sind dynamisch und das Programmieren der Diagramme ist recht einfach und lässt viele Spielereien zu. Ein noch offenes Problem ergibt sich, sobald man auf die Dynamik verzichten will. In unserem Fall mussten wir für die Animation die x-Achse festsetzen. Das führte aber zu einem nicht gewünschten Nebeneffekt. Flex interpolierte die Säulen nicht immer, sondern verschob sie. Dies ist wahrscheinlich darin begründet, dass Flex manchmal "faul" ist und erkennt, dass das Schieben der Säulen mit weniger Aufwand verbunden ist als das Interpolieren der Säulen. Zusammengefasst sind die Komponenten in ihrer Handhabung einfach, solange man ihre Einstellungen übernehmen will. Die Dynamik kann hier aber auch zu Problemen führen, falls man teilweise auf sie verzichten möchte.


Page last modified on September 18, 2008, at 05:09 PM