Summary

• Page properties (1 modified, 0 added, 0 removed)
• Objects (1 modified, 0 added, 0 removed)
  • Confluence.Code.ConfluencePageClass[0]

Details

Page properties

Content

...	...	@@ -1,3 +1,70 @@
	1	+= Thema des Projekts =
	2	+
	3	+Betrachtung einer anderen Darstellungsweise von Hierarchien (explizite Darstellung Kindknoten außerhalb der Elternknoten)
	4	+
	5	+= Motivation =
	6	+
	7	+Testen von Alternativen um (im besonderern für die Tapete) ein anderes Layout zu erzeugen.
	8	+
	9	+Mit Grundvoraussetzung das die Kindknoten explizit gezeichnet werden.
	10	+
	11	+= Überleitung =
	12	+
	13	+Da nicht ein Layout alle Probleme löst, betrachten wir verschiedene Use Cases.
	14	+
	15	+= Use Cases =
	16	+
	17	+== Case 1 - Ausdrucken ==
	18	+
	19	+Ziel: Wenig Whitespace/kompaktes Layout mit einem guten Seitenverhältnis.
	20	+
	21	+Mögliche Lösungen: HV-Bäume\Recursive Winding
	22	+
	23	+TODO: weitere Kompaktionsmöglichkeiten suchen
	24	+
	25	+== Case 2 - Überblick über das Modell ==
	26	+
	27	+Ziel: Verdeutlichung von Hierachien und Abhängigkeiten.
	28	+
	29	+Mögliche Lösungen: Mr. Tree, Radiales Baumlayout
	30	+
	31	+
	32	+
	33	+== Case 3 - Signal Verfolgung ==
	34	+
	35	+Ziel: Nachvollziehen von Signalflüsse
	36	+
	37	+Mögliche Lösung: Hervorhebung einzelner Signalflüsse. Nachteil bei diesem Ansatz ist, dass Signale zwischen zwei Kindern wieder durch den Parent fließen müssen.(Oder neue Kante)
	38	+
	39	+Grundsätzlich sind kurze Kanten zu bevorzugen. Kein Algorithmus hat besondere Vorteile dafür.
	40	+
	41	+
	42	+
	43	+== Case 4 - Nachvollziehbarkeit (mit Hilfe von Navigation)/Detailansichten ==
	44	+
	45	+Ziel: Durch Navigation und andere Hilfsmittel können einzelne Teile des Modells gesondert betrachtet/ nachvollzogen werden.
	46	+
	47	+Mögliche Lösung: Fokus und Kontext- Lösungen, Möglichkeit verschiedene Teile des Modells zu minimieren oder hevorzuheben.
	48	+
	49	+
	50	+
	51	+== Verworfene Ideen ==
	52	+
	53	+3D
	54	+
	55	+= Umsetzung =
	56	+
	57	+Erster Schritt : KGraph Synthese
	58	+
	59	+
	60	+
	61	+Priorisierung der Use Cases:
	62	+
	63	+1. Use Case 2
	64	+1. Use Case 4
	65	+1. Use Case 3
	66	+1. Use Case 1
	67	+
1	1	= Zeitplan =
2	2
3	3	(% class="wrapped" %)
...	...	@@ -53,6 +53,10 @@
53	53	* kein echtes radiales bei wenig Kindern
54	54	* dadurch auch viel Whitespace (besonders bei vielen Blättern)
55	55
	123	+
	124	+
	125	+Erfragen:radiales Layout möglich
	126	+
56	56	== HV ==
57	57
58	58	[[image:attach:IMG_8358.png]]
...	...	@@ -91,6 +91,9 @@
91	91
92	92	Pros
93	93
	165	+* Platzsparendes Layout
	166	+* in KIELER bereits vorhanden
	167	+
94	94	Cons
95	95
96	96	* keine klare Position der Wurzel -Highlighting nötig
...	...	@@ -102,6 +102,8 @@
102	102
103	103	== Balloon Tree ==
104	104
	179	+Zuordnung Kind zu Aktor ist durch n
	180	+
105	105	== Hybrid ==
106	106
107	107	= Feature Ideen =
...	...	@@ -113,23 +113,12 @@
113	113
114	114
115	115
116		-= Behandlung der Kanten =
	192	+= Behandlung der Kanten/Hilfslinien =
117	117
118	118	* Initialler Vorschlag war zwei Kanten vom Aktor, die zu den Ecken des Kindes führen - unnötige/verwirrende Kanten im Bild
119	119	* Einfachste Lösung Kante zwischen Knoten- Nachteil ist, dass nicht sofort ersichtlich, welcher Aktor, welcher ist
	196	+* Kanten zwischen Aktor und Kindknoten
120	120
121	121
122	122
123	123
124		-
125		-
126		-
127		-
128		-
129		-
130		-
131		-
132		-
133		-
134		-
135		-

Confluence.Code.ConfluencePageClass[0]

Id

...	...	@@ -1,1 +1,1 @@
1		-20153827
	1	+20153884

URL

...	...	@@ -1,1 +1,1 @@
1		-https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTP16/pages/20153827/Proposalsammlung
	1	+https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTP16/pages/20153884/Proposalsammlung