Design-Schwächen vor Abgabe
4 verfasser
Seite 1 von 2
Seite 1 von 2 • 1, 2
Design-Schwächen vor Abgabe
Guten Tag liebes UI-Team,
beim Testen sind mir ein paar Schwächen / Fehler aufgefallen:
1. In den Dialogzeilen gibt es den Button "Add Note", der keine Funktion hat. Die Notiz ist immer vorhanden. Entweder kann man den Button entfernen, oder so einstellen, dass er die Notes ein- und ausblendet.
2.Es gibt noch keinen Button zum Löschen von Dialogzeilen. Wie ich grade erfahren habe, gibt es den Button schon und er befindet sich unter den Conditions und Consequences auf der rechten Seite. Allerdings ist dieser Bereich mit (m)einem Laptop nicht erreichbar.
3. Wenn man einen Charakter mit einem langen Namen erstellt hat und ihm bei der Dialogerstellung (Involved Characters) eine Emotion zuweisen will, dann geht das nicht, weil die Combobox nicht erreichbar ist. Eine waagerechte Scrollbar wäre eine Lösung.
So weit so gut. Wenn mir noch etwas einfällt, dann sag ich Bescheid
beim Testen sind mir ein paar Schwächen / Fehler aufgefallen:
1. In den Dialogzeilen gibt es den Button "Add Note", der keine Funktion hat. Die Notiz ist immer vorhanden. Entweder kann man den Button entfernen, oder so einstellen, dass er die Notes ein- und ausblendet.
2.
3. Wenn man einen Charakter mit einem langen Namen erstellt hat und ihm bei der Dialogerstellung (Involved Characters) eine Emotion zuweisen will, dann geht das nicht, weil die Combobox nicht erreichbar ist. Eine waagerechte Scrollbar wäre eine Lösung.
So weit so gut. Wenn mir noch etwas einfällt, dann sag ich Bescheid
Maxim Babinski- Anzahl der Beiträge : 69
Anmeldedatum : 24.10.12
Re: Design-Schwächen vor Abgabe
Hi zusammen:
hier was mir noch aufgefallen is:
1. Bei den Persönlichkeits bedingungen:
Eure UI gibt textfelder für einen bereich "von" "bis" an. Die tolerance nach design (schröpfer) hat aber nur einen wert als toleranz, der die distanz zur maximal ausgeprägten dimension einschränkt.
2. Ich hab immernoch nichts offizielles aus richtung konzept gehört, aber die save/cancel buttons in den ganzen emo/pp klamotten sind redundant.
3. An einigen stellen lese ich "Openess" oder "Openes" bei den persönlichkeitsausprägungen. Rechtschreibfehler sind mir normalerweise egal, da wir aber daran binden, wäre es gerade hier wichtig alles richtig zu schreiben ("Openness")
4. Deleteline rechts unten wird zwar funktionieren (sind gerade dabei die funktionalität dafür hinzuklatschen), allerdings halte ich es für deutlich benutzerfreundlicher, wenn das ganze als Button direkt bei der textline oder in der nähe auftaucht.
5. TextLine kleinigkeiten:
- MainID und SubID sind immernoch auf zwei label rechts und links von der textbox verteilt. Halte ich nich für intuitiv. Wir stellen euch ne property "ID" bereit die das ganze in der Form "1.1" zurückgibt.
- Außerdem glaube ich dass die Zeilennummer unter dem "From" anzuzeigen nich gut aussieht. Da das die nummerierung ist, sollte sie an einer prominenteren Stelle stehen, entweder links daneben oder darüber oder so ähnlich (vllt Fettgedruckt?)
- Wenn man eine Lange textzeile eingibt, wächst das Textfeld. Das ist soweit auch gut. Allerdings verschiebt es alle elemente rechts- und linksunten davon. Wenn man die Zeile nicht selektiert hat, verschwinden ja die buttons, dh wenns möglich wär, wärs cool wenn die Textzeile sich dann entsprechend staucht (bsp mockup untere hälfte screenshot)
- Es stand ja auch noch im Raum, ob die Notiz ausgeblendet (oder vllt anders dargestellt) wird, wenn keine Notiz vorhanden ist, um den Blick des Users nicht unnötig dort hinzuleiten. Gab es dazu noch konkrete äußerungen?
- Wenn man das Fenster breit zieht, vergrößert sich zwar der Innenbereich (TextEditor) in der breite, aber die Textzeile inkl. ihrer Elemente gehen nicht mit. gleiches gilt für das stauchen.
6. In Anlehnung an Maxims Problem mit dem Deletebutton: Wie sehen die Pläne zur Unterstützung niedrigerer Auflösungen aus?
7. Kriegen wir noch n Icon für die linke obere Ecke (und taskbar)? (höchst optional, wollts nur mal erwähnen)
hier was mir noch aufgefallen is:
1. Bei den Persönlichkeits bedingungen:
Eure UI gibt textfelder für einen bereich "von" "bis" an. Die tolerance nach design (schröpfer) hat aber nur einen wert als toleranz, der die distanz zur maximal ausgeprägten dimension einschränkt.
2. Ich hab immernoch nichts offizielles aus richtung konzept gehört, aber die save/cancel buttons in den ganzen emo/pp klamotten sind redundant.
3. An einigen stellen lese ich "Openess" oder "Openes" bei den persönlichkeitsausprägungen. Rechtschreibfehler sind mir normalerweise egal, da wir aber daran binden, wäre es gerade hier wichtig alles richtig zu schreiben ("Openness")
4. Deleteline rechts unten wird zwar funktionieren (sind gerade dabei die funktionalität dafür hinzuklatschen), allerdings halte ich es für deutlich benutzerfreundlicher, wenn das ganze als Button direkt bei der textline oder in der nähe auftaucht.
5. TextLine kleinigkeiten:
- MainID und SubID sind immernoch auf zwei label rechts und links von der textbox verteilt. Halte ich nich für intuitiv. Wir stellen euch ne property "ID" bereit die das ganze in der Form "1.1" zurückgibt.
- Außerdem glaube ich dass die Zeilennummer unter dem "From" anzuzeigen nich gut aussieht. Da das die nummerierung ist, sollte sie an einer prominenteren Stelle stehen, entweder links daneben oder darüber oder so ähnlich (vllt Fettgedruckt?)
- Wenn man eine Lange textzeile eingibt, wächst das Textfeld. Das ist soweit auch gut. Allerdings verschiebt es alle elemente rechts- und linksunten davon. Wenn man die Zeile nicht selektiert hat, verschwinden ja die buttons, dh wenns möglich wär, wärs cool wenn die Textzeile sich dann entsprechend staucht (bsp mockup untere hälfte screenshot)
- Es stand ja auch noch im Raum, ob die Notiz ausgeblendet (oder vllt anders dargestellt) wird, wenn keine Notiz vorhanden ist, um den Blick des Users nicht unnötig dort hinzuleiten. Gab es dazu noch konkrete äußerungen?
- Wenn man das Fenster breit zieht, vergrößert sich zwar der Innenbereich (TextEditor) in der breite, aber die Textzeile inkl. ihrer Elemente gehen nicht mit. gleiches gilt für das stauchen.
6. In Anlehnung an Maxims Problem mit dem Deletebutton: Wie sehen die Pläne zur Unterstützung niedrigerer Auflösungen aus?
7. Kriegen wir noch n Icon für die linke obere Ecke (und taskbar)? (höchst optional, wollts nur mal erwähnen)
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
8. Es gibt immernoch keine Eingabemöglichkeit für die 'To's. Das is essenziell um anständige branched-Dialoge aufbauen zu können...
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
9. Das DataTemplate für die Emotions-Consequences Liste fehlt immernoch
Edit:
Hab angefangen die Consequenzliste einzubauen. Das Datatemplate fehlt noch, aber ich hab schonmal dafür gesorgt, dass minimum 1 item in der Liste auftaucht. Das Item ist vom Typ EConsequenceVM, demnach könnt ihr dann auf dessen properties zurückgreifen wenn ihr das Datatemplate bastelt (siehe screenshot)
Edit: Liste funktioniert jetzt. Keine standard-testdaten mehr. Es wird automatisch eine Consequence für jeden beteiligten Charakter eingefügt.
Datatemplate fehlt immernoch
Edit:
Hab angefangen die Consequenzliste einzubauen. Das Datatemplate fehlt noch, aber ich hab schonmal dafür gesorgt, dass minimum 1 item in der Liste auftaucht. Das Item ist vom Typ EConsequenceVM, demnach könnt ihr dann auf dessen properties zurückgreifen wenn ihr das Datatemplate bastelt (siehe screenshot)
Edit: Liste funktioniert jetzt. Keine standard-testdaten mehr. Es wird automatisch eine Consequence für jeden beteiligten Charakter eingefügt.
Datatemplate fehlt immernoch
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
10. Der gesamte Emo/PP Bereich wird angezeigt, selbst wenn keine Dialogzeile aus dem Dialogzeile ausgewählt ist.
-> Lösung 1: Wir versuchen zu verhindern, dass keine Zeile ausgewählt ist
--> Automatisches auswählen der ersten Zeile beim Dialog öffnen
--> Automatisches auswählen einer anderen Zeile, wenn die Zeile gelöscht wird
+ Wirkt ganz gut, wenn der Bereich nicht verschwindet
- gerade das automatische auswählen beim löschen könnte kniffelig werden.
-> Lösung 2: Wir blenden den Bereich aus, Solange keine Textzeile ausgewählt ist. Das wäre dann nach dem öffnen der Fall, und wenn eine Zeile gelöscht wird
-> Lösung 3: Kompromiss:
--> Wir wählen automatisch die erste Zeile beim öffnen
--> Wir blenden den bereich nach dem Löschen aus
Der teil mit der autoselektierung wäre backend-gebunden, das ausblenden würde in der view per setter funktionieren.
-> Lösung 1: Wir versuchen zu verhindern, dass keine Zeile ausgewählt ist
--> Automatisches auswählen der ersten Zeile beim Dialog öffnen
--> Automatisches auswählen einer anderen Zeile, wenn die Zeile gelöscht wird
+ Wirkt ganz gut, wenn der Bereich nicht verschwindet
- gerade das automatische auswählen beim löschen könnte kniffelig werden.
-> Lösung 2: Wir blenden den Bereich aus, Solange keine Textzeile ausgewählt ist. Das wäre dann nach dem öffnen der Fall, und wenn eine Zeile gelöscht wird
-> Lösung 3: Kompromiss:
--> Wir wählen automatisch die erste Zeile beim öffnen
--> Wir blenden den bereich nach dem Löschen aus
Der teil mit der autoselektierung wäre backend-gebunden, das ausblenden würde in der view per setter funktionieren.
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
So, hier nochmal die Design (!) Schwächen, die man aus dem Feedback bisher ableiten kann:
- keine Tooltips (Svenja arbeitet an einer Hilfe)
- die Dialogzeilen Aufteilung ist verwirrend (werde ich morgen anpassen, ich lade dann wahrscheinlich nochmal meine Idee hoch, bevor ich etwas implementiere und ich werde mir Philipps MockUp nochmals anschauen:P)
- das Problem mit den selektierten Listenelementen (eine Möglichkeit hatte ich bereits hier im Forum vorgestellt, aber da hatte keine ein Feedback gegeben; kann ich aber mal testweise einbauen)
- wir müssen die Interaktion bzgl. der Notizen nun endlich klären (ob immer sichbar oder der Button nur ein Feld sichbar macht usw.)
- Emo/PP Block muss angepasst werden
- Besprechen ob Save/Cancel Buttons benötigt werden
- Schaffen wir es Short Cuts einzubauen? Und wer könnte das übernehmen?
- Man könnte neben den Reglern bei den Characters Textfelder für den Wert einbauen (könnte ich auch morgen machen)
- mit der involves Charakter Haken Sache weiß ich nicht, ob man das über Styles machen könnte (jemand eine Idee?)
Kann sein, dass ich jetzt noch ein paar Punkte vergessen habe. Aber ich denke das ist zur Zeit das Wichtigste.
- keine Tooltips (Svenja arbeitet an einer Hilfe)
- die Dialogzeilen Aufteilung ist verwirrend (werde ich morgen anpassen, ich lade dann wahrscheinlich nochmal meine Idee hoch, bevor ich etwas implementiere und ich werde mir Philipps MockUp nochmals anschauen:P)
- das Problem mit den selektierten Listenelementen (eine Möglichkeit hatte ich bereits hier im Forum vorgestellt, aber da hatte keine ein Feedback gegeben; kann ich aber mal testweise einbauen)
- wir müssen die Interaktion bzgl. der Notizen nun endlich klären (ob immer sichbar oder der Button nur ein Feld sichbar macht usw.)
- Emo/PP Block muss angepasst werden
- Besprechen ob Save/Cancel Buttons benötigt werden
- Schaffen wir es Short Cuts einzubauen? Und wer könnte das übernehmen?
- Man könnte neben den Reglern bei den Characters Textfelder für den Wert einbauen (könnte ich auch morgen machen)
- mit der involves Charakter Haken Sache weiß ich nicht, ob man das über Styles machen könnte (jemand eine Idee?)
Kann sein, dass ich jetzt noch ein paar Punkte vergessen habe. Aber ich denke das ist zur Zeit das Wichtigste.
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
gute zusammenfassung
von technischer seite:
- tooltips: is vermutlich ne xaml sache. jemand schon erfahrung damit?
- Dialogzeilenaufteilung: Meinst du das Datatemplate für ne einzelne Textzeile oder die Anmerkung dass eine Art "Gruppierung" für die Optionen pro answer nett wäre? (letzteres wäre glaube ich sehr umfangreich...)
-Emo/PP Block: welche anpassung meinst du da genau? die Felder/beschriftungen optimieren/korrigieren, oder dass der block bei nichtselektion im editor ausgeblendet wird?
- Shortcuts: Ich weiß immernoch nicht wie die genau funktionieren, alles was ich mal dazu gefunden hatte war dass die wohl an commands gebunden würden. Da die commands dazu im grunde schon existieren sollte das nich viel arbeit sein.
- Textfelder neben Reglern is gut, nur denk dran dass der bereich dann auch breiter wird (gerade lowres-user würde das nerven wenn die textfelder dann ned sichtbar wären)
- invCharacters haken: Weiß nich wie das mit styles aussieht, im zweifelsfall kann man im datatemplate aber denke ich zwei checkmark bilder machen, die dann per Trigger an die IsSelected Eigenschaft der Liste gebunden werden (oder so ähnlich??? is jetz mehr geraten)... Fände das glaub ich auch ganz cool wenn das Element dann gar nich mehr ausgewählt blau hinterlegt erscheint, sondern nur Checkmark hellgrau/Checkmark grün wäre oder sowas in der art... würde glaub ich dann auch etwas eindeutiger aussehen für den user...
Zu den involved Characters auch noch: Die Comboboxen für die Stammemotionen: 1. Rechtsbündig wäre schön, 2. Ausblenden wenn der Charakter nicht "involved" ist... ist das erwünscht, dann probier ich den trigger im datatemplate.. (wäre übrigens derselbe trigger wie für checkmarks fällt mir grad auf)
von technischer seite:
- tooltips: is vermutlich ne xaml sache. jemand schon erfahrung damit?
- Dialogzeilenaufteilung: Meinst du das Datatemplate für ne einzelne Textzeile oder die Anmerkung dass eine Art "Gruppierung" für die Optionen pro answer nett wäre? (letzteres wäre glaube ich sehr umfangreich...)
-Emo/PP Block: welche anpassung meinst du da genau? die Felder/beschriftungen optimieren/korrigieren, oder dass der block bei nichtselektion im editor ausgeblendet wird?
- Shortcuts: Ich weiß immernoch nicht wie die genau funktionieren, alles was ich mal dazu gefunden hatte war dass die wohl an commands gebunden würden. Da die commands dazu im grunde schon existieren sollte das nich viel arbeit sein.
- Textfelder neben Reglern is gut, nur denk dran dass der bereich dann auch breiter wird (gerade lowres-user würde das nerven wenn die textfelder dann ned sichtbar wären)
- invCharacters haken: Weiß nich wie das mit styles aussieht, im zweifelsfall kann man im datatemplate aber denke ich zwei checkmark bilder machen, die dann per Trigger an die IsSelected Eigenschaft der Liste gebunden werden (oder so ähnlich??? is jetz mehr geraten)... Fände das glaub ich auch ganz cool wenn das Element dann gar nich mehr ausgewählt blau hinterlegt erscheint, sondern nur Checkmark hellgrau/Checkmark grün wäre oder sowas in der art... würde glaub ich dann auch etwas eindeutiger aussehen für den user...
Zu den involved Characters auch noch: Die Comboboxen für die Stammemotionen: 1. Rechtsbündig wäre schön, 2. Ausblenden wenn der Charakter nicht "involved" ist... ist das erwünscht, dann probier ich den trigger im datatemplate.. (wäre übrigens derselbe trigger wie für checkmarks fällt mir grad auf)
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
[img][/img]
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
Nur zur Erläuterung:
ich hatte es jetzt so verstanden, dass bei dem from/to mehrere Zahlen aufgelistet werden sollten. Also habe ich versucht einfach die Reihe komplett frei zu lassen, sodass theoretisch so viele Zahlen hinpassen könnten wie man möchte. Daher habe ich Philipps MockUP bzgl der from/tos verändert. Alles Andere orientiert sich aber daran.
Also ich persönlich wäre lieber für die rechte Aufteilung, da so das from/to klar von der Textzeile getrennt ist. Außerdem finde ich, dass die from/tos auf der linken Seite so dominant wirken. Naja, aber das waren jetzt einfach mal Ideen für die Aufteilung. Bitte gebt mir möglichst schnell Feedback, damit ich weiß was ich umsetzen soll;)
ich hatte es jetzt so verstanden, dass bei dem from/to mehrere Zahlen aufgelistet werden sollten. Also habe ich versucht einfach die Reihe komplett frei zu lassen, sodass theoretisch so viele Zahlen hinpassen könnten wie man möchte. Daher habe ich Philipps MockUP bzgl der from/tos verändert. Alles Andere orientiert sich aber daran.
Also ich persönlich wäre lieber für die rechte Aufteilung, da so das from/to klar von der Textzeile getrennt ist. Außerdem finde ich, dass die from/tos auf der linken Seite so dominant wirken. Naja, aber das waren jetzt einfach mal Ideen für die Aufteilung. Bitte gebt mir möglichst schnell Feedback, damit ich weiß was ich umsetzen soll;)
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
Also zunächst: es kann beliebig viele "From"s geben, aber nur ein "To". Das bedeutet, selbst ne ganze Reihe für das "From" könnte auf Dauer nicht reichen (stelle dir einen einzelnen return-point vor, bei dem der Dialog startet und von 30 verschiedenen dialogverläufen wird immer wieder auf diesen startpunkt verwiesen, dann brauchste platz für 30 "Froms". Daher denke ich ein Textblock mit Zeilenumbrüchen wäre vermutlich sinnvoller.
Außerdem finde ich dass die Zeile jetzt sehr überladen wirkt, und der eigentlich zentrale Punkt (nämlich der Text) geht da jetz sehr unter. (is jetz abe auch nur meine meinung...)
Ne idee die ich hatte war, könnte man den From bereich vielleicht mit nem kompakten Expander versehen, sodass zB 2-3 Froms angezeigt werden, und um die evtl restlichen zu sehen expandiert man halt oder so? oder n eigenes scrollviewding oder sonst irgendein mechanismus um den bereich kompakt zu halten? (nur ein spontaner gedanke)
Ein weiterer Nachteil der mir grad an dem aufbau oben auffällt, die "Line" Zeile steht jetz sehr einsam da. Außerdem hat man zB bei einem einzelnen "From" den gesamten platz unter der Textzeile verschwendet. Ich denke angesichts der Tatsache dass wir viele Textzeilen in ner Liste haben würde es sich anbieten den bereich so flach und kompakt wie möglich zu halten
Eine Idee (bloß ne kritzelei) hab ich hier ma eben zusammengeschustert:
Also Den sprechenden Charakter könnte man glaub ich problemlos in die Obere Zeile verschieben, das macht mehr platz links vom text für die Froms. Die strecken sich dann entweder per Zeilenumbruch nach unten (würde die Zeile wieder aufblähen) oder wir suchen ne andere mechanik um den bereich klein zu halten. To auf der rechten Seite neben der Notiz (so wie bisher auch) und unten drunter die buttons, die ausgeblendet werden können. Die kompakte version besteht also nur noch aus zwei zeilen. Is jetz sicher nich das non-plus-ultra, zumal wir in der oberen Zeile immernoch viel Platz verschwenden, aber ich hab sonst echt angst, dass wir den ganzen bereich total aufblähen.
Außerdem finde ich dass die Zeile jetzt sehr überladen wirkt, und der eigentlich zentrale Punkt (nämlich der Text) geht da jetz sehr unter. (is jetz abe auch nur meine meinung...)
Ne idee die ich hatte war, könnte man den From bereich vielleicht mit nem kompakten Expander versehen, sodass zB 2-3 Froms angezeigt werden, und um die evtl restlichen zu sehen expandiert man halt oder so? oder n eigenes scrollviewding oder sonst irgendein mechanismus um den bereich kompakt zu halten? (nur ein spontaner gedanke)
Ein weiterer Nachteil der mir grad an dem aufbau oben auffällt, die "Line" Zeile steht jetz sehr einsam da. Außerdem hat man zB bei einem einzelnen "From" den gesamten platz unter der Textzeile verschwendet. Ich denke angesichts der Tatsache dass wir viele Textzeilen in ner Liste haben würde es sich anbieten den bereich so flach und kompakt wie möglich zu halten
Eine Idee (bloß ne kritzelei) hab ich hier ma eben zusammengeschustert:
Also Den sprechenden Charakter könnte man glaub ich problemlos in die Obere Zeile verschieben, das macht mehr platz links vom text für die Froms. Die strecken sich dann entweder per Zeilenumbruch nach unten (würde die Zeile wieder aufblähen) oder wir suchen ne andere mechanik um den bereich klein zu halten. To auf der rechten Seite neben der Notiz (so wie bisher auch) und unten drunter die buttons, die ausgeblendet werden können. Die kompakte version besteht also nur noch aus zwei zeilen. Is jetz sicher nich das non-plus-ultra, zumal wir in der oberen Zeile immernoch viel Platz verschwenden, aber ich hab sonst echt angst, dass wir den ganzen bereich total aufblähen.
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
die obere Zeile wäre allerdings echt klein und unauffällig wenn nur die Line drin steht. Hätte es fürs Auge nur schöner gefunden, wenn der Dialog direkt neben dem Namen des Charakters auftaucht. Aber ist echt geschmacktsache. Wo ist denn bei dir nun eigentlich dieses "as Answer" hin? Ich blick nämlich echt nicht mehr durch, welche Funktion das nun haben soll. Es gab ein To und ein "line as answer". Außerdem frage ich mich, warum es denn immer nur ein To gibt. Weil eine Zeile kann doch mehrere Antworten haben oder wird das mit den Linebezeichnungen gelöst?
Mit der Expander Sache müsste man schauen. Ich vermute, dass es Expander eher ungeeignet ist. Ich schau mal, ob ich noch etwas anderes finde.
Mit der Expander Sache müsste man schauen. Ich vermute, dass es Expander eher ungeeignet ist. Ich schau mal, ob ich noch etwas anderes finde.
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
ok, ich hab es grad mit dem Expander ausprobiert. Das funktioniert schon, aber ich muss es jetzt nur noch in schön hinbekommen:P
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
Die Idee hinter unseren Main und Sub IDs war es, nur ein "To" zu haben.
Dieses To referenziert nur eine MainID, also eine einzelne "Answer". Diese wiederum besteht aus verschiedenen Optionen. Wenn eine Zeile als "To" zB 3 hat, dann könnten die antwortmöglichkeiten dann 3.1,3.2,3.3,3.4,3.5 und 3.6 sein.
Da meistens die Optionen ja wirklich "gleichwertige" optionen (zB andere formulierungen für NPCs oder verschiedene antwortmöglichkeiten für den Spieler) sind, macht es durchaus Sinn, nur auf eine MainID zu verweisen, statt auf 5-6-7-8 oder noch mehr Optionen die alle in der selben Answer vorkommen. Daher, und zur einfacheren Benutzung nur ein eindeutiges "To"
Die ganze "Line X as Answer" klamotte war irgendwie nie irgendwem so richtig klar, sollte ursprünglich die eingabemethode für das "To" sein. Da aber einfach ein Textfeld neben dem To wesentlich einfacher und kompakter ist als Text+Textbox+Button, und auch vom interaktionsflow her simpler is, haben wir es dabei belassen.
Die Obere Zeile wäre durchaus unauffällig, da spricht auch fast nichts gegen, nur stell dir mal 20 Zeilen davon übereinander vor. das is viel verschwendeter Platz. Ne andere möglichkeit die ich nach nochmaliger betrachtung wiederbringen möchte: Strecken wir doch die Textzeile über die gesamte Höhe. Ich denke die Dialogzeilen werden oft die Zweite Zeile erreichen, dann wäre der Platz zumindest sinnvoll genutzt...
Bspw so:
Eine weitere Idee für die Froms:
Man könnte versuchen eine "kurzform" anzuzeigen, also dann zB "1.1, 2.3, ..." mit ... als indikator dass da mehr is, und vllt kann man nen dynamischen tooltip drauflegen der den kompletten string anzeigt? (wär ne variante....)
Dieses To referenziert nur eine MainID, also eine einzelne "Answer". Diese wiederum besteht aus verschiedenen Optionen. Wenn eine Zeile als "To" zB 3 hat, dann könnten die antwortmöglichkeiten dann 3.1,3.2,3.3,3.4,3.5 und 3.6 sein.
Da meistens die Optionen ja wirklich "gleichwertige" optionen (zB andere formulierungen für NPCs oder verschiedene antwortmöglichkeiten für den Spieler) sind, macht es durchaus Sinn, nur auf eine MainID zu verweisen, statt auf 5-6-7-8 oder noch mehr Optionen die alle in der selben Answer vorkommen. Daher, und zur einfacheren Benutzung nur ein eindeutiges "To"
Die ganze "Line X as Answer" klamotte war irgendwie nie irgendwem so richtig klar, sollte ursprünglich die eingabemethode für das "To" sein. Da aber einfach ein Textfeld neben dem To wesentlich einfacher und kompakter ist als Text+Textbox+Button, und auch vom interaktionsflow her simpler is, haben wir es dabei belassen.
Die Obere Zeile wäre durchaus unauffällig, da spricht auch fast nichts gegen, nur stell dir mal 20 Zeilen davon übereinander vor. das is viel verschwendeter Platz. Ne andere möglichkeit die ich nach nochmaliger betrachtung wiederbringen möchte: Strecken wir doch die Textzeile über die gesamte Höhe. Ich denke die Dialogzeilen werden oft die Zweite Zeile erreichen, dann wäre der Platz zumindest sinnvoll genutzt...
Bspw so:
Eine weitere Idee für die Froms:
Man könnte versuchen eine "kurzform" anzuzeigen, also dann zB "1.1, 2.3, ..." mit ... als indikator dass da mehr is, und vllt kann man nen dynamischen tooltip drauflegen der den kompletten string anzeigt? (wär ne variante....)
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
ok bevor du das mit dem expander jetz ganz lange bastelst, wär die tooltip variante evtl ne möglichkeit? das is simpler umzusetzen und mit sicherheit genauso zweckdienlich... vllt kriegt man genug platz in den textblock, dass man 3-4 referenzen anzeigen kann?
BTW mir fiel grad noch was zur Notiz ein. Falls sich dann endlich mal jemand entscheidet ob wir die ein/ausblenden wollen wenn sie existiert/nicht existiert. Wie wärs, wenn wir den "Add Note" button unten zu add answer und add option packen, und bei existierender Notiz zu "Remove Note" machen? so rein vom flow her kommt das glaub ich hin
1. Zeile markieren
2. "Add Note" fügt notiz hinzu
3. Notiz schreiben und sich freuen
4. Schnauze voll haben von der Notiz
5. "Remove Note" entfernt notiz
-> et viola
BTW mir fiel grad noch was zur Notiz ein. Falls sich dann endlich mal jemand entscheidet ob wir die ein/ausblenden wollen wenn sie existiert/nicht existiert. Wie wärs, wenn wir den "Add Note" button unten zu add answer und add option packen, und bei existierender Notiz zu "Remove Note" machen? so rein vom flow her kommt das glaub ich hin
1. Zeile markieren
2. "Add Note" fügt notiz hinzu
3. Notiz schreiben und sich freuen
4. Schnauze voll haben von der Notiz
5. "Remove Note" entfernt notiz
-> et viola
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
Beispiel 1 mit dem Expander. Hier sehe ich halt 2 Probleme:
- der Expander nimmt viel Platz nach unten ein, wenn er geöffnet ist und vergrößtert in diesem Fall auch die zwei Textfelder.
- das ist ein generelles Problem, welches ich nicht behoben bekomme: die größe des Textfeldes passt sich nie dem Format an. Wenn ich * oder Auto sonstwas benutze, dann vergrößert sich das Textfeld immer ins unendliche. Das sieht zwar so ganz gut aus, macht aber wenig Sinn, wenn man es benutzen will. Also muss eigentlich immer eine MaxWidth angegeben werden. Nur auf welche Größe soll man sich da festlegen, damit das fast bei allen Formaten trotzdem gut aussieht (bei mir z.B. ist immer rechts ganz viel Platzverschwendung, aber bei einem Netbook wäre die Zeile schon wieder viel zu lang...)
[img][/img]
- der Expander nimmt viel Platz nach unten ein, wenn er geöffnet ist und vergrößtert in diesem Fall auch die zwei Textfelder.
- das ist ein generelles Problem, welches ich nicht behoben bekomme: die größe des Textfeldes passt sich nie dem Format an. Wenn ich * oder Auto sonstwas benutze, dann vergrößert sich das Textfeld immer ins unendliche. Das sieht zwar so ganz gut aus, macht aber wenig Sinn, wenn man es benutzen will. Also muss eigentlich immer eine MaxWidth angegeben werden. Nur auf welche Größe soll man sich da festlegen, damit das fast bei allen Formaten trotzdem gut aussieht (bei mir z.B. ist immer rechts ganz viel Platzverschwendung, aber bei einem Netbook wäre die Zeile schon wieder viel zu lang...)
[img][/img]
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
achja, die ComboBox sieht jetzt nur so blöd aus, weil ich vergessen hatte die mindestGröße anzugeben^^
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
ok, mit dem Tooltip an sich ist das kein Problem. Aber wie das mit dem From:1.1,2.3 ... dann gehen sollte (also teilweise Daten im TextBlock und Daten im Tooltip)...das weiß ich leider nicht. Da wüsste ich auch gar nicht wie ich das machen sollte:/
[img][/img]
[img][/img]
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
Das wäre dann wieder n grid problem
Die textfelder und das from feld sind in der selben Zeile, daher werden die größen angepasst.
Hast du vielleicht skype, wo wir mal das ganze fix bequatschen können, das is glaub ich einfacher als hier im forum
Die textfelder und das from feld sind in der selben Zeile, daher werden die größen angepasst.
Hast du vielleicht skype, wo wir mal das ganze fix bequatschen können, das is glaub ich einfacher als hier im forum
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
also die ... habe ich jetzt selbst hinzugefügt
ich kann grad leider nicht skypen...muss eben Essen kochen:D Aber ich kann Bescheid geben, wenn ich fertig bin.
ich kann grad leider nicht skypen...muss eben Essen kochen:D Aber ich kann Bescheid geben, wenn ich fertig bin.
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
OK mit tooltips is gut. Ich vermute du hast jetz tooltip gebunden und Textfeld fix auf "..." gesetzt. Setz den Textblock inhalt auch auf den Inhalt des Tooltips (binding) und dann stellst du in den eigenschaften von textblock in dem abschnitt "Text" die Eigenschaft "TextTrimming" auf "WordEllipsis". Das sorgt dafür dass Text, der nicht in die Box passt automatisch mit "..." abgekürzt wird (wortweise, so würde ich es als sinnvoll erachten). damit hätten wir zumindest diese funktionalität schonmal genutzt. Wenn jetz noch generell genug platz da wäre, um sagen wir 3-4 IDs zu halten in dem Textfeld, wär das glaub ich ganz gut.
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
ok sag bescheid, und adde mich schonma bei skype
(email arne@yodaguitar.de). Dann bequatschen wir die möglichkeiten da mal in ruhe
(email arne@yodaguitar.de). Dann bequatschen wir die möglichkeiten da mal in ruhe
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
also ich hab jetzt zeit
Jennifer Jendral- Anzahl der Beiträge : 149
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
DataTemplate rechter Bereich. Was soll der können?
Tobias Stein- Anzahl der Beiträge : 88
Anmeldedatum : 23.10.12
Re: Design-Schwächen vor Abgabe
alles das was er bereits kann... oder was genau meinste jetz?
ahertel- Anzahl der Beiträge : 507
Anmeldedatum : 25.10.12
Re: Design-Schwächen vor Abgabe
Steht irgendwo weiter oben das da noch ein DataTemplate fehlt. Lad mich gleich mal ins skype ein bitte, dann kannste mich mal eben updaten was noch zu machen ist.
Tobias Stein- Anzahl der Beiträge : 88
Anmeldedatum : 23.10.12
Seite 1 von 2 • 1, 2
Seite 1 von 2
Befugnisse in diesem Forum
Sie können in diesem Forum nicht antworten