mit ENTER ins neue FIELD...

[TMC]

Übrigens: Letzte Woche erst erlebt:

Einer Usergruppe neue Notes-DB gezeigt und die Leute darin geschult.

User gibt im 1. Feld was ein und will ins nächste wechseln. Er betätigt intuitiv ENTER.
(jo mei).

Die User sind das auch von Excel gewohnt. Enter = neue Zeile bzw. "springe in die Zelle unter der jetzigen".

Viele User kennen die Tab-Taste leider gar nicht. Das ist leider Realität  

[TMC]

@Matthias: wir haben parallel gepostet.
Ich kenne solche Anforderungen. Lohnen tut sich der Aufwand nicht.

@Axel: Mein letzter Post war wieder parallel  

Anyway:
Du hast natürlich Recht. In irgend einem Domino-Blog war letztens eine 10Punkte-Liste was ein Developer/Projektmanager beachten soll. War gar nicht schlecht die Liste (wenn auch schon alles/vieles bekannt). Wenn ich sie noch finde poste ich diese...
Ein Punkt war: Keine zusätzlichen Features einbauen - wenn nicht explizit gefordert. Hier würde ich das auch noch erweitern um "Nicht von Notes-Standards abweichen". Bringt sonst imho nur Ärger mit sich.

Typisches Beispiel: User will mit F5 (also Win-Standard) refreshen statt mit F9.

Hier muss - denke ich - ein Projektleiter einschreiten und höflich klarstellen, dass wir uns hier in einer Non-MS-Umgebung befinden. F9 wird wohl auch in R9 der Refresh-Button sein.
Und aktuell ist eben ENTER keine definierte Taste für das "ins nächste Feld springen" sondern eben TAB. Auch wenn ich mir das für Apps wünschen würde um Verwirrungen und De-Intuition zu vermeiden....

[Marinero Atlántico]

Matthias,

als externer kann das ein Zeit- und allgemeine-zielorientiertheit-Haltung-des-Projektteams-Problem werden. Auch wenn ich für Zeit billable bin, wird letztlich danach beurteilt, wieviel Leistung ich im avisierten Zeitrahmen abliefere. Solche Haltungen wie haha-der-dumme-Kunde-will-das-also-mach-ich-den-Quatsch sind nämlich oft auch nicht so gut für den entscheidenden Gesamteindruck.

In einer besseren Welt, würde die Diskussion so ablaufen:
PM Kunde: Aber die Leute sind das so gewohnt.
Ich: In Notes gibt es null/nada/zilch eventhandler, den ich da einklinken könnte.
PM Kunde: Aber in dem Programm geht das.
Ich: Das ist C++. Da gibt es einen Eventhandler für.
PM Kunde: Geht es wirklich nicht. Es ist glaub ich für die Anwender wichtig.
Ich: Ich kann theoretisch ein Applet erzeugen, dass über LiveScript (oder eine andere Technik, weiss wo ich nachschlagen muss) mit Feldern in der Maske kommuniziert. In Java gibts TastaturListener.
PM Kunde: Das hört sich aber kompliziert an und dürfte wohl die Anwendung unnötig mit crap aufblähen.  
Ich: Genau.
PM Kunde: OK. Dann geht das nicht.

In der Realität. Wenn man da nicht höllisch aufpasst, findet man sich wegen sowas dann in einem Meeting mit 8 bis 10 Leuten mit voller Bewirtung wieder. 4 kommen zu spät. Inkompetente Leute produzieren sich. Der ganze Wahnsinn eben. Das Projekt mache ich dann zwischen 18:00 - 22:00 Uhr, wenn die ganze Bande weg ist.  

Gruß Axel

[koehlerbv]

ENTER geht in Notes einfach nicht, da es für zu viele andere Zwecke dringend gebraucht wird (Zeilenschaltung in Textfeldern, Trennung von Mehrfachwerten). Es wäre also eher verwirrend, wenn man zum Bleistift einen Schalter hätte in den field properties: "ENTER sets focus to next field". Mal würde dann ENTER das eine, mal das andere bedeuten. Das wäre dann erst die perfekte Verwirrung  

Notes ist ja bei weitem auch nicht das einzige Programm, das auf ENTER so reagiert. Andererseits geht TAB (fast) überall, um den Focus auf das nächste Eingabefeld zu setzen. Sogar in Excel  

Bernhard

[TMC]

Andererseits geht TAB (fast) überall, um den Focus auf das nächste Eingabefeld zu setzen. Sogar in Excel  

Jein. In Excel springt der Cursor bei TAB zum Feld rechts daneben. Bei Enter nach unten. In Notes sind oft die Maskenfelder untereinander angeordnet. Somit für den reinen Excel-Anwender nicht 100% intuitiv.

Aber ansonsten gebe ich Dir natürlich Recht. Passt einfach heute nicht ins Notes-Konzept.
Wobei eine Laufzeit-Eingabevalidierung (also vor Exiting-Event) imho ganz praktisch wäre. Z.B. man definiert für ein Feld max. 10 mögliche Zeichen. User gibt den 11. Buchstaben ein: Fehlermeldung.

[Marinero Atlántico]

Hier ist vorher der Begriff "Windows-Standard" gefallen. Ich muss mir das mal besorgen. Da gibt es nämlich klare Dokumentation zu. Und nach dem Windowsstandard bewirkt <return> nämlich nicht, dass man in ein neues Feld springt. Das ist der für mich der entscheidende Punkt.
Selbst Sun propagiert inzwischen, dass sich die Entwickler darum kümmern müssen, das eine GUI-Anwendung auf allen Plattformen konform sein soll:
Zumindest hat das Hani Suleiman aus einer Sun Session so geblogt:

Yes, amazingly, you DO need to know the UI guidelines of your target platform. Yes, you DO need to test using multiple platforms. If you don't, you end up with shit like Eclipse, which, through the divine gift of obstinate fuckwittedness, behaves like a Windows application no matter what platform you run it on. If your UI is successful and usable, the best outcome is no feedback from your end users. They'll be suffused with a happyhappy feeling and won't quite know why. They'll eagerly use your application and not cringe when they're asked to do something with it.

On the downside, when you have a bad UI, very very few users will be able to pinpoint what is so bad about it. Instead, they'll hate your application and feel an incoherent rage towards anyone insisting they use it. It's not like web shit where there are a few million html monkeys and two ways of doing everything; with rich clients, there are thousands of ways of doing everything, and about 3 people who know the right way. Finding the sweet spot is a task far more daunting than farting out yet another silly web intranet app.

Conclusion? The user drives the UI and features, NOT the underlying code. It's your responsibility as a developer to ensure that the mapping between your UI and your underlying functionality works well, and to acknowledge that such a mapping is necessary. Also, always always go that extra mile to ensure that your app is well behaved on all platforms, and be prepared to spend a lot of time and effort doing that with no feedback. No feedback that is beyond smiley gleeful users who are more often than not totally unable to attribute that sensual sense of satisfaction with anything you might have done.

Fazit: Die wirklich wichtigen Sachen stehen im Bile Blog.  

[TMC]

In der Realität. Wenn man da nicht höllisch aufpasst, findet man sich wegen sowas dann in einem Meeting mit 8 bis 10 Leuten mit voller Bewirtung wieder. 4 kommen zu spät. Inkompetente Leute produzieren sich. Der ganze Wahnsinn eben.

Und beschlossen wird dann, dass man das ganze in den Steuerkreis zur Entscheidung kippt   (in dem natürlich nur die Bosse sitzen die am wenigsten Plan haben). Beschlossen wird dann je nach Lust und Laune.
(habs zumindest so ähnlich schon öfter erlebt). Widerspruch dann zwecklos, wenn es mal soweit ist.

[TMC]

Zumindest hat das Hani Suleiman aus einer Sun Session so geblogt:

Und das ganze klingt sehr vernünftig (egal jetzt erstmal welche Plattform)  

[koehlerbv]

Jein. In Excel springt der Cursor bei TAB zum Feld rechts daneben. Bei Enter nach unten. In Notes sind oft die Maskenfelder untereinander angeordnet. Somit für den reinen Excel-Anwender nicht 100% intuitiv.

Das ist jetzt aber kein Argument, welches sticht   Der "reine Excel-Anwender" soll dann auch kein Notes benutzen, sonst ist er ja nicht mehr "rein" ...

Aber ansonsten gebe ich Dir natürlich Recht. Passt einfach heute nicht ins Notes-Konzept.
Wobei eine Laufzeit-Eingabevalidierung (also vor Exiting-Event) imho ganz praktisch wäre. Z.B. man definiert für ein Feld max. 10 mögliche Zeichen. User gibt den 11. Buchstaben ein: Fehlermeldung.

Das passt auch später nicht mehr ins Notes-Konzept: Notes ist keine Tabellenkalkulation, Notes ist kein RDMS usw. usf.
Aber mit einem Event "OnKeyStroke" könnten die Jungs und Mädels von Iris wirklich mal 'rausrücken. ENTER umbiegen wäre zwar Mist (Axel hat da die besten Argumente geliefert), aber zum Bleistift korrekte Eingaben von Datums- oder Zeitangaben überwachen, Passworteingaben zu registrieren, aber nicht auf dem Bildschirm darzustellen etc. - das ist wirklich ein absolut fehlendes Feature !!

Bernhard

[TMC]

Jein. In Excel springt der Cursor bei TAB zum Feld rechts daneben. Bei Enter nach unten. In Notes sind oft die Maskenfelder untereinander angeordnet. Somit für den reinen Excel-Anwender nicht 100% intuitiv.

Das ist jetzt aber kein Argument, welches sticht   Der "reine Excel-Anwender" soll dann auch kein Notes benutzen, sonst ist er ja nicht mehr "rein" ...

Na ja, Bernhard, Du hast ja das "Excel-Argument" gebracht  
Und Tab führt da eben nach Rechts und nicht nach Unten. Somit nicht 100% intuitiv.

Ansonsten wären wirklich ein paar mehr Hilfsmittel recht zur Eingabevalidierung. Würde vieles vereinfachen.....

[koehlerbv]

Ich befürchte, wir sind in einem recht müssigen Diskurs  
TAB setzt Fokus auf Zelle unter der aktuellen. Okay, that's Excel. Aber was hat das mit Notes zu tun ? Wieviele Masken gibt es, die Felder nur untereinander gruppieren ? Excel-Liebhaber scheitern da dann ja sowieso.

Wenn so ein Excelzist mit der Enter-Taste und "das geht ja immer so ..:" kommt, sollte man den Schnelldenker auch gleich fragen, ob er denn auch Word benutzt  

Bernhard

[Semeaphoros]

Excel ist genau das richtige Beispiel: Microsoft durchbricht die eigenen Regeln/Standards (zum Bleistift die völlig eigene Art, mit dem Kopieren und Einfügen umzugeehen). Vermutlich würde Excel nicht einmal den Microsoft-Test "Runs with Windows" bestehen ... go figure ...  

[koehlerbv]

Gut gebrüllt, Semeaphoros !
Die Anwender sollten sich da auch mal an der eigenen Nase kratzen. Eine Argumentation "Aber in Programm XYZ geht das doch auch so ..." ist oft (aber nicht immer - da müssen wir auch immer aufpassen !) totaler Schwachsinn. Über die unterschiedliche Procedere, wie zum Bleistift bei Hersteller A im Gegensatz zu Hersteller B den  Rückwärtsgang des Autos schalten lässt, moniert sich auch keine Sau - obwohl man da was tun könnte (wie bei der Blinkerschaltung oder der Scheinwerferauswahl, die ja auch de jure standardisiert ist).

Bernhard

[Semeaphoros]

Jo, genau das was ich meine, wenn immer möglich sich an das halten, was üblich ist, aber das nicht unbedingt mit dem Kopf durch die Wand durchsetzen wollen. Kompromisse muss man ja eh irgendwie schliessen. Ich versuche immer, mir selbst die Frage zu stellen, was erwartet der User an dieser Stelle oder wo könnte er die Funktionalität suchen, und da muss man schon fast mit anderen Produkten vergleichen und beobachten, wie es andere machen. Aber konsequent irgendwas durchzuziehen ist unmöglich. Wozu ein  "Datei"-"Speichern" implementieren, wenn das Programm nur anhzeigt und nichts verändern .... nur weils im CUA-Standard so defniert ist

[-Michael-]

Wozu ein  "Datei"-"Speichern" implementieren, wenn das Programm nur anhzeigt und nichts verändern .... nur weils im CUA-Standard so defniert ist

Datei/Speichern-Menüdialog können wir in Notes-Apps ja eh nicht bieten.

Meine Meinung: Bitte keine API-Konstrukte um das "Enter-> nächstes Feld" umsetzen. Sonst heißt es irgendwann noch "Hey, ich hab das in Notes schon gesehen dass das geht".
In der Input Translation die Zeilenumbrüche rauswerfen sollte reichen.
Den sog. "Windows-Standard" bricht MS leider oft genug selber. Ist also wohl nicht wirklich ein Standard.