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.

Das Ende des Java-Plugins

 Java, Swing, UI  Kommentare deaktiviert für Das Ende des Java-Plugins
Feb 032016
 

Ich habe mich ja schon zu Anfangszeiten dieses Blogs als Fan der Java Applet-Technologie geoutet. Daran hat sich eigentlich nichts geändert. Nach wie vor halte ich Applets für den elegantesten Weg, vernünftige Benutzeroberflächen in den Browser zu bringen und gleichzeitig problemlos mit derselben Codebasis die Freunde des FatClients zu bedienen. Kluge Menschen haben behauptet, die Idee, GUIs in den Browser zu bringen, hätte die Qualität von Benutzeroberflächen 20 Jahre zurückgeworfen. Inzwischen dürften es wohl eher 25 Jahre sein, denn die Qualität von gängigen Oberflächen der 90er, sei es RISC OS oder MacOS oder die diversen GEM-Varianten, ist bis heute nicht erreicht. Optisch vielleicht schon, aber ergonomisch und performancetechnisch auf keinen Fall.

Nun hat Oracle verkündet (und schon vorher anklingen lassen, siehe etwa hier), man werde das Java-Plugin, das für die Ausführung von Applets im Browser zuständig ist, mit Java 9 als „deprecated“ erklären und es in einer späteren Version aus Java entfernen. Als Grund wird genannt, dass mobile Browser ja noch nie Plugins unterstützt hätten und diverse Browser entweder die Plugin-Unterstützung schon entfernt hätten (Chrome), dies vorhätten (Firefox) oder noch nie eine gehabt hätten (MS Edge). Dazu die Security-Problematik.

So weit, so traurig. Insbesondere den Security-Aspekt konnte ich noch nie nachvollziehen – man kann das Java-Plugin ja so konfigurieren, dass es nur Applets mit bestimmter Signatur überhaupt ausführt, insofern ist diese Technologie wohl kaum unsicherer als die Ausführung beliebigen anderen Codes auf der Maschine. Dass es ab und zu in der Sandbox (auch klaffende) Security-Lücken gab, ist ja kaum ein Alleinstellungsmerkmal von Plugins – auch die Browser selbst sind ja wandelnde Sicherheitslöcher, selbst bei so simplen Dingen wie Grafikdecodierung. Das hat man halt davon, wenn man in Pseudo-Hochsprachen wie C entwickelt. Aber ich schweife ab.

Letztlich ist das alles „water under the bridge“, und man sollte nach vorne schauen. Dazu sollte man zunächst herausfinden, in welchem Zeitrahmen man nun Abschied von den Applets nehmen muss.

Entscheidend dafür ist zunächst der verwendete Browser. Bei IE11 kann man sich noch etwas Zeit lassen – Januar 2023 endet der Support von Microsoft für den IE11, zumindest unter Windows 8. Bei Firefox muss man sich schon eher sputen, Ende 2016 dürfte es vorbei sein. Es gibt aber durchaus noch Browser, die die NSAPI für Plugins unterstützen und noch nicht abgekündigt haben – Konqueror, QupZilla oder Midori (allesamt WebKit-basiert). Wie lange das anhält, wird man sehen – nicht so weit verbreitete Browser folgen ja häufig mit kurzer Ankündigungsfrist dem Mainstream und bieten selten lange Support-Garantien.

Wie sieht es auf der Java-Seite aus? September 2017 endet voraussichtlich die Verfügbarkeit öffentlicher Java 8-Updates, basierend auf dem Oracle-Releasezyklus wird das Ende der öffentlichen Java 9-Updates also frühestens September 2019 sein. Danach kann man Oracle etwas Geld in den Rachen werfen, um weiterhin Java 9-Updates zu bekommen. Bis heute unterstützt Oracle ja gegen Einwurf kleiner Münzen sogar Java 5. Wer es also aussitzen will bis zuletzt, muss sich vermutlich bis zum Ende von IE11 (frühestens 2023 laut Microsoft) keine Sorgen machen.

Executive Summary: Don’t Panic.

Beknackte Oberflächen – heute: Outlook 2010 EMail-Export

 Software, UI  Kommentare deaktiviert für Beknackte Oberflächen – heute: Outlook 2010 EMail-Export
Jul 112015
 

Ich fürchte, die heute begonnene Serie „Beknackte Oberflächen“ könnte ein Dauerbrenner werden. Es gibt weniges, was mich so nervt wie beknackte, unintuitive Benutzungsoberflächen. Es nervt deutlich mehr als hässliche, aber wenigstens funktionale Oberflächen.

Microsoft musste ja viel Kritik einstecken für die Einführung des „Ribbon“-Konzepts. Und das völlig zu Recht. Heute noch frage ich mich, was denn der große Vorteil dieses Konzepts sein soll, und warum es nicht wenigstens möglich war, beide Konzepte parallel zu integrieren – denn letztlich wird ja auch jede Ribbon-Aktion entweder direkt ausgeführt (so wie bei der guten alten Toolbar) oder öffnet irgendwann denselben schäbigen Dialog wie früher.

Es geht ja das Gerücht, dass Microsoft Legionen an UI-Experten beschäftigt und ständig Versuchspersonen befragt zur Benutzbarkeit ihrer Oberflächen. Keine Ahnung, wo diese Experten waren, als ein Programmierer die Aufgabe bekam, in Outlook 2010 die Funktionalität „EMail exportieren“ einzubauen.

Die Ausgangssituation: ich hatte diverse zu exportierende EMails in einer Folder-Struktur gesammelt und wollte nun diesen Folder exportieren und war schon gespannt, welche Formate mir wohl Outlook anbieten würde – Microsoft ist ja auch bekannt dafür, Industriestandards – wenn sie nicht von Microsoft selbst erfunden wurden – entweder nicht oder unvollständig oder fehlerhaft zu unterstützen.

Es stellte sich aber heraus, dass das Export-Format gar nicht das Problem ist, denn die Frage war zunächst: wie funktioniert der Export denn überhaupt? Intuitiv wäre gewesen, den Export über das Kontextmenü erreichbar zu machen – aber da geht nur, über „Eigenschaften“ über den Reiter „AutoArchivierung“ zu archivieren – aber ich wollte ja jetzt exportieren und nicht irgendwann archivieren. Vielleicht direktes Drag&Drop des Folders ins Dateisystem? Nein, da empfängt mich das Verbotsschild. Also mal im „Datei“-Ribbon nachgeschaut, ob es da „Export“ oder „Speichern“ oder sowas gibt. Gibt es nicht. Jetzt war ich doch einigermaßen ratlos und bin die anderen Ribbons durchgegangen. Nix zu sehen. Die Symbolleiste für den Schnellzugriff inspiziert. Geschaut, ob es dort in den „Weiteren Befehlen“ vielleicht irgendeine Export-Aktion gibt. Wieder nix.

OK, dann mal in den „Optionen“ nachschauen, ob man dort irgendwo was aktivieren kann. Dann die Überraschung: Unter „Erweitert“ gibt es tatsächlich einen Bereich „Exportieren“ nebst zugehörigem Button. Drückt man diesen, gibt es noch eine Überraschung: ein Dialog öffnet sich, der eine Auswahl von 9 Aktionen anbietet. 9 Export-Aktionen? Nein, natürlich nicht. 7 davon sind Import-Aktionen. Ah ja. Immerhin: die anderen Dinge unter „Optionen -> Erweitert“ scheinen wirklich Optionen zu sein und keine gut versteckte Funktionalität. Es ist also noch nicht alles verloren.

XYplorer – ein Dateimanager für Windows

 Software, UI  Kommentare deaktiviert für XYplorer – ein Dateimanager für Windows
Nov 292014
 

Die meiste Zeit benutze ich Rechner, die unter Windows laufen. Momentan Windows 7 in der Mehrzahl der Fälle. Ganz freiwillig ist das nicht. Am liebsten würde ich RISC OS nutzen, aber das hat inzwischen nur noch wenig Software verfügbar, die ich für die tägliche Arbeit brauche – Java, eine IDE, ein Browser, alles Mangelware unter RISC OS. Linux nutze ich nur für Spezialaufgaben (aktuell ps3mediaserver, CVS-Server, git-Server, NFS-Server).

Egal welches Betriebssystem man nutzt – eine zentrale Aufgabe ist immer die Navigation im und die Organisation des Dateisystems. Erstaunlich, dass Windows dort seit Version 3.0 mit ziemlich schlechter Software ausgerüstet ist. Der Dateimanager machte den Anfang, später dann der Explorer. Bis heute nicht gerade die Spitze was Leistungsfähigkeit und Ergonomie angeht. Die Änderungen zwischen XP und 7 sind auch eher Verschlimmbesserungen.

Ich habe diverse „Commander-ähnliche“ Dateimanager ausprobiert, vom TotalCommander bis zum muCommander. Ich konnte mich nie daran gewöhnen. Eventuell ist das meiner RISC OS-Vergangenheit geschuldet – den RISC OS-Filer halte ich bis heute für das ergonomischste Werkzeug für Dateisystemoperationen. Der Filer ist von derartig eleganter Schlichtheit, dass man den Erfindern täglich auf Knien huldigen will. Unter Linux gibt es den ROX-Filer, entwickelt von einem ehemaligen RISC OS-Benutzer – trotzdem fühlt er sich nicht wie das Original an. Komisch, soll aber nicht das Thema sein.

Letztlich habe ich unter Windows immer mit dem normalen Explorer gearbeitet, in Ermangelung an (mir bekannten) Alternativen. Die Wende kam heute: ich las mal wieder einen der berühmten „die x wichtigsten Freeware-Tools“-Artikel, diesmal in der Geschmacksrichtung „The Register“. Wie so oft waren die Kommentare interessanter als der Artikel, und einer der Kommentatoren nannte ein Tool namens XYplorer als unverzichtbares Werkzeug. Heruntergeladen, auf die Platte extrahiert (ja, es gibt eine „mobile“-Version, die nicht installiert werden muss), gestartet – und sofort gesehen, dass dieses Tool genau das richtige für mich ist.

Highlight-Features aus meiner Sicht – neben der Basisidee der multiplen Tabs – sind der Mini Tree und die „Mouse Down Blow Up“-Funktion. Das lässt sich mit Worten ganz schwer beschreiben, das muss man selbst ausprobieren, oder hier nachlesen. Auch die Such- und Filterfunktionen sehen sehr vielversprechend aus.

Schwächen? Die Internationalisierung scheint nicht vollständig, die deutschen Texte sind immer mal wieder von englischen Einsprengseln unterbrochen, vor allem in den Menüs.

Also: die kostenlose Version herunterladen und ausgiebig testen. Bin gespannt, wie lange meine Euphorie anhält.

Ein Hoch auf die Applet-Technologie

 Java, UI  Kommentare deaktiviert für Ein Hoch auf die Applet-Technologie
Sep 092014
 

Java-Applets waren mal hip. Zu einer Zeit, als das Wort hip noch nicht hip war. Als noch nicht mal Netscape der Browser der Wahl war, sondern gerade HotJava sich anschickte, Mosaic abzulösen.

Seit geraumer Zeit verfolgt die Applet-Technologie jedoch ein schlechter Ruf. Breit publizierte Sicherheitslücken im Java-Plugin, die teilweise fragwürdigen Entscheidungen von Sun und Oracle in punkto Weiterentwicklung, und durchaus auch schlechte Qualität der Plugins in den Anfangsjahren. Inzwischen scheint der allgemeine Konsens zu sein, dass Java eigentlich auf den Server gehört. Maximal ist noch ein FatClient akzeptabel. Aber Applet? Tote Technologie. Wenn Browser-Oberfläche, dann HTML-basiert. Mit Frameworks wie GWT, Vaadin, ZK, Wicket. Oder node.js, AngularJS, jQuery. Auch die ehemals hippen Technologien wie Flash, Silverlight oder Flex sind totgesagt.

Zweifellos gibt es valide Anwendungen für pure Browser-Oberflächen. Google Maps oder Gmail zeigen das eindrucksvoll. Und doch sind die Anwendungen meist nur ein Schatten von „echten“ Anwendungen. Word im Browser? Noch nie gescheit gesehen. VisualStudio oder Eclipse im Browser? Wer mal JazzHub probiert hat – wenn sich mal jemand den Spaß am Coden verleiden will, ist das ein probates Mittel.

Doch wenn ich heute eine einigermaßen komplexe Anwendung mit graphischer Oberfläche entwickeln muss, wäre meine erste Wahl immer noch Java mit Swing als Oberflächentechnologie. Erstens ist man flexibel, was das Einsatzszenario angeht – egal ob Anwendung standalone oder als Applet im Browser. Dazu weitgehende Unabhängigkeit vom Betriebssystem und anständige Performance. Für die Entwicklung kann man das leistungsfähige Java-Tooling verwenden. Dazu die Unmengen an Librarys des Java-Ökosystems.

Durch die Flexibilität des Look&Feels von Swing (oder natürlich das neumodische CSS für JavaFX für die, die näher am Hype sein wollen) kann man eine sehr gute Integration in vorhandene Webanwendungen erreichen. Und mit der entsprechenden Konfiguration des Plugins, nur signierte Applets aus vertrauenswürdiger Quelle auszuführen, ist die Security-Problematik ebenfalls stark entschärft.

Bleibt der Nachteil, dass ein Plugin installiert werden muss und der Browser allein nicht ausreicht. Aber ist das ein größeres Problem als die Cross-Browser-Kompatibilität?