Changes for page Proposalsammlung

Last modified by ybl2 on 2025/01/30 12:15
<
From version < 9.1 >
edited by ybl2
on 2016/11/15 13:45
To version < 16.1 >
edited by ybl2
on 2023/07/13 12:53
>
Change comment: Renamed from xwiki:RTP16.Proposalsammlung

Summary

Details

Page properties
Parent
... ... @@ -1,0 +1,1 @@
1 +Real Time Project WS 1617 (Layout)
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,6 +36,12 @@
36 36  Abschlussvortrag
37 37  )))
38 38  
109 +==== Verworfene Ideen ====
110 +
111 +3D
112 +
113 +Force Directed Layout
114 +
39 39  = Layout Algorithmen =
40 40  
41 41  == Radiales Layout ==
... ... @@ -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  
132 +
133 +
134 +Erfragen:radiales Layout möglich
135 +
56 56  == HV ==
57 57  
58 58  [[image:attach:IMG_8358.png]]
... ... @@ -91,6 +91,9 @@
91 91  
92 92  Pros
93 93  
174 +* Platzsparendes Layout
175 +* in KIELER bereits vorhanden
176 +
94 94  Cons
95 95  
96 96  * keine klare Position der Wurzel -Highlighting nötig
... ... @@ -102,33 +102,25 @@
102 102  
103 103  == Balloon Tree ==
104 104  
188 +Zuordnung Kind zu Aktor ist durch n
189 +
105 105  == Hybrid ==
106 106  
107 107  = Feature Ideen =
108 108  
109 -* 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
110 110  * FishEye View Minimizing the focus surrounding Nodes
111 111  * gleiche Aktoren nur einmal darstellen → vllt kein Baum mehr
112 112  
113 113  
114 114  
115 -= Behandlung der Kanten =
201 += Behandlung der Kanten/Hilfslinien =
116 116  
117 117  * Initialler Vorschlag war zwei Kanten vom Aktor, die zu den Ecken des Kindes führen - unnötige/verwirrende Kanten im Bild
118 118  * Einfachste Lösung Kante zwischen Knoten- Nachteil ist, dass nicht sofort ersichtlich, welcher Aktor, welcher ist
205 +* Kanten zwischen Aktor und Kindknoten
119 119  
120 120  
121 121  
122 122  
123 -
124 -
125 -
126 -
127 -
128 -
129 -
130 -
131 -
132 -
133 -
134 -
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 -20153824
1 +20153724
URL
... ... @@ -1,1 +1,1 @@
1 -https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTP16/pages/20153824/Proposalsammlung
1 +https://rtsys.informatik.uni-kiel.de/confluence//wiki/spaces/RTP16/pages/20153724/Proposalsammlung

Navigation

Quick Links

KIELER on GitHub
RTSYS Homepage