Seit einigen Jahren mischen Smartphones und Tablets den klassischen PC-Markt auf. Immer mehr Menschen gehen mit ihren mobilen Geräten ins Internet. Diesem Trend versucht OTTO mit diversen geräteoptimierten Shops sowie hybriden Apps gerecht zu werden. Daraus resultiert eine nicht zu unterschätzende Design-, Code- und damit auch Feature-Fragmentierung.

Seit 2010 gibt es aber auch einen anderen Ansatz, um auf die Multi-Device Problematik einzugehen, und zwar Responsive Webdesign. Zum ersten Mal wurde der Begriff von Ethan Marcotte in einem Artikel für das Magazin A List Apart verwendet. Er beschreibt ihn dort wie folgt:

„Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.“

Aus technischer Sicht bedeutet das ganz konkret: Eine einzige HTML Struktur mit dazugehörigem CSS für alle Endgeräte, also keine Fragmentierung mehr. Besonders interessant wird Responsive Webdesign unter dem Gesichtspunkt, dass die Grenzen zwischen den Geräten zunehmend verschwimmen.

Fast feedback is a cornerstone of agile software development. When developing the LHOTSE project at Otto, we tried to be as agile as possible and many of our means and methods revolve around fast feedback. Here is a list of my favourite things we do to foster fast feedback. It does not at all cover everything we do in our daily work, let alone everything one possibly could do.

All methods have one thing in common: They try to let the development team know as early as possible when things are going into the wrong direction. The key hypothesis is: The sooner you recognize a mistake, the easier it is to fix it. If you introduce a bug in the software, it is easiest to fix it right away, when you still know what you where doing and when you can associate the bug with the small change you just did. When you learn about a bug later, you first have to identify the change that introduced it, then try to remember the intentions of that change. When adjusting the change, you have to be careful not to break anything that was built on top of it later.