Durch meine Entwicklung am Bundeskampf-Bot haben sich meine Sichtweisen auf andere Programme erheblich verändert. Als Entwickler versucht man sich jeden erdenklichen Einsatzzweck vorzustellen und Testet das Programm dementsprechend. Bei auftretenden Fehlern wird das Programm mit Werkzeugen untersucht, die nur dann richtig angesetzt werden können, wenn man weiß, wie der Fehler auftritt und aus welcher Richtung er kommt. Somit sind wir bei dem Kernproblem angekommen: Wie bekommt der Entwickler diese Informationen über den Fehler.
Im meiner Computer-Anfangszeit nutzte ich Windows-XP und hatte, wie viele andere Benutzer auch, relativ schnell die Fehlerberichterstattung satt. Dauernd ging ein Fenster auf und Windows wollte „nach Hause telefonieren“. Das der Fehler in den meisten Fällen gar nicht an Microsoft lag, störte den Dienst nicht, allerdings die Nutzer.
Viele andere große oder kleine Software-Produkte bauten eine automatisierte Übermittlung der Fehlerberichte in ihre Programme ein. Bei den Nutzern löste das dann meist einen Schockzustand aus: „Jetzt wollen die uns auch ausspionieren.“ Auch ich habe solchen Übermittlungen bei verwendeten Programmen immer widersprochen, indem ich die Einstellungen dafür änderte.
Mit der oben schon erwähnten Entwicklung eines eigenen Programms ist man auf die Mitarbeit der Nutzer angewiesen. Wenn diese keine Fehler melden, wird das Programm auch nicht besser. Allerdings wissen sie zum Teil nicht, was für Informationen notwendig sind (Stacktrace, etc.), zum anderen denken Sie, dass ihre illegale Aktivität somit aufgedeckt werden würde (was ja auch verständlich ist).
Für mich stellt sich nun die Frage, wie man Nutzer davon überzeugen kann einen solchen Fehlerberichterstattungsdienst anzuerkennen und ihn auch zu nutzen. Bisher konnte ich diese noch nicht beantworten.
Ich kenne das Problem. Jedoch habe ich diese Dialoge immer abgebrochen, weil mir Microsoft hier nicht helfen kann. Nur der Entwickler. Das Programm selber sollte hier die Fehlererstattung übernehmen. Eine Variante, die zumindest mich immer beruhigt bei Fehlerberichten, ist die Anzeige des zu sendenden Inhalts. Ich weiß jedoch nicht, wie gut ein normaler Nutzer damit umgehen kann.
Prinzipiell finde ich solche Dialoge mittlerweile gar nicht mehr so schlimm, wenn es sich nicht gerade um etwas wie, das von dir erwähnte, Negativbeispiel handelt. Je nach Frustgrad, den die Software bei mir auslöst, sende ich diese Berichte dann auch tatsächlich ab. Wichtig ist mir dabei, dass er sich aber auch genau so schnell überspringen lässt, falls ich die Nase von dem Programm voll hab.
Anforderungen, die ich an so einen Dialog stellen würde sind auf jeden Fall:
– kurze Erklärung für DAUs, was passiert ist, warum der Dialog erscheint und wozu er dient
– eine optionale Detailansicht (per Button oder Reiter) der zu übermittelnden Daten
– ein Häckchen, dass sie die getätigte Auswahl merkt, im nachhinein aber auch wieder an anderer Stelle geändert werden kann („In Zukunft nicht mehr nachfragen“)
Das Schlimmste, was in solchen Fällen passieren kann, ist wenn der Fehlerdialog selbst Probleme bereitet. Sollten also bei der Zusammenstellung der Daten oder deren Übermittelung Fehler auftreten, dem Nutzer auf keinen Fall noch weiter „auf den Sack gehen“ und den Bericht für den nächsten Übertragungsversuch zwischenspeichern oder verwerfen.
Georg lebt noch und ließt anscheinend sogar seine E-Mails … :)
Was ich vergessen hatte, zu erwähnen. Das Programm ist zur Zeit als Konsolenprogramm realisiert. Zur Zeit steht dann dort immer sowas wie:
Bitte melden Sie folgende Zeilen dem Entwickler per E-Mail:
Stacktrace ....
....
Wenn man das jetzt als GUI-Diaglog baut, ist die schöne Möglichkeit gestorben, das Programm ohne Oberfläche (auf dem Server) laufen zu lassen.
Na das ändert die ganze Geschichte ja schon gewaltig. Dann vielleicht noch einen Export in eine extra Datei mit einbauen, die dann als Anhang versandt werden kann. Dann gibts auch keine fehlenden Informationen durch copy&paste.