Von iA Writer direkt ins Blog

Mit der neusten Version des iA Writer, der von mir geschätzten Software zum Schreiben, ist es möglich Texte direkt in selbst gehostete WordPress Blogs oder andere Blogs zu veröffentlichen, die Micropub unterstützen.

Um direkt in selbst gehostete WordPress Blogs zu veröffentlichen können zwei Wege gewählt werden:

1. IndieAuth

Üm über IndieAuth direkt aus iA Writer heraus in Deinem WordPress Blog Artikel zu veröffentlichen, musst Du das IndieAuth-Plugin installieren, und dieses einrichten.

Danach öffnest Du unter Einstellungen > Accounts und fügst einen WordPress-Account hinzu.

2. Micopub

Ähnlich funktioniert es mit der Nutzung des Micropub-Standards. Da es sich hierbei um einen offenen Standard handelt kann er auch für viele weitere Blogsysteme verwendet werden, sofern sie diesen Standard unterstützen. Für WordPress kann er über das Micropub-Plugin verwendet werden.

Ist das Plugin installiert und eingerichtet, wird das Blog ebenfalls unter Einstellungen > Accounts über die Auswahl Microblog hinzugefügt.

Es lassen sich auf diese Weise mehrere Accounts innerhalb des iA Writer anlegen. Ordnen und umbenennen der Accounts ist selbstverständlich auch möglich. Was aus meiner Sicht perfekt ist, da so mehrere Blogs direkt aus der Applikation heraus mit Inhalten versorgt werden können. Die Texte selbst werden nicht direkt veröffentlicht, sondern zunächst als Entwürfe angelegt – dies ist meiner Ansicht nach eine sehr gute Entscheidung der Entwickler:innen, da es den Bloger:innen einen Blick auf den Artikel im Blog ermöglicht, bevor dieser das Licht der Welt erblickt.

Vielen Dank an die Information Architects für diese hilfreiche Erweiterung des iA Writers, und die Unterstützung offener Standards! Ein Blogpost zu diesen und weiteren Neuerungen findet sich wie gewohnt in deren Blog.

Fairness und Respekt

Im Verlag des Smashing Magazine ist recht frisch The Ethical Design Handbook von Trine Falbe, Kim Andersen, and Martin Michael Frederiksen erschienen. Dabei handelt es ich um ein zeitgemäßes Buch in dem es darum geht digitale Produkte zu entwickeln, die Entscheidungen der Nutzer*innen respektieren und mit Blick auf ethische Prinzipien konzipiert, gestaltet und entwickelt wurden.

In der Einleitung definieren die Autor*innen ethisches Design folgendermaßen:

»Businesses, products, and services that grow from a principle of fairness and fundamental respect towards everyone involved.«

Bereits hier wird deutlich, dass ethisches Design sich nicht auf Produkte beschränkt, sondern nur dort entstehen kann, wo der Umgang miteinander von Fairness und Respekt geprägt ist. Ethisches Design kann somit als Haltung verstanden werden, die sich sowohl in der Unternehmenskultur, in den Produkten und den Dienstleistungen zeigt. Unternehmen, Produkte und Dienstleistungen, die aus einer Haltung der Fairness und des fundamentalen Respekts gegenüber allen Beteiligten erwachsen, verkörpern dementsprechend ethisches Design.

Im ersten Kapitel sprechen die Autor*innen über die Notwendigkeit von ethischem Design. Anhand von einigen Beispielen bekannter Unternehmen und deren digitaler Produkte erläutern sie welche Bedeutung ethisches Design für die Nutzer*innen hat.

»Unethical design is problematic: It reduces freedom, compromises privacy and safety, and can cause addiction. A wide range of companies seem to think it’s acceptable to use manipulative methods to steer users into certain behavioural patterns.«

Auch wenn so genannte ›dark patterns‹ gerne als alternativlos dargestellt werden, um das gewünschte Ergebnis zu erzielen, machen die Autor*innen deutlich, dass ein Geschäftsmodell nicht ethisch ist, wenn es dem Paradigma eines ›Du willst es doch auch‹ folgt, und Nutzer*innen hinters Licht führt und sie* zu Handlung überlistet zu denen sie* sich nicht entschieden hat.

Freiheit, Privatsphäre und Sicherheit sollten niemals geopfert werden, um Erfolg zu haben. Vertrauen der Nutzer*innen dem Unternehmen, Produkt und der Dienstleistung gegenüber ist wichtig und sollte sorgfältig gepflegt werden. Die DSGVO stellt nach Ansicht der Autor*innen ein regulierendes Element dar, das auch als extrinsische Motivation verstanden werden kann, jede Person die mit dem Unternehmen, Produkt oder der Dienstleistung in Berührung kommt fair und respektvoll zu behandeln.

Design umschreiben

«Sometimes the writing isn’t done because we’re trying to solve everything with “pure design.” Supposed UX thought leaders throw around baloney like “Good design doesn’t need explanation” and “If you have to use words, you’ve failed.” Come on. I hope my pilot knows what all those switches in the cockpit do, but I also hope they’re labeled, just in case.»

Scott Kubie, Writing For Designers.

Das Ergebnis des Designprozesses sollte so selbsterklärend wie möglich sein, keine Frage. Da es sich jedoch immer um eine Abwägung unterschiedlicher Ansätze und Entscheidungen handelt, bleibt die Notwendigkeit das Design zu umschreiben. Also mit Worten zu erklären wie es zu diesem Ergebnis kam und welche konzeptionellen Überlegungen eingeflossen sind.

Die Benutzung des Produkts sollte ebenfalls so intuitiv wie möglich funktionieren, dennoch ist es – wie von Scott Kubie in obigem Zitat angedeutet – hilfreich eine zweite Ebene zu haben, die erklärend zur Seite steht und dadurch die Benutzung erleichtert.

Diese beiden Gedanken können, wie die zitierte Haltung gutes Design komme ohne Worte aus, als Allgemeinplätze verstanden werden, dennoch möchte ich sie für mich festhalten und besser darin werden meine Arbeit kurz und prägnant zu umschreiben und die angesprochene zweite Ebene direkt mitzubedenken.

Information verändert sich

«The creative organization of information creates new information,» wrote architect Richard Saul Wurman. This axiom is at the core of our work. When we organize information—that is, when we structure it, order it, display it, label it, connect it—we alter it. We change how information will be perceived, for better or for worse.

Lisa Maria Martin, Everyday Information Architecture.

Durch die Organisation von Information entsteht neue Information, schrieb Richard Saul Wurman, auf den der Begriff Information Architect zurückgeführt wird. Da sich Information verändert, je nachdem in welchem Kontext sie steht, wie sie angeordnet ist und wie sie dargestellt wird, ist es wichtig mit Information sorgfältig umzugehen.

Merkzettel für die Kommandozeile

Die Kommandozeile ist eine treue Begleiterin meiner Arbeit. Für einige Kommandos habe ich mir Aliase angelegt, andere benutze ich jeden Tag und kann sie mir daher gut merken, doch es gibt auch andere, die ich nur ab und an verwende und bei denen ihr mir nie so ganz sicher bin. Zwei davon halte ich heute hier fest, um nächstes Mal direkt zu wissen wo ich nachschauen kann.

Benutzername und Passwort erzeugen

Um die Entwicklung eines Projekts mit Kund*innen oder Koleg*innen abzustimmen, verwende ich ab und zu einen durch ein Passwort geschützten Bereich auf meinem Server. Benutzernamen und Passwort verwalte ich in einer htaccess-Datei, die das Passwort nicht als Klartext, sondern als Hash, enthält. Eine solche Benutzernamen-Passwort-Kombination lässt sich über das Kommando htpasswd ganz einfach in der Shell erzeugen. Die Ausführung des Kommandos kann über Parameter angepasst werden. Das folgende Kommando erzeugt eine Benutzername-Passwort-Kombination, die direkt in der Shell ausgegeben wird:

htpasswd -nmb BenutzerName G4nz5ichere5Pa$$w0rt

Die verwendeten Parameter bedeuten folgendes:

-n
Ergebnis nicht in eine Datei ablegen, sondern in der Shell ausgeben.
-m
Hash des Passworts mittels MD5 erzeugen
-b
Passwort der Eingabe nutzen, und nicht extra danach fragen.

Wird das letzte -b weggelassen fragt die Shell nach dem Passwort, wodurch dieses nicht im Klartext auf dem Bildschirm erscheint. Dieses Vorgehen ist auch deswegen sicherer, da sich das Passwort nicht im Verlauf der Shell befindet, und daher nicht ausgelesen werden kann. Eine etwas sichere Methode zur Erstellung einer Benutzername-Passwort-Kombination sieht demensprechend so aus:

htpasswd -nm BenutzerName

Wie bereits angedeutet fragt die Shell nach der Bestätigung des Kommandos das Passwort ab – dieses wird auch bei der Eingabe nicht angezeigt – nach wiederholter Eingabe des Passworts erscheint die erzeugte Kombination in der Shell und kann in die htpasswd-Datei kopiert werden.

Eine kurze Dokumentation zur Verwendung des Kommandos kann über den Parameter --h in der Shell ausgegeben werden:

htpasswd --h

Die erzeugte Benutzername-Passwort-Kombination lässt sich auch direkt in eine Datei schreiben. Das ist sowohl lokal als auch direkt auf dem Server mittels SSH-Tunnel möglich. Bisher kopiere ich die neu angelegten Kombinationen von Hand in die Datei, vielleicht ändere ich das aber demnächst.

Mit externen Repositories arbeiten

Alle meine Projekte versioniere ich per Git, und seit ich Git For Humans von David Demaree gelesen habe, mache ich das meist in der Shell. Kürzlich wollte ich die URL eines externen Repositories verändern, weshalb ich kurz etwas dazu schreiben möchte.

Zunächst ist es wichtig zu sehen welche externen Repositories mit meinem Projekt verbunden sind. Das erledigt:

git remote -v

Dieses Kommando zeigt eine Liste der entfernten Repositories an, die aus den Namen, den URLs und den verfügbaren Kommandos besteht. Fällt mir nun auf, dass ein externes Repository fehlt, kann ich es über folgendes Kommando hinzufügen:

git remote add origin ssh://user@server.net/home/user/repos/mein-repo.git

Falls schon ein anderes externes Repository mit diesem Namen angelegt ist, bekomme ich einen Fehler, worauf entweder das Bestehende umbenannt, oder das neue externe Repository anders benannt werden kann:

git remote rename origin destination

origin wäre hier der bisherige Name, destination entsprechend der Neue.

Falls sich an der URL des externen Repository etwas verändert, sei es der Benutzername, der Pfad oder der Name des Repos, kann die URL folgendermaßen angepasst werden:

git remote set-url origin user@server.net/home/user/repos/mein-repo.git

Ausführliche Erläuterungen rund um die Arbeit mit entfernten Repositories finden sich in der Git-Dokumentation.

Micro Blogging im eigenen Blog

In seinem aktuellen Artikel ›Untitled‹ schreibt Matthias Pfefferle darüber wie die Nutzung des eigenen Blogs für mehr als klassische Blogartikel™ sowohl die Blogs als auch die Feedreader verändert.

Im Sinne von micro Blogging, das der Nutzung von Twitter entspricht, werden immer öfter kurze Posts in Blogs veröffentlicht, die ein Bild, ein Zitat oder eben ein paar Sätze beinhalten. Diese kurzen Updates erscheinen ohne Titel, da der Inhalt für sich steht.

Alle Formen des Bloggens auf eine Plattform zu vereinen, und die Inhalte von dort aus in die unterschiedlichen Netzwerke zu verteilen, kann ich sehr gut verstehen. Die Möglichkeit nach Gedanken, Links und Zitaten in meinem Blog zu suchen ist mir sehr viel Wert. Für Fotos und Zitate habe ich das Vorgehen in meinem Blog getestet, es aktuell aber pausiert, da diese Art der Nutzung des eigenen Blogs meiner Ansicht nach einiger Einstellungen bedarf:

  • Die unterschiedlichen Veröffentlichungsarten würde ich durch Kategorien oder Post-Typen ordnen.
  • Längere Artikel und kurze Veröffentlichungen würde ich strukturell und visuell voneinander abheben.
  • Die kurzen Veröffentlichungen würde ich aus dem Feed nehmen, oder zumindest explizit einen Artikel-Feed anbieten.

Solche Grundentscheidungen helfen meiner Ansicht nach dabei das eigene Blog weiterhin attraktiv zu halten. Die Nutzer*innen bekommen dadurch die Möglichkeit sich gezielt darauf zu bewegen und finden sich in den unterschiedlichen Sparten gut zurecht.

Homebrew Website Club

Gestern fand der zweite Homebrew Website Club in Karlsruhe statt. Der Homebrew Website Club ist ein regelmäßiges Treffen von Personen, die leidenschaftlich dabei oder interessiert sind, ihre eigene Website zu konzipieren, designen, entwickeln und zu verbessern.

In diesem Sinne tauschten wir uns über die eigenen Webseiten, Arbeitsweisen und aktuelle Projekte aus. Wir sahen uns das ActivityPub-Plugin von Matthias an. Das Plugin erweitert WordPress durch das ActivityPub-Protokoll, wodurch das Blog beispielsweise mit Mastodon kommunizieren kann – neue Artikel werden dort publiziert und Reaktionen fließen zurück ins Blog.

Die Teilnehmer des Homebrew Website Club am 20.02.2019 in Karlsruhe

Falls Du vorhast bei einem der nächsten Treffen dabei zu sein, kannst Du Dir schon Mal die kommenden Termine eintragen:

  • 20.03.
  • 17.04.
  • 15.05.
  • 26.06.
  • 10.07.
  • 07.08.
  • 18.09.
  • 15.10.
  • 13.11.
  • 11.12.

Der Karlsruher Homebrew Website Club trifft sich jeweils um 18:30 Uhr im NUN Kulturraum, Gottesauer Straße 35, 76131 Karlsruhe.

Alle Termine können auch über diesen Kalender abonniert (ICS-Datei) werden.

Wie werden heute Webseiten entwickelt

Was die Entwicklung der Benutzeroberfläche von Webseiten angeht, ist eine Kontroverse sichtbar, die sich an der Schwerpunktsetzung von Kompetenzen und verwendeten Sprachen und Techniken entzündet. Wer auf Twitter ein paar Entwickler*innen folgt, sich Projektausschreibung oder Jobangebote durchliest, stößt sehr schnell auf die gewachsene Bedeutung von JavaScript und den darauf basierenden Bibliotheken. Anhand der Fragestellung zu vorausgesetzten Arbeitsweisen und damit einhergehenden Bewertungen entspannt sich ein Konflikt.

Chris Coyier von CSS-Tricks spricht in diesem Zusammenhang von »The Great Divide« und erkennt zwei unterschiedliche Schwerpunktsetzungen:

  • Auf der einen Seite sind Entwickler*innen deren Interessen, Verantwortlichkeiten und Können sich hauptsächlich auf JavaScript konzentriert.
  • Und auf der Anderen finden sich Entwickler*innen deren Interessen, Verantwortlichkeiten und Können sich auf andere Bereiche der Benutzeroberfläche wie HTML, CSS, Design, Interaktionen, Strukturen, Accessibility fokussiert.

Der Artikel »The Great Divide« auf CSS-Tricks lohnt sich auch deshalb zu lesen, da Chris Coyier einige wichtige Stimmen aufgreift, wodurch Breite und Bedeutung des Konflikts deutlich wird, und zur Schärfung des Begriffs ›Front-End Development‹ anregt.

Als ich vor ungefähr fünfzehn Jahren begann mich intensiver mit Design und Entwicklung von Benutzeroberflächen zu beschäftigen, fand ich bei Entwickler*innen um Jeffrey Zeldman mit dem Schwerpunkt auf Webstandards meine Inspiration. Aus diesem Grund widmete ich mich in erster Linie semantischem Markup (HTML) und validen Stylesheets, so dass alle Inhalte für Mensch und Maschine lesbar sind. Die Bedeutung von JavaScript war dem nachgeordnet und diente der Interaktivität und Anreicherung von Inhalt und Erlebnis auf der Webseite.

In diesem Sinne verstehe ich den Artikel »HTML, CSS and our vanishing industry entry points« von Rachel Andrew. Rachel Andrew führt aus, dass am Ende HTML und CSS vom Browser interpretiert werden, und dass es daher wichtig ist diese beiden Sprachen flüssig zu sprechen. Des Weiteren weist sie auf die Abstraktion hin, die durch die Betonung von JavaScript und die entsprechenden Bibliotheken, dem Entwickeln von Benutzeroberflächen hinzugefügt wird, wodurch der Einstieg in die Entwicklung von Webseiten erschwert wird.

There is something remarkable about the fact that, with everything we have created in the past 20 years or so, I can still take a complete beginner and teach them to build a simple webpage with HTML and CSS, in a day. We don’t need to talk about tools or frameworks, learn how to make a pull request or drag vast amounts of code onto our computer via npm to make that start. We just need a text editor and a few hours. This is how we make things show up on a webpage.

That’s the real entry point here and yes, in 2019 they are going to have to move on quickly to the tools and techniques that will make them employable, if that is their aim. However those tools output HTML and CSS in the end. It is the bedrock of everything that we do, which makes the devaluing of those with real deep skills in those areas so much more baffling.

[…]

I might be the “old guard” but if you think I’m incapable of learning React, or another framework, and am defending my way of working because of this, please get over yourself. However, 22 year old me would have looked at those things and run away. If we make it so that you have to understand programming to even start, then we take something open and enabling, and place it back in the hands of those who are already privileged. I have plenty of fight left in me to stand up against that.

Rachel Andrew: HTML, CSS and our vanishing industry entry points

Entwickler*innen wie Rachel Andrew sprechen sich daher auch für die Notwendigkeit aus, HTML, CSS und JavaScript in der Tiefe zu kennen und die Bibliotheken wie früher jQuery, Angular und heute React oder Vue bei bedarf zusätzlich zu lernen, dabei aber im Blick zu behalten, dass sich im Web ständig einiges ändert, und vielleicht schon morgen eine andere Bibliothek heiß gehandelt wird.

Ende letzten Jahres veröffentlichte Mandy Michael ein lesenswertes Plädoyer für die Bedeutung von HTML und CSS, in dem sie auch auf die Abwertung gegenüber Entwickler*innen, die ›nur HMTL und CSS schreiben‹, reagierte:

What I don’t understand is why it’s okay if you can “just write JS”, but somehow you’re not good enough if you “just write HTML and CSS”.

When every new website on the internet has perfect, semantic, accessible HTML and exceptionally executed, accessible CSS that works on every device and browser, then you can tell me that these languages are not valuable on their own. Until then we need to stop devaluing CSS and HTML.

Mandy Michael, Is there any value in people who cannot write JavaScript?

Diesen Artikel habe ich vor Allem deswegen geschrieben, um darüber nachzudenken wie ich auf den Konflikt reagiere und um zu verstehen woraus sich meine Reaktionen speisen. Mir ist nun wieder bewusster, weshalb mich einige Aspekte automatisch erzeugten Markups stören und was mir an der Einfachheit gefällt Webseiten und Prototypen zu erstellen, und dabei die Benutzbarkeit derselben immer im Hinterkopf zu haben. Gleichzeitig möchte ich mich nicht auf meinem aktuellen Standpunkt ausruhen und mich darüber wundern wie schnell „die Jungen“ neue Techniken und Arbeitsweisen lernen, sondern mich weiterhin mit den Entwicklungen des Webs beschäftigen und neues lernen.

Da es in diesem Konflikt auch immer wieder um den Begriff Programmiersprache geht und die Frage auftaucht, ob Entwickler*innen, die HTML und CSS schreiben auch programmieren, möchte ich abschließend noch den Artikel »CSS is a Declarative, Domain-Specific Programming Language« von Lara Schenck empfehlen.

Homebrew Website Club in Karlsruhe

Am 23.01.2019 findet der erste Homebrew Website Club in Karlsruhe statt.

Matthias fragte Anfang Oktober auf Twitter ob es Interesse an einem solchen Treffen in Karlsruhe gebe. Da ich Mitte September endlich Webmentions integriert hatte, war mein Interesse groß, und so reagierte ich kurz nach Marc direkt, ein paar Weitere bekundeten im Laufe der Zeit Interesse. Nach einige Absprachen findet der erste HWC nun am Mittwoch 23. Januar um 18:30 Uhr im NUN Kaffeehaus statt.

Homebrew Website Club

Der Homebrew Website Club ist ein regelmäßiges Treffen von Personen, die leidenschaftlich dabei oder interessiert sind, ihre eigene Website zu konzipieren, designen, entwickeln und zu verbessern.

Matthias schreibt zu unserem Treffen:

Wir versuchen den HWC eher ungezwungen und frei zu gestalten und wollen den ersten Termin dazu nutzen, uns kennen zu lernen und den weiteren Ablauf zu besprechen.

Bisher war ich noch bei keinem IndieWeb-Treffen, und freue mich, dass sich das nun ändern wird.

Falls Du auch Interesse hast, komm vorbei oder gib Bescheid, wenn Du über weitere Termine informiert werden möchtest.

Homebrew Website Club am im NUN Kaffeehaus, Gottesauer Straße 35, 76131 Karlsruhe, DE.

Das dunkle Erscheinungsbild von macOS im Webdesign nutzen

Seit macOS 10.14 ist es möglich statt des klassisch hellen ein dunkles Erscheinungsbild zu wählen. Die Auswahl des Erscheinungsbilds hat systemweite Auswirkung, und verwandelt die Benutzeroberfläche des Mac in ein angenehm dunkles Farbspektrum. Nach einer kurzen Testphase gefiel mir die dunkle Ästhetik wesentlich besser und ich wechselte auch im Editor zu einem dunklen Theme.

macOS Systemeinstellungen, Allgemein

Während viele Programme die dunkle Ästhetik sehr gut umgesetzt haben, wirkten helle Webseiten, wie diese hier, sehr schnell wie ein Störkörper in der sonst dunkel gehaltenen Ästhetik. Aus diesem Grund nahm ich mir eben einen Moment Zeit um den kommenden Ausdruck für eine Media Query zu testen, um auch eine Webseite auf die Auswahl der Nutzerin reagieren zu lassen. Die Media Query, die dafür verantwortlich ist, liest sich folgendermaßen:

@media (prefers-color-scheme: dark) {
  /* dark mode styles */ 
}

Wird diese verwendet, lässt sich eine Webseite so designen, dass sie sowohl das helle wie das dunkle Erscheinungsbild unterstützt.

In diesem Codepen habe die Anwendung des dunklen Erscheinungsbildes auf eine Webseite schnell getestet. Bisher unterstützt nur Safari Technology Preview (ab Version 68) den Ausdruck prefers-color-scheme, der für ein solches Webdesign benötigt wird. Falls Du diesen Browser nicht installiert hast, siehst Du unter obigem Link die helle Version der Webseite, die dunkle sieht folgendermaßen aus:

Webdesign: Dunkles Erscheinungsbild (Dark Mode)

Zum direkten Vergleich, hier noch ein Bildschirmfoto der hellen Version:

Webdesign: Helles Erscheinungsbild (Light Mode)

Bis der Ausdruck in allen gängigen Browsern unterstützt wird, kommen nur weniger Nutzerinnen in den Genuss des dunklen Webdesigns. Im Sinne von Progressive Enhancement kann diese Technologie schon jetzt eingesetzt werden, so dass das Erlebnis einiger weniger Nutzerinnen schon jetzt verbessert wird, und andere zu einem späteren Zeitpunkt in den Genuss kommen werden.

Vor einigen Wochen las ich den Artikel Redesigning your product and website for dark mode von Andy Clarke, der noch auf einige weitere wichtige Aspekte eingeht. Die Entwickler-Dokumentation von Apple gibt ebenfalls nützliche Hinweise zum Design für das dunkle Erscheinungsbild.