Changes for page Proposalsammlung

Last modified by ybl2 on 2025/01/30 12:15
<
From version < 8.1 >
edited by ybl2
on 2016/11/15 13:37
To version < 16.2 >
edited by ybl2
on 2023/07/13 12:53
>
Change comment: Update document after refactoring.

Summary

Details

Page properties
Parent
... ... @@ -1,0 +1,1 @@
1 +RTP16.Real Time Project WS 1617 (Layout).WebHome
Content
... ... @@ -1,5 +1,68 @@
1 -= Zeitplan =
1 += Vortrag =
2 2  
3 +==== Thema des Projekts ====
4 +
5 +Betrachtung einer anderen Darstellungsweise von Hierarchien (explizite Darstellung Kindknoten außerhalb der Elternknoten)
6 +
7 +==== Motivation ====
8 +
9 +Testen von Alternativen um (im besonderern für die Tapete) ein anderes Layout zu erzeugen.
10 +
11 +Mit Grundvoraussetzung das die Kindknoten explizit gezeichnet werden.
12 +
13 +==== Überleitung ====
14 +
15 +Da ein Layout nicht alle Probleme löst, betrachten wir verschiedene Use Cases.
16 +
17 +==== Use Cases ====
18 +
19 +===== Case 1 - Ausdrucken =====
20 +
21 +Ziel: Wenig Whitespace/kompaktes Layout mit einem guten Seitenverhältnis.
22 +
23 +Ansicht: voller Graph (alle Kanten, alle Beschriftungen)
24 +
25 +Mögliche Lösungen: HV-Bäume\Recursive Winding
26 +
27 +TODO: weitere Kompaktionsmöglichkeiten suchen
28 +
29 +===== Case 2 - Überblick über das Modell =====
30 +
31 +Ziel: Verdeutlichung von Hierachien und Abhängigkeiten.
32 +
33 +Ansicht:
34 +
35 +Mögliche Lösungen: Mr. Tree, Radiales Baumlayout
36 +
37 +===== Case 3 - Signal Verfolgung =====
38 +
39 +Ziel: Nachvollziehen von Signalflüsse
40 +
41 +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)
42 +
43 +Grundsätzlich sind kurze Kanten zu bevorzugen. Kein Algorithmus hat besondere Vorteile dafür.
44 +
45 +===== Case 4 - Nachvollziehbarkeit (mit Hilfe von Navigation)/Detailansichten =====
46 +
47 +Ziel: Durch Navigation und andere Hilfsmittel können einzelne Teile des Modells gesondert betrachtet/ nachvollzogen werden.
48 +
49 +Mögliche Lösung: Fokus und Kontext- Lösungen, Möglichkeit verschiedene Teile des Modells zu minimieren oder hevorzuheben.
50 +
51 +==== Umsetzung ====
52 +
53 +Erster Schritt : KGraph Synthese
54 +
55 +Priorisierung der Use Cases:
56 +
57 +1. Use Case 2
58 +1. Use Case 4
59 +1. Use Case 3
60 +1. (((
61 +Use Case 1
62 +)))
63 +
64 +==== Zeitplan ====
65 +
3 3  (% class="wrapped" %)
4 4  |=(((
5 5  Datum
... ... @@ -18,6 +18,13 @@
18 18  )))
19 19  |(% colspan="1" %)(% colspan="1" %)
20 20  (((
84 +
85 +)))|(% colspan="1" %)(% colspan="1" %)
86 +(((
87 +Zwischenergebnis Präsentation
88 +)))
89 +|(% colspan="1" %)(% colspan="1" %)
90 +(((
21 21  19.03
22 22  )))|(% colspan="1" %)(% colspan="1" %)
23 23  (((
... ... @@ -36,10 +36,14 @@
36 36  Abschlussvortrag
37 37  )))
38 38  
39 -= Layout Algorithms =
109 +==== Verworfene Ideen ====
40 40  
41 -
111 +3D
42 42  
113 +Force Directed Layout
114 +
115 += Layout Algorithmen =
116 +
43 43  == Radiales Layout ==
44 44  
45 45  [[image:attach:IMG_8357.png]]
... ... @@ -55,6 +55,10 @@
55 55  * kein echtes radiales bei wenig Kindern
56 56  * dadurch auch viel Whitespace (besonders bei vielen Blättern)
57 57  
132 +
133 +
134 +Erfragen:radiales Layout möglich
135 +
58 58  == HV ==
59 59  
60 60  [[image:attach:IMG_8358.png]]
... ... @@ -93,6 +93,9 @@
93 93  
94 94  Pros
95 95  
174 +* Platzsparendes Layout
175 +* in KIELER bereits vorhanden
176 +
96 96  Cons
97 97  
98 98  * keine klare Position der Wurzel -Highlighting nötig
... ... @@ -104,32 +104,25 @@
104 104  
105 105  == Balloon Tree ==
106 106  
188 +Zuordnung Kind zu Aktor ist durch n
189 +
107 107  == Hybrid ==
108 108  
109 109  = Feature Ideen =
110 110  
111 -* Expanding all the nodes you like and minimize the others.
194 +* Ausgewählte Knoten können expandiert/minimiert (durch Paltzhalter ersetzt) werden
195 +* Ausgewählte Knoten kommen in den Fokus
112 112  * FishEye View Minimizing the focus surrounding Nodes
197 +* gleiche Aktoren nur einmal darstellen → vllt kein Baum mehr
113 113  
114 114  
115 115  
116 -= Behandlung der Kanten =
201 += 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
205 +* 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 -
IMG_8355.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.XWikiGuest
Size
... ... @@ -1,0 +1,1 @@
1 +9.6 MB
Content
IMG_8356.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.XWikiGuest
Size
... ... @@ -1,0 +1,1 @@
1 +9.7 MB
Content
IMG_8357.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.XWikiGuest
Size
... ... @@ -1,0 +1,1 @@
1 +10.0 MB
Content
IMG_8358.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.XWikiGuest
Size
... ... @@ -1,0 +1,1 @@
1 +9.6 MB
Content
IMG_8359.png
Author
... ... @@ -1,0 +1,1 @@
1 +XWiki.XWikiGuest
Size
... ... @@ -1,0 +1,1 @@
1 +10.0 MB
Content
Confluence.Code.ConfluencePageClass[0]
Id
... ... @@ -1,1 +1,1 @@
1 -20153821
1 +20153724
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTP16/pages/20153821/Proposalsammlung
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTP16/pages/20153724/Proposalsammlung

Navigation

Quick Links

KIELER on GitHub
RTSYS Homepage