Beknackte Oberflächen – heute: Windows-Explorer

 UI  Kommentare deaktiviert für Beknackte Oberflächen – heute: Windows-Explorer
Mrz 252016
 

Gerade kopierte ich eine größere Menge Daten zwischen verschiedenen Platten hin- und her. Wider besseren Wissens per Standard-Explorer (Windows 7). Da erreicht mich folgende Fehlermeldung: „Zielpfad ist zu lang. Die Dateinamen wären zu lang für den Zielordner. Kürzen Sie die Dateinamen und wiederholen Sie den Vorgang, oder verwenden Sie eine anderen Ort, der einen kürzeren Pfad hat.“

OK, danke für die Info. Den kleinen Grammatikfehler finde ich für den Multi-Milliarden-Konzern Microsoft zwar peinlich, aber halb so schlimm. Auch schlimm, aber auch nicht Thema: die Tatsache, dass im 21. Jahrhundert die Pfadnamenlänge überhaupt noch eine Rolle spielt. Nein, das Problem ist vielmehr der gravierende Mangel an Information. Welche Dateinamen? Welcher Zielordner? Wenn ich den „Vorgang“ wiederholen soll, wäre das doch schön zu wissen. Im Dialog wird ein Name partiell angezeigt (ist es der Zielpfadname? Ein Dateiname? Oder das Quellverzeichnis?), leider nur die ersten 44 Zeichen, danach folgen die beliebten drei Punkte. Gut, dass der Fehlerdialog nicht vergrößerbar ist, um den Namen ganz anzeigen zu können – konnte ja keiner ahnen, dass bei einer Meldung bezüglich zu großer Länge von Datei-/Pfadnamen tatsächlich lange Namen angezeigt werden müssen. Und die Größe von Dialogen scheint ja weiterhin dem „Benutzer hat maximal 640×480“-Paradigma zu folgen. Wer hat sich nicht schon über den Dialog geärgert, wo man die Systemvariablen setzt. Scrollbars als Notlösung scheinen auch aus der Mode gekommen zu sein. Selbst ein Tooltipp mit dem vollen Namen wäre zur Not akzeptabel.

Ganz schlecht, liebe Freunde von Microsoft. Der Grundsatz des „information hiding“ sollte bei der Programmierung realisiert werden, nicht bei der Benutzerinformation.

Beknackte Oberflächen – heute: WinZip

 Software, UI  Kommentare deaktiviert für Beknackte Oberflächen – heute: WinZip
Mrz 202016
 

Nein, es soll nicht darum gehen, dass der einzig wahre Weg, Archive zu behandeln, die Idee des „Image Filing System“ unter RISC OS ist, und nach wie vor SparkFS von David Pilling die ultimative Implementierung dieser Idee ist. Warum unter Windows bis heute nichts annähernd vergleichbares existiert, ist eines der großen Mysterien der Weltgeschichte. Naja, dort hält man ja teilweise auch den Explorer noch für eine gute Idee.

Also, was nervt mich heute darüber hinaus an WinZip? Das unglaublich schlechte Fehlerhandling. Ich archiviere ein Verzeichnis mit ein paar tausend Dateien. Am Ende des Vorgangs informiert mich WinZip mit folgender alarmierender Meldung: „Es sind Fehler aufgetreten. Möchten Sie die WinZip-Protokolldatei aufrufen?“ Fehler? Natürlich will man wissen, was schiefgegangen ist. Also die Protokolldatei öffnen (keine Ahnung, welcher Schwachspieler hier „aufrufen“ übersetzt hat). Aber was bekommt man zu sehen? Nicht etwa eine Liste der aufgetretenen Fehler. Nein, eine Liste aller Vorgänge. Wie das Hinzufügen einer Datei zum Archiv. Und wie findet man jetzt die Fehler? Leider gibt es überhaupt keinen Hinweis, durch welchen Text so ein Fehler benannt werden könnte. Doch es kommt noch besser: oft sind gar keine Fehler im Protokoll zu finden, sondern lediglich Warnungen.

Fassen wir zusammen: Irreführende Fehlermeldung, gut versteckte Informationen – ein würdiger Kandidat für den Preis der „Beknackten Oberfläche“. Ergonomiewertung: 0%.

In meinem Falle ist der Grund für Warnungen übrigens meistens, das Dateien mit Datestamps früher als dem 1.1.1980 (das früheste Datum, das im ZIP-Format darstellbar ist) archiviert werden. Da fragt man sich doch direkt, was sich Phil Katz damals gedacht hat. Leider können wir ihn nicht mehr fragen.