#2353 closed Verbesserung/Featurewunsch (wont-fix)
Focus (Cursor-Position) nach "Erneuern" beibehalten
| Erstellt von: | od-peter | Verantwortlicher: | |
|---|---|---|---|
| Priorität: | normal | Meilenstein: | |
| Komponente: | kivitendo ERP | Version: | 3.0.0 unstable |
| Schweregrad: | Verbesserung | Stichworte: | |
| Beobachter: |
Beschreibung
Nach meiner Erfahrung sind vielen Anwender von der Tatsache verwirrt, dass nach dem "Erneuern" eines Forms (bzw. nach dem betätigen der Eingabetaste) der Focus zur letzten Zeile in der Liste springt.
Vor allem beim nachträglichen Korrigieren in Dokumenten mit vielen Positionen stört dieses Verhalten den Arbeitsfluss. Viel intuitiver wäre doch, wenn der Focus im aktuellen Eingabefeld bliebe oder in des nächste Feld wechseln würde (Tabulator-like).
So wie ich das beurteilen kann, ist die Umsetzung nicht ganz trivial, aber machbar:
Eine anonyme Funtion im <body> müsste bei jedem Focuswechsel die Position speichern:
var $focused = $(':focus');
Um diesen danach wiederherzustellen
$(document).ready( function(){ $focused.focus() });
Bitte um kurzes Feedback, ob ich die Usability und den Aufwand richtig einschätze...
Gruß Peter
Änderungshistorie (5)
comment:1 Geändert vor 19 Monaten durch m.bunkus@…
comment:2 Geändert vor 19 Monaten durch s.schoeling@…
Das letzte fokussierte Element speichern ist jetzt schon ein Teil der Fokusmechanik. Das ganze intuitiv hinzukriegen ist aber bei Weitem nicht so einfach wie Du Dir das vorstellt, unter anderem aus den Gründen die mosu genannt hat.
Dazu kommen noch so ein paar technische Probleme. Focus speichern ist ne tolle Sache, aber Du kannst keine DOM Elemente über den Request retten (oder sogar jQuery wrapper um DOM Elemente wie in Deinem Beispiel), aller höchstens ids von DOM Elementen. Einige Stellen sind :focussable aber haben keine id, die sind dann zum Beispiel nicht speicherbar. Das zu fixen hieße durch alle Masken zu gehen und sicherzustellen, dass jedes Element immer eine eindeutige und reproduzierbare id kriegt, was sich aber wiederum mit unseren internen Helperfunktionen beisst.
Dann das Kompositionproblem - wenn der neue Request eine andere Maske ist, die aber ein Element mit der id des alten fokussierten Elements hat, ist das wieder unintuitiv das einfach zu fokussieren.
Wenn der User von da aus aber wieder zurück in die alte Maske springt will er wieder das letzte Element da fokussiert haben. Passiert nie? Waren auswählen in Belegen sind ein eigener Zwischenrequest.
Als nächstes ein ganz anderes Problem, Submitbuttons sind fokussierbar. Wenn Du den Updatebutton anklickst, dann hat der als letztes Fokus. Ausser im Chrome. Chrome hat viele bekannte Bugs mit Fokushandling. Wenn Du das also einfach speicherst, dann wird alles was Du schreibst immer den letzten Button fokussieren, was sicher nicht intuitiv ist.
Das sind nichtmal alle Probleme, auf die ich dabei gestossen bin, und ein gutes befriedigendes Konzept habe ich da immernoch nicht. Versuch Dich ruhig dran. Vielleicht kriegst Du es besser hin, aber unterschätze den Aufwand nicht.
comment:3 Geändert vor 19 Monaten durch od-peter
Hmm, OK, ich gebe zu den Aufwand "leicht unterschätzt zu haben" :)
Dennoch haben wir mittlerweile (Gestern) eine Erweiterung implementiert welche fast 80% der Kundenwünsche abdeckt und dennoch recht einfach zu implementieren ist.
In der Benutzerkonfiguration (Program->Einstellungen) hat der User nun die Möglichkeit folgende Cursor-Positionen einzustellen:
- Neue Zeile, Art.-Beschreibung (kivitendo-Default)
- Neue Zeile, Art.-Nr.
- Aktuelle Zeile, Art.-Beschreibung
- Aktuelle Zeile, Art.-Nr.
Bei den letzten zwei Einstellungen ist das mit der "Aktuellen Zeile" etwas ..ehm... "geflunkert", denn tatsächlich landet der Cursor dabei einfach in der vorletzten Zeile (rowcount-1), was aber fast immer dem aktuell vom User bearbeiteten Artikel entspricht.
Damit sind aber nach der aktuellen Umfrage praktisch alle unsere zufrieden.
Falls jemand Interesse hat, kann ich den Patch hier anhängen.
Gruß Peter
comment:4 Geändert vor 19 Monaten durch m.bunkus@…
- Lösung auf wont-fix gesetzt
- Status von new nach closed geändert
comment:5 Geändert vor 19 Monaten durch n.simon@…
Die Erweiterung in den Programmeinstellungen ist zwar keine Lösung des Ausgangsproblems, speziell die Auswahlmöglichkeit Art-Beschreibung / Art-Nr. ist jedoch eine Konfigurationsmöglichkeit, die individuell sinnvoll ist. Bei den weiteren Optionen bin ich mir nicht sicher, wobei man das ggf. durch andere Texte ("Letzte Zeile") zumindest "ehrlicher" machen könnte und das dann ebenfalls Anwender-Interessen bedient.
Vorschlag: Stell den Patch in einem neuen Thread mit kurzer Erläuterung zur Verfügung, eine derartige Konfigurationsmöglichkeit halte ich für grundsätzlich sinnvoll (über den Lösungsweg kann dann mit deinen Patch philosophiert werden).
Nein, so einfach ist es nicht. Zum Einen gibt es für den Focus JavaScript-seitig bereits mehrereverschiedene Implementation (siehe js/common.js), die aus verschiedenen Stellen im Perl-Code heraus unterschiedlich aufgerufen werden. Eine weitere einzuführen, ist eine ganz schlechte Idee. Wenn das Verhalten geändert werden soll, so muss das auf einem der bestehenden Mechanismen aufsetzen.
Zum Anderen ist das, was für dich "viel intuitiver" ist, für andere nicht so wirklich intuitiv. Wir haben Kunden und Benutzer, die das aktuelle Verhalten explizit wollen, um schnell nacheinander mehrere Positionen hinzufügen zu können. Manche arbeiten so herum besser, andere machen erst eine Position komplett fertig, bevor sie die nächste einfügen.
Wenn das Verhalten also geändert wird, so muss es unbedingt für jeden Benutzer einstellbar sein.