search

rowe42 / lhm_animad_admin_html5

0 stars 6 forks source link

Automatische Aktualisierung von Listen nach Editieren und Speichern einer Entität. #205

Closed dragonfly28 closed 6 years ago

dragonfly28 commented 6 years ago

Beispiel 'Keepers': Wenn ich über die Liste eine einzelnen Keeper editiere und speichere dann gelange ich nach dem Speichern wieder automatisch auf die Liste. Dort sehe ich allerdings noch die alten Werte und muss explizit neu suchen um meine Änderungen zu sehen. Besser wäre, wenn man auf der Liste unmittelbar die aktuellen Werte sehen würde.

rowe42 commented 6 years ago

Man müsste also die Suche neu anstoßen. Was aber tun wenn die aktuelle Suche so eingestellt ist, dass der neue oder geänderte Eintrag gar nicht vorkommt? Wir haben die Frage heute auch unseren zukünftigen UX Experten gestellt, vielleicht kommt ja da sinnvoller Input. @Baumfrosch @olympialice

xdoo commented 6 years ago

Eine Suche bildet immer den Datenbestand zu einem bestimmten Zeitpunkt ab. D.h. die Erwartungshaltung, dass ich durch ein zukünftiges Ereignis das Ergebnis einer Aktion in der Vergangenheit verändere kann ich nicht wirklich teilen. Ich bin vielmehr der Meinung, dass uns hier einfach eine Komponente fehlt, die alle Objekte eines bestimmten Kriteriums anzeigt. Beispielsweise alle Aktionen zu einem Fall. Würde man hier eine weitere Aktion erstellen, dann müsste die natürlich in der Liste erscheinen. Suchergebnisse zu manipulieren halte ich für keine gute Lösung.

dragonfly28 commented 6 years ago

Na dann frage ich mich aber, warum beim Löschen einer Entität im "Suchergebnis" die Liste danach modifiziert ist. Ist irgendwie nicht konsistent mit dem Editieren einer Entität. Ich denke, die Liste ist derzeit auch mehr als ein reines Suchergebnis, das man nur durch eine neue Suche ändert sondern eher ein CRUD-Aufsatz für die Entitäten. Darum gibt es ja auch die Edit/Delete-Icons die bei einem reinen Suchergebnis eher unüblich sind.

xdoo commented 6 years ago

Sehe ich nicht so. Natürlich kann ich mit den Dingen, die ich gefunden habe etwas tun. Dafür sind die Aktionen da. Ob ich bei der Aktion "löschen" das Objekt aus dem Suchergebnis entfernen muss, läßt sich streiten. Ich fände es richtiger keine Aktionen zu dem gerade gelöschten Objekt mehr anzuzeigen, es aber in der Ergebnisliste stehen zu lassen. Dann kann ich halt nichts mehr damit machen.

Na dann frage ich mich aber, warum beim Löschen einer Entität im "Suchergebnis" die Liste danach modifiziert ist.

Weiß ich auch nicht. Habe ich nicht entschieden und auch nicht implementiert, finde ich aber auch nicht schlimm und kriegsentscheidend. Wie gesagt - eine Lösung wie oben beschrieben würde mir besser gefallen.

Aber in diesem Ticket geht es ja nicht darum Dinge aus dem Suchergebnis zu löschen, sondern sie in ein Suchergebnis einzufügen, das zu einer Suche gehört, die zu einem Zeitpunkt ausgeführt wurde, als es dieses Ding noch gar nicht gab. Was ist denn mit den Dingen, die andere Nutzer in der Zwischenzeit angelegt haben und die ich durch eine erneute Suche sehen würde? Müsste ich die dann auch sehen, ohne eine Suche durchzuführen?

Besser wäre, wenn man auf der Liste unmittelbar die aktuellen Werte sehen würde.

Genau das fände ich aus den dargestellten Gründen nicht.

dragonfly28 commented 6 years ago

Wir diskutieren hier über unterschiedliche Anforderungen und unterschiedliche Sichtweisen. Wenn ich in einer Listenansicht editiere und lösche sehe ich selbstverständlich die getätigten Änderungen in der aktuellen Listenansicht. Kein Benutzer würde etwas anderes erwarten. Wenn ich lediglich ein Suchergebnis habe, kann ich üblicherweise weder editieren noch löschen sondern vielleicht einzelne Suchergebnisse ausblenden oder 'zur weiteren Bearbeitung' öffnen. Derzeit haben wir aber einen Mix aus beidem.

@olympialice Hier sollte mal ein UI-Designer drüber schauen, wie man das am Besten macht.

xdoo commented 6 years ago

Wir führen eine Suche durch und haben danach kein Suchergebnis? Das daran festzumachen, dass mit Suchergebnis etwas machen kann, erschließt sich mir nicht. Wenn wir nach etwas suchen, dann haben wir auch (wie in unserem Fall) ein Suchergebnis. Das ist keine Liste. Wir haben aktuell keine Listenkomponente. Wir haben hier auch keinen "Mix".

Grundsätzlich ist das Verhalten hier eine fachliche Frage. Wir müssen uns Gedanken machen, welche unterschiedlichen Möglichkeiten der Navigation es in der Regel geben wird und wie die einzelnen Komponenten unterstützen können. Wie es letztendlich in einer Zielanwendung umgesetzt wird entscheiden die Kollegen im Projekt. Wir können das natürlich in der Doku, die @olympialice dokumentieren und Empfehlungen geben.

Mögliche Pfade:

  1. Der Sachbearbeiter sucht etwas und bekommt eine Ergebnismenge geliefert.

2a. Er findet es. 3a. Er bearbeitet es in einer anderen View.

2b. Er findet es nicht. 3b. Er erstellt es in einer anderen View.

4ab. Wenn er jetzt zur Suche zurück kehrt, dann sollte das Suchergebnis leer sein (er muss ja nicht mehr suchen - er hat es ja schon gefunden [a] oder eben nicht [b]). Ob er zur Suche zurück kehrt ist die Sache des Projektes - nicht unsere. Aber warum sollte denn das alte Suchergebnis manipuliert werden?

2c. Er findet es. 3c. Er löscht es in der Komponente. An dieser Stelle gibt es keine Navigationsbewegung. Das ist der einzige Fall, indem ich in der Ergebnismenge anzeigen würde, dass gerade etwas mit dem Objekt passiert ist. Will man das nicht, dann muss man auf einer anderen View löschen. Damit würde sich der Löschvorgang genauso verhalten wie die anderen. (in diesem Fall fehlt uns eine "Delete-Form" Komponente)

Daraus ergeben sich für mich folgende Anforderungen an die Suchkomponente:

Das Suchergebnis sollte NICHT manipulierbar sein.

Es gibt hier ein schönes Designprinzip: "do one thing and do it well". Genau das sollten wir anwenden und eine Suche als Suche behandeln und eine Liste als Liste. Wenn eine Komponente fehlt, dann muss sie halt gebaut und nicht eine EierlegendeWollmilsau-Monsterkomponente geschaffen werden.

Ich bin dafür dieses Ticket zu schließen.

ejcsid commented 6 years ago

Anforderungen formulieren, aber dann das Ticket schließen?

  • Es sollte konfigurierbar sein, dass das Suchergebnis bei Absprung gelöscht wird.
  • Es sollte konfigurierbar sein, dass die "Löschen" Funktionalität ausgeschaltet werden kann.
  • Schön wäre es, wenn man die letzten Suchanfragen zur Verfügung hätte, um diese schnell wieder ausführen zu können.

Dann schließe ich dieses Ticket.

xdoo commented 6 years ago

Anforderungen formulieren, aber dann das Ticket schließen?

Anforderungen, die dann natürlich (falls nicht eh schon vorhanden) in eigene Tickets münden. Danke fürs anlegen :)