Externes Feedback 1

So liebe leuts,
ich hab mal nem Arbeitskollegen das Tool zukommen lassen und wir haben gerade mal ein wenig feedback zusammengetragen:

QA Feedback:
- Es fehlen Tooltips
- TextLine: Charakterauswahl combobox zu klein für namen
- Ungünstige Anordnung. es entsteht der eindruck, das "From:" würde die Combobox betiteln -> Folgeverwirrung der Funktion von "To"
- froms passen bei mehreren Zeilen nicht mehr ins feld
- Übersicht: Abgrenzung Options/Answers (bei vielen Zeilen wird es unübersichtlich, sie nur anhand der IDs auseinanderzuhalten)
- Notiz und Notizbutton nicht klar im aktuallen status
- Emo/PP block ist nicht selbsterklären

(info button muss funktionieren, tooltips, klarere beschriftung)

- Save buttons unten links wirken "ungewohnt" für den benutzer und wären nicht zwingend notwendig

(unmittelbare Änderungen wären wohl kein Problem, die Gefahr etwas aus versehen zu ändern wäre wohl nicht groß genug, um diese zusätzliche Save-Mechanik notwendig zu machen)

- STRG-S (Save) (und andere shortcuts)
- Hervorhebung von Anfangs-Schlusszeilen

(wie definieren wir eigentlich die anfangszeile? alles was kein "From" hat? was ist mit Ring-dialogen die später zur startzeile zurückkehren, dann hätte sie ein from. daher müsste u.U. eine andere mechanik her. Immer die erste Zeile als "From"? Warnung bei anderen From-losen Zeilen?)

Bugs:
- Notizen werden nicht gespeichert
- Änderungen im Dialog werden verworfen, wenn man während des Editierens einmal auf den "Character" tab klickt, und dann zurück

Lösungsansätze -> Popup über verworfene änderungen
-> autosave ? (änderung UI Flow, s. "Save buttons ungewohnt")
-> irgendwie halten der DialogueVM (beim Setzen von LastSelected prüfen auf dID?)
--> Selbes problem taucht auch umgekehrt bei charakteren auf

So, n anderer Arbeitskollege hatte es sich jetz auch ma für 10 minutn angeguckt...

- "Untitled Project" in der Titelleiste scheint die Leute zu verwirren...

Sollte da vielleicht etwas stehen wie "Toolsmith - Untitled Project" ? (wäre eigentlich mal ne schöne einfache entscheidung für konzept oder wie?)

- Tooltips fehlen
- "PC" haken ist unklar
- Textfeld erwünscht neben ocean reglern (soll Zahlenwert anzeigen und man könnte die Zahl manuell eintippen)
- Neuen Charakter erstellen sollte den neuen Charakter automatisch auswählen (hat aus versehen alten charakter editiert)
- Idee: involved Character Auswahl durch Haken visualisieren (bessere Sichtbarkeit)
- "From" und "To" sind sehr unklar. Positionierung der charakterauswahlbox suggeriert scheinbar sehr stark dass es sich bei from und to um charakterreferenzen handelt...

Sasi und ich haben heute getestet und ne pdf mit unserem Feedback erstellt. Liegt im SVN: Hab nen neuen Ordner erstellt mit dem Namen Test da findet ihr die Datei.

Bitte schreibt das doch nich als PDF ins SVN, sondern direkt als Post hier ins Forum, damit auch alle sehen worum es geht

1. Linefeed erlauben in Character/Further Information
2. Scrollbar für Textfeld Character/Further Information
3. nur 3 Personality Regler beim programmstart (sind auflösungsabhängig, wär ganz gut wenn ihr nochmal dazu schreibt mit welcher Auflösung ihr testet) Die Scrollbar für den Bereich is da, allerdings is der Editorbereich etwas verrutscht und verdeckt diese
4. Charakterliste scrollbar -> Selbes Problem
5. Sollte der Charakterlistenbereich überhaupt vertikal skalierbar sein???
6. Was meint ihr mit "In die nächste Zeile springen"?
7. Kann man das Scrollbarverhalten für Listen beeinflussen auf ein "weiches" Scrollen?
8. Bug: Löschen einer Zeile löscht nicht das "To" einer referenzierenden Zeile
9. Wie habt ihr denn die Zeile über Enter hinzugefügt? ich vermute dass der Fokus auf dem Button lag, dh das is dasselbe wie wenn man den Button klickt. Ich vermute was passiert ist, ist dass ihr der selben Zeile eine Neue Antwort zugewiesen habt (lässt sich dann ja unschwer am "To" erkennen), sodass die From referenz der ersten Antwort verschwindet. Das funktioniert dann as intended (es sei denn das Konzept hätte etwas anderes vorgesehen)
10. Was soll denn die Lösung zu dem "Alle lines löschen" problem sein? die Frage wurde hier im Forum bereits gestellt...
11. Wir können denke ich automatisch in die Neue Textzeile springen
12. Emo/PP Save und Cancel sind redundante buttons (wurde auch hier im Forum durchdiskutiert) und sind völlig funktionslos.
13. Das rot markierte Feld ist ebenfalls redundant (auch schon im Forum breitgetreten), da eine Personality Condition nach Konzept einen Threshold hat der aus EINEM Wert besteht (daher habe ich nur das erste Textfeld angebunden) Das erklärt die Tatsache dass es ein totes ungebundenes Textfeld ist, in das man eintragen kann, was man will und das sich nie nach daten synchronisiert.
14. Markierung der Textlines bei Fokuswechsel beibehalten wird bereits dran gearbeitet.
15. Consequences-Personality: Was soll denn sonst da hin?
16. Dialogeditieren/InvolvedCharacters: Die Combobox sollte rechtsbündig liegen, dadurch wäre das Problem der verschwindenden Box gelöst. Ebenso könnte das Textfeld für den Namen mit TextTrimming den namen abkürzen (tooltip für vollständigen Namen). Bitte Feedback zu dieser Idee

Wir haben das als pdf geschrieben, weil wir das nicht so schön und verständlich erklären können wie du Arne, deshalb haben wir uns gedacht das wir das mit Screenshots veranschaulichen...hat ja jeder Zugriff auf den SVN Ordner.

Zu 3.Wir haben mit einer Auflösung von 1366 x 768 getestet
Zu 6. Was meint ihr mit "In die nächste Zeile springen"? Wenn man die Enter-Taste drückt kommt man in die
nächste
Zeile
Bei unserem Tool funktioniert das aber nicht.

is ja richtig dass jeder zugriff aufs svn hat, aber es is einfacher, den krempel einfach hier reinzuschreiben, dann sieht man im thread auch sofort worum es geht und den verlauf der dinge...

Zu 6. was meint ihr mit nächste Zeile? Soll man innerhalb der Selben Textzeile eine Zweite Zeile im Texteingabefeld damit erzeugen, oder mit der Entertaste zur nächsten Textzeile springen?
Wenn ihr ersteres meint, ich denke die UI gruppe hat das sehr bewusst für dieses Textfeld deaktiviert, da es keinen Sinn macht innerhalb einer Textzeile Zeilenumbrüche einzufügen.

Wir meinten, dass man innerhalb der selben Textzeile eine zweite Zeile im Texteingeabefeld damit erzeugt, damit das ganze wenn viel Text geschrieben wird übersichtlicher aussieht. Aber wenn die UI Gruppe das bewusst so entschieden hat, dann kann es selbstverständlich so bleiben.

Es sei denn jemand sieht ein Großes Problem damit, keine Zeilenumbrüche machen zu können.

Die Frage ist, wie ein Autor hiermit umgehen würde. Würde er im Falle eines längeren Monologs den ganzen Monolog in eine Textzeile reinquetschen oder lieber einen linearen Dialog daraus machen? (bzw linearen Monolog), bei dem Textzeile auf Textzeile folgt.

Vom System her würde ich zB sagen dass Sinnabschnitte über mehrere Textzeilen zu verteilen Sinn macht. (zB Bei kurzen Sprechpausen, wo dann auch ggf eine neue Audiodatei anfängt, falls nötig). In dem Fall wäre ein Zeilenumbruch innerhalb einer Zeile unnötig.

Is aber entscheidung von UI/Konzept

Also ich würde es ebenfalls als unnötig erachten.

Tabreihenfolge der Zeilen ändern, sodass die Buttons zu erst selektiert werden nach dem textfeld

wenn man eine neue antwort erzeugt (ich denke bei option genauso) dann wäre es schön, wenn sofort die Combobox selektiert wäre, sonst ist man gezwungen die maus zu benutzen.

schon bekannt dass man nur mit klick auf die graue fläche die buttons einblendet?

Falsch, Die Buttons blenden ein, Wenn die Textline ausgewählt ist, funktioniert also ebenso mit den Pfeiltasten

Und bei AddOption würde ich nich die combobox auswählen sondern direkt die Textline.


-- in der tat

welches programm, stable oder toolsmith? habe gerade die aktuelle toolsmith und da werden die buttons nicht eingeblendet

Ich hab mir heut morgen noch ne exe in die dropbox gezogen (is alles was ich grad überhaupt ansehen kann)... Das generelle navigieren mit pfeiltasten durch die textlines funktioniert aber?

könnte das was mit dem "es ist immer ne zeile ausgewählt" fix zu tun haben?

könnte dann nur an diesem Code liegen:









den findest du im Style der Listbox. Was natürlich blöd wäre, weil das eine schöne Lösung für die "Listitem ist ausgewählt" Sache. Wahrscheinlich müssten wir es dann doch anderes lösen?

haste ausprobiert obs daran lag? weil ich grad nich seh wie das das kaputt machen sollte... keyboardfokus is der trigger und der settet das "IsSelected"... und IsSelected müsste eigentlich die buttons einblenden sobald es aktiv is, das is ja wiederum der andere trigger....

nein leider bin ich grad auf der Arbeit. Dachte nur, dass vielleicht jemand anderes mal ausprobieren will;)

ich weiß nich ob seit heut nachmittag jemand was daran gemacht hat, aber das verhalten ist etwas anders als beschrieben.

1. starte programm
2. füge neue Zeile hinzu
-> Augenscheinlich liegt der fokus jetzt auf der 2. Zeile, die buttons werden dort angezeigt.

Nu wirds interessant in zwei szenarien
Szenario A:
3. Klicke in Zeile 1 in das Textfeld oder die combobox
-> Keine buttons, Fokus scheint auf der 2. Zeile zu bleiben
4. klicke in Zeile 1 irgendwo auf ein nicht-element (graue fläche)
-> Fokus wechselt zurück
5. klicke jetzt in Zeile 2 in das Textfeld/combobox/sonstwas interaktives
-> Wechsel
===> Schlussfolgerung: Der Bug tritt nur kurz nach erstellen der neuen Zeile auf. Offenbar liegt also hier irgendwo der Hase begraben.

Szenario B (angesetzt nach der erstellung der neuen Zeile)
3. Klicke auf ein völlig anderes Fenster (zB der Browser in den du gerade ne Analyse des Problems einträgst)
-> Der Fokus switcht sofort zurück zur ersten Zeile.



These: Ich bin mir technisch noch nicht darüber im klaren, wie die neue Textzeile automatisch ausgewählt wird, aber unsere TextEditorVM wird darüber nicht informiert ("Selected"-Property).
Das hat zurfolge dass im Hintergrund bei der Gebundenen Eigenschaft immernoch Zeile 1 den Fokus hat, was
A: beim klicken auf die Textfelder keine Änderung mit sich zieht, weshalb die UI nicht mit dem Trigger reagiert.
B: Beim verlieren des Fensterfokus die UI updated und Zeile 1 wieder in Fokus setzt.

Bitte einmal alle beteiligten darüber nachdenken, insbesondere einmal eine ausführliche erläuterung über das automatische auswählen der neuen Textzeile.


Edit: Offenbar wird die TextEditorVM doch informiert, aber irgendwie nich richtig, ich forsche weiter...
Edit2: Es funktioniert mit jeder Textzeile, außer der, von der aus man die Zeile erstellt hat.
Edit3:

Code:


                        <Trigger Property="IsKeyboardFocusWithin" Value="True">
                            <Setter Property="IsSelected" Value="True" />
                        </Trigger>

                        <Trigger Property="IsKeyboardFocusWithin" Value="False">
                            <Setter Property="IsSelected" Value="True" />
                        </Trigger>


Das is tatsächlich der übeltäter. Wenn der Keyboardfokus False ist, wird IsSelected auf True gesetzt. Das heißt (freie interpretation):
Wenn Keyboardfokus drin is, wird IsSelected auf true gesetzt, wenn nicht dann auch. Wir haben also scheinbar zwei selected items, und weil Zeile 1 noch den Keyboardfokus hat, ändert sich der wert nicht -> UI wird nicht anständig geupdated.

Edit4:
also wir köööönnten auf die trigger verzichten, ich kann das Selected beim erstellen der Textline im VM manuell setzen, das funktioniert auch.
Allerdings kommen die buttons dann wirklich IMMER nur, wenn man aufs graue klickt, nicht wenn man den Keyboardfokus ins textfeld setzt.

Was hier fehlt ist die möglichkeit manuell den Keyboardfokus von der alten in die Neue Textzeile zu setzen. Leider ist "IsKeyboardFocusWithin" keine setzbare eigenschaft (habs schon ausprobiert), sonst könnte man die einfach an IsSelected binden, bzw abhängig davon machen.

Dh: Wir müssen eine Möglichkeit finden den Keyboardfokus umzusetzen, das machen wir dann an der Stelle.

Wir können übrigens auch folgendes beobachten:
1. starten von tool
2. add answer
3. tabulator mehrfach drücken
-> wir sehen wie die Elemente von Zeile 1 durchgeswitched werden, obwohl das ausgewählte element Zeile 2 sein sollte.

Edit 5:
ein bisschen magie für zwischendurch (experimente im listbox style)

Code:


 <Trigger Property="IsKeyboardFocusWithin" Value="True">
                            <Setter Property="IsSelected" Value="True" />
                        </Trigger>

                        <Trigger Property="IsSelected" Value="True">

                            <Setter TargetName="ItemBorder" Property="BorderBrush" Value="Red"/>
                            <!--<Setter Property="Visibility" Value="Visible"/>-->

                        </Trigger>
                        <Trigger Property="IsSelected" Value="False">
                            <Setter Property="Focusable" Value="False"/>
                           
                           
                            <!--<Setter Property="Visibility" Value="Visible"/>-->

                        </Trigger>


hab ich mal grad ausprobiert. Damit setzen wir nichtselektierte listbox items auf nicht "Focusable", dadurch verlieren sie den fokus und die fähigkeit gefocust zu werden.

Das funktioniert dann wunderbar, bis auf die kleinigkeit: Wir können sie nicht mehr auswählen indem wir auf den grauen bereich klicken, sondern NUR NOCH durch klicken auf textfeld oder combobox....

vielleicht fällt uns etwas ein, wie wir das alles zusammenführen und in den griff kriegen.

so genug edits, der post is schon zu lang...

ich hab jetz in dem trigger fürs mouseover

Code:

                        <Trigger Property="IsMouseOver" Value="True">
<Setter Property="Focusable" Value="True"/>



focusable wieder auf true gesetzt. das heißt: Wo wir mit der maus drübergehen, können wir auch fokusen. Das funktioniert jetzt fast gut, bis auf eine weitere kleinigkeit:

Wenn man auf add answer klickt, und dann sofort mit der maus ein stück hochgeht (um mit der maus in der gleichen textline zu bleiben)
verhält sich das alles so wie vorher (klicken ins textfeld bringt uns kein "IsSelected"

Wenn man die Maus stillhält, gehts aber, weil die textline mindestens für einen kurzen moment nicht-focusable ist (verliert keyboardfokus). Beim erneuten mouseover ists dann wieder focusable...


Ich hab jetz nich mehr so viel ahnung aber ich hab da unten einen Multitrigger gesehen, wo man wohl mehrere Bedingungen verknüpfen kann. Meine grobe Idee (muss noch zuende gedacht werden):

1. Ein item das selektiert ist, ist focusable (wobei das dann glaub ich schon egal is)
2. ein nichtselektiertes item ist nicht focusable
3. ein item mit mouseover ist focusable, wenn es nicht den keyboardfokus hat.
4. ein item mit mouseover ist nicht focusable wenn es den keyboardfokus hat

-> nach 4. würde das item den keyboard focus verlieren, dann würde es nach 3. wieder focusable sein (hoffentlich aber dann ohne den keyboardfokus wiederzuerlangen)


Das könnte funktioniern is aber sehr reingehackt. vielleicht fällt uns noch was eleganteres ein, ich muss jetz aber erstmal schlafen gehn, mir fallen gleich die augen zu

Noch ein einfall den ich gerade hatte...

Rein hypothetisch:
Wenn wir das Anzeigen der Buttons nicht an die Selektion des Listboxitems, sondern an die Mouseover eigenschaft binden können... das würde das Problem zumindest reduzieren. Dann wären die Buttons immer dort zu finden wo die Maus hinwandert (bin grad etwas unsicher ob es für den user verständlich genug wäre). Das einzige problem das bei dem bug auftreten würde wäre, dass die Box keinen roten rahmen kriegt in diesem spezialfall...

Hallo, ich habe heute auch getestet. Die meisten Sachen wurden ja schon erwähnt, aber mir sind auch noch ein paar Dinge aufgefallen (keine Ahnung ob das schon irgendwo erwähnt wurde oder inwieweit da sowieso dran gearbeitet wird):

1. Wenn man einen neuen Charakter erstellt und auf das Namensfeld klickt um diesen zu ändern, wäre es benutzerfreundlicher wenn das "Unnamed Character" entweder markiert wird oder automatisch verschwindet. (ist natürlich eher eine Feinheit und nichts dringendes)
2. Wenn man einen neuen Dialog erstellt und die erste Zeile löscht, gibt es keine Möglichkeit eine neue zu erstellen, man muss also einen ganz neuen Dialog erstellen um die Anfangszeile zu bekommen.
3. Mir ist noch nicht ganz klar wofür der rote Button neben dem "To:" ist, der bekommt wahrscheinlich noch eine Funktion?
4. Man kann zwar mit der Tab-Taste navigieren, kommt damit aber nicht auf "Add Answer" oder "Add Option", d.h. der Autor muss jedes mal die Maus benutzen.

@ Arne:
sorry...leider blicke ich bei dir jetzt nicht mehr durch, was wir konkret umsetzen sollen:P
Also du meinst wahrscheinlich, dass etwas bei den Styles der Listbox verändert werden muss. Ich verstehe auch in etwa das beschriebene Problem. Aber welcher Code muss da jetzt rein?

ich hab leider auch etwas den überblick verloren, gerade weil sich das problem überschnitten hat mit ein paar sachen die wir
hier besprochen hatten.

Kurzfassung ist, wir wollen programmatisch den keyboard fokus bestimmen können, wenn eine textzeile ausgewählt wird (so die grundidee). In wechselwirkung mit deinen Style triggern, die bei änderung des keyboardfokus "IsSelected" auf true setzen, heißt das aber dass nicht mehr automatisch das neue element ausgewählt würde.

1. Das Selektieren des neuen elementes mach ich jetz im TexteditorVM wenn es hinzugefügt wird. (setzen der "Selected" property)
2. da dann beim klicken das selektierte element den keyboardfokus auf das textfeld gesetzt kriegen würde, wäre der keyboardfokus im alten element und der keyboardfocus trigger der listbox setzt isSelected wieder darauf
3. ohne die keyboardfocus trigger in der listbox wird ein element nicht selektiert, wenn direkt in sein textfeld/combobox/etc geklickt wird
4. wenn wir für combobox und textfelder die "focusable" property von dem "IsSelected" des listbox items abhängig machen, funktionierts wieder

a) ich habs ausprobiert indem ich im IsSelected Trigger des datatemplates diese properties manuell per setter gesetzt habe.
b) ich denke es wäre u.U. eleganter, einfach die focusable eigenschaft der textfelder/combobox per binding an die "Selected" eigenschaft des VM zu binden (weniger unübersichtlicher code, wäre aber zu überprüfen ob es 100% so funktioniert)

Erklärung für die funktionsweise beim anklicken:
- Die einzigen fokussierbaren TextLine elemente befinden sich innerhalb der ausgewählten textzeile
- Die Elemente der inaktiven textlines sind nicht fokussierbar.
- beim anklicken eines elementes in einer inaktiven textline geht der fokus NICHT auf das Element über, stattdessen geht der klick sozusagen auf das gesamte Listbox Item, welches dadurch "IsSelected" auf True gesetzt bekommt (die andere zeile wird dadurch "IsSelected" auf False gesetzt).
- das wiederum setzt die Selected Property der VM, was dann nach b) die Elemente innerhalb dieser TextLine fokussierbar macht.
- Der im anderen thread beschriebene trigger würde dann automatisch den fokus auf die Textline setzen.

Schattenseite:
Beobachtbar wäre dann vermutlich, dass - egal wo ich in eine inaktive textline klicke - der cursor im textfeld landet. Ich persönlich fände das nich ganz so schlimm, allerdings kann es sein dass der User - der ja nicht die fokussierbarkeit sieht, sondern nur dass da ein element ist - irritiert ist, warum das textfeld den fokus erhält, obwohl er doch auf die combobox geklickt hat.
Dahingehend war meine idee, die elemente in inaktiven zeilen durch textblocks zu ersetzen, die optisch nicht editierbar aussehen, und somit nicht suggerieren direkt editiert werden zu können. Der user würde sie also anklicken -> die textzeile wird selektiert -> die elemente werden "editierbar" und die textline erhält den fokus -> der user kann editieren was er will, weil alle elemente editierbar sind.

Wie gesagt ist nur meine idee dafür.

Falls wir den fokus NICHT jedes mal auf die textbox legen wollen, wird ein wesentlich komplexerer trigger nötig sein, bei dem wir dann evtl abfangen müssten ob ein anderes element innerhalb dieser textline bereits den keyboard fokus erhalten hat. Wäre denkbar aber die grundfrage ist wann wo was wie genau unter welchen umständen reagieren muss, bevor wir anfangen da noch mehr zu basteln.


Bitte ergänzt, wenn ihr bedenken wegen irgendwas habt was das hier angeht.

an sich halte ich die idee für gut, dass nicht selektierte lines auch nicht weiter editierbar wirken, allerdings habe ich dennoch bedenken wie der arbeitsfluss ist dadurch beeinträchtigt wird, da ich ja dann immer wieder auf die Combobox klicken muss um einen char auszuwählen.

wie wäre es damit, bzw ist es sehr unmständlich es so zu iplementieren:

a) schreibe lin 1 und klicke auf add answer, bzw shortcut --> füge neue line 2 hinzu und fokussiere combobox

b) das selbe für add option

c) unselektierte lines werden so dargestellt wie du oben beschrieben hast, also nicht editierbar --> wenn eine line angeklickt wird, also irgendwo im linegrid, wird die textbox fokussiert...

das müsste doch an sich leicht abzufragen sein (mal ganz naiv behauptet, ohne den code wirklich zu kennen)

also
a) bei add answer die combobox zu fokussieren ok,
b) bei add option macht das keinen sinn, da eine Option ja im normalfall denselben charakter betrifft (is ja auch so implementiert dass der charakter übernommen wird)
c) das nicht editierbar machen is durchaus möglich...

Problem: Wie differenzieren wird beim IsSelected Trigger zwischen den fällen a, b und c?

und: wäre es nicht einfacher, überall immer die textline als hauptfokus zu benutzen, und einfach den charakterwechsel zB durch shortcut einfacher
umzusetzen?

dann könnte ich zB shortcut benutzen für add answer, die textzeile hat den fokus und kann direkt erstmal den text schreiben und danach oder auch davor per shortcut den "nächsten" charakter wählen.

könnte mir zB vorstellen dass folgende Tastenfolge den 2. Charakter mit "Hallo" antworten lassen könnte:

[1. Zeile wird geschrieben.....]
Strg+Enter (neue Zeile wird erstellt)
Strg+Shift+C ("nächster charakter" -> Charakter 1 in Liste ausgewählt)
Strg+Shift+C ("nächster charakter" -> Charakter 2 in Liste ausgewählt)
Hallo (Texteingabe)

Ich kann mir gut vorstellen, dass man sich dann in einem Dialog mit 2-3 personen sehr schnell orientieren kann, wie oft man für welchen Charakter wie oft Strg+Shift+C drücken muss, das könnte super fix gehen. Mit einem umfangreichen Set von Textline-shortcuts könnte man einen ziemlich schnellen ablauf erzielen

Strg+Shift+C ("nächster charakter" -> Charakter 1 in Liste ausgewählt)
Strg+Shift+C ("nächster charakter" -> Charakter 2 in Liste ausgewählt)
Hallo fremder (Texteingabe)
Strg+Enter (neue Zeile wird erstellt)
Strg+Shift+C ("nächster charakter" -> Charakter 1 in Liste ausgewählt)
Ebenfalls hallo, werter Herr (Texteingabe)
Strg+Shift+N (Notizfeld)
Charakter soll verunsichert klingen (Notizanmerkung)
Enter (Option wird hinzugefügt, selber Charakter ist bereits ausgewählt)
Wie war das? (Texteingabe)
Strg+Shift+N (Notizfeld)
Starke verwunderung in der Stimme
Strg+Shift+T (To Feld fokussieren)
1 (Rückkehr zu Zeile 1 festlegen)

... das würde meines erachtens nach sogar noch Zeit sparen gegenüber der "mit tab durchswitch" methode.