Weiteres Vorgehen Februar/März

Ich hab da ma ne Frage an die Allgemeinheit:

Wie gehen wir im Februar/März weiter vor? Wir stehen ja jetzt (hoffentlich bald mal) kurz davor alle features drin zu haben. (btw, Wie sehn eure Zeitpläne da eigentlich aus?)

-> Wir wollten ja noch ne Testrunde beim Lehrstuhl anmelden, sobald wir die emo/pp sachen drin haben. Sollen wir das machen sobald es drin ist oder vorher selber noch mal ne debugging runde machen?

-> Wie genau bauen wir den workflow auf, wenn es um bugs geht? seperater Bugthread wo dann alle leute (auch aus der Konzeptgruppe) reinschreiben können was nich geht? Am besten wäre es wohl auch das ganze zu trennen nach funktionalen fehlern, bzw reinem qualitätsfeedback...

-> Wann setzen wir uns unsere Finale Deadline? Ich würde vorschlagen wir setzen sie ein bis zwei Wochen oder so VOR der Präsentation an, da die Erfahrung zeigt, dass wir deadlines eh nie einhalten können...

Ok, ich sehe wir haben die bug threads irgendwelche anmerkungen zum Rest?

Deadline sehe ich genauso

Und lehrstuhl, soweit die klamotte rechts funktioniert... walter weiß zumindest bescheid, hate ihm letzte woche ne mail geschickt

Gut. Dann würd ich sagen sollten wir den kram rechts asap ans laufen kriegen. Mehr Testzeit von denen heißt Mehr qualitätsfeedback, und früheres feedback heißt höhere chancen, dass wir darauf reagieren.

OK hab grad mal das ECondition panel angebunden. Bitte alle interessenten einmal drüberschauen rumprobieren und sagen wenn was nich geht, bzw wenn es nicht funktioniert wie intended.

(Save/Cancel buttons sind wie besprochen erstmal wirkungslos, änderungen werden direkt bei der Auswahl übernommen)

Speichern/Laden in/von Datei unterstützt jetzt die EConditions. Für alle die noch mitmachen: bitte mal drübergucken und testen.

PCondition is jetz gebunden. Da zwei Textfelder vorhanden sind (von/bis), aber wir nur einen toleranzwert benötigen hab ich mal nur an das erste Feld gebunden.

Beim setzen des Toleranzwertes wird geprüft ob es ein Integer wert von 1-5 ist. Wenn die Eingabe aus Buchstaben besteht, wird der wert unverändert zurückgesetzt, bei Werten < 1 wird der wert auf 1 gesetzt, bei >5 auf 5.
Anmerkungen:
Das Update passiert nur bei "LostFocus", dh das Textfeld muss den Fokus verlieren, bevor alles geprüft und gespeichert wird.
Problem: Wenn man nach Eingabe ohne dass das Textfeld den fokus verliert direkt eine andere Zeile anklickt, wird der Wert nicht gespeichert.
-> Beim Versuch den updatetrigger auf "PropertyChanged" zu ändern ergäbe sich leider das Problem, dass zwar der Wert unmittelbar gespeichert wird, aber nicht rückläufig korrigiert werden kann. dH wenn man zB "A" eingibt, wird die kontrolle durchlaufen und der Wert ändert sich nicht, das "A" bleibt aber stehen.
-> Ideen wie man das lösen kann, sind willkommen. Ich dachte darüber nach ob es eine alternative eingabemethode gibt die hier Sinn macht.

PS: Ich war mir nicht mehr sicher, wie wir die Toleranz für PConditions Wertetechnisch aufbauen wollten, daurm hab ich erstmal Integer 1-5 genommen. Wenn das doch float werte mit ner anderen Grenze sein sollen, sagt bescheid, das lässt sich leicht ändern.

PPS: Testrunden und feedback wären wie immer erwünscht

Habe gerade abgeschlossen mit der EConsequences klamotte. Wenn man Charaktere für den Dialog auswählt, tauchen entsprechend viele EConsequences in der Liste (unten rechts) auf.

ich hab jetz ein erstes datatemplate für die Econsequences eingebaut. nicht schön aber zweckdienlich
außerdem ist das "To" in der textzeile jetzt ein textfeld in dem man die MainID der folgeZeile eintragen muss. Das Auto-From system funktioniert auch, sodass die Froms der betroffenen Zeilen aktualisiert werden.

Zudem hab ich das Databinding für das EConsequences Template schonmal eingebaut und die Speicherroutine dahingehend aktualisiert dass das alles gespeichert wird.

Tests und feedback blablabla

Edit:

Wenn jetzt niemandem mehr etwas auffällt, ich glaube dass wir jetzt alle geplanten grundfunktionen endlich drin haben, dh theoretisch könnte damit die erste Testrunde am Lehrstuhl losgehen. Kommentiert mal was ihr dazu sagt.

Edit2: kommando zurück, das löschen der Dialogzeilen fehlt noch...

Ich habe eine neue Aufteilung für die Textzeilen. Sagt mir einfach wie ihr die findet. Ist jetzt vom Format immer noch nicht ideal. Vor allem mit der Textzeile und den Buttons. Aber da weiß ich ehrlich gesagt nicht ganz weiter, wie sich die Größe immer anpassen soll, aber dann auch eine neue Zeile angefangen werden soll. Bei mir vergrößert er dann immer weiter das Grid.
Außerdem gibt es einen Button in jeder Textzeile, den man zum Löschen nutzen könnte...wenn das so ok ist.
Ich bin morgen den ganzen Tag unterwegs...habe daher die ursprüngliche Main auch ins SVN gespeichert, falls ihr das rückgängig machen möchtet. Sagt mir dann einfach Bescheid:)

Ok auf jeden fall schonmal besser als vorher.
Ein paar punkte und ideen noch:

1. Jetzt scheint die textbox bündig nach unten zu sein, was dafür sorgt dass über ihr ein leerer Raum entsteht. das liegt vermutlich daran dass ihr nur ein Grid verwendet, dass sich dann wie eine Tabelle aufspannt. die oberen Zellen werden nur von dem neuen deletebutton, "Line:" und der Zeile verwendet (btw ich hab mal das Binding darauf auf ID geändert damit da jetzt "1.1" steht statt 1 zb)
In Zeile 3 im Screenshot hab ich mal eingezeichnet wie der Grid aufbau im moment wäre. Da sieht man sehr schön dass sich quasi kein Element bis oben ausdehnen kann, weil das dann die obere Zelle ist.

Ich habe im screenshot darunter mal skizziert was funktinoieren könnte. In Gelb ist da das "Hauptgrid", das nur drei Spalten trennt. Innerhalb der Spalten gibt es wieder grids, die eine entsprechende unter-aufteilung bilden. Das heißt jetzt zB dass in der Mitte nur das Grid mit Textfeld und buttons drin ist, und sobald die Buttons ausgeblendet werden nur noch das Textfeld -> Maximale vertikale ausdehnung.

So bzw so ähnlich könnte man also da heran gehen um die Elemente präziser zu platzieren.

2. Ein Problem das mir gerade bewusst wird: die "From" liste ist ein Label, das sieh ausdehnt wie es will. Es gibt keinen Zeilenumbruch und wenn man mehrere "From" zeilen hat, überlappt es mit dem Label "From: " (hab ich unten in den screenshot nochmal reinkopiert.

3. Die Zeilen enthalten rechts vom "Add Option" button immernoch die zweite Linereferenz und das Label "As Answer"

4. ich vermute der button links von der Notiz is das replacement für "Add Note". Was soll dieser Button denn jetz überhaupt tun?

zu 4. : ich denke mal, der soll das ein/ausblenden? wäre für mich am naheliegensten.

dann zu 3. : also wir müssen uns jetzt nocheinmal klar entscheiden, wie wir es handlen, branching dialoge zu machen: wieso "müssen" (an arnes post weiter oben) wir auf einmal bei To: eine zeile angeben? das war vorher nie so.
dafür war in meinem Mockup zumindest die "line /textbox/ as answer klamotte gedacht. da ist aber keine textbox und kein button /as answer/ angeboten.
ich weiß jetzt nicht, ob jenny das implementiert hat, wir hatten ja extra im facebook nochmal kurz darüber gesprochen. also was dieses feature betrifft, haben wir uns anscheinend noch nicht eindeutig festgelegt.

mit dem from-problem ist knifflig. ich dachte im ersten moment daran, es hinter die Line-id zu stellen. das ganze als zeile des hierarchisch höchsten grids. so hätten wir die gesamte spaltenbreite für viele viele froms. solang es dann realisierbar ist, dass dort ein zeilenumbruch stattfindet und die zeile vertikal größer wird (die textbox etc. also auch nach unten geschoben wird).
ich weiß, dass ist ziemlich simpel, aber auf anhieb eben das, was mir eingefallen ist.

zu 4. Ich dachte alle vorhandenen notizen sollten auf jeden Fall angezeigt werden, sonst könnten welche übersehen werden. Was wir tun können ist (wie mehrfach angesprochen), dass eine Leere notiz versteckt wird. Dh Kein Text-> Kein Feld. Der AddNote Button könnte dann einfach Text in die Notiz einfügen damit sie sichtbar wird oder so ähnlich.

zu 3. Das system funktioniert genau auf die gleiche art, nur simpler.

Bei Dir: Zielzeile in die Line Textbox eintragen -> "As Answer" drücken -> das "To" wird auf die neue Zielzeile gesetzt
Wie es jetzt erstmal ist: Zielzeile in das "To" eintragen -> To wird auf neue Zielzeile gesetzt.
Egal wie man es macht, es gibt genau ein "To" und die From liste der entsprechend betroffenen Zeile wird automatisch angepasst.

Was ihr in facebook besprochen habt, kriegen wir ja hier im forum clevererweise nicht mit darum weiß ich nich was ihr da vereinbart habt, aber ich denke so wie es jetzt ist (oder so ähnlich) wirds am einfachsten sein.
Nach wie vor wird übrigens das "To" auch automatisch gesetzt, wenn man in der Zeile auf "Add Answer" drückt, dieses feature bleibt also nach wie vor vorhanden. Außerdem wird das To in Zukunft auch verändert wenn man ne Textzeile löscht (is zumindest so geplant).

Wenn ihr irgendwelche änderungen vorhabt, oder das Konzept hierzu völlig anders ist, und ich das line/textbox/as answer ding missinterpretiere, bitte drückt das präzise, klar und vollständig aus, am besten mit workflowbeispiel, damit man das auch unmissverständlich versteht.

das From Problem ist glaub ich gar nich so wild. Das ding muss glaub ich nur bündig nach oben sein, und ne fixe breite haben. Dann sollte der eigentlich automatisch n Zeilenumbruch machen. außerdem würds glaub ich auch helfen, wenn man die Character-Combobox nach oben setzt, sodass sie das from label nich blockiert (oben is genug platz, und so könnte man das label für die froms breiter machen, sodass ein Zeilenumbruch erst bei >3 froms nötig würde oder so)


Zusatzanmerkung:
Skalieren der Textline: Das Grid scheint zu skalieren, die elemente weisen dann allerdings lücken auf. u.A. wird die textzeile selbst auch nich breiter...

Nach wie vor wird übrigens das "To" auch automatisch gesetzt, wenn man in der Zeile auf "Add Answer" drückt, dieses feature bleibt also nach wie vor vorhanden. Außerdem wird das To in Zukunft auch verändert wenn man ne Textzeile löscht (is zumindest so geplant).

-- sry da hab ich im kopf gepennt, hätte mir klar sein müssen... aber gut, dass es jetzt einmal geklärt ist.
Was das verständnis des konzeptes/mockups angeht: ich hatte immer das gefühl bisher, dass viele das nicht wirklich verstanden haben, allerdings auch nicht wirklich nachgefragt haben... dann kamen öfter mal implementierungen auf, die das gezeigt haben, deswegen das hin und her... du hast es aber richtig verstanden wie ich es mir gedacht hatte. deine umsetzung ist aber auf jedenfall simpler zu nutzen

außerdem würds glaub ich auch helfen, wenn man die Character-Combobox nach oben setzt--- find ich gut

okidoke, das Delete für die TextLines ist drin.

Folgeprobleme: Antwort hinzufügen fügt die Zeile immer als letzte ein. Eine gelöschte ZeilenID wird also nie neu hinzugefügt.

Bsp:
- es existieren Zeilen 1.1, 1.2, 2.1, 3.1
- Löschen von Zeile 2.1
- es existieren Zeilen 1.1, 1.2, 3.1
- Antwort hinzufügen
- es existieren Zeilen 1.1, 1.2, 3.1, 4.1
- Löschen von 4.1
- es existieren Zeilen 1.1, 1.2, 3.1
- Antwort hinzufügen
- es existieren Zeilen 1.1, 1.2, 3.1, 4.1

... Ist natürlich etwas unschön, die Frage ist wie das verhalten sein soll (denkbar wäre, immer die erstbeste freie ID zu belegen, oder beim Löschen automatisch die anderen Textzeilen IDs zu bereinigen (alle folgenden Textline IDs würden um 1 dekrementiert)

Ähnlich: AddOption fügt eine Zeile mit SubID von [Anzahl Optionen mit dieser MainID]+1 ein. Dadurch können doppelte IDs auftreten (Major bug)

Bsp:
- Es existieren 1.1, 1.2, 1.3, 1.4
- Lösche 1.3
- Es existieren 1.1, 1.2, 1.4
- Hinzufügen von option
- Es existieren 1.1, 1.2, 1.4, 1.4

Das ist ausgesprochen unschön, sollte aber behebbar sein. Vorher aber trotzdem mal klären wie das Verhalten sein soll (lücken füllen / Beim löschen die restlichen IDs automatisch neu verteilen)

Letztes Problem:
Man kann die letzte TextZeile löschen, was das hinzufügen neuer Zeilen unmöglich macht.

Repro:
1. programm starten
2. einzige Zeile löschen
-> et viola

Lösungsansatz hier: letzte Zeile nicht löschbar / Beim löschen der Letzten Zeile wird automatisch eine neue Leere hinzugefügt (fühlt sich ähnlich an, nur dass bei letzterer Variante wenigstens der Inhalt der Zeile gelöscht wird)


Fragen anmerkungen etc immer hier.

Nichtsdestotrotz haben wir jetz glaub ich die grundfunktionen alle abgedeckt. Wäre schön wenn die hier genannten Probleme noch eingedämmt/gelöst werden könnten und danach sollten wir die Testrunde am Lehrstuhl ansetzen damit wir rechtzeitig ergebnisse kriegen.

so, grad noch den kram mal wieder als stable wegkopiert.

Mir is noch aufgefallen dass jetz unten rechts noch der Delete Line button existiert, obwohl wir ja in jeder zeile jetz einen haben.

Also zu dem Löschproblem mit den IDs:

Welche ID bei einer neuen Antwort generiert wird, sollte von der ausgehenden line abhängen und dann immer die erste freie, würde ich sagen
Wir haben: 1.1 1.2 ; 2.1; 3.1

wir löschen 2.1 --> 1.1 1.2;3.1;4.1

und jenachdem, wo wir nun auf add answer klicken wir die nächste freie zahl genommen. wenn wir bei 1.1 auf add answer klicken: 1.1 --> 2.1 (die hauptid wird erhöt und dann wird als sub-id die erste freie möglichkeit genommen, also 2.1) wenn wir bei 4.1 auf answer klicken: 4.1 --> 5.1

Nachvollziehbar, Denkprobleme bei mir?

würde nach nem plan klingen... alternativ, bzw besser bei zweiter überlegung... wie wärs wenn wir die Zeilen immer verschieben, je nachdem wo wir ne antwort einfügen?
Bsp:
wir haben 1.1, 2.1, 3.1, 3.2
neue einfügen bei 2.1
-> wir haben 1.1, 2.1, 3.1, 4.1,4.2
wobei 3.1 die neue is und 4.1, 4.2 die alten 3.1, 3.2 sind...

Dann könnten wir einfach nen kleinen resort-algorithmus einbauen der das für uns erledigt und den auch anwenden wenn ne Zeile gelöscht wird.
Einziges Manko: ich weiß nich ob es für den Benutzer zu verwirrend ist, wenn die Zeilen die Zahlen auf einmal automatisch verändern...

Ansonsten wäre "nächste Freie zahl nehmen" nich das problem denke ich. Wie gehen wir bei den Optionen vor? Optionen sind ja ein wesentlich überschaubarerer Bereich, hier würde es sich vielleicht wirklich anbieten, die sub-IDs zu rücken

Bsp
1.1, 1.2, 1.3
lösche 1.2
1.1, 1.2 (wobei 1.2 die alte 1.3 is)
einfügen bei 1.1 / 1.2 (egal)
1.1, 1.2, 1.3

Also bei den subids finde ich das sinniger, weil es, wie du sagst überschaubarer ist. bei den hauptids würde ich auch wie du die frage stellen, ob es verwirrend ist. ansonsten hatte ich die möglichkeit auch im kopf, wie siehts denn da von der effizienz aus? ist das von der performanz her okay, dass da alle vorhandenen abgendert werden? keine ahnung, vllt ist die frage auch unsinnig

nur nochmal zur Erläuterung meiner Änderungen von vor zwei Tagen bzgl. der "as Answer" Sache. Ich habe nur mit den bereits vorhandenen Elementen gearbeitet, da ich noch keine Zeit hatte mich nochmal mit dem MockUp zu beschäftigen. Aber an sich hab ich das schon verstanden...nur eben noch nicht alles so umsetzen können.
Zur Grid Aufteilung: das stimmt schon, dass sie etwas chaotisch bei mir wirkt. Nur ich hatte dieses Verschwinden der Button Zeile nur hinbekommen, wenn ich das ganze Grid hab verschwinden lassen. Ich werd es mir im Laufe der Woche nochmal anschauen und dann kann ich es auch anpassen (wenn es denn niemand anderes schon macht;)). Morgen habe ich leider keine Zeit, da ich Dienstag Klausur schreibe und noch einiges lernen muss.

@Admin:
Gute frage mit der performance, da man aber nich wie bei aufwändigen grafikanwendungen (spielen) mit 60Hz Zeilen hinzufügt, denke ich dass das schon klar geht
Der Algorithmus wird da evtl doch etwas komplexer:
1. Zeile einfügen
2. Alle Zeilen hinter der neuen Zeile MainID erhöhen
3. Alle Zeilen "Froms" einstellen.

Da wir ja vorher wissen, welche Zeilennummer eingefügt wird, können wir den Algorithmus vermutlich etwas effizienter gestalten. U.U. können wir sogar n neues System dafür aufbauen, wenn wir die Froms direkt referenzieren, das wäre dann späteres improvement.

Fürs erste bin ich für die "Nächste freie Zeile" variante für answers und das dynamische ID verwalten der optionen...

@Jenny:
von welcher buttonzeile redeste jetz genau? die answer/option buttons funktionieren doch... Naja ne neuaufteilung des grids wär halt ne optische verschönerung, aber kein dringendes must-have... ich denke andere sachen sind wichtiger, aber Priorisierung von eurem kram müsst ihr selber entscheiden.

Was mich betrifft bin ich mit meinen eigenen Tasks fürs erste fertig, bis die Flut an Bugs eintrudelt, in sofern hab ich mir nur noch nen UI-Betreuungs task gemacht. Wenn ihr also Fragen habt, steh ich voll und ganz zu eurer Verfügung.

aaalso ich hab jetz ma das verhalten so angepasst, dass sowohl SubIDs, als auch MainIDs der folgezeilen beim löschen dekrementiert werden. dh es gibt keine Lücken mehr, da sie sofort geschlossen werden.

Dafür wird jetz beim Löschen einmal die Liste durchgegangen, und für alle Elemente die die gleiche MainID haben, die SubID verglichen und ggf dekrementiert, für alle Elemente die ne höhere MainID als die gelöschte Zeile wird die MainID dann dekrementiert.
Zudem wird dann (damit alles konsistent bleibt) die Liste für jede geänderte ID noch einmal durchlaufen, und alle Froms und Tos, die die alte ID kannten geändert.

Insgesamt haben wir also für diesen Algorithmus ne Komplexität von O(n²)...
nich das schönste, aber ich denke durchaus vertretbar, wenn man bedenkt, wie oft das vorkommt, bzw wie niedrig frequentiert der benutzer zeilen löscht.

guckt euch das mal bitte an und sagt mir wie sich das anfühlt beim Benutzen.

Wir können jetzt auch einfach beim Hinzufügen von Zeilen diese ebenfalls einfach "einschieben" (zumindest hoffe ich dass es einfach wird...)
Ich denke die komplexität davon wird sich nicht groß unterscheiden. Liste neu aufbauen, element an der richtigen Stelle einfügen und anschließend die ID-Management sache... also insgesamt vermutlich sowas wie O(n+n²) oder O(2*n²) oder sowas in der art.

Schaut euch das mit dem Löschen jedenfalls schonmal an, und guckt ob bei irgendwem auf nem netbook vielleicht ein merkbares delay auftritt bei 100000 Zeilen oder so, und wenn wir das einschieben bei AddAnswer/Option wollen sagt bescheid

Edit: Ich hab grad ma ausprobiert, mit 1000 Zeilen merk ich immernoch kein delay beim löschen... (btw... auch wenn wir immer hypothetisch von nicht ungewöhnlichen 100000 Zeilen geredet haben... wären die alle in EINEM dialog? ich glaub eigentlich nich oder? Hat jemand ne Vorstellung von Textzeilen innerhalb desselben Dialogs, was wir benchmarktechnisch wirklich leisten müssen?)

Wie sehen jetz eigentlich die Pläne bezüglich der Lehrstuhltestrunde aus? Mach mal einer ne Ansage, gibts noch features/improvements die jemand unbedingt vorher drinhaben will, oder sollen wir das was wir jetz haben einfach mal zum testen abgeben? (Dann sagt mir dann nochmal bescheid dann mach ich dann noch mal ne stable mit allem was dann drin is, die die dann testen können...)

Herr Walter hat erstes Feedback im Moodle gegeben. Ich würde vorschlagen dass sich das jeder mal anguckt, denn im grunde is jedes team davon betroffen (gibt noch n paar designentscheidungen zu machen)...