Moin,

angeregt durch die SB möchte ich hier mal generell darüber diskutieren, wie man Anwendungen auf Dauer (für den Benutzer) übersichtlich hält. Ich schreib einfach mal runter.

Ich denke, wir kennen das alle. Mit der Zeit wächst die Anwendung. Die Benutzer wünschen sich neue Funktionen. Man baut sie ein und wieder ist die Software um einen Programmpunkt oder Einstellung gewachsen.
Das ist zugleich das Problem. Die Benutzer kennen nicht alle Funktionen, ja selbst ich bin manchmal überrascht, was für Funktionen meine Software hat.

Ich habe gerade mal spaßeshalter gezählt, wie viele Tabs mein Einstellungsdialog hat. Hier werden nur die ganz grundlegenden Einstellungen gesetzt. In den einzelnen Programmteilen kann man teilweise noch mehr Sachen einstellen. In diesem grundlegenden Dialog komme ich schon auf 16 Tabs. Und auf jeder Tabpage hab ich im Durchschnitt 10 Einstellungen. Mal mehr, mal weniger. So komme ich schon auf 160 Checkboxen, Radiogroups, Comboboxen, etc....
Ich hab auch mal meine DFM-Dateien gezählt. Ich komme auf 193 Formulare.... (bin gerade selbst überrascht).
Aber auf die Einstellungen kann ich auch nicht verzichten. Denn Kunde A sagt "wäre schön, wenn das Programm an der Stelle nicht X machen würde, sondern Y". Mag auch sinnvoll sein. Wenn man jetzt die Funktion auf Y ändert, gibts von 20 Kunden Applaus und von 40 Kunden drohen mit dem Rechtsanwalt "weil ja nichts mehr funktioniert". Was macht man also? Man macht es einstellbar (X oder Y). Alle sind zufrieden - soll man denken. Aber sie 20 Kunden, die Y gutfinden, finden die Einstellung nicht. Sie kommen gar nicht auf die Idee, dass es eine Einstellung dafür geben könnte.
Also rufen sie bei unserer Hotline an und sagen "wäre schön, wenn das Programm an der Stelle nicht X machen würde, sondern Y" (kommt euch dieser Satz bekannt vor?). Die Hotline kann dann nur sagen "Wieso, geht doch. Müssen Sie nur Einstellen. Steht doch im Handbuch...". Und das kommt dann 20x vor und blockiert die Ressourcen der Hotline für "richtige" Probleme. Und das ist noch der bessere Fall. Ich behaupte, 80% der User ärgern sich einfach über die Software, weil sie X macht und nicht Y. Manchmal sprechen uns die Kunden dann z.B. auf Messen an. Man fragt, wie sie so zufrieden sind. Und erst dann kommen sie damit raus "wäre schön, wenn das Programm an der Stelle nicht X machen würde, sondern Y".
Hat zur Folge, dass sich der Kunde unnötig über das Programm geärgert hat. Fraglich ist, ob man das hätte verhindern können.

Bin auf die folgende Diskussion gespannt. Wie kann man ein Programm mit vielen Funktionen/Einstellungen aussstatten, und trotzdem übersichtlich halten?

Die Optionen mit sinnvollen Defaults vorbelegen, diese in einer Datenbank in einer Bausmtruktur verwaltbatr machen und die Datenbank kundenspezifisch filtern?

Im Prinzip keine schlechte Idee.
Sinnvolle Defaults sind eigentlich selbstverständlich. Wenn man eine neue Funktion man, wo es Einstellungsmöglichkeiten gibt, sind die Default sinnvoll zu wählen.
Wenn man aber eine Einstellung für eine bestehende Funktion einführt, dann wählen wir die Default grundsätzlich so, dass sich das Programm so verhält wie vorher. Sonst würden die Kunden Amok laufen, wenn die Software plötzlich nicht mehr das macht, was sie vor dem Update gemacht hat.
Kundenspezifisch filtern: das ist in der Tat eine Idee, worüber ich mal nachdenken kann. Allerdings haben wir > 200 Kunden, da kann man nicht für jeden Kunden den Individuellen Einstellungesdialog zusammensetzen. Aber wir haben noch ein paar andere Kriterien, nach denen man sowas vielleicht filtern könnte.
Ist auf jeden Fall eine gute Idee.

Jens

Also, zur Verwaltung und Pflege der Optionseinstellungen will ich erstmal keine aussage machen. Aber das von Nersgatt geschilderte Problem, das der Kunde gar nicht weiss, das es die Einstellung gibt, erschlage ich z.b. durch die Hilfe.
Mal ein ganz einfacher Beispielfall:
Kundenstamm, Kundenname speichern (normalerweise speichern wie geschrieben)
Option in Einstellungen : 'Kundenname in Großbuchstaben speichern'

In der Hilfe steht dann z.b.:

Kundenname:
Der hier eingegebene Name wird in der DB als Kundenname gespeichert.
Hinweis: Wenn in den <Systemparameter\Kunden> die Einstellung 'Kundenname in Großbuchstaben speichern' aktiviert wurde, wird der eingegebene Name unabhängig von der Schreibweise in Großbuchstaben in der DB gespeichert.

Das ist natürlich beim Schreiben der Hilfe etwas aufwändiger, aber damit kann ich dem Kunden dann wirklich sagen: RTFM

die von dir geschilderte Problematik kenne ich auch gut. Natürlich kann man sich Gedanken zu machen, ob man durch bestimmte Controls die Übersichtlichkeit erhöhen kann (wie von Bummi vorgeschlagen). Meiner Erfahrung nach gibt es aber genügend "resistente" Benutzer, die auch dann bei der Hotline anrufen. Lieblingsspruch: "Aber ich bin doch nur Anwender, von solchem Computerkrams verstehe ich nichts".

Die zweite Möglichkeit stellt eine gute Dokumentation dar, aber auch hier wird man häufig den Spruch hören, dass die arbeitende Bevölkerung (im IT Bereich gehört man wohl nicht dazu) keine Zeit hat, um irgendwelche Handbücher anzusehen.

Von daher ist meine Antwort: Einstellungen so gut wie möglich themenbezogen zusammenfassen, damit die interessierten Nutzer sie finden können, gff. auch an verschiedenen Stellen einen Zugriff darauf einbauen, im Handbuch dokumentieren und generell prüfen, wenn sich Anfragen zu einem Programmteil häufen. Vielleicht helfen auch Newsletter, die interessante Änderungen an die Kunden kommunizieren. Bei den restlichen dreivierteln deiner Kunden, muss man wohl damit leben, dass sie lieber anrufen...

Viele Grüße
Sybok.

@zuma: Das setzt aber vorraus, dass die User die Hilfe auch lesen. Machen sie aber nicht. Wir haben bei unserer Software die Onlinehilfe sogar wieder rausgeworfen, weil sie niemand gelesen hat. Sie hat uns mehr Zeit an Pflege gekostet, als das es etwas bringen würde.
Es gibt natürlich ein Handbuch, in dem ist jede Einstellung haarklein beschrieben. Und entgegen dem allgemeinen Trend liefern wir unser Handbuch noch in gedruckter Form als gebundenes Buch aus. Die Kunden können es also sogar immer auf dem Tisch liegen haben.
Und wenn man dann wirklich mal RTFM sagt (eine unsere Damen kann das guuut, die ist eiskalt ), dann sind die Kunden beleidigt.

Dazu fällt mir etwas ein, was eine Hotlinedame mal erzählte. Gespräch mit dem Kunden "wie mach ich x?" Antwort der Hotline "Steht im Handbuch in Kapitel 0815 schrittweise erklärt. Arbeiten Sie das bitte durch. Wenn Sie dann noch Fragen haben, rufen Sie wieder an". Antwort vom Kunden: "Das Handbuch hab ich weggeschmissen, können Sie mir das nochmal zuschicken"

Von Newslettern halte ich persönlich nicht viel. Wir versenden zwar welche, ich glaub aber nicht, dass die wirklich gelesen werden.

Beim EdgeMonkey halte ich es mit Martok in der Regel so, dass eigentlich jede Option auf einer passenden Seite in den Settings abgelegt ist. Alle Settings liegen zentral und nur wo nötig gibt es bei den Funktionen selber noch einmal eine Möglichkeit zur Einflussnahme, z.B. durch APEX und EX.

Patch, die bestehendes Verhalten ändern, ohne die Möglichkeit für Anpassungen zu geben, werden oft nicht übernommen oder vorher um diese ergänzt.

Der beste Fall ist immer, wenn der Benutzer gar nicht merkt, dass er Grad ein Programm konfiguriert.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

es geht ja nicht nur im die Konfiguration. Auch um Funktionen die nicht offensichtlich sind.
Um mal beim Affen zu bleiben. Wenn man ihn installiert, sieht man sofort, dass man in der SB die Pfeilbuttons hat. Man klick drauf und "aha, man kann blättern".
Aber auf Funktionen, dass man z.B. mit @Benutzername direkt auf das Profil linken kann, kommt man nicht. Man muss es wissen (woher?). Oder /me ist auch so eine nicht offensichtliche Funktion. Wie macht man sowas intuitiv bedienbar?

Beide genannten Funktionen sind Konventionen aus anderen Programmen: @ stammt von Twitter und das /me aus IRC. Hier gilt es, dem Benutzer durch Analogien mit anderen Systemen zu leiten, bzw. Elemente anderer Software aufzugreifen, die der Nutzer gewohnt ist.

In Bezug auf das Oberflächen-Design ist der Affe aber nicht zwingend ein Vorbild, da große Bereiche einfach zusammen gehackt sind; aber dennoch ist er Bediener, als manche App unter Freeware hier im Forum.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Moin,

Was mal eine Konstruktive Maßnahme wäre, wäre, statt dieser sinnbefreiten Changelocks mit irgendwelchen Zahlen in grauenhaftem Format endlich mal ein Paar kurze, knackige Anleitungen und Tipps, die man gerne liest (KEIN stayonTop "Wussten Sie Schon?") z.B. in Form eines Interaktiven Tutorials innerhalb des Programms oder mindestens eines Videos. Aber das ist wahrscheinlich für die meisten Entwickler eine zu viel Arbeitsaufwand.

Bezüglich komplizierter Einstellungen kann ich nur, wie immer, auf HelgeLanges MAF-Components hinweisen.

LG

Also, das mit 'Hilfe nicht lesen' oder 'Handbuch? liegt im Kamin..' kenn ich auch. Irgendwann kommt natürlich immer der Punkt, wo man dem User dann nicht mehr helfen kann, wenn der so unwillig ist.

Newsletter find ich auch doof, die wandern nämlich meist auch ungelesen in den Papierkorb.

Eine weitere Variante ist ein Changelog. Wir z.B. führen eh ne ToDo-Liste, in der alle Änderungen/Erweiterungen gelistet werden. Wenn ich dort einen punkt abarbeite, schreibe ich unter den Eintrag eine kurze Info (wer, wann, Versionsstand, Besonderheiten(z.b. neuer Schalter), etc), damit ein Kollege von mir dann ne Art Kurztext fürs changelog hat (Ausliefern/installieren/einweisen macht eine bestimmte Person, nicht alle hier im Haus). Das changelog wird dann bei jedem Programmupdate ebenfalls an den Kunden gesandt (derzeit noch per mail, in zukunft kann man das im Programm aufrufen).
Damit ist zumindest teilweise die Nachfragerei etwas weniger geworden. Aber ganz lässt sich das Problem eh nie lösen, da einige Kunden lieber zum tel. greifen als sich was zu merken bzw. nachzugucken.

Nersgatt hat folgendes geschrieben :

Aber auf Funktionen, dass man z.B. mit @Benutzername direkt auf das Profil linken kann, kommt man nicht. Man muss es wissen (woher?). Oder /me ist auch so eine nicht offensichtliche Funktion. Wie macht man sowas intuitiv bedienbar?

Wie BenBE sagte, das stammt aus Twitter bzw. IRC. Dabei folgt das ganze so ungefähr dem Ansatz, den User da abzuholen wo er ist - ihm also Funktionen zu bieten, wie er sie kennt. An der Stelle geht das sogar soweit, dass die @-Convention in der SB schon vor dem EM da war und aktiv genutzt wurde. Ich habe die dann nur aufgehübscht, mit anderen Worten eine Krücke ("selber denken") ersetzt durch eine identische, aber komfortablere Variante.
Das gilt natürlich für so grundlegende Sachen wie "OK&Abbrechen"-Buttons immer unten zu platzieren. Aber auch kompliziertere Vorgänge kann man teilweise gut in Analogien verpacken. Zum Beispiel sollte "Kunde Anlegen" irgendwo in der Nähe von "Kundenstamm bearbeiten" liegen, und das Formular möglichst ähnlich aussehen (wenn nicht identisch sein). Sowas halt.

Und zur Menge der Einstellungen: siehe meine Signatur

Was sich aber auch gut macht: nur Einstellungen anzeigen, die im aktuellen Kontext Sinn machen ODER dranschreiben, warum bestimmt keine Auswirkung haben könnten. So kann man Fälle umgehen, wenn Settings miteinander in Konflikt stehen, und sich der User wundert "ich hab das doch angeschaltet, warum tut sich nix". Sanity Checks also.
Grade wenn sich verschiedene Teile der Applikation weit voneinander entfernen (z.B. Lohnbuchhaltung vs Lagerhaltung an einer SAP-artigen Alles-Anwendung), macht es auch Sinn separate Einstiegsmöglichkeiten in die Einstellungen zu bieten, die gleich auf die für den aktuellen Kontext relevanten Seite springen oder ähnliches.

Aber gegen das 200-Forms-Problem habe ich auch nix

Vielleicht wäre es mölglich, viele dieser Fragen dadurch zu erschlagen, dass man die "Options-Tabs" um ein Tab "FAQ" erweitert, in dem die am häufigsten abgefragten Optionen aufgelistet sind. Vielleicht werden dann die Hotline-Anfragen weniger. Ein direkter Zugriff über das Hauptmenu auf diese Optionsseite wäre dann sicher sinnvoll.

Aber ich gebe Euch Recht, jedem kan man es nicht Recht machen, denn ich kann mir bei größeren Programmen und vielen Usern vorstellen, dass sich die eine oder andere Option gegenseitig ausschließen würde.

Hallo,

ich denke wenn du dein Programm wirklich Optimal gestalten willst, ist das eine Verlagerung des Großteils der Arbeit. Die Zeit die deine Supporter weniger erklähren müssen müssen deine Programmierer anstelle dessen in die Entwicklung stecken, wenn du eine wirklich anständige Lösung haben möchtest. Und einige Benutzer sind einfach nicht willens, selbst eine Lösung zu suchen, die werden immer den Support anrufen. Das heißt aber nicht, dass man sich gar nicht anstrengen sollte. Daher hier einige Punkte (teilweise wurden sie schon genannt) die ich für Sinnvoll halte:

• Ein gut Strukturierter Konfigurationsdialog:
  Bei Optionen ist es wichtig, dass der User die entsprechende Einstellung schnell findet. Daher sollte alles in einem möglichst übersichtlichen und Logisch strukturierten Dialog stecken. Was ich immer mal wieder sehe, dass es mehrere Dialoge für verschiedene Einstellungen gibt halte ich für kontraproduktiv. Was man meiner Meinung nach auch tunlichst unterlassen sollte ist die Verwendung von PageControls auf der Hauptgruppenebene. Spätestens wenn die Tabs mehrzeilig werden steigt da niemand mehr durch, der Durchschnitsuser ist schlicht überfordert, wenn eine Tabreihe auf einmal von der hinteren auf die vordere Ebene verschoben wird. Daher preferiere ich Optionsdialoge die Links ein Navigationselement, z. B. einen Baum oder eine Outlook-Bar enthalten und dann Rechts die Einstellungen Anbieten. So kann man dann auch leicht Untergruppen in den Einstellungsebenen bilden, welche den Nutzer das suchen nach dem richtigen Punkt erleichtern.
  Wichtig ist hier auch, das der Dialog nicht erschreckt. Er sollte (auch wenn es vielleicht albern klingt) "freundlich" gestaltet sein. Bei einem links/rechts Geteilten Dialog wie ich ihn beschreibe heißt das insbesondere, das im Linken Bereich (gerne große) freundliche und sinnvolle Icons verwendet werden, damit der User nicht von dem "vielen Text" erschreckt wird und das auf der Rechten Seite nicht zu viele Optionen auf einem Blick zu sehen sind. Zeige deinem User niemals 25 Checkboxen auf einmal, das überfordert ihn und er wird den Dialog sofort erschrocken schließen. Verteile die Boxen lieber über 4 Seiten, damit er bei jeder Seite immer den Eindruck behält das ganze auch beherrschen zu können.
  
• Ein sinnvoller Einrichtungsassistent:
  Wenn eine Anwendung entsprechend Komplex geworden ist, sollte es einen guten Einrichtungsassistenten geben. Gut heißt hierbei nicht, dass über diesen schon alles einzustellen ist, sondern dass er dem Programm die Entscheidung ermöglicht, welches Set an Default Einstellungen für diesen Kunden das Geeignetste ist und eventuell auch, ob du komplette Programm und Einstellungsbereiche ausblenden kannst.
  Angenommen du hast eine Anwendung, die Kann Kunden Verwalten, Rechnungen Schreiben, Automatische Mahnungen erzeugen, Bestellungen aus dem eigenen Webshop abrufen und eben solche aus eBay übernehmen. Dann werden wahrscheinlich 90% deiner Kunden nicht alle Funktionen nutzen. Klar Rechnungen und Kundenverwaltung brauchen alle User, aber der Einrichtungsassistent sollte den Kunden Fragen:
  
  • Wollen sie, dass $Programmname automatisch Mahnungen erstellt, wenn eine Zahlung ausbleibt?
    
  • Beabsichtigen sie Bestellungen aus Ihrem Webshop ab zu rufen?
    
  • Verkaufen Sie Wahren über das Aktionshaus eBay und möchten Sie diese mit $Programmname entgegennehmen?
  
  Jedes mal wenn ein user auf eine diese Fragen mit nein Antwortet, kannst du nicht nur ein paar Schritte im Einrichtungsassistenten überspringen, du kannst auch die Entsprechenden Punkte im Konfigurationsdialog ausblenden und sogar in deinen Programmmenüs. Dein Programm wirkt dadurch nämlich übersichtlicher und der Nutzer wird die Funktionen, die er wirklich nutzen möchte schneller Finden und somit zufriedener mit der Anwendung sein.
  Natürlich darfst du in einem solchen Fall nicht vergessen eine Möglichkeit in den Einstellungen zu schaffen, die deaktivierten Programmbereiche wieder zu aktivieren, Fall dein Kunde doch irgendwann einen Webshop betreiben möchte .
  
• Auf die Einstellmöglichkeiten hinweisen:
  Wie du ja festgestellt hast, ist es nicht nur wichtig, dass etwas einstellbar ist, der Kunde muss es auch merken. Daher solltest du wichtige Einstellungen Bewerben. Das bekannteste Konzept ist hier sicher der (ewig nervende) "wusten Sie schon..."-Dialog, je nach Anwendung kann man aber auch einen Permanenten Info Bereich anzeigen, der Kontextbezogen Hilfe und Hinweise gibt. Ich habe auch schon gesehen das es neben den Hilfe Menü ein "Wie kann ich..." Menü gibt, welches ebenfalls kontextbezogen einige Tips (FAQs) listet. Und mit "Wie kann ich..."->"...Bestellungen aus meinen Webshop abrechnen", welches mir angeboten wird wenn ich am Rechnungen schreiben bin, erfahre ich dann, dass ich eventuell erst einmal das Webshop Modul aktivieren sollte.
  
• Schnellzugriff auf Einstellungen:
  Je nach Anwendung kann es auch sehr sinnvoll sein Schnellzugriffe auf einen Bestimmten Einstellungsbereich zu ermöglichen. Das kann z.B. ein Form eines (dezenten) Einstellungen-Knopfes sein, welcher sich auf jedem Form immer an der gleichen Stelle findet. Drückt man auf diesen wird nicht nur der Einstellungsdialog geöffnet, sondern es wird auch gleich auf den richtigen Bereich in diesem Dialog navigiert. Wenn ich also bei schreiben von Rechnungen ein Problem habe, drücke ich erst einmal auf Einstellungen um direkt in den Rechnungseinstellungen zu landen wo ich ja vielleicht eine Option für mein Problem Finde.
  

So, dass sollen erst einmal meine Anregungen gewesen sein, was wann in welchen Zusammenhang wirklich sinnvoll ist und ob der Arbeitsaufwand den Nutzen rechtfertigt muss jeder für sich selbst entscheiden. Dabei sollte man auch nicht vergessen, dass man je nach Abrechnungsmodell mit jeder Minute die der Suporter Telefoniert um eine banale Frage zu beantworten Geld verdient mit der Zeit die ein Programmierer in zu ausgefeilte Hilfesysteme steckt aber nicht .

critter