Usability als Prozess in Theorie und Praxis
Friday, 26. March 2021
Ich habe hier jetzt viel über Usability geschrieben und wer mir folgte weiß jetzt so einiges. Wir wissen, was Usability ist, können Usability von UX unterscheiden und haben Beispiele für diese Prinzipien anhand von Alltagsbeispielen gesehen. Vor einer Weile schrieb ich sogar schon über typische konkrete Hürden bei der Softwarenutzung. Aber wenn ich jetzt eine neue Anwendung bauen will, wie beachte ich dann dieses ganze Wissen und erbaue die Anwendung mit guter Usability? Die Antwort: Indem im wie auch immer gearteten Entwicklungsprozess Usability explizit berücksichtigt wird.
Eine Prozessblaupause
Es geht dabei ausdrücklich nicht darum, einen bestimmten Entwicklungsprozess vorzuschreiben. Es ist egal, ob das Wasserfall, Scrum, agile Entwicklung oder eine Mischform ist. Es gibt nur zwei Kernbedingungen, die meist hinzugefügt werden müssen: Die Nutzungsanforderungen müssen möglichst früh erhoben und die Usability der Software muss mit echten Zielgruppennutzern getestet werden.
In irgendeiner Form sollte dabei dieser modisch als Kreislauf gezeichnete Prozess abgebildet werden:
Den Kreislauf als Teil des eigentlichen Prozesses beginnt man möglichst früh und hört erst auf, wenn die Lösung sich in einer Evaluation bewährt hat. Für jeden dieser Schritte gibt es eine Menge an Werkzeugen, die üblichsten liste ich hier auf:
1. Nutzungskontext erheben
Wir erinnern uns: Den Nutzungskontext brauchen wir, weil wir Usability immer im Kontext einer bestimmten Nutzung für eine bestimmte Aufgabenerledigung betrachten. Ohne den Kontext können wir ins Blaue designen und testen, reduzieren damit aber eben erheblich die Chance für die Zielnutzung eine gute Lösung zu finden. Um den Kontext zu erheben greife ich üblicherweise auf Nutzerinterviews zurück. Was auch gehen könnte: Beobachtungen. Die sind aber meist schwer umzusetzen. Fokusgruppen wären auch denkbar, verleiten aber dazu, die tatsächliche Nutzungspraxis in der Diskussion durch Gruppendynamiken zu verdecken.
Bei Interviews ist es dann noch wichtig, tatsächlich mit Nutzern zu reden und nicht mit Leuten, die über Nutzer sprechen. Lass dir von ihnen ihre tatsächliche Praxis beschreiben. Aus den Interviews lassen sich dann die Nutzungsanforderungen ableiten.
2. Nutzeranforderungen spezifizieren
Wie das genau aussieht folgt aus dem vorherigen Schritt. Habe ich Interviews gewählt und transkribiert, leite ich aus diesen Texten Anforderungen ab und packe sie in ein Dokument. Oder man muss sich die Videos anschauen, oder die eigenen Beobachtungsnotizen durchforsten. Egal wie: Am Ende diesen Schrittes sollte eine Liste von Anforderungen an die Lösung stehen, die bei deren Entwurf zu berücksichtigen ist.
3. Lösung implementieren
Mit den Anforderungen in der Hand kann nun die Lösung gebaut werden. Je nachdem, in welchem Entwicklungsstand man ist und was man am Ende baut wird das völlig unterschiedlich aussehen. Bei Software starte ich eventuell mit einem Papier-Prototyp, oder einer Prototyp-Software. Später ist die Umsetzung schlicht Softwareentwicklung. Vielleicht aber stellt man mit den Anforderungen in der Hand fest, dass Software gar nicht die Lösung ist, sondern eine Prozessänderung oder ein Echtwelt-Artefakt bauen die beste Lösung wäre.
4. Lösung evaluieren
Am Ende des iterativen Prozess steht dieser allerwichtigste Schritt: Die Evaluierung der Lösung mittels Nutzungstests.
Dabei ist es völlig egal was gebaut wurde. Und selbst wenn alles andere ignoriert wurde: Echte Nutzungstests mit echten Nutzern bringen so viele Erkenntnisse, dass sie auf jeden Fall durchgeführt werden sollten. Dabei liegt die Betonung auf "echte". Es bringt nichts, mit Leuten zu testen die später die Lösung gar nicht benutzen sollen, beispielsweise anderen Softwareentwicklern eine neue Nähmaschine vorzusetzen. Es bringt genausowenig falsch zu testen, also nicht Nutzer die konkrete Aufgabenerledigung durchspielen zu lassen und dabei Probleme zu beobachten, sondern ihre Meinung zur Hintergrundfarbe der Titelleiste zu erfragen.
Nein, echte Nutzungstests spielen mit echten Zielgruppennutzern ihre Aufgabenerledigung nach. Dafür hat der Nutzer meist einen Testleitfaden, der die Aufgaben vorgibt. Der Tester sitzt daneben oder am anderen Ende der Telefonleitung und schaut mit auf den Bildschirm. Was ihn ausschließlich interessiert sind Momente, in denen der Nutzer irritiert ist oder nicht weiterkommt. Solche Critical Incidents (CIs) können immer auf die Verletzung von Dialogprinzipien zurückgeführt werden. Eine so generelle Aussage mag überraschen, aber die Prinzipien sind dafür wirklich ausreichend umfassend und aussagestark. Die CIs zu protokollieren und einzuordnen motiviert dann die nächste Iterationsrunde des Prozess. Mit besserem Verständnis des Nutzungskontexts bzw. der eigenen gebauten Lösung muss die nun angepasst werden, sodass die CIs beim nächsten Test nicht mehr auftreten.
Und wenn es keine CIs gab oder sie die Aufgabenerledigung nur unwesentlich behinderten? Dann sind wir mit der Usabilityarbeit fertig.
Der Prozess in der Praxis
Das oben beschriebene ist keine akademische Fingerübung. Es wird tatsächlich in der Praxis umgesetzt und es funktioniert wirklich. Klar: Niemand und kein Prozess kann garantieren, dass egal welche Hürden es gibt das Endergebnis super wird. Aber Usability mittels dieser Prozesselemente zu beachten vermeidet effektiv, am Ende Nutzern ein Produkt vorzusetzen, mit dem sie schlicht nichts anfangen können. Schon das richtige Testen alleine verhindert das. Denn wenn die Lösung nichts taugt, merkt man das in professionellen Nutzungstests zu 100%. Das Management darf diese Ergebnisse dann nur nicht ignorieren, aber das ist ein Thema für sich.
Praktisch läuft das so ab: Bei der Produktentwicklung gibt es immer ein Entwicklungsteam und Entwicklungsleiter. Dieses Team hat irgendeinen Prozess, mit dem es Lösungen entwirft und umsetzt. Diesem Prozess fügt man nun Usability-Experten hinzu. Man kann einen Usability-Experten als Consultant anheuern, eine Usability-Agentur beauftragen oder einen Usability-Experten einstellen – ob der dann Teil eines Designteam wird oder Teil des Entwicklerteams, gar ein vorheriges Entwicklungsteamitglied mit neuer Zusatzausbildung ist, ist erstmal egal.
Ich habe alle drei Lösungen in der Praxis erlebt. Meinem Eindruck nach funktioniert das Einbinden des Usability-Experten in das Softwareentwicklungsteam am besten, aber dafür muss man nunmal einen der seltenen Usabilityleute finden, die auch Softwareentwickler sind. Hier sollte ich erwähnen: Dieser mein Eindruck könnte daher kommen, dass ich eben selbst einer dieser Usability-Softwareentwickler bin. Die direkte Einbindung hat aber nunmal den Vorteil, dass in einer solchen Konstruktion die Usabilityexpertise sehr nah am Entwicklungsteam lebt und mühelos berücksichtigt werden kann. Wenn stattdessen eine externe Agentur die Usability-Analyse übernimmt, macht die ihre Arbeit und wirft schlimmstenfalls am Ende eine 300-seitiges Ergebnisdokument über den Zaun, von dem das Management nur die Zusammenfassung liest und das dann vom Entwicklerteamleiter im internen Wiki einer Unterseite als .doc angehängt wird, auf dass es keiner der praktischen Entwickler jemals auch nur aufmache. Aber vielleicht funktioniert es manchmal besser.
Egal welche Konstruktion es wird ist dies der Wunsch: Die Leute mit Usability-Expertise erheben den Nutzungskontext (wenn er noch nicht bekannt ist) und erstellen (oder ergänzen die bestehenden) Nutzungsanforderungen. Oberflächen und Funktionalität wird mit den Anforderungen vor Augen designt – prototypisch oder direkt in Zielform –, dann mit Nutzern getestet, schließlich wird auf die CIs reagiert. Und dann wird das wiederholt, wobei Kontexterhebung in späteren Iterationen meist übersprungen wird.
In irgendeiner Form muss das in jeden Entwicklungsprozess einzubauen sein. Am einfachsten ist es wohl bei echter agiler Entwicklung, bei dem die Entwickler zusammen mit den Designern je nach Prozessstand den nächsten Zeitabschnitt der anstehenden Aufgabe widmen. Also zum Beispiel nach der Entwicklung der ersten Alpha-Version im nächsten Wochensprint Nutzungstests durchführen, und im folgenden Sprint je nach Ergebnis entweder nochmal Designworkshops abhalten oder entdeckte Bugs wie Problemstellen in der Software reparieren.
Und das wärs. Usability mit all den dahinterstehenden Konzepten wird zu Prozesselementen, die Entwicklungsfirmen in den ihren einbauen können. Das zu tun verbessert ihre Produkte, vermeidet Kosten und hilft so der Firma. Nebenbei macht es die Entwicklung angenehmer: Bei Nutzungstests die Reaktionen der Nutzer mitzukriegen und Produkte daraufhin verbessern zu können, sodass Nutzer auf einmal mit ihnen gut zurechtkommen, ist auch für klassische Entwickler toll.
Usability im Entwicklungsprozess zu berücksichtigen ist eine wirklich gute Idee. Es ist wohl der einzige Weg, nicht einfach Glück haben zu müssen, sondern bei der Entwicklung einer neues Anwendung eine gute Usability gezielt herstellen zu können.
Xmodmap per udev aktivieren
Monday, 22. March 2021
Meine Tastatur soll mit englischem Tastaturlayout laufen. Gleichzeitig muss das nervige CapsLock deaktiviert sein. Die Taste dient dann zusammen mit dem rechten Alt dem Setzen von Umlauten. CapsLock-q steht für ä, CapsLock-y für ü und CapsLock-p für ö. Um diese Belegung umzusetzen braucht es eine Mischung aus setxkbmap
und xmodmap
:
setxkbmap -variant altgr-intl -option -option compose:rctrl -option lv3:ralt_switch -option terminate:ctrl_alt_bkspc -option eurosign:e -option nbsp:level3n xmodmap /home/onli/.Xmodmap
Wobei in der .Xmodmap nur das hier steht:
clear lock keycode 66 = ISO_Level3_Shift NoSymbol ISO_Level3_Shift
Diese Befehle sendet meine ~/.icewm/startup bei jedem Login. Aber seit ich wegen der Heimarbeit regelmäßig die Tastatur zwischen Arbeitslaptop und eigenem PC wechselte, störte es mich langsam, dass ich nach jedem Wechsel bei angeschaltetem PC die Befehle neu ausführen musste. Das müsste man doch auch ohne Desktopumgebung automatisieren könnte. Desktopumgebungen wie KDE und Gnome könnten die Tastaturbelebung dauerhaft setzen, dafür ist dort meine Zielkonfiguration mit dem deaktivierten CapsLock und den erreichbaren Umlauten trotz US-Layout gar nicht so einfach umzusetzen.
Und tatsächlich gibt es für sowas udev. Damit können bei jedem Hardwarewechsel Berechtigungen gesetzt, Namen verteilt und eben auch beliebige Befehle ausgeführt werden. Doch leider ausgerechnet diese Tastaturumstellung nicht. Die Befehle werden einfach geschluckt, als ob nach udev nochmal der XServer auf den Hardwarewechsel reagiert und die Tastatur zurücksetzt. Zum Glück bin ich dann über diesen Artikel gestolpert, der zusammen mit einem Arch-Forenbeitrag beschreibt wie hier udev doch noch eingesetzt werden kann. Der Trick: Anstatt die Befehle direkt auszuführen schreibe in eine Datei, worauf ein inotify-Watcher reagiert daraufhin und im richtigen Kontext die Befehle ausführt.
Konfiguration udev
Wir starten mit udev. Zuerst gucken wir, wie die Tastatur identifiziert werden kann:
onli@fallout:~$ lsusb Bus 003 Device 002: ID 8087:8001 Intel Corp. … Bus 002 Device 007: ID 046a:a087 Cherry GmbH Wireless Mouse Bus 002 Device 009: ID 258a:1006 SINO WEALTH USB KEYBOARD
258a:1006
ist die gesuchte Kombination. Das packen wir nun in die udev-Regel unter /etc/udev/rules.d/80-ajazzmapping.rules (der Abschnitt vor .rules kann natürlich anders benannt werden):
ACTION!="add|change", GOTO="ajazz_rules_end" ATTRS{idVendor}=="258a", ATTRS{idProduct}=="1006", RUN+="/usr/local/bin/keyboard-udev.sh" LABEL="ajazz_rules_end"
Das Skript reagiert nur auf die Aktionen add oder change des Hardwaresystems, also wenn die Tastatur angesteckt wird. Per idVendor und idProduct schränken wir die Regel weiter ein auf genau die Hardwareidentifikatoren, die wir oben lsusb
entnomment haben. Und dann soll ein Skript ausgeführt werden.
Aktion: keyboard-udev.sh
Und zwar dieses, gespeichert als /usr/local/bin/keyboard-udev.sh:
#!/bin/bash # Path to lock file lock="/tmp/keyboard.lock" # Lock the file (other atomic alternatives would be "ln" or "mkdir") exec 9>"$lock" if ! flock -n 9; then notify-send -t 5000 "Keyboard script is already running." exit 1 fi echo '' > /tmp/keyboard.lock & # The lock file will be unlocked when the script ends
Das mit dem Lock ist gar nicht so ganz simpel, aber eigentlich müssen uns die Details hier nicht weiter interessieren. Wichtig ist: Nach /tmp/keyboard.lock wird geschrieben, und darauf können wir nun reagieren.
Die Reaktion
Dafür wird bei Start des Xservers der inotify-Watcher gestartet. Dafür kommt ein Aufruf zu file-inotify.sh
in die $HOME/.xinitrc, sodass sie bei mir nun so aussieht:
/usr/local/bin/keyboardMapping.sh file-inotify.sh /tmp/keyboard.lock /usr/local/bin/keyboardMapping.sh & # Triggered by udev rule xrdb -merge -I$HOME ~/.Xresources exec dbus-run-session /usr/bin/icewm-session --notray
file-inotify.sh müssen wir noch anlegen, ich erstellte es als /usr/local/bin/file-inotify.sh:
#!/bin/bash # Usage: file-inotify <file># Command is run when file is written. path=$(realpath "$1") job="$2" #basename=$(basename "$1") dirname=$(dirname "$1") inotifywait -m -e close_write --format '%w%f' "$dirname" \ | while read file do if [[ $(realpath "$file") == "$path" ]]; then sh -c "$job" fi done
Und die /usr/local/bin/keyboardMapping.sh? Das sind einfach die Tastatursetzbefehle von oben:
#!/bin/bash echo "remapping keyboard" setxkbmap -variant altgr-intl -option -option compose:rctrl -option lv3:ralt_switch -option terminate:ctrl_alt_bkspc -option eurosign:e -option nbsp:level3n xmodmap /home/onli/.Xmodmap
Die Tastatur sitzt
Jetzt steht das ganze System. Bei Systemstart wird per xinitrc der inotify-Watcher gestartet, der auf Dateisystemaktionen reagiert. Wenn udev das Einstöpseln der Tastatur mitbekommt schreibt es in die beobachtete Datei, woraufhin das Tastaturlayout gesetzt wird. Das funktioniert verlässlich und verursacht beim Warten keine Systemlast.
Die keyboardMapping.sh und damit die setxkbmap
- und xmodmap
-Befehle nicht manuell ausführen zu müssen ist an sich nur eine Kleinigkeit. Aber das automatisiert zu haben ist eine sehr angenehme Kleinigkeit. Ich vergaß es doch immer mal wieder, tippte daraufhin Unsinn zusammen und musste das Umschalten dann nachholen. So brauch ich nicht mehr dran zu denken.
Zur Zukunft von Serendipity mit PHP 8.0
Tuesday, 16. March 2021
Uberspace hat PHP 8.0 aktivierbar gemacht. Da dort meine Entwicklungsinstallation lebt habe ich mir angeschaut, was da genau auf die Blogsoftware zukommt. PHP 8.0 ist zwar schon draußen, PHP 7.4 wird aber noch eine ganze Weile unterstützt, es eilt also nicht. Andererseits gibt es viel zu tun. Zumindest ist das meine Einschätzung.
Die inkompatiblen Änderungen von PHP 8.0
PHP 8.0 ist inkompatibel mit einigem Code, der in den letzten 20 Jahren bei Serendipity zusammengekommen ist. Vor allem diese Änderungen (von hier) machen der Software zu schaffen:
A number of notices have been converted into warnings:
Attempting to read an undefined variable.
…
Attempting to read an undefined array key.
…
Serendipity macht beides sehr, sehr oft. Und noch öfter, wenn man die Smarty-Templates hinzurechnet, die nun ebenfalls bei Zugriff auf undeklarierte Variablen solche Warnungen werfen. Werden Warnungen geworfen ist das im Zweifel im Blog sichtbar, kann generiertes HTML und CSS kaputtgehen, bei Entwicklungsversionen bricht die Ausführung ab.
Der Code schaut zum Beispiel oft, ob in $serendipity
ein gesuchter Key gesetzt ist, oder switcht sogar über diesen Wert:
switch($serendipity['POST']['adminAction']) { … }
Wenn $serendipity['POST']['adminAction']
nie gesetzt wurde, wirft das jetzt eine Warnung. Vorher war das Ergebnis einer solchen Abfrage einfach null und machte entsprechend nichts. Wir können das reparieren, mit isset
oder dem ??
-Operator:
switch($serendipity['POST']['adminAction'] ?? '') { … }
Aber will man die Warnungen nicht verstecken muss das eben durch den gesamten Code hindurch gemacht werden.
Der aktuelle Stand
Warnungen zu unterdrücken halte ich wirklich für keine gute Option. Tatsächlich wurden durch dieses neue Verhalten jetzt schon einige Bugs sichtbar, als ich die Warnungen nachverfolgend durch den Code ging. Es ist zwar unangenehm bei altem Code wie diesem – tatsächlich ist Serendipity kein toller Kandidat für die Portierung auf PHP 8 – aber die Änderungen sind grundsätzlich gut. Serendipity sollte da mitgehen.
Ich habe einen ersten Pull-Request vorbereitet. Den will ich so nicht mergen, er ist zu groß geworden, aber ich werde ihn aufsplitten (der erste Folge-PR ist hier). Mit diesen Codeänderungen kann der Blog mit Standardplugins schon wieder fehlerlos dargestellt werden, auch alle Hauptseiten im Backend werfen keine Fehler mehr. Mit etwas mehr Arbeit wird wahrscheinlich bald der Rest des Kerns wieder gehen.
Anstehende Entwicklungen und Entscheidungen
Es würde wohl in ein Serendipity 3.0 münden. Die von PHP 8.0 diktierten Änderungen werden s9y teilweise zu inkompatiblen Änderungen zwingen. Zum Beispiel bei der Redeklarierung von Konstanten, was nun ebenfalls einen Fehler wirft, aber für das Fallback bei den Sprachdateien genutzt wird.
Aber ich könnte mich täuschen. Vielleicht lassen sich solche Änderungen durch Ideen anderer Entwickler vermeiden. Vielleicht sollte man temporär an dieser Stelle doch die Fehlermeldungen unterdrücken, wo wir da doch wirklich wissen, dass davon kein Bug versteckt wird. s9y versucht ja auch sonst immer, inkompatible Änderungen zu vermeiden. Ich hoffe, die jeweilige Änderung in den PRs mit den anderen zu besprechen.
Dann bleiben aber immer noch die alten Themes und Plugins.
Bei den Themes ist es möglich, dass die genutzte Template-Engine Smarty eine neue Version herausbringt, die besser auf PHP 8.0 ausgerichtet ist und die Warnungen bei undeklarierten Variablen vermeidet. Wenn nicht, werde ich die empfohlenen Designs reparieren (und natürlich auch dieses hier im Blog genutzte), wäre dann aber sehr dafür die alten Themes ohne eigenen Maintainer aufzugeben.
Bei den Plugins ist die Situation ähnlich. Auch die werden wahrscheinlich fast alle repariert werden müssen. Die wichtigsten werde ich bei meiner Arbeit an Serendipity selbst mitreparieren, wenn mir niemand zuvorkommt. Man könnte es beim Rest mit automatisierten Tools wie rector versuchen. Und nachbessern falls Nutzer Probleme melden. Dabei sollten wir aber die Plugins markieren, die bereits repariert sind, damit ein etwaig unbedarfter Nutzer nicht unwissentlich ein eventuell inkompatibles Plugin installiert.
Wie gesagt, das ist nur meine unabgesprochene Einschätzung. Durchaus möglich, dass ich gute Alternativen übersehe und mein Ansatz arbeitsintensiver ist als nötig. Aber so oder so schadet es nicht, wieder durch den Code zu gehen und den von Hand geradezubiegen. Das werde ich in nächster Zeit immer mal wieder machen, dabei auf Github PRs vorbereiten und einsenden.
Das positivste: Der für PHP 8.0 angepasste Code lief problemlos mit PHP 7.4, sicher auch mit 7.3. Die Änderungen dürften also nicht zu einem harten Bruch führen. Wenn das Projekt den hier beschriebenen Weg weitergeht sollte die nächste Serendipity-Version mit allen aktuellen PHP-Versionen zugleich funktionieren.
Dieser Blog lief zu lange ohne Backups
Wednesday, 10. March 2021
Heute ist OVH in Straßburg ein Rechenzentrum abgebrannt. Die Bilder sehen nicht so aus, als ob da Daten überleben könnten:
Und während auf Hackernews die Leser über ihre Notfallpläne diskutierten ging ich im Kopf auch die meinen durch. Lokales Backup via pogo, externes Backup via rsync. Selbst wenn da ein Datenzentrum abbrennt, kann nichts wirklich passieren. Oder? Um zu überprüfen, dass die Backups wirklich durchgeführt werden, ging ich meine Server durch. Auch den dieses Blogs. Und sah: Nichts.
Kein Backupskript. Kein Eintrag in der crontab. Keine aktuelle Backupdatei auf dem Backupserver. Selbst die Backupoption des Hosters (die 0.50€ kostet!) war aus.
Ich hatte bei meiner Blog-Migration von scaleway zu vultr Backups schlicht vergessen. Ich weiß noch, dass ich kurz dachte, das einen Moment später machen zu können weil ich wegen des Umzugs ein lokales Backup hatte. Ein Fehler. Es war eine stressige Zeit und ich habe da nie wieder dran gedacht. Bis heute.
Die Einträge eines Jahres wären verloren gewesen. Klar, mancher steckt vielleicht noch in Caches, aber garantiert nicht alle. Dieser Blog lebt seit 2008, es ist meine wichtigste Webpräsenz, auch nur Teile davon zu verlieren wäre furchtbar ärgerlich gewesen. Ich habe Unmengen Glück gehabt, dass die Daten auf dem Server ohne Backup überlebten. Backups, die jetzt wieder aktiviert sind.
Rennt da nicht rein: Überprüft eure Backups, macht welche wenn ihr noch keine habt.
Endless Space, ein modernes und doch klassisches 4X-Spiel
Monday, 8. March 2021
Auch wenn Endless Space von 2012 und damit aus diesem Jahrtausend ist: Der 4X-Vertreter ähnelt trotz modernen Ansätzen mehr den Klassikern des Genres, wie Master of Orion und Ascendancy, als neueren Varianten wie Stellaris. Das gibt ihm anfangs den gleichen Reiz, aber macht das Endspiel auch ähnlich ermüdend.
Kolonisieren mit Aliens
Doch zuerst beginnt man mit einer Stärke des Spiels, der Rassenauswahl. Es gibt zwar wie üblich mit den Menschen eine wenig aufregende Standardzivilisation, aber die anderen sind interessanter. So spielte ich meine Hauptpartie mit den Amöben, zur Weltraumzivilisation hochentwickelten diplomatisch begabten Einzellern. Ich hätte auch eine Rasse von narzisstischen Klonen oder weltenfressenden Insekten wählen können. Einerseits sind die detailreichen Beschreibungen nach Spielstart weg, selbst Beschreibungstexte gibt es kaum. Andererseits geben sie spielverändernde Modifikatoren und Spielmechaniken vor, wenn zum Beispiel eine Rasse permanent mit allen anderen im Kriegszustand ist und von Planet zu Planet ziehen muss.
Daher bleibt es auch nicht bei dem einen Startplaneten. Die Sternensysteme sind verbunden, in jedem können mehrere Planeten sein, die mit der richtigen Technologie alle kolonisiert werden können. Je nach Planetenklasse werden dann pro Siedler vier Ressourcen produziert (Nahrung, Industrie, Forschung und Dust, die Währung). Gewichtigen Einfluss haben neben der Planetenklasse auch noch die Anomalien; Eine Wasserwerwelt mit einem unglücklich machenden schwerem magnetischen Feld ist gleich weniger attraktiv, der eigentlich komplizierte Lavaplanet kann dagegen ein tolles Ziel abgeben, wenn dort vor Urzeiten ein Relikt der Endless errichtet wurde.
Einzelne Gebäude und Zuordnung der Einheiten zu diesen Gebäuden gibt es nicht, nur eine generelle Spezialisierung pro Planet. Dafür können sternensystemweite Verbesserungen gebaut werden, die teils massiv die Produktion verbessern oder die Verteidigung erhöhen. Alternativ können in jedem System Schiffe gebaut werden, die in einem Schiffsdesigner selbst zusammengestellt werden. Die Elemente dafür muss jedoch erst die Forschung freigeschalten.
Forschen
Jede Rasse hat einen leicht abgewandelten Forschungsbaum. Die meisten Technologien sind gleich. Aber die Starttechnologie ändert sich und es gibt Spezialtechnologien, die der Ausrichtung entsprechen. So haben meine Amöben mit ihrem Schwerpunkt auf Diplomatie passende Technologien, wie durch Kooperationsabkommen einen großen Zufriedenheitsbonus auf allen Systemen zu bekommen.
Der Forschungsbaum ist dabei in vier Kategorien aufgeteilt. Völlige Spezialisierung ist praktisch nicht möglich – der rechte Forschungsbaum schaltet z.B. Ressourcen frei, die bei den oberen Militärtechnologien gebraucht werden. Aber ein Fokus lässt sich schon setzen.
Die durch die freigeschalteten Technologien immer breiter werdenden Möglichkeiten machen Spaß, dann kommen manchmal noch Zufallsereignisse mit Entscheidungen dazu.
Kriege
Die Möglichkeiten werden irgendwann wahrscheinlich in einen Krieg münden. Irgendwann ist jedes freie System besiedelt, die nahen Grenzen verärgern die Nachbarn. Oder – das passierte mir – man schließt eine Allianz, worauf eine andere Alienrasse sich bedroht fühlt und den Krieg erklärt. Dann kommen die Schiffe zum Einsatz.
Die Schiffe können zu relativ kleinen Flotten zusammengefasst werden, wobei immer eine Flotte gegen eine andere kämpft. Klar, hier spielt wieder die Forschung rein, der Technologiefortschritt bestimmt wie groß die Flotte sein kann. Neben Schiffen mit normalen Waffen und Panzerung für den Schiffskampf gibt es auch Belagerungsausrüstung wie Bodentruppen, mit denen die Planeten der Feinde übernommen werden.
Kämpfe zwischen den Flotten werden entweder berechnet oder in einer 3D-Ansicht angezeigt, wobei auch dann der Kampf automatisch abläuft. Es gibt drei kurze Phasen, in denen die Schiffe aufeinander einschießen, für jede Phase kann per Karte eine Strategie ausgewählt werden.
Diese Karten kommen teilweise auch von den Helden, das sind dann Spezialvarianten mit entsprechenden Boni. Jede Zivilisation hat nur wenige Helden. Sie können auf Planeten dienen und steigern dort dann teils massiv die Produktion, oder sie wirken als Flottenkapitän in Schlachten mit. Bei Aktionen sammeln sie Erfahrung, dann kannst du ihnen neue Fähigkeiten geben. Ein nettes Rollenspielelement.
Aber bei den Kämpfe selbst ist der Spieler notgedrungen sehr passiv. Ähnlich wie in Stellaris geht es im Grunde nur darum, genug Schiffe an die richtige Stelle zu packen. Ausgerechnet hier fehlt die Orientierung an die Klassiker, wo doch in Ascendancy noch Schiffe einzeln in Echtzeit gesteuert und in Master of Orion tolle Rundenkämpfe ausgetragen wurden. Immerhin, die Begrenzung auf viele kleine Flotten macht das System etwas taktischer als bei Stellaris, aber ideal ist es nicht.
Spielbarkeits- und Interfaceprobleme
Einschränkungen bei den Kämpfen hin oder her, die Spielelemente greifen wie im Genre üblich gut zusammen. Das Errichten eines erst kleinen, dann langsam größeren Sternenimperium ist supermotivierend, die immer wieder dazukommenden Technologien halten das Spiel lange frisch. Aber irgendwann kippt es, und teils hängt das schlicht an der Bedienung.
Ein großes Imperium zu verwalten artet in Arbeit aus. Gleichzeitig will ich meine Planeten nicht von der KI verwalten lassen, weil ich der keine genauen Bauvorgaben machen kann und viele Planeten mit guten Upgrades zu haben im Grunde das Spielziel ist. Hier könnten moderne Komfortfunktionen helfen, aber dafür ist wohl die Anlehnung an die Genreklassiker zu stark, oder sie sind zu versteckt.
Zwei Probleme potenzieren sich:
Ersten, das Bauen der Sternensystemupgrades läuft via fuzzelig kleinen Icons, die aus einer immer länger werdenden Liste ausgewählt werden. Das ist extrem unkomfortabel, vor allem wenn man es bei einer längeren Partie bei zig Sternensystemen machen muss. Und nicht vergessen: Dazu kommen die Planeten, auf denen auch mehrere Upgrades ausgewählt werden müssen.
Zweitens, Systeme können auch nichts tun und das Spiel warnt dann nicht. Es gibt jede Runde eine Benachrichtigung wenn eine Konstruktion fertig ist, in ihr sieht man wenn keine weitere vorgesehen ist. Verpasst man diese Chance aber, dann muss man selbst in der Sternenkarte auf das System klicken oder in der immerhin vorhandenen Übersicht das inaktive System entdecken. So muss im Grunde regelmäßig die Konstruktion überprüft werden.
Das Interfaceproblem wird noch verschlimmert, weil Systeme ohne bessere Option auch einen Teil ihrer Industrieproduktion in Forschung oder Dust umwandeln können. Sie produzieren dann ein unendliches Upgrade im Konstruktionsslot. So verpasst man aber natürlich die Chance, neu freigeschaltete Upgrades bauen zu lassen wenn die vorherigen fertig sind, das gerade gebaute wird ja nie fertig. So wird jeder entsprechende Forschungserfolg zu einem Anlass, wieder durch die Sternensystem durchgehen zu müssen...
Fazit: Ein klassischer Genrevertreter
Mit den Steuerungsproblemen wird das ansonsten gute Endless Space weit weniger spaßig. Damit ist es aber in bester Gesellschaft, die wenigsten 4X-Spiele schaffen es große Imperien angenehm kontrollierbar zu machen. Fast alle schwächeln daher am Ende, obwohl dann die vielen Handlungsmöglichkeiten erst so richtig zur Geltung kommen. Stellaris hatte das Problem damals erkannt und mit den Zwangs-KI-Gouverneuren gegengesteuert, was aber auch keine tolle Lösung war, vor allem weil die KI in verschiedenen Patchversionen immer wieder versagte. Endless Space lässt die KI-Unterstützung offen, aber eigentlich sind es Interfaceverbesserungen und Komfortfunktionen die ich mir wünschen würde – die unendliche Produktionsumwidmung hätte nicht sein müssen, Sternensysteme mit neuen Upgradeoptionen bräuchten ihre eigene Benachrichtigungsliste, und insgesamt müsste das Interface schlicht größere Bedienelemente haben. Denn auch wenn ein Spiel von 2012 nicht neu ist, ist es doch kein DOS-Klassiker und braucht sich gerade in der Bedienung nicht so geben.
Aber der obere Absatz klingt negativer, als ich das Spiel eigentlich empfand. Die Rassen mit ihren unrerschiedlichen Spielstilen machen einen erneuten Durchgang reizvoll, die Kolonisierungsphase war klasse, insgesamt greifen die Spielmechaniken bis kurz vor Ende wunderbar ineinander. Es hat schon seinen Grund, warum dieses Genre trotz der typischen Macken immer wieder aufgegriffen wird. Gerade dass Endless Space so klassisch angelegt ist sorgt eben auch dafür, dass es zwischendurch ähnlich fasziniert wie die Spiele, die das Genre in den Neunzigern geformt haben. Und dabei hat es ja schon ein paar moderne Elemente und eigene Ideen. Anspielen lohnt sich daher – es ist derzeit sogar kostenlos, wenn man sich auf der Herstellerseite registriert und einen Steam-Account verbindet.
FreshRSS
Thursday, 4. March 2021
Feedtragon war für mich der perfekte Feedreader – kein Wunder, baute ich ihn doch selbst. Als Schwachstelle entpuppte sich Superfeedr, als der als Backend genutzte Service die Preise anhob hätte ich feedtragon auf ein eigenes Backend umbauen müssen. Stattdessen benutzte ich mehrere Fertig-Feedreader: BazQux (hervorragend, aber damals wollte ich nichts bezahlen), den Digg Reader (abgeschaltet) und bis zuletzt Feedly (gut, aber etwas umständlich). Nun bin ich bei FreshRSS gelandet, was auf meinem uberspace von mir selbstgehostet wird.
Eindruck nach ein paar Wochen
FreshRSS ist freie Software (AGPL) und funktioniert einwandfrei. Die Installation ist im Uberspace-Wiki dokumentiert, uberspace bietet sich für sowas immer als unproblematischer und fähiger Hoster an. Meine Installation ist jetzt schon ein bisschen her, aber es muss gepasst haben, sonst würde ich mich an Probleme erinnern.
Das Interface ist das eines klassischen RSS-Readers. Links ist die Liste der Feeds, rechts die Artikel. Mit der Toolbar oben können diverse Aktionen mit den Artikeln durchgeführt (z.B. als Favorit markieren) und zwischen den verschiedenen Ansichten umgeschaltet werden.
Kleinigkeiten empfinde ich als nicht optimal. Das automatische Markieren als gelesen durch Scrollen der eingeklappten Artikelliste war extrem stressig, zum Glück kann die Funktion deaktiviert werden. Die Taste M
sollte den Gelesen-Status von Artikel umschalten, aber bewirkt nichts. Und das Warnungsicon bei Uncategorized in der Feedliste links ist nervig, wenn wie bei mir alle Feeds nicht in Kategorien sind und das auch so bleiben soll.
Aber das sind wirklich Kleinigkeiten. Der Rest passt. Insbesondere habe habe ich den Eindruck, dass die Infrastruktur sehr gut funktioniert. Damit meine ich, dass die Software einwandfrei per Cronjob die Feeds liest und neue Artikel entdeckt. Die Darstellung der Artikel selbst ist gut, die wichtigsten Tasten J
und K
zum Weitergehen in der Artikelliste sind belegt. Der eingebaute RSS-Feed gibt die Option der Weiterverarbeitung. Mehr braucht es nicht.
Es tut gut, wieder einen selbstkontrollierten Feedreader zu haben. Und noch dazu einen, den ich nicht selbst bauen muss, auch wenn feedtragon wieder zum Laufen zu bringen immer noch als gutes Projekt in meinem Hinterkopf herumschwebt. Feedly hatte schon okay funktioniert, aber mir waren die Limitierungen unangenehm und es nagte auch der Gedanke, warum ich nicht freie Software benutze wenn es denn gute Optionen gibt.
Als nur tt-rss mit seinem problematischen Autor auf meinem Radar war sah das nicht so aus, aber FreshRSS füllt die Rolle gut. Unter anderem Dirk hatte die Software in seinem Blog erwähnt. Auch wenn ich nicht mehr genau weiß, welcher Autor und welcher Artikel den Ausschlag gab: Danke für den Hinweis.
Usability mit Alltagsgegenständen
Monday, 1. March 2021
Auch wenn Usability normalerweise die Benutzbarkeit von Software meint: Man muss es wirklich nicht auf Software beschränken. Die Dialogprinzipien passen auch sehr gut zu Gegenständen, Usability als Konzept sowieso. Und bei Alltagsgegenständen finden sich viele Designprinzipien, die entweder gut angewandt werden oder eben merklich fehlen. Mein Haushalt hat ein paar schöne Beispiele. Natürliches Mapping ist eines davon.
Beispiel 1: Der Herd und das Mapping
Natürliches Mapping habe ich in dieser Artikelserie noch gar nicht erwähnt. Es ist ein Konzept, um die Funktion von Knöpfen zu vermitteln. Findet sich oft bei Software, aber ist im Haushalt schöner zu erklären. Zum Beispiel mit dem Herd. Der hat ja meistens 4 oder 5 Kochfelder, die in einem Rechteck angeordnet sind.
Wenn dann das Bedienfeld so aussieht:
Welcher Regler kontrolliert dann welches Kochfeld? Das bleibt völlig unklar. Man kann es erlernen, Symbole könnten es erklären, aber es ist nicht intuitiv direkt ersichtlich.
Wenn die Bedienknöpfe dagegen in der gleichen Logik angeordnet sind wie die Kochfelder selbst, also so:
Dann wird auf einen Blick klar, welcher Regler welches Kochfeld kontrolliert. Vorausgesetzt, man schafft es zu ignorieren, dass sich in diesem Foto des Kochfelds die Dunstabzugshaube spiegelt.
Touchscreens in der Küche mag ich eigentlich nicht, aber hier wird ihr Vorteil – der geringe Platzbedarf – effektiv genutzt.
Natürliches Mapping ist eines der wenigen universellen Instrumente, mit denen klar verständliche Oberflächen und Kontrollelemente geschaffen werden können.
Beispiel 2: Dunstabzugshaube und Designerknöpfe
Der Herd macht eine Sache richtig, die Dunstabzugshaube bei uns in der Küche ist dagegen ein Negativbeispiel. Sie hat diese Knöpfe:
Auf den ersten Blick komisch ist die Einreihung des Lichts ganz rechts. Da der Knopf etwas ganz anders macht wäre es hilfreich, wenn er sich anders anfühlte oder nicht mit den anderen drei in einer Reihe angeordnet wäre. Etwas Abstand dazwischen wäre gut. So würde die verschiedene Funktionalität getrennt werden.
Richtig seltsam aber wird es, wenn man die Knöpfe drückt:
1, 2 und 3 regelt die Stärke, das ist soweit klar. Aber statt dass es exklusive Radiobuttons sind, können sie zusammen gedrückt werden. Richtig wäre, wenn ein eingedrückter Knopf wieder hochgeht sobald der nächste gedrückt wird. Stattdessen bleibt er hier einfach in Position. Und es zählt immer der stärkste. Im Beispielbild ist also welche Stärke ausgewählt? 2, denn 1 und 2 sind beide gedrückt.
Es sei nur Stärke 3 ausgewählt. Will ich jetzt von Stärke 3 auf 1 wechseln kann ich nicht einfach auf 1 drücken, sondern muss auch auf 3 drücken um diesen Knopf zu deaktivieren. Wie umständlich!
Eine Umsetzung ohne Sinn und Verstand, bei der nur darauf geachtet wurde, dass das Bedienfeld schön symmetrisch ist. Statt Produktdesign und Usability stand visuelles Design im Fokus. Das mag ein Aspekt der Benutzererfahrung sein, aber wenn Usabilitykriterien so komplett missachtet werden ist die Gesamterfahrung trotz eines ansehnlichen Aussehens immer negativ. Diese Dunstabzugshaube hätte ich mir nie ausgesucht.
Beispiel 3: Mikrowelle und Konventionen
Unsere Mikrowelle habe ich selbst ausgesucht und ich hatte ein ziemlich simples Auswahlkriterium: Ich will sie bedienen können.
Die billigsten Mikrowellen machen das oft am besten. Sie haben einen Scheibenregler für die Stärke und einen zweiten für die Dauer. Natürliches Mapping ist da kein Thema, aber es ist schnell erlernbar und einfach zu verstehen. Stärke einstellen, Dauer einstellen – ich muss nur wissen wie lange mein Essen normalerweise braucht. Und das weiß ich, bei 900W sind die Nudeln etwa in zwei Minuten aufgewärmt. So sieht das bei unserer aus, die ich selbst gebraucht gekauft und dann in die Küche getragen habe:
Der Stärkeregler ist leicht verkompliziert wegen der Grillfunktion, aber selbst das wird durch die Symbole verständlich und die Bedienung bleibt simpel genug.
Ich hätte auch so etwas kaufen können:
Und hätte mich bei jeder Benutzung geärgert, warum ich nicht einfach und schnell Stärke und Zeit auswählen kann.
Mikrowellen sind ein Beispiel dafür, dass simple Konventionen die besten sein können. Sie sind leicht erlernbar und gute Konventionen führen zu einer effizienten Bedienung. Aber der Markt ist erstaunlich fähig, sie zu ignorieren. Um eine 200€-Mikrowelle zu verkaufen darf die ja nicht so aussehen wie die 20€-Mikrowelle vom Supermarkt, entsprechend werden Funktionen draufgepackt. Dann passen die simplen Scheibenregler nicht mehr. Ergebnis: Die Produkte werden ohne Studieren der Bedienungsanleitung unbenutzbar, jede normale Benutzung dauert länger.
Beispiel 4: Waschbecken und fehlende Aufgabenangemessenheit
Ich habe noch ein Beispiel für Verschlechterung – unser Waschbecken:
Und zwar geht es um den Stöpsel. Normalerweise – so kenne ich das – wäre hinter dem Wasserhahn ein Metallhebel, mit dem der Verschluss gesenkt oder gehoben werden kann. Es gibt aber (seit einer Weile?) auch dieses Prinzip, bei dem der Stöpsel selbst bewegt wird. Meiner Wahrnehmung nach besonders häufig in schicken Hotels, aber eben auch bei uns im Bad.
Das hat ja seinen Reiz: Anstatt dass ein völlig entferntes Bedienelement erlernt werden muss, ist das zu bewegende Teil direkt beweglich. Das ist noch besser als natürliches Mapping. Der Stöpsel vermittelt durch den Greifer in der Mitte auch direkt, dass er beweglich ist – bei Interfaces spricht man da von der Affordance. Ein Button muss die Affordance haben klickbar zu sein, der Stöpsel hier, senk- und hebbar zu sein. Die Selbstbeschreibungsfähigkeit ist dadurch gegeben, der Aspekt funktioniert.
Doch ist die Lösung völlig aufgabenunangemessen, was das wichtigere Prinzip ist. Wenn das Wachbecken voll ist, muss der Nutzer jetzt in die Drecksbrühe greifen um das Wasser ablaufen zu lassen. Der Greifer hinter dem Wachbecken mag nicht schick sein, er kann kaputt gehen und die Metallverbindung unter dem Wachbecken würde Platz kosten. Aber er ist trotzdem insgesamt die viel bessere Lösung, weil nur er die Aufgabe richtig löst: Das Wasser im Waschbecken ablassen zu können, ohne ins Wasser greifen zu müssen.
Usability betrifft unseren Alltag öfter als man vielleicht zuerst glaubt. Selbst Alltagsgegenstände können in ihrer einfachen Benutzbarkeit stark variieren. Dabei ist absolut nicht gegeben, dass teure Produkte eine bessere Usability haben.
Küchen sind da besonders anfällig, weil die Leute sie basierend auf einem Ersteindruck kaufen. Aber auf den ersten Blick werden ungeschulten Augen Usabilityprobleme selten direkt auffallen. Und dann ärgert man sich jahrelang mit schlechten Lösungen rum – zum Beispiel mit der Mikrowelle, die keiner im Haus wirklich bedienen kann. Und sucht dann im Zweifel die Schuld bei sich selbst, anstatt zu erkennen, dass die Mikrowelle einfach schlecht gemacht ist.
Da beim Kauf mehr drauf zu achten lohnt sich. Einem Produkt mit guter Usability den Vorzug zu geben kann für viele Jahre einen kleinen Aspekt des Alltags etwas angenehmer machen.
Usability vs UX
Monday, 22. February 2021
Im allgemeinen Sprachgebrauch, selbst in der Industrie, wird Usability und User-Experience oft vermischt. Da wird dann ein UX-Consultant gesucht, der für die reibungslose Nutzung sorgen soll (dabei ist das viel mehr Usability) oder es wird erwartet, dass der Usability-Experte mit einem neuen Farbschema für die Software ankommt (dabei ist das visuelles Design und mehr ein Teil von UX). Tatsächlich ergänzen sich die beiden Disziplinen, aber sie reden nicht über das gleiche und haben unterschiedliche Methoden.
Definitionen
Usability haben wir hier im Blog gerade erst ausführlich definiert. Zu UX gibt es wieder eine Norm, DIN EN ISO 9241-210. Sie ist demnach abhängig von den Reaktionen des Nutzers, seinen Emotionen, psychologischen und physiologischen Reaktionen. Das kann von allem möglichen abhängen: Ja, auch von der Usability der Software, aber auch vom visuellen Design oder mit ihr verbundenen Statusgefühlen. UX ist demnach viel breiter als Usability.
Gleichzeitig passt sie gut in das kleine Stufenmodell, das bei Usability benutzt wird. Effektivität, Effizienz und Zufriedenstellung, die aufeinander aufbauenden Softwarequalitätsebenen. Zu Zufriedenstellung hat Usability nicht viel zu sagen – zu Effektivität schon mehr, vor allem aber zur Effizienz mittels der Dialogprinzipien. UX lebt aber geradezu auf der Zufriedenstellungsebene. Auch hier muss man sich vorher mit den Grundlagen beschäftigt haben. Aber wie dann tatsächlich die Zufriedenstellung erreicht wird, das wäre in meinen Augen der Fokus von UX.
Abgrenzung
Wobei, kurz eingeschoben, das ist kein Nachteil von Usability. Es kommt mehr aus dem Umstand, dass Usability ein klares Methodenset und ein klares Ziel vor Augen hat, während die Ganzheitlichkeit der UX eben auch Beliebigkeit bedeuten kann. Eine Beliebigkeit, die auch dafür sorgen kann, dass ein vermeintlicher UX-Experte sehr wohl Usability-Arbeit macht, womöglich ohne dass er den Unterschied so wahrnimmt wie ich.
Nehmen wir als Abgrenzungsbeispiel Apple. Apple-Produkte werden oft gepriesen für ihre tolle Benutzbarkeit. Gleichzeitig finden sich unzählige Beispiele, in denen das System nicht besonders aufgabenangemessen, die Selbstbeschreibungsfähigkeit gar nicht da ist und die Erlernbarkeit auch fehlt. Natürlich gibt es schlimmere Systeme, aber Apple-Software ist doch voller Usability-Probleme. Trotzdem gibt es eine riesige Gruppe, die Apple-Produkte quasi-religiös verehrt und sie ganz toll findet. Eine Diskrepanz für Usability, da hier Zufriedenstellung von Effektivität und Effizienz abhängt und wir generell fokussiert von einer konkreten Aufgabenerledigung reden. Erklärbar mit UX, wenn dort das visuelle Design, Marketing und Statusdenken mitbeachtet wird.
Doch es geht zusammen
Usability und UX schließen sich nicht aus. In der Praxis werden die Definitionen vermischt, meine trennende Perspektive hier könnte im Laufe der Zeit von immer weniger Menschen geteilt werden. Aber aus Sicht eines Usability-Experten sind die beiden Disziplinen nicht auf der gleichen Ebene. Usability würde mit Nutzertests die effiziente Aufgabenerledigung testen wollen, die weitere Wirkung des Produkts wäre ein per Umfrage abgedeckter Nachgedanke (aber zur Methodensammlung kommen wir noch). UX dagegen würde diese Umfrage zur emotionalen Wirkung ins Zentrum stellen und dann im Zweifel darauf hinwirken, dass das visuelle Design angepasst wird.
Wie XCOM 2 die Schraube anzieht
Friday, 19. February 2021
Wer als Veteran des Vorgängers Enemy Unknown das neuere XCOM 2 spielt könnte sich wundern, wieviel die Entwickler am Spieldesign geändert haben. Eine Änderung insbesondere ist kritisch: Viele Missionen haben eine Rundenzeitbegrenzung. Als ich damals darüber las ging ich sogar davon aus, dass dieser neue Ansatz überhaupt nicht zu meiner Spielweise passen würde. Was stimmt – aber das ist überraschenderweise kein Problem. Stattdessen ist das Rundenlimit eine der Änderungen, die das Spiel noch besser als den ersten Teil machen.
Die Wurzeln: Rundenkämpfe, RPG-Elemente und Basisbau
Es täuscht, aber: Auf den ersten Blick ändert sich nicht viel. Noch immer gilt es die Erde gegen eine Alieninvasion zu verteidigen, nur sind sie diesmal schon angekommen und etabliert. Ihr führt den Widerstand, der den Kampf gegen die Alienherrscher gewinnen und ihre finsteren Pläne vereiteln will.
In erster Linie passiert das in den bekannten Rundenkämpfen. Immer ein kleines Team aus XCOM-Soldaten muss die Siegbedingungen auf den nicht zu großen Karten erreichen. Und das möglichst, ohne dass einer der vier (später auch mehr) geführten Recken stirbt. Das bedeutet: Deckung nutzen, Gegner flanken, geschickt die Sonderfähigkeiten der Soldatenklassen einsetzen, ein bisschen Glück haben und im Zweifel neu laden. Von den Spezialaktionen gibt es bald mehr, erledigte Gegner bringen Erfahrung, bei Levelaufstiegen darf eine von immer zwei möglichen Fähigkeiten erlernt werden. Aber immer erst nach der Mission, nur in der Heimatbasis kann die Beförderung verliehen werden.
Die Basis ist auch sonst ein wichtiges Spielelement. Sind ein paar Räume wie das Forschungslabor schon vorhanden, ist da noch weiterer Platz für Einrichtungen. Beispielsweise für das Psi-Labor, mit dem neue Rekruten mit den übernatürlichen Fähigkeiten ausgestattet werden können, die auch die Aliens immer wieder gegen die Spielertruppe einsetzen. Doch für die Räume braucht es Ressourcen wie auch genug Energieproduktion, zudem müssen fast alle Einrichtungen sowie Ausrüstungsgegenstände erstmal erforscht werden.
Diese Ressourcen gewinnt man durch erfüllte Missionen, aber auch durchs Kontrollieren der Weltkarte. Die Sektoren müssen kontaktiert werden, was Zeit kosten, dann gibt es monatlich Unterstützung. Und auch gibt es immer wieder Ressourcenquellen auf der Karte, bei denen gegen Zeiteinsatz z.B. neue Rekruten oder Intel gewonnen werden können. Meist aber ruft sowieso eine der Missionen.
Die Hauptressource: Zeit
Es gibt also überall etwas zu tun und man hat gerade am Anfang unzählige Optionen. Doch XCOM 2 lässt eben nicht frei die Möglichkeiten auszuprobieren. Stattdessen gibt es immer wieder zeitkritische wichtige Missionen. Das Spiel poppt deren Beschreibungen auf und sagt ganz klar: Du hast im Grunde keine Wahl, du musst jetzt eine dieser drei wählen um eine Aktion der Aliens zu vereiteln oder eine einzelne erfüllen, um Ressourcen zu erhalten.
Vor allem das Avatarprojekt droht da als klar sichtbares Zeitlimit, das sabotiert werden muss. Dafür können Alienforschungseinrichtungen hochgejagt werden. Ironischerweise ist das eine der wenigen Missionstypen, bei denen der Spieler einmal kein Zeitlimit hat. Dafür praktisch in allen anderen: Dann ist z.B. in dem zu kapernden abgestürzten UFO ein Peilsender, der in 5 Runden Verstärkungen anfordern und damit zum Rückzug zwingen wird, sollte er nicht rechtzeitig abgeschaltet werden.
Doch ist dieses Zeitlimit in den Missionen nicht so stressig wie es klingt. Es zwingt zum aggressiveren Vorgehen, klar. Aber zum einen tut das XCOM gut, denn es verhindert das übervorsichtige Vortasten bei dem dann meist minutenlang nichts passierte. Vor allem aber ist das Spiel für diese schnellere Spielweise ausgelegt. Es gibt nicht die große übermächtige Gegnermassen, sondern es sind relativ wenige Aliens auf den Karten unterwegs, die sich zudem in kleine Gruppen von immer etwa drei Gegner aufteilen. Manchmal trifft man mehrere dieser Gruppen in einem Zug, aber meistens können sie nach und nach abgearbeitet werden. Vor allem wenn man nach einer Weile 5 oder 6 eigene Figuren mit guter Ausrüstung und Sonderfähigkeiten führt werden die Missionen beherrschbar.
Die vielen Verbesserungen
So können die vielen Verbesserungen scheinen. Wie klar wurde, dazu zähle ich das Missionsdesign mit seinem Zeitlimit, aber das ist beileibe nicht alles.
Durch die vielen automatisch auftauchenden Missionen gerade am Anfang des Spiels ist der Spieler zwar zuerst sehr unfrei, aber auch geführt. Die Missionen fordern und gleichzeitig sollen ja doch auf der Weltkarte und beim Basisbau längerfristige Entscheidungen getroffen werden. Aber doch wird man nicht überfordert, weil mit den Missionen immer Fortschritt erreicht wird. So verhindert XCOM 2 effektiv, dass die schiere Komplexität zum blockierenden Problem wird. Und der Schwierigkeitsgrad wird gemächlich erhöht, zumindest langsamer als es mir beim Vorgänger vorkam.
Diesem besseren Spielgefühl dienen auch die stärkeren Klassen. Sie alle haben ein klareres Profil mit besseren Spezialfähigkeiten bekommen. Wer dann noch halbwegs fleißig Ressourcen in Soldatenupgrades investiert kämpft nicht mehr als absoluter Underdog gegen die Feinde, anders als im ersten Teil.
Es gibt immer noch einen Heavy und einen Scharfschützen, die immer noch mit schwerem Geschütz bzw. Gewehr die Gegner aufräumen. Dazu kommt diesmal der Ranger mit Schrotflinte und Nahkampfangriff, der sich entweder auf diesen spezialisiert oder auf die Tarnung. Und dann komplettiert auch schon der Spezialist die regulären Klassen, der als Heiler oder als Hacker sehr wichtig geworden ist. Vor allem, dass er als Hacker Roboter besonders effektiv ausschalten oder sogar zeitweise übernehmen kann macht ihn sehr effektiv. Dazu kommt dann noch der Psi-Soldat, der schnell sehr viele sehr starke Fähigkeiten bekommt, dann humanoide Gegner sogar dauerhaft übernehmen kann, garantiert trifft oder Flächenschaden verursacht.
Dazu setzt XCOM 2 den Fokus auf die Inszenierung fort. Die Missionen sind weit davon entfernt wie das Herumziehen kleiner Pixelfiguren zu wirken. Dafür sorgen die vielen Momente, in denen die Kamera in die Nahansicht geht um Aktionen und ihre Ergebnisse zu zeigen. Auch außerhalb der Missionen gibt es viele Zwischensequenzen, besonders wenn eines der Hauptziele erfüllt wurde, in denen auch die Mitstreiter des Widerstands auftreten.
Ein gelungener schmaler Grat
Die geringe dem Spieler mögliche Initiative am Anfang hätte nerven können, das Zeitlimit in den Missionen stressen, die Weltkarte langweilen. Stattdessen fügt sich XCOM 2 zu einer tollen Mischung zusammen, die schlicht nochmal besser funktioniert als der auch schon sehr gute Vorgänger.
Wie knapp das war zeigen die sich wiederholenden Missionen, in denen ein Sender vor den Aliens verteidigt werden soll. Der ist immer auf der anderen Seite der Karte. Ein festes Zeitlimit gibt es nicht, aber manchmal wird er von der ersten Runde an angegriffen. Dann reicht die Zeit höchstens gerade so, rechtzeitig den Sender zu erreichen und die Gegner zu besiegen. Ich schaffte es immer, aber gerade am Ende des Spiels (wenn die Gegner stärker sind) nur durch exzessives Ausnutzen der Quickload-Funktion, um immer optimale Spielzüge zu machen. Selbst dann war es ein paarmal unwahrscheinlich knapp. Und das ist dann nicht mehr herausfordernd spaßig, sondern frustrierend unfair.
Ich kann mir daher sehr gut vorstellen, dass die oft zu lesende Kritik an den DLCs berechtigt ist, dass sie entweder mit weiteren starken Feinden oder mit zu vielen weiteren – und dann durch die unweigerlich ausfallenden verletzten Soldaten nicht mehr gewinnbaren – Pflichtmissionen am Anfang die Balance kippen.
Aber so wie das Grundspiel ist funktioniert die Mischung hervorragend. Und die Linuxversion funktioniert mit sehr wenigen kleinen Macken (wie manchmal etwas etwas spät nachladenden Texturen) ebenfalls sehr gut. XCOM 2 wird mittlerweile im Sale für 4€ auf Steam verscherbelt, das Geld ist es auf jeden Fall wert.
Was ist Usability?
Monday, 15. February 2021
Normalerweise versteht man unter Usability die einfache Benutzbarkeit von Software. Tatsächlich aber hat Usability eine genormte Definition nach DIN EN ISO 9241-11 und ist nach meinem Stand der Grad, zu dem ein Werkzeug in einem bestimmten Kontext bei bestimmten Nutzern eine bestimmte Aufgabe effektiv, effizient und zufriedenstellend erledigt. Da steckt ein bisschen mehr drin als bei der ersten Definition, die die meisten von uns im Kopf haben dürften.
Usability nach Norm
Erstens geht es dann nicht mehr nur um Software, sondern um jedes Werkzeug oder Produkt. Zweitens geht es nicht mehr um generelle Einfachheit, sondern um die Eignung in definierten Anwendungsfällen. Und drittens gibt es nach dieser Definition mit effektiv, effizient und zufriedenstellend Gradmesser der Usability, wobei damit konkret gemeint ist:
- Effektiv kann das Werkzeug die Aufgabe überhaupt erledigen (viele Dinge hämmern)
- Dabei ist es mehr oder weniger effizient (der Hammer hämmert besser als das Telefon)
- Nach dem ganzen ist der Nutzer mehr oder weniger zufrieden, vielleicht sogar sehr, wenn der Hammer super effektiv und effizient war, minimalen Kraftaufwand braucht und gleichzeitig dem Handwerker Komplimente macht.
Bewaffnet mit dieser Definition gibt es gerade in Deutschland eine (kleine?) Industrie, die Fortbildungen anbietet und (normalerweise) Software auf diese Kriterien abklopft. Mein vorheriger Job war genau in dem Bereich – führte mich also vom breiteren Studium der Mensch-Computer-Interaktion (HCI) zurück zu sehr viel konkreterer angewandter Usability, genau was mich an HCI genug fasziniert hatte um es als Master zu wählen.
Hilfreicher: Grundlagen der Dialoggestaltung
Aber von wegen angewandt: Natürlich ist die Definition trotz allem reindefinierten viel zu abstrakt, um damit viel konkretes anzufangen. Um Software zu bewerten geht man daher einen Schritt weiter und schaut sich die Grundlagen der Dialoggestaltung (ISO 9241-110) an:
Aufgabenangemessenheit
Kann die Aufgabe angemessen erledigt werden? Ja, man kann mit Paint eine Doktorarbeit schreiben, aber der Aufwand ist unnötig hoch.
Selbstbeschreibungsfähigkeit
Ist der Zweck jedes Interfaceelements direkt ersichtlich? Typisches Problem hier sind Icons, deren Bedeutung unklar bleibt oder Buttons, die nicht wie Buttons aussehen (Flat-Design!).
Steuerbarkeit
Kann man (z.B. in einem Wizard) wieder zurückgehen?
Erwartungskonformität
Ist alles konsistent mit der Nutzungserwartung? Darüber schrieb ich hier im Blog schonmal bezüglich des prägenden Einflusses des ersten Kontakts mit einem Systems.
Fehlertoleranz
Verzeiht das System Falscheingaben des Nutzers und bewahrt ihn vor solchen?
Individualisierbarkeit
Beispiel Schriftgröße – kann das System an die Bedürfnisse des Nutzers angepasst werden? Hier geht es dann ganz schnell auch um Accessibility
Lernförderlichkeit
Kann der Nutzer die Software erlernen und hilft sie dabei? Markierungen für Tastenkürzel in Menüs gehen z.B. in die Richtung.
Das sind schon besser greifbare Kriterien, mit denen man Software auf der Effizienzebene bewerten kann und dann rausbekommt, welche Probleme sie hat.
Diese Grundlagen wurden übrigens vor kurzem überarbeitet. Unter anderem wurde laut Wiki Benutzerbindung – System ist einladend und motivierend hinzugefügt. Das ist Unsinn, weil es dem Prinzip hinter ihnen zuwider läuft, klar definierbare Eigenschaften von Dialogen auf der Effizienzebene abzudecken und stattdessen der schwer greifbaren Zufriedenstellung oder User-Experience entspricht (zur Abgrenzung von UX und Usability will ich später noch etwas schreiben). Du könntest also an anderen Stellen eine andere Definition finden, solltest die aber ignorieren. Die oben gezeigte ist die richtige.
Testbarkeit, Einstellungssache und Anwendbarkeitsprobleme
Mir ist wichtig etwas zu betonen, was bei den ganzen Definitionen vielleicht nicht direkt klar wird: Usability ist die Antithese zu RTFM. Dieses elitäre Gehabe, das zumindest vor Ubuntu im Linuxumfeld zu finden war und immer noch in einigen Bereichen zu finden sein wird, hat als Kern den Anspruch, dass bei Problemen der Nutzer schuld ist und er sich anpassen muss. Usability gibt dagegen ein Werkzeugset, mit dem man schauen kann wie Software so gebaut wird, dass zumindest die Zielnutzergruppe ihre Aufgabe gut erledigen kann. Was Anleitunglesen nur dann einschließt, wenn es die übliche Praxis der Zielgruppe ist.
Üblicherweise macht man diese Prüfung mit Nutzungstests. Da spielt das ganze "definierter Nutzer, Kontext und Aufgabe" der Usabilitydefinition mit rein. Natürlich kann auch ich mich vor eine Software setzen und gucken, welche Probleme mir auffallen – das ist sogar ein valides erstes Testmittel, mit einer Expertenevaluation finden sich viele typische Probleme. Aber dem Atomkraftwerksingenieur, der normalerweise vor der Software sitzt, dem werden noch ganz andere Dinge auffallen und wichtig sein. Wenn ich also ihn bei seiner Aufgabenerledigung beobachten kann wird viel wahrscheinlicher, dass die wichtigen Probleme auftreten und analysiert werden können.
Hier im Blog hatten wir das auch schonmal in einem schönen Beispiel bei der kleinen Kontroverse um Gimps Umbau des Speicherdialogs, denn dort war der springende Punkt, dass es eben darauf ankommt was die eigentlichen Nutzer während der echten Arbeit davon halten – wobei bei Gimp das eben sehr viele Nutzer mit unterschiedlichen Anforderungen sein können.
Man sieht da ein Problem: Usability nach Normdefinition eignet sich besser für kleinere Nutzergruppen, vor allem für Angestellte in Unternehmen. Wenn ich weiß, dass alle meine Techniker eine bestimmte alte Software beherrschten und grundsätzlich diese X Dinge über das verkaufte Produkt wissen, dann kann ich die Nachfolgesoftware gut mit denen testen. Wenn ich alle Menschen auf der Erde ansprechen will, geht all der definierte Kontext aus der Definition den Bach runter. Als Usability-Experte kann ich dann immer noch mit Tests arbeiten, Konsistenz herstellen und mir Zielnutzergruppen raussuchen, für die meine Software besonders gut funktionieren wird – aber da kommt man immer an die Grenze des machbaren, an der dann schon der kulturelle Unterschied zu groß ist um ihnen allen eine gute Usability zu bieten.
An ähnliche Probleme kommt man, wenn die Software eine schwierig zu definierende Aufgabe hat. Versuch mal, Facebook auf eine einzelne Aufgabenerledigung runterzubrechen.
Manchmal geht das dann schief und Software wird im Auftrag der Designer kaputtsimplifiziert. Etwas einfach zu halten kann helfen möglichst viele mögliche Nutzer nicht vor Probleme zu stellen, kann aber eben auch die Aufgabenerledigung für die anderen (im Zweifel: Die echten und bestehenden Nutzer) behindern. Windows 8 kann man so einordnen. Generell im Zweifel alles, wo Oberflächen für beschränkte Medienkonsumierungsgeräte wie Smartphones und Tablets auf PCs übertragen werden. Aber auch die misslungene Umstellung des Fedora-Installers von einem simplen linearen Wizard auf eine komplizierte Menüstruktur im Namen der vermeintlich zugänglichen modernen GUI schlägt in diese Kerbe
Mehr als eine Norm: Usability für alles
Gut, dass es wirklich nicht nur um Software geht und Usability mehr ist als nur unsympathisch hinter Zahlschranken versteckte DIN-Normen. Das Buch The Design of Everyday Things von Don Norman zeigt das besonders stark. Norman sammelt darin sehr viele Beispiele von Alltagsgegenständen, deren Usability schlecht ist. Tolles Beispiel sind Türen: Schonmal vor einer gestanden und nicht gewusst, ob man ziehen oder drücken muss? Auch das wird zu einer grundsätzlichen Einstellungsfrage: Die meisten Menschen fühlen sich blöd, wenn sie falsch lagen. Dabei ist es doch nicht ihr Fehler, wenn die Tür so gestaltet ist, dass ihre Bedienung unklar ist! Mit den Dialogprinzipien von oben würde man sagen: Die Selbstbeschreibungsfähigkeit war ungenügend.
Ich habe das Buch vor kurzem verliehen und als Fazit zurückbekommen, dass es anfangs sehr gut und überzeugend ist, aber nach eine Weile sich zu wiederholt. Das stimmt wohl, aber es hat auch viele gute Beispiele und bringt bis dahin Usability als Denkansatz gut rüber. Es geht über die Normen hinaus und gibt weitere Erklärungen, was gute Usability ausmacht und Beobachtungen, wie Nutzer Probleme angehen: Hilfreiche Dinge wie mentale Modelle und Seven stages of action.
Usability ist ein relativ weites Feld und HCI ist noch viel weiter. Aber gerade Usability ist faszinierend, weil es so wunderbar anwendbar und hilfreich ist. Und ich empfand immer eine große Anziehungskraft des Begriffs: Als jemand, der damals Software zu schreiben lernte wollte ich doch natürlich auch wissen, wie diese Software für gute Benutzbarkeit gestaltet zu sein hat. Auch heute ist das mein Anspruch.
Doch hier im Blog habe ich nur selten darüber geschrieben, selbst die fast allumfassende HCI-Kategorie ist relativ ungefüllt. Ich habe mir daher vorgenommen, noch etwas mehr über Usability zu schreiben. Vor allem, wie man dieses Konstrukt konkret nutzen kann um benutzbare Software zu gestalten.
Urheberrechtsreform: SPD und CDU dienen der Medienindustrie
Friday, 5. February 2021
Via Zeit.
Das war damals die Entgegnung auf die Vorwürfe der Demonstranten, zu denen auch ich mich zählte:
Die Union veröffentlichte im März 2019 einen Vorschlag, laut dem der Einsatz von Uploadfiltern insgesamt vermieden werden können sollte. Und das deutsche Justizministerium ließ in einer Protokollerklärung bei der Zustimmung zur EU-Richtlinie im Frühjahr 2019 verlauten, dass Uploadfilter "nach Möglichkeit" zu verhindern seien.
Und das kam bei raus:
Genau an diesem Punkt, der zuvor unter dem Stichwort Pre-Check hitzig diskutiert worden ist, dürften in vielen Fällen die heiß diskutierten Uploadfilter zum Einsatz kommen. Denn wie anders wären im Meer der minütlich hochgeladenen Inhalte sofort diejenigen zu erkennen, die einen Schnipsel enthalten, für den ein Sperrverlangen vorliegt und die zudem auch noch die Schranken für die Bagatellnutzung überschreiten? Der Gesetzgeber ist sich darüber im Klaren: Im Kabinettsbeschluss sind explizit Regelungen für den Fall definiert, dass es bei dieser Überprüfung zum "Einsatz automatisierter Verfahren" kommt.
Nichts ändert sich. Seit über einer Dekade kämpfen wir gegen die korrupte Unfähigkeit der Politikerkaste bei allem, was mit Internet, Urheberrecht und Datenschutz zu tun hat. Aber es bleibt konstant alles beim alten: CDU und SPD sind Parteien, die heute dem Volk das eine versprechen, um morgen im Auftrag von Lobbyisten das Gegenteil zu machen. Man kann es auch Verrat nennen. Diese "Volksparteien" haben keine einzige Wahlstimme verdient.
Serendipitys Social-Buttons mit Zähler aktualisiert
Thursday, 4. February 2021
Hier im Blog läuft das Plugin serendipity_event_social/Share Buttons, das unter den Einträgen per shariff umgesetzte datenschutzfreundliche 2-Klick-Buttons anzeigt. Mit denen kann man den Blogartikel in sozialen Netzwerken wie Twitter und Facebook teilen, aber ohne dass allein durch das Laden dieser Seite deren Code geladen wird. Das verhindert Überwachung.
Die Buttons funktionierten weiterhin, aber der Zähler war hier im Blog kaputt. Shariff hat auch ein Backend, das ich für alle Pluginnutzer auf meinem uberspace laufen lasse. Das Backend holt die Zahlen. Aber hier im Blog hatte ich es auf die falsche URL gestellt, das /
am Ende fehlte. Das ist nun korrigiert.
Die Gelegenheit habe ich genutzt, um auch das Backend zu aktualisieren - es lief noch eine ältere Version. Wohl dadurch war die Facebook-API deaktiviert worden, sie ist jetzt wieder an. Das Backend-Update war wohl generell notwendig. Wenn also auch bei euch im Blog der Zähler nicht funktionierte wäre nun ein neuer Test eine gute Idee.
Beim Serendipity-Plugin musste nichts geändert werden, nur die richtige URL habe ich jetzt dokumentiert.
Ich war mir sicher, über das Plugin hier im Blog bereits geschrieben zu haben. Aber ich finde keinen Artikel dazu, nur dass ich vor 9 Jahren schonmal mit shariff experimentiert hatte. Deshalb sei hier noch erwähnt, dass das Plugin mehr macht als nur die Buttons anzuzeigen: Es baut auch das HTML, um das erste genutzte Bild oder eine gesetzte Alternative bei diesen Kästen einzusetzen, die Seiten wie Twitter bauen wenn bei ihnen ein Artikel verlinkt wird. Was ich für ein nettes Feature halte.
Und damit wäre die Vorstellung nachgeholt.
Lärmfilter fürs Mikrofon unter Alsa
Monday, 1. February 2021
Ich möchte hier alsa_rnnoise vorstellen. Aber dafür muss ich erstmal das tolle NoiseTorch erwähnen. Es ist ein Programm, das den Umgebungslärm reduziert der vom Mikrofon aufgenommen wird. Wenn man via dem PC mit anderen Leuten spricht und sie nicht mit beispielsweise dem Tastaturlärm oder anderen Lärmquellen belästigen will ist das praktisch. Und auch wenn man Aufnahmen außerhalb eines isolierten Raums macht könnte es nützlich sein. Ich nutze NoiseTorch während der Arbeit am Laptop für unsere Telefonkonferenzen.
Aber weil es im Kern ein Pulsaudio-Plugin ist funktioniert es für mich nicht am heimischen, mit ALSA eingerichteten PC. NoiseTorch hat auch ein paar Macken, wie die hohe Prozessorlast selbst ohne Sound-Input, die aber an Pulseaudio hängt – was mich darin bestärkt weiterhin kein Pulseaudio zu installieren. Deswegen ist es für mich besonders toll, dass der Entwickler arsen sich die Mühe gemacht hat ein ALSA-Plugin mit der gleichen Kernfunktionalität zu bauen. Eben alsa_rnnoise. Das namensgebende RNNoise ist das neuronale Netzwerk, das auch NoiseTorch benutzt um Lärm wegzufiltern.
Installation
Weder RNNoise noch alsa_rnnoise waren für void gepackt, daher musste ich beides manuell installieren. Was sich zusammen mit der folgenden ALSA-Konfiguration ein bisschen anfühlte wie Linux vor einer Dekade. Aber wer modernen Komfort will könnte sich ja an NoiseTorch mit Pulseaudio halten. Zum Glück beschreibt die jeweilige Readme fast vollständig was zu tun ist.
Stell erstmal sicher, dass alsa-dev installiert ist:
sudo xbps-install alsa-lib-devel
Dann installiere RNNoise:
git clone https://gitlab.xiph.org/xiph/rnnoise.git cd rnnoise ./autogen.sh ./configure make sudo make install
Die Libraries von RNNoise werden so nach /usr/local/lib/ gepackt.
Den Ordner von RNNoise müssen wir bei der Installation von alsa_rnnoise dem Buildsystem mitteilen, ebenso wie den richtigen Ordner für ALSA-Plugins:
PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/:/usr/lib/pkgconfig/:/usr/lib64/pkgconfig/ meson build -Dplugin_dir=/usr/lib/alsa-lib/ ninja -C build sudo ninja -C build install
Damit ist das System bereit um ALSA zu konfigurieren. Die Readme schlägt diese Konfiguration vor, die in der $HOME/.asoundrc zu platzieren wäre:
pcm.urnnoise { type rnnoise slave.pcm "sysdefault" } pcm.rnnoise { type plug slave { rate 48000 pcm "urnnoise" } } pcm.!default { type asym playback.pcm "cards.pcm.default" capture.pcm "rnnoise" }
Bei mir muss da aber noch das softvol-Plugin dazwischen, da mein t.bone MB 88U sonst zu leise ist, plus eine manuelle dmix-Konfiguration. Daher sieht die .asoundrc bei mir etwas anders aus:
pcm.!default { type asym playback.pcm { type plug slave.pcm "dmixer" } capture.pcm rnnoise } ctl.!default { type hw card "PCH" } pcm.softvol { type softvol slave.pcm "hw:Device" control { name "Softmaster"; card "Device"; } max_dB 20.0 min_dB -5.0 } pcm.urnnoise { type rnnoise slave.pcm "softvol" } pcm.rnnoise { type plug slave { rate 48000 pcm "urnnoise" } } pcm.dmixer { type dmix ipc_key 1024 slave { pcm "hw:PCH" buffer_size 16384 period_time 0 period_size 1024 } }
Der Filter funktionierte so direkt.
Soundtest
Aber funktioniert er auch gut, lohnt sich der Aufwand? Ich habe ein paar Testaufnahmen gemacht um das einzuordnen. Eingebunden sind unkomprimierte .wav-Dateien, die auf .ogg zurückfallen falls der Browser mit ersteren nicht umgehen kann (mit ffmpeg umgewandelt, maximale Qualität).
Ohne Lärm
Im ersten Test habe ich in einem ruhigen Raum ohne besondere Lärmquelle kurz in das Mikrofon gesprochen. Hier sollte der Filter im Idealfall kaum wahrnehmbar sein, auf jeden Fall sollte er die Stimme nicht abschneiden. Doch hört selbst wie es lief.
Ich fand das Ergebnis gut. Der Raum klingt ein bisschen anders, oder? Aber ich habe nicht den Eindruck, dass es schlechter klingt oder meine Sprache abgehackt wird. Da auch die Prozessorlast nicht hoch war ein erster Hinweis, dass alsa_rnnoise immer anbleiben könnte.
Mit Tastaturlärm
Regulären Lärm wie das Klappern der Tastatur rauszufiltern oder zu reduzieren wäre mir am wichtigsten. So könnte ich guten Gewissens in Gesprächen das jeweilige Programm nicht auf Push-To-Talk stellen. Und wenn sowas funktioniert, dann wird wahrscheinlich auch ein in der Ferne vorbeifahrendes Auto weggefiltert.
Ein gutes Ergebnis! Wenn ich nicht spreche ist die Tastatur weg, wenn ich spreche ist sie leiser. Und sie ist vorher ja sehr laut, gar nicht mal nur das Klicken der Tasten, sondern da wurden auch die Schwingungen des Tisches übertragen. Als ob ich auf die Tastatur hämmern würde, dabei tat ich das gar nicht.
Wenn ich während eines Gespräches mal tippen müsste wäre der Lärmfilter sehr hilfreich.
Mit einem Staubsauger an der Seite
Ich dachte, wenn ich einen Handstaubsauger anmache wäre ich ohne Filter nicht zu hören und mit Filter vielleicht etwas, wobei ich andererseits fürchtete, dass das zuviel erhofft ist. Tatsächlich funktionierte es nicht, aber anders als erwartet.
Die Aufnahme ohne Filter war besser als erwartet, weil trotz des Lärms meine Stimme aufgenommen wurde und sogar verständlich blieb. Mit dem Filter dagegen war zwar der Staubsaugerlärm reduziert, aber war leider auch meine Stimme immer wieder verzerrt. Als ob die Aufnahme übersteuern würde, wobei ich mir ziemlich sicher bin nicht wesentlich lauter geredet zu haben als bei der ersten Aufnahme. Bei solchem extremen Lärm liegt bei alsa_rnnoise wohl eine Grenze, ob es jetzt am Alsaplugin oder am RNNoise-Kern selbst liegt kann ich nicht sagen.
Fazit
NoiseTorch ist derzeit natürlich schon einfacher zu installieren und zu konfigurieren, aber ich sehe großes Potential in der ALSA-Lösung. Sie könnte einfach von Distributionen ausgeliefert werden und wir dann eine Konfigurationsoption davon entfernt sein, automatisch die Sprachaufnahmen aller Linuxnutzer verbessern zu können. Egal ob das Aufnahmen für Podcasts oder VoIP-Gespräche sind. Damit das machbar wird sollte mit Aufnahmen während extremen Umgebungslärms etwas besser umgegangen werden. Andererseits dürfte niemand erwarten bei solchem Lärm gut verstanden zu werden, daher ist das in der Praxis vielleicht ein relativ kleines Problem.
Ich bin gespannt was draus wird. Bei meinem System lasse ich das jetzt einfach erstmal an und schaue, ob es sich bewährt.
Open-World in Bestform bei Mad Max
Friday, 29. January 2021
Das 2015 etwas nach dem Release des hervorragenden Films Mad Max: Fury Road veröffentlichte Spiel zu Mad Max ging trotz positiver Tests wohl ziemlich unter, zumindest hörte man schnell nichts mehr davon. Auch kein gutes Zeichen: Der ins Hauptmenü gesetzte Menüpunkt DLC führt zu einer leeren Shopseite, die Online-Funktionen werden abgeschaltet. Also werden es viele nicht gespielt haben, und das ist ein Verlust – denn Mad Max ist richtig gut.
Szenario
Mad Max ist eigentlich eine Filmreihe, bei der bis zu Fury Road Mel Gibson die Hauptrolle spielte. Es ist wieder mal eine postapokalyptische Dystopie und ähnelt daher etwas Fallout, aber es kommt ohne dessen schwarzen Humor aus. Stattdessen ist diese Zukunftsversion viel mehr verstörend, mit zu Monstern verkommenen Menschen, lebensfeindlichen Wüstenlandschaften und aus dem verbliebenen Schrott der Zivilisation zusammengeklaubten Unterschlüpfen – und vor allem Autos. Ganz vielen Autos, mit denen sich die Überlebenden bekriegen und wobei Benzin selten ein Mangel ist. Max ist einer dieser Fahrer und auch er ist eine ziemlich beschädigte Figur, wenn auch etwas weniger auf einem wahnsinnigen Vernichtungstrip als seine üblichen Antagonisten.
Das Spiel jetzt setzt die Handlung in die Nähe des letzten Films, der wiederum keine klare Kontinuität mit den vorherigen Filmen hatte. Es ist immer noch so in etwa die gleiche Welt und die gleiche Figur, aber es gibt selten eindeutigen Verweise auf was vorher passiert. Im Spiel sind ein paar mehr als im Film war, so wird die Donnerkuppel zitiert (Two men enter; one man leaves!). Und es gibt klare Verweise auf den Film, der Bösewicht ist gebaut wie einer der Verbündeten des Film-Bösen.
Die Handlung ist ansonsten simpel: Zu Beginn verliert Max im Kampf gegen Scrotus sein Auto. Doch er trifft auf den buckeligen Mechaniker Chumbucket, der ihm ein neues bauen kann. Allerdings reicht der verbaute V6-Motor Max nicht, er will einen V8. Den könnte er in Gastown gewinnen. Aber dort muss er erstmal hinkommen, eine in der Haupthandlung zu überwindende Mauer und viele Gegner wie Nebenmissionen trennen ihn von der auch im Film erwähnten Stadt.
Viel zu tun in der offene Welt
Das Spiel ist ein Actionspiel mit RPG-Elementen in einer offenen Welt und daher vom Genre in der gleichen Kategorie wie ein Assassin's Creed oder Far Cry. Und als dystopische Version dieser Spiele könnte man es auch treffend beschreiben. Allerdings gibt es ein sehr viel wichtigeres aufrüstbares Auto, dafür weniger reguläre Waffen, und funktioniert das Spielkonzept wirklich gut.
In der Spielwelt sind eine Reihe von Feinden und Orte verteilt, die unterschiedlich viel Aufmerksamkeit und Zeit beanspruchen.
Zuerst fährt natürlich nicht nur der Spieler in der Gegend herum. Sondern auch eine ganze Menge an Feinden, meist die Warboys von Scrotus, die mit ihren Autos direkt den Wagen des Spielers angreifen werden. Wer nicht flieht steckt immer wieder in Autokämpfen, bei denen die Fähigkeiten des Wagens wie die Harpune oder Maxs Schrotflinte zum Einsatz kommen werden.
Zivilisten gibt es auch, sie teilen Informationen oder Schrott, beteiligen sich ansonsten aber nicht an den Kämpfen.
Bei den Orten stolpert man zunächst über die Scarecrows, aus Metall und Leichen zusammengehaltene Feuertürme. Max kann sie mit seiner Harpune niederreißen, was den Gefährdungsfaktor des Sektors etwas senkt und sammelbaren Schrott hinterlässt.
Ähnlich funktionieren die Scharfschützentürme, nur schießen die halt zurück und ist der Lohn nicht Schrott, sondern Munition und von einem Ort weniger beschossen zu werden.
Schrott, Munition und manchmal Erinnerungsstücke der Zivilisation finden sich an den gelb markierten neutralen Orten, bei denen aber auch immer ein paar Banditen sich aufhalten und was aufs Maul wollen.
Das gilt meistens auch für die Aussichtsorte. Bei ihnen gibt es aber noch einen Heißluftballon, mit dem man aufsteigt und so die Umgebung erkunden kann. Das Pendant zum Erklimmen von Türmen in anderen Open-World-Spielen samt Markierung anderer Orte auf der Karte. Einmal erkundet dienen diese Orte dann noch als Schnellreisepunkt und bleiben feindeslos.
Aber es sind die Festungen der Verbündeten, die eher als gute Rückzugsorte dienen. Sie alle sind Teil der Haupthandlung. Da ist zum Beispiel die Mannschaft eines riesiges Schiffs, das mitten in der Wüste auf einem Hügel festsitzt, wobei die Bewohner auf die Rückkehr des Ozeans warten. In diesen Festungen gibt es immer ein paar Nebenmissionen und wer an den anderen Orten die richtigen Kisten findet kann in ihnen Stationen aufbauen. Danach bekommt man bei jedem Besuch der Festung z.B. den Wasserkanister aufgefüllt.
Und natürlich haben auch die Feinde Basen. Die sind oft ebenfalls fantastisch in die kaputte Welt integriert. Es gibt dabei verschiedene Arten von feindlichen Festungen, bei der einen muss beispielsweise der Ölförderturm in die Luft gejagt, bei einer anderen alle Gegner besiegt werden. Diese Orte werden einmal befreit von Alliierten in Besitz genommen und bringen regelmäßige Schrotteinnahmen.
Ein Auto-RPG, ein Survivalgame?
Mit dem Schrott und wenn die Gebiete der Verbündeten ausreichend befriedigt wurden schalten sich immer weitere Upgrade frei, die den eigentlichen Star des Spiels verbessern: Das Magnum Opus getaufte Auto. So wird es schneller, bekommt einen Flammenwerfer, bessere Panzerung und einiges mehr. Manche der Upgrades sind auch ans Bewältigen von Haupt- oder Nebenmissionen gebunden, wie der erwähnte V8-Motor. Tatsächlich machen die Verbesserungen ordentlich was aus, gerade wenn die Autos der Gegner anfangen gepanzert zu werden ist nach etwas investiertem Schrott der Unterschied im Kampf deutlich spürbar.
Und auch Max bekommt Upgrades, die verbessern ihn dann in den Faustkämpfen, die er immer wieder zu erledigen hat wenn er zu Fuß unterwegs ist. Das ist ähnlich wie in den Batmanspielen: Linksklicken zum Angreifen, langer Klick für einen stärkeren langsamen Angriff, wenn ein Gegner angreift muss mit rechter Maustaste gekontert werden. Dazu kommt die Schrotflinte, kurzzeitig verwendbare Nahkampfwaffen und ein paar andere Kampffähigkeiten wie Shims oder später freischaltbare Zusatzfähigkeiten. Außerdem gibt es für Errungenschaften (wie den Zornzustand durch gute Kampfkombinationen in wenigen Sekunden zu erreichen) Punkte, die bei einem Schamanen in weitere Boni umgewandelt werden können.
Max kann nur wenig Munition mit sich rumschleppen. Er heilt sich über das Wasser im Kanister, das nicht gerade viel ist. Und selbst das Benzin im Auto geht mit der Zeit aus. Anfangs wirkt Mad Max daher wie ein Survivalspiel, bei dem knappe Ressourcen sorgsam verwaltet werden sollen. Doch das ändert sich schnell: Überall liegt alles rum was Max braucht, Benzin z.B. gibt es im Überschuss und regeneriert auch noch. Dazu sind die meisten Schamanenupgrades solche, die den Ressourcenmangel entgegenwirken, sodass z.B. mehr Schrott und Wasser gefunden wird. Wenn dann noch ein paar Stationen in den Festungen gebaut wurden ist der Ressourcenmangel komplett vorbei. Immerhin bleibt der Munitionsmangel ein Thema, weil eben nur wenig mitgenommen werden kann, wodurch die Kämpfe interessant bleiben und beim Spielen eben doch etwas rationiert werden muss.
Schnell, hübsch und gutklingend
Positiv überrascht war ich von der Technik des Spiels. Gut, es ist nicht ganz neu, aber das ist mein PC ja auch nicht. Ich hatte absolut stabile 75 FPS, das bei meinem Monitor durch FreeSync gegebene Maximum. So wirken die Fahrten viel besser als wenn es geruckelt hätte. Dabei sieht Mad Max stellenweise toll aus, die diversen Wüstenlandschaften insbesondere. Auch die düstere Umgebung von Gastown ist klasse gemacht und die Autos sind genau so faszinierend gepanzerte coole Schrottkisten wie in den Filmvorbildern. Die in tolle Explosionen aufgehen, wobei auch Feuer und Rauch stark wirken.
Mit gutklingend meine ich besonders die Motoren. Die Musik steht nicht stark im Vordergrund. Und obwohl die Sprecher ausnahmslos gut waren: Es ist der V8-Motor, der genau so klingt wie er klingen soll und generell die Autokämpfe, die eine tolle Soundkulisse schaffen.
Vereinzelte Bugs und die verschwundene Linuxversion
Anders als die Psyche von Mad Max ist das Spiel Mad Max sehr stabil. Ich sah nur vereinzelte Bugs. So blieb in einem Gespräch mit einem Zivilisten der Sound weg, ein anderes endete mit einem schwarzen Bildschirm, nachdem währenddessen ein kleiner Wirbelsturm die Spielfigur in die Höhe riss. Fragwürdiger ist da die Linuxversion. Mad Max wurde eigentlich von Feral portiert und diese Version auch per Steam verteilt. Mittlerweile aber wird sie nicht mehr auf der Steamseite erwähnt und tatsächlich startete sie bei mir nicht (wobei Feral-Portierungen auf meinem System generell seltenst funktionierten), die Windowsversion mit Proton-5.21-GE1 lief dann auch unter Linux einwandfrei.
Die Mischung machts
Ich habe bisher im Grunde nur aufgezählt was im Spiel drin ist und bin dabei noch nicht mal fertig. Es gibt zudem noch Rennen, Stürme, von Zivilisten vergebene Missionen, die Basen haben Verteidigungsmechanismen und Sammelitems gibt es auch noch. Mad Max ist prall gefüllt. Aber das macht ein Spiel noch nicht gut. Andere Open-World-Spiele sind eher abschreckend, wenn es an jeder Ecke etwas anderes zu tun gibt.
Das besondere an Mad Max ist wie gut die Elemente zusammenpassen. Da ist erstmal das Szenario, das vollumfänglich ausgenutzt wird um absurde Charaktere wie Chumbucket mit seiner religiösen Verehrung des Automobils zu platzieren oder auch schillernde Gegenfiguren wie die Kurtisane Hope. Die Hauptmissionen führen in die Festungen, die mit ihren Upgrades und Nebenmissionen Motivation geben die Spielwelt zu erkunden. Das wiederum schafft Bedarf für die Upgrades von Max und dem Magnum Opus, was ebenfalls durch das Erkunden der Spielwelt bedient werden kann. Und dann funktioniert es eben wenn in der Spielwelt einiges los ist, es überall Scarecrows umzustürzen und feindliche Basen zu erobern gibt, ohne dass die Aktivitäten sich zu sehr unterscheiden als dass es verwirren würde. Es hilft auch, dass es mit dem Metallschrott nur eine einzige Sammelressource gibt. Und dass das Spiel auch deutlich macht: Du musst das alles nicht tun, da drüben ist der grüne Punkt der zur nächsten Hauptmission führt. Etwas 40 Stunden habe ich so im Spiel verbracht, was für ein Einzelspieler-Actionspiel sehr ordentlich ist.
Außerdem ist es endlich mal ein gutes Spiel zu einem guten Film. Auch wenn Max im Spiel nicht aussieht wie Max im Film, ist es doch klar die gleiche Welt, bedient sich Film wie Spiel der gleichen Elemente und Atmosphäre und baut dabei das Computerspiel dieses Universum ein bisschen weiter aus als ein Film es könnte. Erhalten bleibt auch der Fokus auf das Auto und auf Autoschlachten, was größtenteils durchaus Spaß macht.
Nur stellenweise wird das etwas zum Manko, wenn später die gegnerischen Wagen ziemlich viel aushalten und man eigentlich keine Lust mehr hat, schon wieder Minuten darein zu investieren sie kaputtzurammen. Dann aber hat man meist auch andere Optionen wie den Flammenwerfer, man muss sich nur überwinden deren Munition auch einzusetzen.
Ein paar der Sammelelemente hätten auch nicht sein müssen. So kann man Convoys vernichten und dadurch Trophäen für das Magnum Opus sammeln, welche die Werte verbessern. Die Kämpfe sind nett, nur dass die Upgrades sich wiederholen und jeder Bonus der gleichen Kategorie so stark ist wie der andere. Die findbaren Zivilisationsartefakte sind okay wenn Max einen Kommentar abgibt, aber sie zu sammeln gibt das Spiel außer einer Prozentanzeige keinen Grund. Und warum man feindliche Wagen kapern und in die eigene Garage stellen sollte bleibt auch unklar, ist der Magnum Opus doch schneller, stärker, besser zu steuern – und wiegt durch die anderen Wagen erstmal von Gegnern ignoriert zu werden das nicht auf.
Aber das sind sind kleine Macken in einem ansonsten tollen Spiel, das mit Story, Grafik, Spielmechaniken und vor allem dem Szenario super ansprechend ist. Wer ein bisschen was übrig hat für diese Art von Open-World-Actionspielen sollte es nicht weiter ignorieren.