Wiki source code of Proposalsammlung

Version 13.1 by ybl2 on 2016/11/15 16:34
Show last authors
1 = Zeitplan =
2
3 |=(((
4 Datum
5 )))|=(((
6 Milestone
7 )))
8 |(((
9 24.11
10 )))|(((
11 Proposalvortrag
12 )))
13 |(((
14 22.12
15 )))|(((
16 Erster (primitiver) Prototyp
17 )))
18 |(% colspan="1" %)(% colspan="1" %)
19 (((
20 19.03
21 )))|(% colspan="1" %)(% colspan="1" %)
22 (((
23 Ende der Implementierung
24 )))
25 |(% colspan="1" %)(% colspan="1" %)
26 (((
27 20.03
28 )))|(% colspan="1" %)(% colspan="1" %)
29 (((
30 Start der Benutzerstudie
31 )))
32 |(((
33
34 )))|(((
35 Abschlussvortrag
36 )))
37
38 = Layout Algorithmen =
39
40 == Radiales Layout ==
41
42 [[image:attach:IMG_8357.png]]
43
44 Pros
45
46 * Wurzel ist immer in der Mitte
47 * Guter Überblick über den Datenfluss -
48 klare Zuordnung der Kindern zu ihren Eltern
49
50 Cons
51
52 * kein echtes radiales bei wenig Kindern
53 * dadurch auch viel Whitespace (besonders bei vielen Blättern)
54
55
56
57 Erfragen:radiales Layout möglich
58
59 == HV ==
60
61 [[image:attach:IMG_8358.png]]
62
63 Pros
64
65 * klare Position der Wurzel (wenn man den Algorithmus kennt)
66
67 Cons
68
69 * möglicherweise viel Whitespace
70
71 == Recursive Winding ==
72
73 Pros
74
75 * klare Position der Wurzel
76 * wenig Whitespace
77 * beliebig skalierbar/ beliebiges Seitenverhältnis
78
79 Cons
80
81 * kompliziert (zu implementieren)
82
83
84
85
86
87
88
89 [[image:attach:IMG_8356.png]][[image:attach:IMG_8359.png]]
90
91
92
93 == Force Directed ==
94
95 Pros
96
97 * Platzsparendes Layout
98 * in KIELER bereits vorhanden
99
100 Cons
101
102 * keine klare Position der Wurzel -Highlighting nötig
103 * Sonderbehandlung um mehrfach ein ähnliches Layout zu erzeugen
104
105 == 3D ==
106
107 == Grid ==
108
109 == Balloon Tree ==
110
111 Zuordnung Kind zu Aktor ist durch n
112
113 == Hybrid ==
114
115 = Feature Ideen =
116
117 * Ausgewählte Knoten können expandiert/minimiert (durch Paltzhalter ersetzt) werden
118 * Ausgewählte Knoten kommen in den Fokus
119 * FishEye View Minimizing the focus surrounding Nodes
120 * gleiche Aktoren nur einmal darstellen → vllt kein Baum mehr
121
122
123
124 = Behandlung der Kanten/Hilfslinien =
125
126 * Initialler Vorschlag war zwei Kanten vom Aktor, die zu den Ecken des Kindes führen - unnötige/verwirrende Kanten im Bild
127 * Einfachste Lösung Kante zwischen Knoten- Nachteil ist, dass nicht sofort ersichtlich, welcher Aktor, welcher ist
128 * Kanten zwischen Aktor und Kindknoten
129
130
131
132 = Use Cases =
133
134 == Case 1 - Ausdrucken ==
135
136 Ziel: Wenig Whitespace/kompaktes Layout mit einem guten Seitenverhältnis.
137
138 Mögliche Lösungen: HV-Bäume\Recursive Winding
139
140 TODO: weitere Kompaktionsmöglichkeiten suchen
141
142 == Case 2 - Überblick über das Modell ==
143
144 Ziel: Verdeutlichung von Hierachien und Abhängigkeiten.
145
146 Mögliche Lösungen: Mr. Tree, Radiales Baumlayout
147
148
149
150 == Case 3 - Signal Verfolgung ==
151
152 Ziel: Nachvollziehen von Signalflüsse
153
154 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)
155
156 Grundsätzlich sind kurze Kanten zu bevorzugen. Kein Algorithmus hat besondere Vorteile dafür.
157
158
159
160 == Case 4 - Nachvollziehbarkeit (mit Hilfe von Navigation) ==
161
162 Ziel: Durch Navigation und andere Hilfsmittel können einzelne Teile des Modells gesondert betrachtet/ nachvollzogen werden.
163
164 Mögliche Lösung: Fokus und Kontext- Lösungen, Möglichkeit verschiedene Teile des Modells zu minimieren oder hevorzuheben.
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182

Navigation

Quick Links

KIELER on GitHub
RTSYS Homepage