pixel
Select Page

NETWAYS Blog

Standards vs. Apps

Apps

Eine haeufig gehoertes Thema fuer Absprachen dieser Tage ist gern mal
der Abgleich der Kommunikationsapps um eine gemeinsame Teilmenge zu
finden, die man dann in Zukunft verwenden koennte. Das Ergebnis ist dann,
abhaengig von der Gruppengroessee und der Interessenlage der Beteiligten
verschieden zufriedenstellend und kann durchaus zu der Installation
von Apps fuehren.

Chatapps

Man koennte sich natuerlich an der Stelle dann auch die Frage stellen,
warum es das braucht, warum ein Telegramm nicht mit einem Signal, iMessage,
Snapchat oder [beliebige Chatapp hier einfuegen] reden kann. Es waere ja irgendwo
schon gemuetlicher nur eine App zu haben. Von der Funktionalitaet sind
solche eher selten und in wenigen Punkten unterschiedlich.
Und die Antwort darauf kann schlechterdings eine technische
sein, Protokolle fuer solche Zwecke gibt es und eine “Uebersetzungs”-Schicht
einzubauen waere vermutlich ein vertretbarer Aufwand.
Es wuerden sicherlich ein paar Sachen nicht ueber verschiedene Dienste
hinweg funktionieren, aber 1:1-Chats und Gruppen waeren ja schon ausreichend.

Die naechste Option waere ja dann, wenn die Firmen hinter den Apps schon nicht miteinander
reden wollen, dass man auf seinem Geraet nur eine App installiert, die sich dann
mit allen diesen Diensten verbindet und das vermischt. Etwas frei zitiert:

“One App to rule them all, one app to bind them,…”
– Inschrift auf dem einen Ring, stark verfaelscht

Ein erstrebenswertes Ziel, wuerde es doch ebenefalls den Aufwand reduzieren (ganz zu schweigen
von Speicherplatz und Datenvolumen). Aber auch das ist nicht gaengig.

Angesichts der finanzstarken Lage vieler Betreiber solche Apps scheint es
mir unwahrscheinlich, dass solche Themen an einem “Koennen” scheitert.
Ein Erklaerungsansatz fuehrt diesen Zustand auf das Geschaeftsmodell zurueck,
das viele der Betreiber fahren.
So wird bei der Benutzung des Dienstes und durch die Apps oft das Verhalten
der Benutzer:innen ausgespaeht und dieser Datensatz direkt oder indirekt an die Kund:innen
verkauft. Der Kundenstamm rekrutiert sich dann aus den ueblichen Werbeleuten,
Quacksalbern, Propagandisten, Lobbyisten und Meinungsmachern (Mehrfachnennung moeglich,
Redundanz wahrscheinlich).
Interaktion fuer Leute ausserhalb des eigenen Systems zu erlauben wuerde
das Risiko der Reduktion der eigenen “Datenernte” beherbergen, da Personen
ausserhalb des Systems sich nicht die App installieren muessten, um mit einem Gegenueber innerhalb des Systems
zu kommunizieren und es wuerden vielleicht sogar welche die App entfernen.
Es waere also fundamental geschaeftsgefaehrdend, ein “offeneres” System zu bauen.

Videochats

Obwohl es schon vor 2020 diverse Videokommunikationssysteme gab, ist deren
Bedeutung stark angestiegen. Die Gruende dafuer sind offensichtlich, doch wie ist
denn der Zustand diese Oekosystems dieser Tage?
Das traurige Bild, dass sich einem bei der Betrachtung bietet, ist wiederum
das der verschiedenen Apps, die nicht miteinander interagieren.
Jetzt stellt sich bei verschiedenen Personenkreisen immer wieder die Frage,
ob man denn Zoom-, Teams-, Hangouts- oder sonst irgendein Meeting hat.
Dafuer gibt es dann jeweils eine dazugehoerige App oder man hofft, dass es noch
in einem von drei verschiedenen Browsern mit allen Funktionen laeuft.
Mit Glueck und am zweiten Vollmondtag in geradzahligen Monaten trifft das sogar zu.

Aber auch hier ist die gewuenschte Funktionalitaet sehr klar umrissen und wird von
allen abgedeckt. Es sollen n Teilnehmer 1 bis (n-1) Video- und Audiostreams bekommen
und auf der Seite ist ein Chatfenster.
Das klingt wiederrum technisch ueberschaubar, aber dennoch kann ich nicht mit
einem Teams-Client in ein Zoom-Meeting.
Das Szenario aehnelt somit in wesentlichen Punkten dem Zustand der Messenger,
der weiter oben beschrieben wurde.

Und damit kommt hier die rhetorische Frage, die zum naechsten Abschnitt ueberleitet:
Ginge das denn auch anders? Und wenn ja, wo?

Telefon

Als Gegenbeispiel kann hier die Telefonie dienen, ein Gespraech quer ueber den
Globus mit einer beliebigen Person ist recht leicht denkbar, soweit
diese auch ueber einen Telefonanschluss (oder heutzutage vielleicht eher einen Handyvertrag)
verfuegt. Dabei muss man nicht nach dem speziellen Dienstanbieter fragen, auch der Hersteller
des Geraetes interessiert wenig, wichtig ist einzig die Nummer.
Selbstverstaendlich gibt es da einige Einschraenkungen, wie etwa die Kosten und diverse
Altlasten, aber das ist in einem System, das deutlich aelter als die meisten Benutzer ist,
kaum verwunderlich. Verschiedenste Protokolle und Standards werden kombiniert um am
Ende das Gespraech zwischen zwei (oder mehr) Personen zu ermoeglichen.

Internet

Auch das Internet selbst ist ein Netzwerk von vielen verschieden Teilnehmern, die
ueber standardisierte Schnittstellen Daten austauschen und viele verschiedene Medien und
Uebertragungsvarianten kombinieren.
Es gibt kein Instagram-, kein Youtube- und kein TikTok-Internet, auch wenn es von
vielen hauptsaechlich dafuer verwendet wird.
Gemeinsame Standards schaffen eine Basis, die dies ermoeglicht.

Auch hier bietet es sich an, einen Blick auf das Geschaeftsmodel zu werfen,
Internet- und Telefonieanbieter verkaufen Zugaenge zu einem Netzwerk, beziehungsweise,
sie vermieten sie, da es meistens eher ein Abonnementmodel ist.
Es ist damit leicht vorstellbar, dass ein anbietendes Unternehmen dann ein gesteigertes Interesse daran
hat, den bestmoeglichen Zugriff auf das restliche Netzwerk zu bieten.
Soweit zumindest Theorie, in der Praxis ist das mit den Internetanbietern eine etwas
durchwachsenere Erfahrung.
So moechte sich etwa mindestens eine der groesseren Anbieter hierzulande den Zugang zu seinen
Kunden teuer bezahlen lassen und ist deshalb weniger auf gute Vernetzung bedacht als darauf
viel Geld dafuer einzustecken. Leidtragenden sind hierbei die Kleinkunden, die als
Verhandlungsmasse dienen. Dass das Geld dann auch nicht wirklich in das System reinvestiert
wird um zukunftsfaehige Verbindungen zu schaffen kommt dazu.
Aber das ist ein System von falschen Anreizen und hier nicht direkt Thema.

In Summe kann man heutzutage mit standardisierten Netzwerkprotokollen (UDP, TCP, HTTP, IMAP,…)
Daten zu fast beliebigen Punkten auf dem Globus schicken. Welches Programm ich dafuer verwende
ist dafuer (abgesehen natuerlich von der implementierten Funktionalitaet) irrelevant.

Standards

Es gibt viele verschiedene Formen von Standards, die ich hier, im Sinne des Artikels, in zwei
Gruppen teilen will.
Da sind zum einen Standards die eine oder mehre bestimmte Eigenschaften sicherstellen|definieren
um einen gewissen Zweck zu erreichen. Ungluecklicherweise ist diese Definition sehr vage,
deshalb moechte sie kurz ein wenig ausfuehren und Beispiele anbringen.
So gibt es etwa eine Klassifizierung fuer LASER (DIN EN 60825-1) die Laserquellen und -anlagen
nach ihrem Gefaehrdungspotential einteilen. Dann gibt es Richtlinien/Regularien, welche Klasse
in welcher Situation erlaubt ist und man kann beim Bau von entsprechenden Anlagen dann Massnahmen
oder Mechanismen einsetzen die zur Erreichung der geplanten Klasse dienlich sind (etwa Schutzvorrichten verbauen oder
Schutzkleidung vorschreiben).
Aehnliche Regelungen gibt es fuer alle moeglichen Arten von gesundheitlichen Gefahren, wie etwa im Brandschutz,
Laermbelastung, Luftverschmutzung, Arbeitszeiten und vielem mehr.

Die Art von Standards, um die es hier aber eigentlich geht, sind die Definitionen von Schnittstellen.
Sie stellen eine Art “passive Kommunikation” dar. Eine Schnittstellendefinition sagt mir, wie meine
Gegenseite in relevanten Punkten aussieht und zwar so, dass die genaue Implementierung nicht relevant
fuer meine Seite ist.
Ein greifbares Beispiel sind zum Beispiel metrische Gewinde (z.B. DIN ISO 1502:1996-12), ein M10er
Schraube wird immer in ein M10er Gewinde passen (solange beide innerhalb der Toleranzen sind), ohne,
dass sich der Hersteller der Schrauben und die Person, die das Gewinde bohrt, jemals persoenlich
absprechen muessten.
Diese Art von Standard gibt es, selbstverstaendlich, auch im Bereich der elektronischen Kommunikation oder Informationstechnik.
So sind etwa bei der IETF wichtige Protokolle standardisiert (IP, TCP, …) oder von der ITU die eher physikalischen
Schnittstellen normiert.

Diese Standards werden teilweise von mehr oder weniger offiziellen Stellen erstellt und betreut, teilweise von
von anderen Organisationen (etwa die Mediawiki-API von der Wikimedia-Gesellschaft, die Linux-API von der Linux Foundation oder
zahlreiche andere Projekte aus dem Bereich Open Source und der freien Software).
Dabei gibt es viele verschiedene Variante und Unterschiede, aber einer der wesentlichen ist, wie der Zugang zu dem
Standard geregelt ist. Waehrend etwa die RFCs frei und offen zugaenglich sind (also auch kostenfrei), sind DIN-Normen
zu erwerben, was ein gewisses Hindernis fuer Umsetzung darstellt.

Ein Standard erfordert natuerlich auch gewisse Zugestaendnisse, so ist etwa die Bereitstellung einer oeffentlichen
API bei einem Programm oder einem Dienst nicht wirklich nuetzlich, wenn sich diese API in kurzen Zeitraeumen
haeufig aendert. Das Erstellen von Drittanbietersoftware wird dadurch aufwaendiger und es erfordert haeufiger Updates
beim Benutzer. Eine Schnittstelle ist also auch ein zusaetzlicher Aufwand und eine Verantwortlichkeit gegenueber
Nutzern.
Dies hat natuerlich auch Nachteile, so koennen neue Features nicht leichtfertig eingebaut werden oder alte
Fehler nicht sofort oder auf beliebige Art und Weise behoben werden.
Ein Beispiel dafuer ist etwa Email, ein System, dass in einer anderen Zeit erdacht wurde und an vielen
Stellen Probleme hat. So waeren etwas Privatsphaere-foerdernde Verschluesselung, eine technisch
saubere und verifizierbare Signatur und andere Erweiterungen oder
Aenderungen durchaus technisch moeglich (moderne Messenger leben das ja teilweise vor), aber durch die Notwendigkeit
des Erhalts einer minimalen gemeinsamen Basis rottet das System auf einem Stand von vor fast 30 Jahren dahin.
Auf der positiven Seite kann man auch noch Mails schreiben indem man eine direkte Netzwerkverbindung zu einem
freundlichen Mailserver aufmacht (und schnell tippen kann).
Diese Problematik fuehrt teilweise zur Abkehr von offenen Standards, etwa beim Messenger “Signal”. Dort wird
auf ein zentralisiertes System gesetzt statt auf eine foerderiertes um den Stand aller
Teilnehmer einigermassen gleich zu halten und gleichzeitig neue Features implementieren zu koennen.

Der Punkt

Nach der langen Einleitung kommen wir nun endlich zum wirklichen Punkt des Artikels.
Im ersten Teil duerfte vermutlich das Wort App ins Auge gefallen sein.
Viele Dienste sind heutzutage mit einer eigenen App verbunden. Dies hat sich soweit
durchgesetzt, dass man bei irgendeinem neuen Dienst inzwischen sofort gefragt wird, was man
installieren muss.
Und dies oft ohne technische Notwendigkeit.

Man ist inzwischen daran gewoehnt, dass man sich fuer einen Dienst eine neue App installieren muss,
die dann froehlich das Addresbuch oder das Nutzungsverhalten irgendwo ins Internet laedt.
Daran ist man gewoehnt.
Der Hersteller der App jederzeit Einschraenkungen einfuehren, etwa Features entfernen, die Funktionalitaet
veraendern oder andere beliebige Masnahmen vornehmen.
So koennen etwa auch bestimmten Inhalte mehr oder weniger effektiv verboten werden.
Auch daran ist man gewoehnt.
Man ist nicht nur der Willkuerlichkeit ausgeliefert, es geht auch viel Potential verloren. So kann es innerhalb
einer Firma leicht zu einer gemeinsamen Perspektive kommen, die nicht unbedingt der der Nutzer entspricht.
Manchmal braucht es die Perspektive von Aussenstehenden um die Probleme zu identifizieren (und zu beheben).
Dies ist nicht moeglich, wenn sich Aussenstehende nicht mit den Moeglichkeiten auseinander setzen koennen
oder nicht duerfen.
Auch daran hat man sich mittlerweile gewoehnt.

Durch diese geschlossenen Oekosysteme entsteht auch gesamtgesellschaftlicher Schaden und neue Risiken.
So sind bereits einige Monopolisten entstanden, die man in bestimmten Bereichen fast nicht umgehen kann.
Ein Unternehmen oder eine Behoerde ohne Microsoft-Komponenten ist kaum denkbar, eine Kommunikation mit Menschen
ohne Whatsapp ist zumindest schwieriger.
Fuer viele proprietaere Softwareloesungen gibt es keine Dokumentation der Datenformate, so dass ein Wechsel
des Systems zwischen prohibitiv teuer und kaum moeglich rangiert.
Teilweise laesst sich auch ein altes System oder ein Teil davon nicht an ein Neues anbinden, weil keine Schnittstellen
existieren oder die vorhandenen nicht dokumentiert sind. Eine entsprechende Anekdote eine Systems, dass ausgemustert
werden musste, weil einige Teile davon veraltet waren, duerften die meisten inzwischen kennen.
Der entsprechende Mehraufwand schlaegt sich natuerlich in unnoetigen Kosten, Muell und verschwendeter Zeit nieder.
Auch aus dem Blickpunkt der Softwaresicherheit ist eine solche Monokultur durchaus bedenklich, wie die
Windows-Sicherheitsluecken der letzten Jahre gezeigt haben. Bei einer standardisierten Schnittstelle mit
verschiedenen Implementierungen gibt es zumindest eine gute Wahrscheinlichkeit, dass nur eine Implementierung
betroffen ist und damit der Schaden durch einen Angreifer reduziert wird.

Schluss

Meiner Meinung nach, brauchen wir fuer die Zukunft in unserer digitalen Welt wieder mehr
Standards (oder zumindest die staerkere Implementierung derselben) und mehr Fokus auf Protokolle, statt dem Fokus auf eine “App”.
Statt hunderte und tausende Male das gleiche neu und ein wenig anders zu implementieren und zwar meistens halbgar,
koennte festgelegt werden was da im Grunde passiert und es in Standards und Protokollbeschreibungen zusammenfassen.
Die Analyse und die Motivation fuer den Status Quo habe ich hier kaum bis gar nicht vorgenommen,
diese kommt vielleicht nochmal in einem weiteren Artikel, aber ich halte ihn, kurz gefasst, fuer ein Resultat
dieses Wirtschaftssystems.
In einer digitalen Welt, in der Konzerne auf eine Monopolstellung hinarbeiten und die meisten Gelder fuer
Konsumentensoftware und -dienste aus Werbeeinnahmen stammen, ist eine Verbesserung nicht so leicht denkbar.
Ganz allgemein ist ein Fokus auf Gewinnmaximierung vermutlich nicht die beste Zielsetzung aus Perspektive der
Softwareanwender.

Fuer die nachhaltigere, resilientere und vielfaeltigere Gesellschaft die fuer die Zukunft
gebraucht und teils gewollt wird, muss auch das digitale Oekosystem angepasst werden.
In dem jetzigen Zustand wirkt es eher unzureichend und zu stark auf Interessen Einzelner
fokussiert.

Ich habe versucht viel in diesen Text hineinzubringen, was vielleicht eher schlecht als recht dort
Platz gefunden hat. Ueber Kritik, Verbesserungen und vielleicht auch Gegenmeinungen wuerde ich mich
sehr freuen.
Fuer die Kuerze und die daraus folgenden Unvollstaendigkeiten moechte ich mich entschuldigen.

Wer sich fuer die hier angesprochenen Themengebiete interessiert, kann auch noch einen Blick auf folgende Themen werfen:

  • XMPP, ein vergleichsweise frueher Ansatz fuer einen sich fortentwickelnden Standard fuer allgemeine Chatdienste, nicht so haeufig zu sehen, aber vermutlich haben Sie es schon mal verwendet
  • Matrix, aehnlich zu XMPP aber juenger. Ebenfalls chatten in einem foerderierten Netzwerk
  • Fediverse, ein Ansatz fuer soziale Netzwerke, ebenfalls foerderiert, beinhaltet z.b. Mastodon (Microblogging wie Twitter), Peertube (Video-Plattform wie Youtube) und diverse andere Dienste und Protokolle
Lorenz Kästle
Lorenz Kästle
Consultant

Lorenz hat seinen Bachelor der Informatik an der FAU gemacht und sich zuletzt mit Betriebssystemen dort beschäftigt. In seiner Freizeit beschäftigt er sich ein wenig mit XMPP und der Programmiersprache Erlang.

Das neue User Interface von Icinga DB

Während mit Icinga DB sehr viel unter der Haube passiert ist, kommt mit dem Release auch ein rundum neu geschriebenes Monitoring Modul für Icinga Web 2. In diesem Zuge erhielt auch das User Interface ein ausführliches Redesign. In diesem Blogpost werden die wichtigsten Änderungen erklärt.

Listen

Wie im bewährten Monitoring Modul gibt es im Monitoring Modul für Icinga DB viele Listenansichten. Daher wurden diese komplett überarbeitet. Allen Listenelementen liegt eine grundlegende einheitliche Anatomie zugrunde.

ListItem Anatomy.jpg

Anatomie eines Listenelements

Visual

Für jedes Listenelement wird ein so genanntes Visual verwendet. Dieses dient dazu, in langen Listen bestimmte Elemente hervorzuheben bzw. einen intuitiven Überblick geben, welchen Zustand das zugrunde liegende Objekt hat. Bei Host- bzw. Servicelisten wird dadurch beispielsweise der State dargestellt. So wird in der Übersicht unmittelbar ersichtlich, bei welchen Objekten Probleme vorliegen.

Title

Der Titel beschreibt ergänzend kurz zusammengefasst den Zustand des Listenelements. So enthält er beispielsweise die Info, dass ein Host gerade Down ist. Während das Visual einen intuitiven Eindruck gibt, erklärt der Titel, was genau passiert ist.

Meta

Der Metabereich ist für zusätzliche Informationen vorgesehen. In der Regel werden hier Zeitangaben des Listenelements angezeigt. In Host und Servicelisten steht hier, wie lange sich das Objekt bereits im entsprechenden Zustand befindet.

Caption

Der Caption-Bereich enthält detaillierte Informationen zum Listenelement. Dies kann im Falle von Hosts und Services der Plugin Output sein. Bei Kommentaren und Downtimes werden hier die Kommentartexte des Users angezeigt. Um die Listendarstellung kompakt und einheitlich zu halten, werden lange Texte auf eine oder mehrere Zeilen gekürzt.

Klickbare Elemente

Viele der Listenelemente enthalten neben dem Hauptelement zwei oder mehrere klickbare Elemente. Alle Teile des Listenelements, die auf weitere Detailinformationen verweisen sind eindeutig hervorgehoben. Dadurch ist sofort erkennbar, hinter welchen Textteilen sich Zusatzinformationen befinden.

Overdue Checks in Host- und Service Listen

In Host und Servicelisten werden Overdue Checks nun besonders auffällig hervorgehoben. Dadurch ist auf den ersten Blick sofort ersichtlich, welche Objekte möglicherweise nicht mehr aktuell sind.

Artboard Copy.jpg

Das neue Icinga DB Design: Hostliste und Detailbereich

Detailgrad der Listenansichten wählen

Der Detailgrad der Host- und Servicelisten ist nun wählbar. Die Standardansicht zeigt den Titel und einen zweizeiligen Plugin Output. In der detaillierten Ansicht wird der gesamt Plugin Output angezeigt. Will man einen größeren Überblick bekommen gibt es außerdem die Minimalansicht. Hier wird in einer Zeile der Plugin Output angeschnitten, wenn genügend Platz vorhanden ist. Dafür sieht man auf einem Bildschirm wesentlich mehr Listenelemente als in den anderen Darstellungen.

State Change Visual in History- und Notification Elementen

In History und Notification Listen sind unter anderem Statewechsel-Elemente zu finden. Hier wird im Visual der Wechsel nun auf den ersten Blick deutlich gemacht. Neben dem aktuellen State wird gleichzeitig auch der vorherige State ersichtlich.

State Changes sind in den Notificationlisten nun besser ersichtlich.

Detailansichten

Optimierte Headerbereiche

Die Headerbereiche der einzelnen Objekttypen erhalten ein neues Design. Während die herkömmlichen Headerbereiche sehr viel Platz brauchten, sind die Informationen kompakter.

Graphen

Die Detailansichten der Elemente waren bisher sehr textlastig. Nach dem Redesign sind die Detailbereiche deutlich visueller angelegt. Nun werden anstatt der bloßen Auflistung Informationen kombiniert und Zusammenhänge dargestellt.

Modaldialoge für schnelle Aktionen

Wollte man bisher aus dem Detailbereich einen Kommentar anlegen oder eine Downtime setzen wurde der Dialog in einer weiteren Spalte angezeigt, so dass die Inhalte der linken Spalte verloren gingen. Im neuen Monitoring Modul gibt es nun ein Modal-Element für kurze Interaktionsdialoge. Für Aktionen im Detailbereich erscheint nun ein Modaldialog. Dadurch bleibt die linke Listenspalte und somit der Kontext besser erhalten.

 

Florian Strohmaier
Florian Strohmaier
Senior UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.

Flying blind – accessibility in the world wide web

Do you know how many visually impaired people there are out there?
I can tell you: There are roughly 188.5 million people with mild vision impairment, 1043 million have moderate to severe vision impairment, and 36 million people are blind (According to the world health organisation in 2018). When it comes to colour blindness there are approximately 300 million people affected – that’s almost as many people as the entire population of the USA! (According to the Colour Blind Awareness Community)

That’s a lot, isn’t it? And a lot of those people also use the web. Not everyone in the same way as most do though.

Have you ever used a screen reader? Or heard of the term at all? A screen reader is a tool used to have the content of your screen read out for you. They are usually used by people who have issues reading what’s presented – either because they cannot distinguish between what’s written and the background because of bad contrasts, because fonts that are too small or just because they can not read or see at all.
For anyone who is interested how it works there is a lot of material on youtube, like this video by the SLCC Universal Access channel. If you have the time you should also try it out yourself, there are a lot of free tools out in the www.

In order to make this all possible there are guidelines provided by the w3, which cover:

  • Web Content Accessibility Guidelines (WCAG) – how to make web content accessible
  • Authoring Tool Accessibility Guidelines (ATAG) – make authoring tools accessible
  • User Agent Accessibility Guidelines (UAAG) – make user agents accessible
  • Accessible Rich Internet Applications Suite (ARIA) – make web content and web applications accessible

For all of the (web) developers reading this, those are definitely worth a read! Sticking to those standards makes the web more accessible for everyone, and that’s what everyone should strive for, right?

For people who have difficulties with contrasts, there are standards set by the w3 and also high-contrast ‘themes’ available for some tools.

People affected by some form of colour vision deficiency there are colour blind variations in some tools – often times they are just being overlooked though. I have some pictures for you, that aim to visualise the most common kinds of colour vision:

colours with different simulated vision impairments

I used ‘Color Oracle’ for the simulated colours.

There is also a more detailed blogpost on icinga.com about our new ‘colour blind’ theme in Icinga Web 2.

Feu Mourek
Feu Mourek
Developer Advocate

Feu verbrachte seine Kindheit im schönen Steigerwald und kämpfte sich bis zum Abitur durch die Schule. Seit September 2016 unterstützt es die Icinga Abteilung bei NETWAYS als Developer, UX Designer und Community Advocate. Seine Freizeit verbringt es hauptsächlich damit Video-, Brett- und Pen and Paper Rollenspiele zu spielen, seine jogging Runden mit seinem Pony drehen, oder damit, Handwerklichen Tätigkeiten am Auto oder der Wohnung nachzugehen.

Entwicklerazubis: Jahr 1, das Projekt

Man bekommt nicht immer das, was man will… außer, man ist bei NETWAYS Azubi!

 

Mein erstes Jahr bei NETWAYS ist fast vorüber, und meine jugendlichen Ambitionen haben den Wunsch in mir erweckt, mit den beiden anderen Dev-Azubis meines Jahres, Loei und Niko, ein eigenes Projekt zu übernehmen, um unsere erlernten Fertigkeiten zu prüfen, eine Übersicht davon zu bekommen, auf welchem Stand wir alle sind, den ein oder anderen Trick voneinander aufzuschnappen und eigenverantwortlich und kooperativ ein Projekt zu vervollständigen. Und alles, was es gebraucht hat, um diesen Wunsch zu erfüllen, war diese Idee zu pitchen und klar und deutlich zu vermitteln, warum dieses Interesse besteht, und was wir uns davon erhoffen. Meine Vorgesetzten scheinen von der Idee zumindest angetan genug gewesen zu sein, dass wir drei Wochen eingeräumt bekommen haben, um uns um dieses Projekt zu kümmern. Danke, NETWAYS!

Die Aufgabe klingt einfach, hat es aber doch durchaus in sich – aus Berichten in Icinga sollen PDFs generiert werden. Die Funktionalität ist schon vorhanden – unsere Aufgabe ist es, den Benutzern mehr Features zur Verfügung zu stellen, damit man eigene Anpassungen an dem Aussehen der PDFs vornehmen kann. Das Schöne an dieser Aufgabe ist die Breite der Elemente und Bereiche, welche eine Rolle dabei spielen. Icingaweb, PHP, HTML, CSS, Google Chrome… es ist in gewisser Art und Weise eine große Reise in das Unbekannte, und natürlich können wir alle drei uns nicht sicher sein, welche Probleme und Hürden sich uns in den Weg stellen werden, und wie die zündenen Ideen kommen, die uns helfen, diese Hürden zu überwinden.

 

Boo

Much better

Und zündende Ideen gab’ es bereits! Ein Beispiel: Google Chrome baut sich aus HTML-Code die PDFs zusammen, lässt sich es aber nicht nehmen, automatisch generierte Header und Footer anzufügen, mit Seitenzahl und Datum. Das ist natürlich ein Element, welches wir gerne unter Kontrolle hätten! Der erste Hack, mit dem ich mich über diese Hürde bewegt habe, ist ein CSS-Styleelement an den übergeben HTML-Code anzufügen. Das ist in seinem momentanen Zustand natürlich noch etwas unschön gelöst, wenn einfach nur der HTML-Code um ein fest eingebautes Codeelement erweitert wird, aber wir haben einen Einstiegspunkt, einen Ansatz, mit der wir weiterbauen und -basteln können.

 

Scheue Dich vor Fragen nicht!

Auch wenn der Kerngedanke dieses Projekts natürlich daraus besteht, dass wir uns selbst beweisen, spricht natürlich Nichts dagegen, bei Fragen, die aufkommen, einen der zahlreichen Experten die NETWAYS hat zu involvieren. Was Benutzeroberflächen angeht, ist bei uns UX-Designer Florian der Ansprechpartner Nummer 1. Wir haben uns zusammengesetzt und konnten ihm live beim Bauen eines Mockups in Sketch zusehen. Eine Gelegenheit, durch die großen Augen, die wir gemacht haben, auch etwas über grundlegende Designansätze in Icingaweb zu lernen, und Grundsätze bezüglich Design. Mit diesem Wissen können wir erstmal diesen Pfad weiter selbst beschreiten, aber natürlich werden wir viel Rücksprache führen. Nur weil man bisher nicht dazu kam, sich extensive Kenntnisse in einem Bereich selbst anzueignen, heißt das nicht, dass man dieses Wissen, wenn es einem zur Verfügung steht, nicht nutzen kann. Und immer schön dran denken, selbst den Fundus an Talenten zu erweitern.

A mockup of things to come…

 

Kooperatives Kodieren

Einer der in meiner Einleitung angesprochenen Tricks, den ich einfach für neat halte, und sehr dem Spirit dieses Projektes entspricht, ist die Möglichkeit in git Co-Authoren einzutragen. Dafür muss man in der commit message einfach

 Co-authored-by: Name <e-mail>

angeben, und git verlinkt automatisch zwei Autoren für diesen commit. In diesem Fall meine beiden Kollegen bei diesem Projekt. Gute Arbeit, Jungs!

Da kann man ruhig mal klatschen! ?

 

Willst Du uns vielleicht nächstes Jahr bei dem nächsten Entwicklungsprojekt behilflich sein? Dann raus mit Deiner Bewerbung an NETWAYS! Wir freuen uns schon auf dich!

Henrik Triem
Henrik Triem
Developer

Henrik ist Anwendungsentwickler und Trainer, verhinderter Rockstar und Open Source-begeistert. Erfolgreich bei NETWAYS ausgebildet geht er hier seiner Leidenschaft für Packaging und Icinga nach. In seiner Freizeit sieht man ihn gerne an Klavier oder Gitarre sitzen.

Weniger ist mehr: Gestaltung unter dem Aspekt der Aufmerksamkeitsökonomie

Das Konzept der Aufmerksamkeitsökonomie versteht die menschliche Aufmerksamkeit als eine begrenzte Ressource. Je mehr Informationen auf den Wahrnehmenden »einprasseln«, desto mehr dieses knappen Gutes benötigt ein Mensch um diese zunächst zu sortieren und zu priorisieren, bevor sie verarbeitet werden können.

read more…

Florian Strohmaier
Florian Strohmaier
Senior UX Designer

Mit seinen Spezialgebieten UI-Konzeption, Prototyping und Frontendentwicklung unterstützt Florian das Dev-Team bei NETWAYS. Trotz seines Design-Backgrounds fühlt er sich auch in der Technik zuhause. Gerade die Kombination aus beidem hat für ihn einen besonderen Reiz.