webfactory Neuigkeiten https://www.webfactory.de/assets-version-1513365823/bundles/webfactorywebsite/img/inside-logo.png Logo Webfactory http://www.webfactory.de Zend_Feed_Writer 2 (http://framework.zend.com) https://www.webfactory.de/blog/ © 2017 webfactory GmbH UXBN@webfactory zu Performance und UX-Test-Methodenmix Nachdem die Teilnehmer gemütlich eingetroffen und mit Getränk und Snacks in der Hand in eine erste Networking-Runde gestartet waren, machte unser Kollege Søren mit seinem Vortrag zu Performance als neuer UX-Grundanforderung den Anfang.

Nach einer kurzen Einordnung, warum Performance (im Sinne von schnellen Ladezeiten und zügig verfügbarer Interaktivität auf Webseiten oder in Apps) ein wichtiges Thema ist, führte Søren die Anwesenden durch eine Reihe von Erkenntnissen der Neurowissenschaften zu Zeit, Zeitwahrnehmung und vor allem der "Psychologie des Wartens". Wichtigstes Take-away: es gibt einen erheblichen Unterschied zwischen objektiv messbarer Zeit und dem, was das menschliche Hirn daraus macht. 

Neben der Unterstützung von Entwicklern bei der Reduktion der objektiven Ladezeiten können sich UX-Spezialisten genau diesen Unterschied mit schlauen Tricks zu Nutze machen, um einen wichtigen Beitrag zur Optimierung der vom Nutzer empfundenen ("perceived") Performance zu leisten. Søren stellte dazu sieben Maßnahmen anhand von praktischen Beispielen vor.

Nach kurzer und diskussionsreicher Pause ging es weiter mit Bastian Weber, der extra aus dem fernen Dresden angereist war, um uns Lehren aus der täglichen Arbeit mit A/B-Tests bei der m-pathy GmbH näherzubringen.

Bastian stellte vor allem heraus, dass A/B-Tests nur eine von vielen Methoden sind, sich einer optimalen User Experience anzunähern. Insbesondere gab er zu bedenken, dass ein A/B-Test nicht notwendigerweise ein korrektes Gesamtbild zeigen muss: In einem Beispiel wären A/B-Tests zur Verbesserung der Absprungraten auf einer bestimmten Seite (hier: Liste von Suchergebnissen) nicht sinnvoll gewesen, da das Problem der Nutzer tatsächlich auf der vorherigen Seite (hier: dem Suchformular) lag.

Neben der Empfehlung, immer lieber auf einen guten Methodenmix zu setzen, als sich auf eine "Lieblingsmethode" zu beschränken, gab Bastian noch ein paar Tipps, wie man zu guten Test-Hypothesen kommt – und wie nicht. 

Nach den beiden Vorträgen ließen wir den Abend bei entspannt-angeregten Gesprächen und netzwerkeliger Atmosphäre langsam ausklingen und freuen uns auf neue UX Themen im nächsten Jahr – sehr gerne auch wieder bei uns im wfLab!

---

* Der Vortrag von Jörg Niesenhaus über Erfahrungen aus 5 Jahren Arbeit mit Gamification musste krankheitsbedingt leider kurzfristig ausfallen, wird aber im Januar beim nächsten UXBN Termin bei Aktion Mensch nachgeholt.
 

]]>
Tue, 12 Dec 2017 13:40:39 +0100 https://www.webfactory.de/blog/uxbn-bei-webfactory-performance-methodenmix https://www.webfactory.de/blog/uxbn-bei-webfactory-performance-methodenmix webfactory GmbH webfactory GmbH 0
Erasmus+ Social Inclusion Days: Dinner in the Dark bei der webfactory Die 21 Teilnehmerplätze für Erasmusstudierende in Bonn waren innerhalb von zwei Stunden nach Beginn der Anmeldung vergeben und wir freuten uns über das große Interesse.

Es galt ein Menü, Tische, Sitzplätze, Geschirr, Besteck und Augendbinden zu organisieren. 

Trotz des engen Zeitplans ist am Freitagabend alles bereit und das dreiköpfige Koch-Team bezieht um 17:30 Uhr die webfactory Küche, wo sie für den Rest des Abends kulinarische Genüsse zaubern. Ab 18 Uhr wird das webfactory Lab umgebaut und Augenbinden werden vorbereitet, bis kurz vor 19 Uhr schon die ersten Gäste eintreffen. Jeder Gast bekommt die Augen verbunden und wird daraufhin zu einem zufällig zugewiesenen Platz an der großen Tafel geführt. 

Als wir den ersten Gang, Feldsalat mit Feta, Granatapfel und Walnüssen, servieren, sind neue Bekanntschaften geschlossen und von oberflächlichen Gesprächen ist keine Spur. Oft wird eine leere Gabel zum Mund geführt, weswegen manche auf manuellere Methoden umsteigen. Für die Organisatoren bieten sich recht amüsante Szenen, zum Beispiel als wir den Teller einer Teilnehmerin entfernen, sodass sie mit Gabel und Löffel den Tisch nach ihrem Salat absucht.

Vor dem Hauptgang servieren wir den Gästen erst noch ein paar Gegenstände, die sie in Teams abtasten, um zu erkennen, worum es sich handelt.

Als Hauptspeise gibt es Nudeln mit Kirschtomaten und Weißweinsauce, welche eine willkommene Abwechslung von den schwer zu befördernden Salatblättern bieten.

Im Anschluss verwöhnt uns das Koch-Team mit einem Bratapfel-Schichtdessert, dessen Keksboden für besondere Verwirrung bei der Identifizierung sorgte.

Bei einem „Dinner in the Dark“ hat man nicht nur ein erhöhtes Geschmacksempfinden, sondern bekommt auch einen Eindruck davon, wie es ist, blind zu sein. Nachdem unsere Gäste die Augenbinden abnehmen dürfen, sagt mir eine Teilnehmerin, dass sie sich zu Hause unbedingt informieren müsse, wie blinde Menschen mit den Herausforderungen zurechtkommen, mit denen Sie sich in den vergangenen zwei Stunden zum ersten Mal konfrontiert sah.

Zum Abschluss zeigen wir zur Belustigung noch die Fotos und Videos des Abends auf der Leinwand.

Unsere Gäste und das ESN Bonn bedanken sich herzlich für die großzügige zur-Verfügung-Stellung der webfactory Räumlichkeiten!

]]>
Mon, 04 Dec 2017 16:24:41 +0100 https://www.webfactory.de/blog/erasmus-social-inclusion-days-dinner-in-the-dark https://www.webfactory.de/blog/erasmus-social-inclusion-days-dinner-in-the-dark webfactory GmbH webfactory GmbH 0
A love letter to the CSS :not() pseudo-class When it comes to CSS and code management, we have long since made the move to BEM and ITCSS with a smattering of Functional CSS. If you haven't heard of one or any of those, have a look at the following articles (familiarity with ITCSS at least is sort of required for the rest of this post):

BEM:

ITCSS:

Functional CSS:

Done? Splendid. Onwards!

As you (now) know, ITCSS was created by Harry Roberts and is essentially a system that helps you to embrace the cascade (the "C" in CSS) and avoid writing convoluted selectors with ever increasing specificity (often referred to as "specificity hell" or "specificity wars") as projects and/or teams grow. ITCSS solves this by organizing your styles in layers from very generic to very specific. Our typical setup for a SCSS-based project follows Harry's layer suggestions quite closely:

  • Settings – Variables for breakpoints, colors, font sizes, …
  • Tools - Mixins & functions
  • Generic - Baseline rules like normalize/reset and box-sizing
  • Elements - Baseline rules for HTML elements, a bit like normalize++
  • Objects - Abstractions and patterns like media object, grids etc.
  • Components - Discrete parts of the UI like buttons and and links, but also composites like accordions, main navigation, page header etc.
  • Trumps - Very specific overrides, mostly functional helper classes for layout (margins, paddings)

Among those, the "elements" layer is dedicated to styling pure HTML element selectors, while the code in the following layers uses classes exclusively (HTML element selectors should be avoided here to keep specificity low).

ITCSS helps us to write styles with the cascade, where we embrace the fact that rules of the same specificity in a lower layer – aka "later" in a concatenated production file - will overwrite earlier rules. However, we make an effort to use overwrites sparsely and avoid complexity (or, as many CSS developers have come to call it, "dark magic").

The  :not()  pseudo-class is the newest tool in our belt for this endeavor. Without it, we used to declare rules for properties like  font-size line-height color font-weight  and especially  margin  in the "elements" layer (i.e. for headings or lists), only to reset them later in the "components" layer for BEM-elements like  news__title  or  accordion__header  that use an appropriate HTML element and not a  <div> . This could be a heading, its level depending on the document outline (i.e.  <h3> ), but it would not necessarily look like a third-level heading.

"Then why do you style classless HTML elements in the first place?", you ask? Excellent question! Let me digress a little.

At webfactory, we help create content-heavy websites that are powered by our content management system (CMS) wfDynamic. Content editors (the people) usually work with so-called WYSIWYG editors (the software) that support text formatting from italic and bold to inserting different types of headlines, lists, tables, links, etc. If you have worked with WYSIWYG editors before, you will know that the good ones produce well-formed, semantic HTML like  <ul><li>…</li></ul>  for unordered lists or  <h2>…</h2>  for sub-headings – HTML without classes.

Obviously, this WYSIWYG content needs to look just as right and correspond to the project's design guidelines as more "handcrafted" components like news teasers or FAQ accordions, where the content is directly retrieved from a database and marked up in a view template by a developer.

This poses a dilemma: It's necessary to style classless HTML elements so WYSIWYG content looks great, but at the same time we don't relish the thought of resetting  margin  or  list-style  for every non-content kind of  <ul>  we want to use in our templates (i.e. for navigation or a tabs component). In the past, we solved this by wrapping any WYSIWYG content in a  <div class="wysiwyg">…</div>  and used the selector to apply our styles contextually, like so:

.wysiwyg {
    h2 { … }
    ul { … }
}

// Note: This kind of rule nesting is a feature provided by SCSS.








The above is a perfectly valid method, but it never felt right. What if we have a design for lists or headings that applies to a majority of all lists or headings with only a few exceptions? The contextual approach requires us to create an additional class with the same styles we used for the  .wysiwyg -selector that can be applied to handcrafted components like  news__title . Again, this is a perfectly valid technique which can be made more maintainable by including a Sass mixin in both use cases (which in turn negates the necessity of a specific class). And still we believed there had to be an easier way that required less code. And there is!

Enter the  :not()  pseudo-class

From MDN web docs:

The  :not()  CSS pseudo-class represents elements that do not match a list of selectors. Since it prevents specific items from being selected, it is known as the negation pseudo-class.

We do not know why it took us so long to realize this, but you can specifically target HTML elements without a class by simply applying  :not([class])  to them.

Here's a simple example of how this looks in a current project:

h2:not([class]) {
    color: #555555;
    font-size: 24px;
    font-weight: 300;
    line-height: 1.2;
}








And a more complex one:

// Due to design and implementation choices, we can reset all our
// unordered lists to a common baseline
ul {
    list-style: none;
    margin-top: 0;
    margin-bottom: 0;
    margin-left: 0;
    padding-left: 0;
}

// All classless unordered lists have an orange bullet and
// are slightly spaced (by applying a margin-top to
// consecutive list items)
ul:not([class]) {
    li {
        line-height: 1.375;
        padding-left: 1.15em;
        position: relative;

        &::before {
            content: '•';
            color: #ff8c00;
            font-size: 1.5em;
            line-height: 1;
            position: absolute;
            top: 0;
            left: .1em;
    }

    + li {
        margin-top: 5px;
    }
}








Suddenly, all our problems vanish into thin air:

  • we can style WYSIWYG content without a contextual class
  • we do not have to overwrite any unwanted rules for our handcrafted components with classes
  • we can benefit from the generic rules for HTML elements whenever we want, simply by omitting to apply a class to them

We have used this approach for the better part of three months now and not encountered any downsides yet.

What do you think?

]]>
Fri, 24 Nov 2017 17:08:56 +0100 https://www.webfactory.de/blog/a-love-letter-to-the-css-not-pseudo-class https://www.webfactory.de/blog/a-love-letter-to-the-css-not-pseudo-class webfactory GmbH webfactory GmbH 0
BonnAgile Meetup zu Gast bei der webfactory mit "Dynamic UI Composition für µServices" Thomas Vidic und Andreas Kluth von REWE digital hatten eine spannende Frage für den letzten Bonner Agile Tech Talk vor der Winderpause mitgebracht: wie geht man mit Frontend-Komponenten für eine Webseite um, wenn hinter der Seite bis zu 25 Entwicklerteams stehen, die möglichst autonom an Microservices arbeiten sollen?

Die Entwicklerszene ist sich grundsätzlich einig, dass eine Microservice Architektur für viele Projekte mehr Vor- als Nachteile mit sich bringt, weil sie vor allem ermöglicht, dass mehrere Entwicklungsteams unabhängig voneinander arbeiten können, ohne viel Kommunikations- und Koordinationsaufwand zu erzeugen. Tatsächlich ist eine klare Kapselung von Aufgaben im Sinne der Unix-Philosophie ("Do one thing and do it well") im Backend recht einfach möglich, weil man Funktionen wie "Nutzer kann sich mehrere Produktfotos ansehen" und "Nutzer kann ein Produkt in den Warenkorb ablegen" völlig unabhängig voneinander betrachten und umsetzen kann. Dagegen gibt es im Frontend (also "im Browser") die Herausforderung, viele dieser programmatisch deutlich unterscheidbaren Funktionen auf einer Seite gleichzeitig und nebeneinander anzuzeigen. Hier entstehen schnell viele Fragen im Hinblick auf konsistentes User Interface (UI) versus autonome Entwicklung, duplizierten Code versus geteilte und versionierte Komponenten, usw.

Thomas skizzierte in seinem Vortrag die Erfahrungen, die REWE digital in den letzten Jahren in diesem Bereich gemacht hat, und stellte drei grundlegende Herangehensweisen vor, die sie für ihre Architektur evaluiert haben:

  1. Frontend-"Monolith" – ein dediziertes Frontend-Team verantwortet das gesamte User Interface und konsumiert von anderen Entwicklerteams hauptsächlich Daten über API-Endpunkte.
    Hauptvorteil: "alles aus einer Hand", damit konsistente Gestaltung und kein wild wuchernder Code
    Hauptnachteil: skaliert schlecht, ein Team wird zum Flaschenhals für alle anderen Teams
  2. "Micropages" – Jede Seite wird als eigenständiger Service betrachtet und isoliert von einem zuständigen Team verwaltet und vertikal integriert, d.h. Backend und Frontend liegen im gleichen Team und eine überall verwendete Komponente wie die Navigation wird im Zweifelsfall von jedem Team neu umgesetzt.
    Hauptvorteil: Maximale Autonomie mit Null Abhgängigkeiten
    Hauptnachteil: Maximale Code-Duplikation bei großer Gefahr von visueller/funktionaler Inkonsistenz
  3. "Dynamic Frontend Composition" — Kritische und komplexe Features kommen vollständig (Backend und Frontend) aus dedizierten Teams und werden von anderen Teams über Integrationsmechanismen zu ganzen Seiten zusammengestellt.
    Hauptvorteile: Kritische Features können autonom entwickelt werden und ihre visuelle/funktionale Konsistenz wird durch die Einbindung zur Laufzeit in ihrer jeweils aktuellen Version zu jedem Zeitpunkt gewährleistet
    Hauptnachteil: Teams, die übergeordnete Seiten verwalten und kritische Komponenten einbinden, verlieren ein Stück weit die Kontrolle über diese kritischen Bestandteile "ihrer" Seiten

Im Folgenden ging Thomas näher auf Details ihrer auf der "Dynamic Frontend Composition" basierenden, aktuellen Architektur ein und schilderte erste Erfolge bei ihrer kürzlichen Umstellung der "In den Warenkorb"-Komponente. Er stellte dazu den "Dynamic User Interface Composer" (DUC) vor, der ähnlich wie Zalandos tailor für die Komposition unterschiedlicher Teile einer Seite zum fertigen Endergebnis im Browser des Nutzers verantwortlich ist.

Im Anschluss an den Vortrag entwickelte sich eine spannende Diskussion mit vielen Detailfragen, so dass der zweite Teil des Abends mit etwas Verspätung erst um 21:00 Uhr weiterging. Andreas Kluth hatte sich zur Aufgabe gemacht, den von REWE digital in Node.js entwickelten (und proprietären) DUC in Java nachzubauen, um einerseits zu zeigen, dass "Java noch lange nicht tot ist" und andererseits eine Implementierung der Kernidee ihrer Software als Open-Source veröffentlichen zu können.

Andreas nahm die Zuschauer mit auf eine geführte Tour durch die Implementierung einer Demo-Produktseite und konnte zum Schluss sogar in unter 10 Minuten beispielhaft einen neuen Service ins Leben rufen, über den eine Empfehlungen-Komponente dynamisch in die Produktdetailseite integriert wurde. Chapeau!

Wir haben uns sehr über die exzellenten Vorträge und die rege Teilnahme gefreut, und hoffen, dass BonnAgile nicht zum letzten Mal bei uns zu Gast war. Vielen Dank an dieser Stelle noch einmal besonders an Andreas, der neben seinem Vortrag ganz nebenbei auch die Organisation der Meetup-Reihe mitverantwortet.

]]>
Fri, 10 Nov 2017 08:47:47 +0100 https://www.webfactory.de/blog/bonnagile-meetup-zu-gast-mit-dynamic-ui-composition-fuer-microservices https://www.webfactory.de/blog/bonnagile-meetup-zu-gast-mit-dynamic-ui-composition-fuer-microservices webfactory GmbH webfactory GmbH 0
Reste retten nach Feierabend: Rudirockt bei der webfactory So kam es, dass ich am 13. Oktober schon zum dritten Mal bei “Rudirockt" bzw. in diesem Fall bei "Rudi rettet Reste” in unserem schönen Bistro servieren konnte.

Rudirockt wurde 2005 von vier Aachener Studenten konzipiert, um Studenten dabei zu helfen Kontakte zu knüpfen. Die Idee haben sie auf der Website rudirockt.de umgesetzt, ein soziales Netzwerk für stadtübergreifende “running dinner”. Man meldet sich in Zweier-Teams an und muss nur noch die Adresse der Küche angeben. Einen Tag vor dem Event erhält man dann eine generierte “Route” zugeschickt, dort steht wo und bei wem man jeweils die Vor-, Haupt- und Nachspeise isst.

Man kann sich Rudirockt als soziales Drei-Gänge-Menü vorstellen: Bei jedem Gang kommen drei Teams (also sechs Personen) zusammen und die Gruppen variieren jedes Mal, sodass man an diesem Abend mit insgesamt zwölf verschiedenen Personen aus den anderen Teams gegessen haben wird.

Die webfactory bietet mit der reich ausgestatteten Küche und dem gemütlichen Bistro inklusive Tischkicker die optimale Location für ein solches Event.

Während ich bei den letzten beiden Events die Hauptspeise als Wunschgang angegeben habe, entschloss ich mich dieses Mal für die Nachspeise, denn diese hat den Vorteil, dass die Gäste nicht noch weiter zum nächsten Gang gehen müssen.

Zum Nachtisch haben wir Käsekuchen nach österreichischem Rezept und eine Cidre-Bowle serviert, während die Zitronen und Orangen für Letztere ganz nach dem Motto "Rudi rettet Reste" von Foodsharing kamen. Außerdem gab es noch veganen Vanillejoghurt mit selbstgemachter Erdbeermarmelade, da wir aus der Route entnehmen konnten, dass sich ein Gast vegan ernährt.

Bei interessanten Gesprächen und viel Lachen klingelte es plötzlich an der Tür. Vier Rudirocker sind auf das fröhliche Treiben im Bistro aufmerksam geworden und haben außerdem ein Team vom vorhergehenden Mittagessen durch die großen Fenster erspäht. Selbstverständlich lud ich sie ein, sich dazu zu gesellen und so vergrößerte sich unsere Runde.

Nachdem noch zwei Freunde meines Nachtischteams dazugestoßen sind, waren wir komplett und nach einem durstlöschendem Kartenspiel war auch die Cidre-Bowle längst ausgetrunken.

Mit diesem Blog-Beitrag möchte ich mich für die tollen Möglichkeiten bedanken, die mir die webfactory sowohl im Beruf, als auch in der Freizeitgestaltung bietet :-)

Rudirockt wurde 2013 sogar bei “Land der Ideen” ausgezeichnet.
 

]]>
Mon, 30 Oct 2017 15:42:29 +0100 https://www.webfactory.de/blog/reste-retten-nach-feierabend-rudirockt-bei-der-webfactory https://www.webfactory.de/blog/reste-retten-nach-feierabend-rudirockt-bei-der-webfactory webfactory GmbH webfactory GmbH 0
Was sind eure Lieblings-Fachbücher? Wir haben die Besucher der FrOSCon-Konferenz gefragt Insgesamt haben wir in unserer Auswertung 329 einzelne Nennungen berücksichtigt. Eine geringe Anzahl an Titeln konnten wir leider bei aller Mühe nicht entziffern. Diese haben wir hier nicht weiter beachtet. Wir sprechen im folgenden Text auch von „Publikationen“ statt von „Büchern“, da nicht jeder genannte Titel auch ein Buch im eigentlichen Sinne war. Die 329 Nennungen haben wir dann zunächst in „fachfremde Publikationen“ einerseits und „fachspezifische“ bzw. „fachnahe Publikationen“ andererseits eingeteilt. Es stellte sich nämlich heraus, dass die Umfrageteilnehmer es mit der Bitte um Nennung von Fachbüchern nicht ganz so eng gesehen haben. Unter die „fachfremde“ Kategorie fielen somit sowohl einige Comics, als auch belletristische Werke wie die „Harry Potter“- oder „Game of Thrones“-Reihe (wobei wir uns bei letzterer gar nicht ganz sicher sind, ob sie wirklich so fachfremd ist: Immerhin verdeutlicht das GOT-Universum doch sehr anschaulich, welche Probleme eine existierende Konkurrenzsituation auf dem Markt mit sich bringt und wie man damit umgehen kann). Außerdem haben wir Publikationen sowie Texte anderer Fachrichtungen – zum Beispiel aus der Astrophysik oder aus dem juristischen Fachbereich – in die „fachfremde“ Kategorie eingeordnet. Wie man Abbildung 1 entnehmen kann, machte diese Gruppe insgesamt 19,1 % der genannten Publikationen aus. 

Abbildung 2 wiederum verdeutlicht, wie sich die „fachnahen“ und „fachspezifischen Publikationen“ zusammensetzten. Als „fachspezifisch“ haben wir dabei Titel eingeordnet, die sich tatsächlich direkt mit Themen aus dem IT- und Webbereich beschäftigen. In die „fachnahe“ Kategorie wiederum fielen themenverwandte Publikationen aus Bereichen wie Projektmanagement, Mathematik oder den Ingenieurwissenschaften. Ein Buch zur Aerodynamik hat uns bei der Einteilung dabei einige Kopfschmerzen bereitet. Wir haben es aber letzten Endes unter „fachnahe Publikationen“ gezählt – wer weiß, was der interessierte Leser an Informationen daraus mitgenommen haben mag. ;-)

Der Großteil der „fachspezifischen“- und „fachnahen Publikationen“ waren in der Tat Einzelnennungen; uns bot sich also ein sehr diverses Bild. Um das Ganze trotz der Diversität der Titel dennoch grafisch irgendwie sinnvoll darstellen zu können, haben wir uns maßgeblich auf die Publikationen konzentriert, die mehr als 3 unabhängige Nennungen erhalten haben. Dies traf auf insgesamt 8 Bücher (hier auch im tatsächlichen Wortsinne zu verstehen) zu, wobei wir zwei von diesen (LPIC-1 und LPIC-2) für unsere Darstellung zusammengefasst betrachtet haben. Als Spitzenreiter (mit insgesamt 16 Nennungen; also 6 %) stellte sich „Clean Code“ von Robert C. Martin heraus, was auch eines unserer eigenen Lieblingsbücher ist. Bei drei der Titel mussten wir ein bisschen raten, was genau gemeint sein könnte, weil es beispielsweise mehrere Buchtitel mit demselben Namen aber unterschiedlichen Autoren gab. Dies war der Fall bei den Titeln: „Linux-Server“, „Modern operating Systems“ und „Design Patterns“. Unter dem genannten Titel „Java ist auch eine Insel“ wiederum finden sich verschiedene Bücher mit unterschiedlichen Subtiteln, die allerdings alle von Christian Ullenboom geschrieben sind.

Grafische Auswertung der FrOSCon-Umfrage

]]>
Mon, 09 Oct 2017 15:58:47 +0200 https://www.webfactory.de/blog/was-sind-eure-lieblingsfachbuecher-wir-haben-die-besucher-der-froscon-konferenz-gefragt https://www.webfactory.de/blog/was-sind-eure-lieblingsfachbuecher-wir-haben-die-besucher-der-froscon-konferenz-gefragt webfactory GmbH webfactory GmbH 0
webfactory goes FrOSCon 12 Vermittelt durch unseren ehemaligen Mitarbeiter Matthias bot sich der webfactory dabei die tolle Gelegenheit, mit dem Team von Kaffetante Ruth zu kooperieren und den FrOSCon Kaffeestand zu betreuen. Wir hielten das für eine ganz großartige Möglichkeit; immerhin gibt es wohl wenig, was sich thematisch besser in das natürliche Habitat von chronisch koffeinkick-süchtigen Code-Schubsern einfügt! ;-)

Die Vorbereitungszeit war für uns eine erfrischende Abwechslung zu unserem normalen Berufsalltag; 400 Kaffeetassen, die wir auf der Konferenz verschenken wollten, mussten bestellt und mit Logos bedruckt werden. Darüber hinaus mussten wir eine für eine Webagentur durchaus ungewöhnlich hohe Anzahl an Printprodukten konzipieren und designen: Darunter ein Flyer, der uns als Firma vorstellen sollte. Unser Fokus lag dabei weniger auf unserer Selbstdarstellung als Dienstleister, da es uns auf der FrOSCon nicht um die Neukundengewinnung ging, sondern vielmehr um unsere Darstellung als attraktiven Arbeitgeber. Immerhin sind wir momentan mit Hochdruck auf der Suche nach intelligenten und kreativen Menschen, die uns zukünftig bei der Softwareentwicklung unterstützen wollen (hier geht's zu unserer Stellenanzeige – wir haben im Büro übrigens auch leckeren Kaffee!). Die gesamte Präsentationsfläche stand also unter dem Motto der Mitarbeitergewinnung und wir fragten uns, was wir vor Ort wohl noch machen konnten, um unserem Ziel näher zu kommen. Dabei stellten wir uns folgende konkrete Fragen: Wollen wir lediglich passiv für uns Werbung machen, wollen wir mit Leuten vor Ort ins Gespräch kommen oder wollen wir vielleicht Kontaktdaten von potenziellen Jobinteressenten sammeln?

Ruth bereitet einen Cappuccino mit Latte-Art zuDas Team von "Kaffeetante" Ruth

Relativ zügig entschieden wir uns für die dritte Variante. Natürlich war auch klar, dass wir vor Ort auch als Ansprechpartner zur Verfügung stehen würden, aber bloß darauf zu warten, bis jemand mit uns das Gespräch sucht, schien uns keine optimale Lösung zu sein. Schlussendlich haben wir uns nach einigem hin-und-her Überlegen und einigen verworfenen Ideen dafür entschieden, jedem Besucher in seiner Konferenztasche einen Kaffeegutschein für unseren Stand zur Verfügung zu stellen. Die Ausgabe eines Getränks war dabei an die Bedingung gekoppelt, uns ein bis drei Lieblingsfachbücher zu nennen. Wir dachten, es könnte sehr interessant sein, was dabei herauskommt und uns außerdem Gelegenheit bieten, in einem kleinen einleitenden Text auf unsere umfangreiche interne Fachbibliothek (über 300 Exemplare!) zu verweisen, auf die wir sehr stolz sind. Darüber hinaus bot der Gutschein den FrOSCon-Besuchern die Möglichkeit, uns ihre Kontaktdaten zu hinterlassen, damit wir sie im Nachgang der Konferenz über unsere Jobangebote informieren konnten. Uns war es dabei wichtig, dass die Angabe der Kontaktdaten optional war und keine Voraussetzung für die Ausgabe des kostenloses Kaffeegetränks.

Ein Kaffeegutschein wird ausgefüllt

Etwas verwundert waren wir darüber, dass von etwa 1800 ausgegebenen Gutscheinen bloß 211 Kaffeegutscheine eingelöst wurden. Wir fragen uns, ob es nicht mehr Bedarf gab, oder ob die Umfrage-Hürde vielleicht letzten Endes doch zu hoch war. Möglicherweise hat auch nicht jeder verstanden, dass die Angabe der persönlichen Daten rein optional war. Wenn wir das für die FrOSCon entworfene Konzept noch einmal an anderer Stelle verwenden wollen, sind dies sicherlich Fragen, mit denen wir uns noch einmal intensiv auseinandersetzen müssen. Unter den abgegebenen Gutscheinen haben uns schließlich insgesamt 13 Leute ihre Kontaktdaten hinterlassen. Zwar hatten wir hier mit einer kleinen Anzahl gerechnet, aber doch insgeheim gehofft, dass es ein paar mehr werden würden.

Das Konferenzwochenende war insgesamt aber dennoch ein voller Erfolg für unsere Firma. Unsere kleine Kaffeeecke war toll geschmückt mit Stehtischen in webfactory-Farben, vier großen Rollups und einem riesengroßen Banner, das wir oberhalb des Stands platzieren konnten. Unser Kollege Søren hatte spontan noch die simple aber geniale Idee, auf den Tischen Metallknobelspiele auszulegen, um die Besucher beim Kaffeetrinken zu unterhalten. Diese entpuppten sich dann auch als der Renner schlechthin: Es gab wohl das gesamte Wochenende über kaum einen Moment, an dem nicht irgendjemand am Knobeln und Rätseln war. Einige Besucher wurden sogar zu unseren Stammgästen und kehrten in den Pausen stets zu unserer Ausstellungsfläche zurück, um kaffeeschlürfenderweise weitere Rätsel zu lösen. Wir haben uns auch sehr darüber gefreut, das ganze Wochenende über viele interessante und durchwegs nette Unterhaltungen mit den Konferenzbesuchern und der FrOSCon-Crew führen zu können. Ein ganz besonderes FrOSCon-Highlight für uns als Firma war natürlich außerdem der beeindruckende Zauberlehrling-Vortrag, den Kollege Malte halten durfte. Besonders geschmeichelt hat uns zu guter Letzt, dass wir trotz zwanzigjährigen Bestehens von etlichen Besuchern für ein Start-up gehalten wurden und nach Richtigstellung stets mit einem überraschten: „Was? Und wie habt ihr es geschafft, dann immer noch so jung auszusehen?“, bedacht wurden. :-)

Søren und Malte am webfactory-StandDie Besucher haben Spaß beim Lösen der KnobelspieleEin Metallknobelspiel aus der NäheDie webfactory Kaffeeecke

]]>
Thu, 05 Oct 2017 18:29:40 +0200 https://www.webfactory.de/blog/webfactory-goes-froscon-12 https://www.webfactory.de/blog/webfactory-goes-froscon-12 webfactory GmbH webfactory GmbH 0
Ubiquitous Language in a non-english domain This is a translation of the original article in German.

As a German company with mostly German clients, this is a situation we encounter every day. Over the past twenty years, we have pursued different approaches to deal with language in our projects, some more successful than others.

The decision for a specific language in the domain model has far-reaching implications and a long life span, so we felt it was crucial to reach consensus within the team and establish a binding regulation.

It is also important to note that this regulation has no automatic consequences for related questions. For example, a decision for German does not mean that we will never employ non-German native speakers in the future. If our conditions change (e.g. different team composition, remote work), we will reopen the discussion.

The obvious question is whether we choose German or English. We quickly noticed that each of us has distinct personal habits and preferences.

Unfortunately, there are no definite rules that allow a clear decision for all use cases. Code, comments, commit messages and documentation are aimed at different audiences which can in turn benefit from different language choices.

The following is a (translated) excerpt from our internal knowledge base and documents our results.

Basics

The choice of language is an important topic in every project: The principle of Ubiquitous Language prescribes the use of an all-encompassing language from technical discussions and analysis with customers to writing code and documentation. Technical terms from the project's business domain should be used literally in the source code.

Building on the rationale behind Ubiquitous Language as a concept, we have coined this ground rule to help us in our discussions:

Our choice of language aims to minimize cognitive load (e.g. translations).

We want to avoid inconsistencies and miscommunication due to translation problems or misunderstandings and, if possible, even make a project glossary unnecessary.

That means that specialized concepts should not have to be "mentally mapped" to structurally different contexts in code, nor should there be translations of technical terms e.g. from German to English.

In our current setup, German is the native language for all team members. It is therefore also the language in which we can best assess linguistic nuances and differences of meaning and choose specific terms. When we express ourselves in English, we may not even notice the inaccuracies or ambiguities that we create for a native speaker.

Language in the code

We keep all terms, particularly in domain-specific parts of the code base, in the language we use to communicate with the customer.

This simple rule could get complicated if the customer is internationally positioned and has several internal languages. We will then take care to agree on English terms for the customer's technical concepts and also use these when we conduct a conversation in German.

It is helpful to consciously make this decision at the beginning of a project and document it in a kind of "charter", as in the end it is less important what language is chosen compared to the fact that there is a conscious and documented decision, which is also "lived" by all parties (customers and developers).

If we write code that we want to release as open source, we generally have an international (specialist) audience. It follows:

Open source code is written completely in English - unless it is aimed at a non-English domain.

Another rule that is derived directly from the principle of Ubiquitous Language is:

Language and terms are used uniformly and consistently in all parts of the code, e.g. PHP, HTML, Javascript, CSS etc.

As an example, it is considered bad practice to create a view template suchergebnis.twig.html and use search-result as class name inside the HTML.

On the other hand, most of the commonly used frameworks, tools, patterns etc. are created or conceived of in English. Because we still want to avoid cognitive load caused by translations, it follows that

Set professional expressions and framework conventions are preserved. Examples are get...() set...() ...Controller ...Factory ...FormType or common usages like click(), toggle(), submit() .

Perhaps one can say that the closer we are to the "infrastructure" layer, the more appropriate the language of English is in the code.

Documentation

For documentation that is intended to be shared with the customer, the same principle applies: We keep it in the language that we speak with the customer.

Language in comments, commit messages, and readme files

Comments, commit messages, readme files, etc. are nothing but postponed ("asynchronous") explanations to colleagues or our future self, which is why they should be written in the language that we would use to talk with the same person if she was sitting right in front of us.

Write a comment exactly how you would say it out loud in a conversation with a colleague.

The difference to the code is that we share terms from the code with the customer, while comments etc. are mostly notes for ourselves. 

Open source projects are, again, treated differently, as the audience is bigger than just our team: Comments, commit messages and all other documentation are written solely in English.

In closing

We are aware that this strong commitment to German might entail future costs of various kinds, if at any point German no longer were to be the intuitive choice of language for our team.

However, we do not think it makes sense to accept very real issues like ambiguous expressions, misunderstandings and translation errors just to avoid theoretical problems in the future.

Also, any non-German native speaker will most likely need to have at least sufficient command of German to be able to understand the key concepts of our German customers' domains - and then this problem is not any "worse" than an English term would be for us today

]]>
Mon, 07 Aug 2017 17:44:10 +0200 https://www.webfactory.de/blog/ubiquitous-language-in-a-non-english-domain https://www.webfactory.de/blog/ubiquitous-language-in-a-non-english-domain webfactory GmbH webfactory GmbH 0
Ubiquitous Language in einer nicht-englischen Fachdomäne: Unsere Herangehensweise This article is also available in English.

Wir haben in den vergangenen 20 Jahren verschiedene Ansätze verfolgt, mit Sprache im Projekt umzugehen. Manche haben sich bewährt, bei anderen sind wir auf Probleme gestoßen.

Da die Entscheidung für eine bestimmte Sprache bei der Begriffswahl im Domänenmodell eine lange Lebensdauer und weitreichende Auswirkungen hat, war es uns wichtig, im Team darüber Konsens herzustellen und eine für alle verbindliche Regelung zu finden.

Dieser Beitrag aus unserem Firmenwiki dokumentiert unsere Besprechungsergebnisse. 

Sprachwahl in Code, Kommentaren, Commits und Dokumentation

Für uns ging es um die Frage, ob wir als Sprache Englisch oder Deutsch wählen. Wie wir schnell gemerkt haben, hat dazu jeder starke persönliche Gewohnheiten und Präferenzen.

Daraus sollen aber keine weitergehenden Festlegungen folgen. So bedeutet eine Entscheidung für Deutsch nicht, dass wir nicht in Zukunft auch nicht-Deutsch-Muttersprachler beschäftigen können. Wenn sich die Rahmenbedingungen ändern (z. B. andere Team-Zusammensetzung, remote teams?) müssen wir das Thema erneut besprechen.

Leider gibt es keine scharfen Regeln, die in allen Fällen eine eindeutige Entscheidung ermöglichen. Wir haben aber gemerkt, dass sich Code, Kommentare, Commit Messages und Dokumentation u. U. an unterschiedliche Zielgruppen richten, was auch zu jeweils unterschiedlichen Entscheidungen führen kann.

Grundsätzliches

Die Sprachwahl ist ein wichtiges Thema: Das Prinzip der "Ubiquitous Language" bedeutet, eine alles durchdringende Sprache zu verwenden, und zwar von der fachlichen Diskussion und Analyse mit dem Kunden bis in den Code. Fachbegriffe der Domäne finden sich wörtlich im Code wieder.

Weder sollten fachliche Konzepte auf anders strukturierte technische Zusammenhänge "mental abgebildet" werden müssen, noch sollte es eine Übersetzung fachlicher Begriffe z. B. vom Deutschen in englische Begriffe geben, die dann im Code stehen.

Als Grundprinzip haben wir formuliert:

Wir wählen die Sprache so, dass wir die Notwendigkeit mentaler Transferleistungen (z. B. Übersetzungen) minimieren. 

Damit beugen wir Missverständnissen vor und reduzieren beispielsweise auch den Bedarf für ein Projekt-Glossar oder -Wörterbuch.

In unserer aktuellen Team-Zusammensetzung ist die Muttersprache für alle Mitarbeiter deutsch. Es ist daher auch die Sprache, in der wir sprachliche Nuancen und Bedeutungsunterschiede am besten beurteilen und Begriffe gezielt wählen können. Wenn wir uns in Englisch ausdrücken, bemerken wir unter Umständen gar nicht, welche Ungenauigkeiten oder Mehrdeutigkeiten wir damit für einen Muttersprachler erzeugen. 

Sprache im Programmcode

Alle Begriffe, insbesondere in Domänen-spezifischen Teilen des Codes, halten wir in der Sprache, die wir auch mit dem Kunden sprechen.

Schwierig könnte es dann sein, wenn der Kunde selbst international aufgestellt ist und evtl. intern mehrere Sprachen nutzt. Dann achten wir darauf, uns mit dem Kunden ggf. auf englische (= internationale?) Begriffe für fachliche Konzepte zu einigen. Diese Begriffe verwenden wir dann auch, wenn wir eine deutsche Unterhaltung führen. 

Es könnte hilfreich sein, diese Entscheidung einmal bewusst zu Beginn eines Projekts in einer Art "Charta" festzuhalten. Es ist dann fast weniger wichtig, welche Sprache festgelegt wird, als dass es überhaupt eine bewusste und dokumentierte Entscheidung gibt und diese auch von allen Beteiligten (Kunden und Entwicklern) gelebt wird.

Wenn wir Code schreiben, den wir quelloffen anbieten, haben wir in der Regel ein internationales (Fach-)Publikum. Dann gilt:

Veröffentlichter open source code nutzt Englisch als Sprache – es sei denn, er ist auf eine nicht-englische Fachdomäne ausgerichtet.

Eine weitere Regel, die direkt aus dem Prinzip der ubiquitous language folgt, ist:

Sprache und Begriffe werden in allen Code-Bereichen, d. h. in PHP, Twig, JavaScript, CSS etc. einheitlich genutzt.

Als Beispiel ist es ist nicht gut, eine View  suchergebnis.html.twig  anzulegen und darin dann die CSS-Klasse  search-result  einzuführen.

Auf der anderen Seite bringen Frameworks, Tools, Patterns etc. Begriffe und Konzepte mit, die typischerweise englisch benannt sind. Weil wir auch hier mentale Transferleistungen vermeiden wollen – nur eben anders herum – gilt:

"Stehende Begriffe" und Konventionen der Frameworks etc. bleiben erhalten. Beispiele sind  get...() set...() ...Controller ...Factory ...FormType  oder übliche Dinge wie  click(), toggle(), submit() .

Vielleicht kann man sagen, dass Englisch als Sprache im Code um so passender ist, je näher wir an der "Infrastruktur"-Schicht sind. 

Dokumentation

Für Dokumentation, die maßgeblich dazu gedacht ist, mit dem Kunden geteilt zu werden, gilt das gleiche Prinzip: Wir halten sie in der Sprache, die wir auch mit dem Kunden sprechen.

Sprache in Kommentaren, Commit Messages und Readme-Dateien

Kommentare, Commit Messages, Readme-Dateien etc. sind im Prinzip zeitlich versetzt vorgetragene Erklärungen an Kollegen oder unser zukünftiges Selbst.

Daher sollten sie um so mehr in der Sprache verfasst sein, die wir mit der entsprechenden Person auch sprechen würden.

Schreibe den Kommentar so, wie du ihn jetzt auch laut deinen Kollegen am Schreibtisch gegenüber vortragen würdest.

Der Unterschied zum Code ist also, dass wir Begriffe aus dem Code mit dem Kunden gemeinsam nutzen, während Kommentare etc. vor allem Notizen für uns selbst sind.

Aber auch hier gilt wieder: In Open Source-Projekten schreiben wir Englisch.

Schlussbemerkung

Uns war bewusst, dass diese starke Festlegung auf Deutsch Kosten verschiedener Art nach sich ziehen kann, wenn es irgendwann nicht mehr die selbstverständliche Sprachwahl unseres Entwicklungsteams sein sollte.

Allerdings macht es keinen Sinn, deshalb jetzt schon mögliche Probleme wie eine unklarere Ausdrucksweise, Bedeutungsverluste bei der Übersetzung etc. einzugehen, um das in Zukunft zu vermeiden.

Außerdem wird vermutlich jeder fremdsprachliche Entwickler zumindest so viel Deutschkenntnisse mitbringen müssen, dass er (oder sie) die Schlüsselbegriffe einer Domäne verstehen kann – und damit ist das Problem nicht "schlimmer", als eine englische Begriffswahl heute für uns wäre.

]]>
Wed, 02 Aug 2017 12:23:16 +0200 https://www.webfactory.de/blog/ubiquitous-language-in-nicht-englischer-domaene https://www.webfactory.de/blog/ubiquitous-language-in-nicht-englischer-domaene webfactory GmbH webfactory GmbH 0
Ein einfaches Formular als Eintrittskarte zur Community Es gehört zu unserer Leidenschaft, Webanwendungen so zu programmieren und zu gestalten, dass sie für User intuitiv bedienbar sind. So dass sie gerne genutzt werden. Ohne dass sich der User verheddert und abbricht.

Ein aktuelles Beispiel dafür findet sich auf der Website EuroPeers.de unseres Kunden JUGEND für Europa. Wir haben dort ein neues Anfrageformular integriert und so das Angebot erweitert.

Die Website

EuroPeers.de ist eine Plattform für junge Menschen, die im EU Programm Erasmus+ JUGEND IN AKTION aktiv waren und ihre Erfahrungen weitergeben möchten. Über 400 Ehemalige sind auf der Website registriert und haben dort ein eigenes Profil angelegt. Ihre Erfahrungen geben sie unter anderem in Schulen weiter. Lehrer können über die Website EuroPeers aus ihrer Region finden, die dann Vorträge oder Workshops vor Ort halten.

Die Problemstellung

Zwar gab es eine Unterseite, auf der alle Profile der Community-Mitglieder aufgelistet wurden. Zusätzlich gab es eine Landkarte, auf der alle EuroPeers mit ihren Wohnorten verzeichnet sind. Wer allerdings als Schulvertreter Kontakt zu ortsnahen EuroPeers aufnehmen wollte, musste sich umständlich durch die Profile klicken und Kontaktdaten händisch herausschreiben.

Eine Alternative bestand darin, bei den Organisatoren direkt anzufragen und um eine Kontaktvermittlung zu einzelnen EuroPeers zu bitten. Dies verursachte jedoch bürokratische Kosten.

Ein weiterer Aspekt: Die Plattform wurde zwar immer attraktiver, je mehr EuroPeers sich angemeldet haben. Gleichzeitig wurde die Suche für externe Interessierte immer unübersichtlicher, weil sie sich durch immer mehr Profile klicken mussten.

Damit ergab sich die Anforderung eine Lösung zu entwickeln, über das Lehrer und andere Interessierte auf einfache Art EuroPeers aus der Region auswählen und anfragen können.

Die Lösung

Für die Suche gibt es jetzt in der rechten Spalte ein erweitertes Formular „EuroPeers finden“. Dort haben wir eine Orts- und Umkreissuche integriert. Wer seinen Ort oder seine Postleitzahl eingibt, erhält automatisch eine Auswahl der EuroPeers aus seiner Region.

 

Bildschirmfoto 2015-11-27 um 10.41.01.png

Anschließend beginnt die Anfrage. Die Profile können per Klick zur Anfrage hinzugefügt werden. Grüne Häkchen geben sofort den Überblick, wen man bereits ausgewählt hat. Das macht Spaß und sieht gut aus.

Über ein Formular wird dann die konkrete Anfrage formuliert. Die Anfrage geht zunächst an eine zentrale Redaktion, um Spam-Nachrichten zu verhindern. Wird sie freigegeben, erhalten die EuroPeers eine Mail.

Hinzu kam eine zweite erweiterte Such- und Anfragemöglichkeit: Über eine Landkarte werden alle EuroPeers angezeigt. Wer auf seine Stadt klickt, erhält die Mitglieder, die sich vor Ort angemeldet haben. Mit einem Klick werden sie jetzt sofort zur Anfrage hinzugefügt.

Lehrern und anderen Interessierten fällt es jetzt deutlich einfacher, nach passenden EuroPeers zu suchen. Das integrierte Anfrageformular ist ihre Eintrittskarte zur Community. Mit wenigen Klicks können Sie schnell Ihre Anfrage stellen.

Unser Fazit

Das Projekt ist ein Beispiel, wie sich Websites kontinuierlich weiterentwickeln lassen. Vorhandene Funktionen und Features werden genutzt und individuell erweitert, anstatt etwas komplett Neues zu entwickeln. Das spart Zeit und Kosten.

Auch die Zusammenarbeit mit unserem Kunden steht exemplarisch für die Art an Problemstellungen heranzugehen. Die Verbindung der existierenden “EuroPeers finden”-Funktion mit dem Anfrageformular war keine Vorgabe des Kunden. Sie hat sich in Gesprächen entwickelt. Es ist ein partnerschaftlicher und agiler Ansatz, der Raum schafft, nach der bestmöglichen Lösung zu suchen.

Das Feedback unseres Kunden

Unser Kunde Andreas Klünter sagt dazu:

Eine sinnvolle Kontaktmöglichkeit für die 200 über Deutschland verteilten EuroPeers hinzubekommen, war eine schwierige Aufgabe. Die Anfragefunktion löst dieses Problem sehr gut und wird regelmäßig genutzt. Auch von den EuroPeers selbst wird die Funktion sehr gut angenommen. Definitiv eine große Verbesserung, die auch zu einer deutlichen Steigerung der Anfragen bei EuroPeers geführt hat.

Dazu passend:

]]>
Fri, 12 May 2017 13:04:13 +0200 https://www.webfactory.de/blog/europeers-anfragefunktion https://www.webfactory.de/blog/europeers-anfragefunktion webfactory GmbH webfactory GmbH 0