(03.01.2013, 22:22)routeconverter Wrote: Ich nehme an, Deine Distribution bietet keine neueren Minorversionen an? Oder warum hast Du nicht aktualisiert, um die Nerv-Messagebox wegzubekommen?
Die neue Version wird es geben (ist ja Windows ;-). Die Java-Version nutzt der RC nicht alleine und ich habe hier noch ein Video-Programm, welches in der Vergangenheit etwas empfindlich auf Änderungen der 64bit-Java-VM reagiert hat. Also "never touch a running system."
Da ich mit dem System nicht surfe habe ich die Gefahr der Sicherheitslücken auch nicht ganz so groß eingestuft.
(03.01.2013, 22:22)routeconverter Wrote: Danke, bitte drückt die Daumen - meinem Erstgeborenen geht es schlecht :-(
(07.01.2013, 06:10)lundefugl Wrote: Die neue Version wird es geben (ist ja Windows ;-). Die Java-Version nutzt der RC nicht alleine und ich habe hier noch ein Video-Programm, welches in der Vergangenheit etwas empfindlich auf Änderungen der 64bit-Java-VM reagiert hat.
Was hältst Du von der Idee, nur 1x im Moment die Information zu bringen, daß eine neue Java-Version existiert?
(08.01.2013, 23:47)routeconverter Wrote: Was hältst Du von der Idee, nur 1x im Moment die Information zu bringen, daß eine neue Java-Version existiert?
das ist schwer zu sagen. Für mich wäre es ok (aber ich kann auch mit dem derzeitigen Zustand leben).
In der Firma haben wir schon die dollsten Anwender gehabt. Messageboxen lesen gehört definitiv nicht zu ihren Stärken. Die klicken meist einfach immer auf "Ja" oder "OK".
Wenn es dann Probleme gibt, so erinnert sich evtl. einer sogar darn, dass da etwas beim Start war und will es nochmal lesen - was nicht gehen würde. Ausserdem ist nicht gesagt, dass Probleme sofort auftauchen. Bei dem späteren Start erinnert er sich dann nicht mehr an eine in der Vergangenheit aufgetretene Messagebox und du hast einen Supportfall.
Daher auch mein Vorschlag es über eine versteckte Option zu machen. Das macht man dann bewusst und sicher auch nur Anwender, die wissen, was sie tun.
Ideal wäre dabei, wenn man in der Registry nicht allgemein die Meldung abschaltet, sondern nur gezielt für eine konkrete Java-Version. Sollte Oracle eine neue Version herausbringen, so kommt die Meldung wieder.
Was natürlich auch möglich wäre ist, dass man über die versteckten Optionen zwischen deiner vorgeschlagenen "Einmalmeldung" und der bisherigen "Dauermeldung" umschalten kann.
Aber wie gesagt - ich kann auch mit dem derzeitigen Stand leben.
Der Einwand von mir bezog sich nur auf den Fall, dass es weitere Boxen gibt und dann der Anwender x-mal etwas quittieren muss. (Zumal sich bei uns gezeigt hat, dass die Sicherheit damit eher ab- als zunimmt, da die Meldungen nicht mehr gelesen werden)
10.01.2013, 10:18 (This post was last modified: 10.01.2013, 10:18 by routeconverter.)
(09.01.2013, 06:21)lundefugl Wrote: In der Firma haben wir schon die dollsten Anwender gehabt. Messageboxen lesen gehört definitiv nicht zu ihren Stärken. Die klicken meist einfach immer auf "Ja" oder "OK".
Viele Anfragen von Nutzern in der letzten Zeit zeigen mir, daß Beschreibungen und Fehlermeldungen nicht verstanden werden. Darum bin ich am überlegen, wie ich diese Anfragen vermeiden kann. Was macht ihr in der Firma gegen dieses Problem?
(09.01.2013, 06:21)lundefugl Wrote: Daher auch mein Vorschlag es über eine versteckte Option zu machen. Das macht man dann bewusst und sicher auch nur Anwender, die wissen, was sie tun.
Ideal wäre dabei, wenn man in der Registry nicht allgemein die Meldung abschaltet, sondern nur gezielt für eine konkrete Java-Version. Sollte Oracle eine neue Version herausbringen, so kommt die Meldung wieder.
So finde ich das auch sinnvoll.
(09.01.2013, 06:21)lundefugl Wrote: Was natürlich auch möglich wäre ist, dass man über die versteckten Optionen zwischen deiner vorgeschlagenen "Einmalmeldung" und der bisherigen "Dauermeldung" umschalten kann.
Oder Du schaltest die "Suche nach Updates" unter Extras/Optionen... aus. Dann erscheint keine Messagebox mehr.
(09.01.2013, 06:21)lundefugl Wrote: Der Einwand von mir bezog sich nur auf den Fall, dass es weitere Boxen gibt und dann der Anwender x-mal etwas quittieren muss. (Zumal sich bei uns gezeigt hat, dass die Sicherheit damit eher ab- als zunimmt, da die Meldungen nicht mehr gelesen werden)
Damit nur eine Messagebox hochkommt zeige ich die Java-zu-alt-Nachricht auch nur, wenn RouteConverter aktuell ist. Die Windows XP-ist-veraltet-Nachricht könnte dann nur erscheinen, wenn RouteConverter und Java aktuell sind.
10.01.2013, 19:12 (This post was last modified: 10.01.2013, 19:20 by lundefugl.)
Hallo Christian,
(10.01.2013, 10:18)routeconverter Wrote: Viele Anfragen von Nutzern in der letzten Zeit zeigen mir, daß Beschreibungen und Fehlermeldungen nicht verstanden werden. Darum bin ich am überlegen, wie ich diese Anfragen vermeiden kann. Was macht ihr in der Firma gegen dieses Problem?
Da gibts verschiedene Strategien.
Die Wichtigste ist, dass es möglichst wenige Boxen gibt. Um so seltener etwas kommt, desto höher die Wahrscheinlichkeit, dass sie nicht weggeklickt wird.
Der wichtigste Weg dazu ist, dass wir für fast alle Funktionen eine Undo-Funktion haben. Wenn man das Ergebnis der Aktion offensichtlich sieht, so merkt der Anwender normalerweise sofort, wenn er etwas gemacht hat, was er nicht wollte. Ausserdem haben wir bei unserer Datenhaltung das normale Laden - Ändern - Speichern-Konzept. Man muss am Ende bewusst auf Speichern drücken, um seine alten Daten platt zu machen.
Ein weiterer Weg ist, dass man gefährliche und selten benötigte Menüpunkte/Funktionen etwas "versteckt". Man ruft z.B. über den Kontext-Menüpunkt erst einen Dialog auf, in dem dann die kritsischen Funktionen drin ist. Hier gibts dann auch noch neben dem Start-Button eine kurze Beschreibung, was die Funktion macht. Ausserdem sind die Buttons so weit entfernt, dass ein abrutschen mit der Maus ausgeschlossen ist.
Dann haben wir noch die Möglichkeit die Bedienung zwischen Standard- und Expertenmodus hin- und herzuschalten. Dabei startet das Programm immer im Standard-Modus. Erst über einen bewussten Klick schalten wir in den Experten-Modus mit Funktionen, die man selten benötigt, aber die Datentechnisch vieles kaputt machen können. Als Kennzeichnung ändern wir in dem Modus dann die Farbe der Menüleiste. Spätestens nach 10 Minuten verlassen wir auch automatisch diesen Modus wieder.
Zuletzt versuchen wir an einigen Stellen statt Messageboxen einen eigenen Dialog zu bringen. Das z.B. dann, wenn man noch optionale Dinge auswählen kann.
Konkret wird das beim importieren von Daten gemacht. Statt einer Box "Sind sie sicher, dass die bestehenden Daten überschrieben werden sollen ?" haben wir einen Dialog, bei dem per Checkboxen ausgewählt werden kann, was überschrieben werden soll. Zwar ist alles immer automatisch ausgewählt, aber der Anwender hat trotzdem einen 2. Dialog, den er bestätigen muss - ohne, dass er die gängelnde Box bewusst erkennt. Er meint vielmehr einen Import-Wizzard vor sich zu haben.
Ziel aller dieser Massnahmen ist, dass mit einem Klick allein keine kritische Funktion direkt abläuft. Der Anwender soll zu einer zweiten bewussten Aktion gezwungen werden.
Fehlermeldungen, die durch Eingabefehler verursacht werden, versuchen wir durch Prüfungen direkt während der Eingabe zu fangen. D.h. der eigentliche Start-Button ist ausgegraut solange die Eingaben nicht korrekt sind.
Hinter den Eingabefeldern erscheint zusätzlich immer bei Problemen ein farbiger Punkt, der anzeigt, ob die Eingabe komplett falsch ist (Fehler), eher unüblich/exotisch ist (Warnung) oder noch fehlt (TODO). Ein Tooltip auf dem Punkt gibt dann eine genau Meldung, was uns nicht gefällt. Da klar ist, auf welche Eingabe es sich bezieht, reichen einfache Texte wie "Es wurde keine Zahl zwisch x und y eingegeben". Oder die Eingabe ist keine gültige Telefonnummer u.ä..
(10.01.2013, 10:18)routeconverter Wrote: Oder Du schaltest die "Suche nach Updates" unter Extras/Optionen... aus. Dann erscheint keine Messagebox mehr.
Das ist ja einfach. Bis jetzt dachte ich immer, dass die Option nur für den Update-Check des RCs wirkt. Auf die Idee, dass das auch für die Java-Version gilt, bin ich nicht gekommen - ist aber eigentlich logisch.
es ist lange gut gegangen, aber mit dem Update auf die openSUSE 13.1
wird eine neue Webkitversion (webkitgtk-2.2.1-1.1) verwendet
Bei der hilft nicht mal der Trick mit dem Link.
Ich habe das aktuelle Log an gehangen, im Moment ist eine Problemlösung
für mich nicht allzu wichtig, da ich auf eine openSUSE 12.3 mit webkitgtk-1.6.x
ausweichen kann
21.11.2013, 11:44 (This post was last modified: 21.11.2013, 11:45 by routeconverter.)
(20.11.2013, 21:21)berndw Wrote: es ist lange gut gegangen, aber mit dem Update auf die openSUSE 13.1
wird eine neue Webkitversion (webkitgtk-2.2.1-1.1) verwendet
Bei der hilft nicht mal der Trick mit dem Link.
Das heißt, Du siehst keine Karte? Im Log steht gar nichts zur Initialisierung der Karte. Vielleicht steht auf der Konsole mehr?
(20.11.2013, 21:21)berndw Wrote: Ich habe das aktuelle Log an gehangen, im Moment ist eine Problemlösung
für mich nicht allzu wichtig, da ich auf eine openSUSE 12.3 mit webkitgtk-1.6.x ausweichen kann
Wir haben es hier mit einer langen Warteschlange zu tun:
Du wartest auf die Unterstützung aktueller WebKit-Versionen
Ich warte seit Anfang des Jahres auf eine neue DJNative Swing-Bibliothek, mit der die Karte in RouteConverter integriert wird.
Der Autor von DJNative Swing-Bibliothek wartet auf eine neue Eclipse SWT-Bibliothek, auf der seine Bibliothek aufbaut.
Die Eclipse SWT-Autoren warten auf Bugfixes in Java AWT, die Oracle seit Anfang des Jahres immer wieder verschiebt, um an der Sicherheit von Java zu schrauben.
(21.11.2013, 12:58)berndw Wrote: Ich hänge Dir mal ein paar Dateien an, ein Screenshot mit dem Fehler, die Ausgabe auf der Konsole und das JVM-Error-Log
Einen Dump kann ich auch erstellen, aber erst heute abend
Laß mal, das Muster kenne ich: da crasht die JVM, die WebKit ansteuert. Lösung wie oben beschrieben
