Die Exclusive Design Challenge

Exclusive Design – was soll das bitte sein?

Vasilis van Gemert versteht Exclusive Design als die Umkehrung von Inclusive Design. Wobei Inclusive Design das Bestreben beschreibt, Interfaces im Web so zu gestalten, dass sie für jeden gleichermaßen benutzbar sind. Ein zentraler Wunsch bezüglich des Web ist ja die Verfügbarkeit für jeden.

Der Inclusive-Design-Ansatz

Der Inclusive-Design-Ansatz birgt dabei zwei Fallstricke:

  1. Er geht davon aus, dass jeder gleichermaßen über (eine oder mehrere) unterschiedliche Formen der Interaktion mit dem Web verfügt.
  2. Er schränkt die Möglichkeiten/Technologien, die wir für User Interfaces einsetzen können, zu seinem nicht geringen Grad ein.

Die Kombination aus diesen beiden Punkten lässt vermuten, dass wir für das Web und seine User nicht unbedingt die besten Interfaces bzw. Design-Lösungen bauen. Vielmehr entwicklen wir Dinge, die weder für Menschen mit (schwerem) Handicap optimal sind, noch für Menschen ohne.

— Exclusive Design Challenge —

Save the date – die nächste Exclusive Design Challenge haben wir im Rahmen des DevCamp.create am 9./10. März in Würzburg geplant. Vorbeikommen lohnt sich!

Exclusive Design Challenge

In einer Exclusive Design Challange hat van Gemert mit 16 Kreativen aus unterschiedlichsten Bereichen die Inclusive-Design-Prinzipien zu Exclusice-Design-Prinzipien umgekehrt und versucht, anhand dieser Prinzipien Probleme stark beeinträchtigter Menschen ausschließlich für diesen einen Menschen zu lösen. Von der „Gleichmacherei“ hin zu einer sehr individuellen Lösung. Und von dieser sehr individuellen Lösung hin zu … Spezialisierteren Environments? Zurück in den Mainstream?

Das wollen wir für uns herausfinden! Auf dem CREATE-Track des Developer Camps Anfang März wollen wir unsere eigene Exclusive Design Challenge durchspielen.

Disclaimer: Wir sind auf Vasilis und seine Exclusive Design Challange auf der Beyond Tellerrand im vergangenen November aufmerksam und neugierig geworden. Wenn ihr noch etwas tiefer in das Thema einsteigen wollt, können wir den Mitschnitt seines Talks sehr empfehlen:


DevCamp.create

Das DevCamp.create ist ein Barcamp für kreative Köpfe. Bei Interesse solltet ihr schnell sein: Die Anzahl der Plätze ist limitiert!

Open Source ist auch Bildung

Es bringt ja Nichts. Egal wie man das Blatt dreht und wendet – von staatlicher Seite scheint in den nächsten Jahren nicht viel zu kommen, wenn es um digitale Bildung geht. Jugendliche stehen mit Ihren Smartphones zwischen dem Verbot an der Schule und den Eltern, die die neue Technik womöglich noch nicht einmal ganz verstehen. Sie stehen der Welt, dem Internet und der Flut der Information beinahe allein gegenüber.

Der Ist-Stand

Es werden zwar aktuell Milliarden-Investitionen für die technische Ausstattung von Schulen für die Bildung besprochen, doch was nützt das alles, wenn weder der Lehrplan noch die Ausbildung der Lehrer die Welt von morgen – oder eigentlich von heute – beinhalten?

Weiterlesen

Unkonventionelles UX-Testing: The User is Drunk

„Don’t make me think“ – nach dem gleichnamigen Buch von Steve Krug – ist der Claim, der Usability und User Experience seit nun fast 20 Jahren bestimmt. Nutzer wollen nicht nachdenken, wenn sie tagtäglich Produkte verwenden. Die Bedienung soll „intuitiv“ sein und schnell zum gewünschten Ergebnis führen.

Intuitive Bedienung ist jedoch eine der größten Mythen der Produktentwicklung, da die vermeintliche Intuition bei der Verwendung von Produkten fast immer auf vorher erlerntes Verhalten zurückgeführt werden kann. „There really is no user interface metaphor that is truly intuitive“ proklamierte Scott Francis 1994 (The Only Intuitive Interface Is The Nipple). Es gibt keine intuitiven Bedienkonzepte – moderne User Interfaces sind immer eine Mischung aus gewohnter (und damit erwarteter) Methodik und der Anreicherung eben dieser mit neuen Ideen und Konzepten.

Weiterlesen

Agile Missverständnisse: Von Helden und Eiern

„Wir machen uns um Onkel Henry furchtbare Sorgen. Er denkt, er sei ein Huhn.“
„Na, warum schicken Sie ihn denn nicht zum Arzt?“
„Naja, das würden wir ja. Aber wir brauchen die Eier.“
— Douglas Adams: Der lange dunkle Fünfuhrtee der Seele: Dirk Gently’s Holistische Detektei

Agile Methoden setzen auf das Team, nicht auf die Individuen. Alles soll das Team entscheiden, alles soll das Team gemeinsam machen. Von Pair über Mob Programming, die meisten Dinge lasten auf mehr als einem paar Schultern. Als Metapher hat man sogar den Bus-Faktor gefunden: Wie viele Leute aus dem Team muss ich mit dem Bus überfahren, bis die Software nicht mehr weiterentwickelt werden kann?

Weiterlesen

Agile Missverständnisse: Was Selbstorganisation nicht ändern darf

Wirklich agil bedeutet doch auch, dass man alles ändern kann. Da ist auch Scrum schon zu dogmatisch, deshalb haben wir das abgeschafft und sind auf Kanban gewechselt. Wir releasen ohnehin die ganze Zeit, da ergeben die Iterationen keinen Sinn. Einen Product Owner haben wir ebenfalls nicht, das hat für uns irgendwie nicht gepasst. Scrum Master sind bei uns jetzt agile Coaches, aber davon brauchen wir auch nicht für jedes Team einen, wir haben jetzt praktisch für alle drei Teams einen.

Weiterlesen

10 Lessons Learned für besseres Pair Programming

Es ist Zeit für Lessons Learned: Nachdem ich in meinem letzten Blogbeitrag eine Einführung in das Thema Pair Programming gegeben habe, möchte ich in diesem Artikel meine persönlichen Erfahrungen mit dieser Arbeitstechnik teilen. Hierzu stelle ich die wichtigsten Regeln vor, die man beim Pairing beachten sollte. Außerdem gebe ich Tipps, die sich im konkreten Doing bei Mayflower als Lessons Learned herausgestellt haben.
Weiterlesen

Agile Missverständnisse: Architektur entsteht emergent

Schon das agile Manifest hat eine klare Ansicht darüber, wo und wann Architektur entstehen sollte:

The best architectures, requirements, and designs emerge from self-organizing teams.

Also ist die Sache doch klar: Das Team entscheidet selbst über die Architektur, und die alten Mächte, die aus den Enterprise Architecture Boards die richtige Architektur aus der Ferne finden wollten, sind bezwungen. Endlich kann man selbst Hand anlegen und Architektur passiert dann, wenn sie gebraucht wird.
Weiterlesen

Pair Programming

Obwohl ich seit 15 Jahren als Softwareentwickler tätig bin, habe ich Pair Programming erst vor ca. drei Jahren bei Mayflower kennengelernt und zum ersten Mal angewandt. Bei all meinen vorhergehenden Tätigkeiten war ich ausschließlich als Code-Einzelkämpfer unterwegs und damit beschäftigt, so schnell und so effizient wie möglich Quellcode zu produzieren.

Ich möchte in diesem Artikel eine grundlegende Einführung in das Thema Pair Programming geben, indem ich die wichtigsten Aspekte zu dieser Arbeitstechnik vorstelle.

Weiterlesen

Agile Missverständnisse: NoEstimates – Schätzungen schaden.

Wer schätzt, verliert. Entweder man hat genug Buffer mit drin und es ist zu aufwändig, oder er fehlt und es klappt nicht pünktlich. Externe Abhängigkeiten werden auf rauen Annahmen geplant, von denen man sich zwar wirklich wünscht, dass sie zutreffen würden, aber in Wahrheit selbst nicht daran glaubt. Und kurz vor dem Launch kommen dann die Überraschungen, mit denen man zwar gerechnet hat, jetzt aber keine Zeit mehr hat, mit ihnen umzugehen.

NoEstimates

Also lieber nicht schätzen, sondern auf Business Value und Durchfluss optimieren. Wenn ich zu jedem Zeitpunkt das Nützlichste mache und meine Strecke auf dem Weg dazu kontinuierlich verbessere – was könnte ich mehr als Beitrag leisten?

Weiterlesen

Chan-jo Jun über … Arbeitnehmerüberlassung & agile Projekte

Das Thema Arbeitnehmerüberlassung ist heiß diskutiert; schließlich hängt einiges davon ab: So besteht zum Beispiel die Gefahr, dass man sich als Konzernanwalt strafbar machen kann, wenn man zulässt, dass fremde Arbeiter im eigenen Unternehmen wie eigene Mitarbeiter eingebunden sind.

Doch wie genau geht man nun mit der Arbeitnehmerüberlassung um? Wie sehen (Team-)Konstellationen in agilen Projekten aus, mit denen man auf der sicheren Seite ist?

Weiterlesen