{"id":2323,"date":"2011-12-14T14:35:05","date_gmt":"2011-12-14T13:35:05","guid":{"rendered":"http:\/\/www.centigrade.de\/blog\/en\/?p=2323"},"modified":"2017-03-03T09:31:20","modified_gmt":"2017-03-03T08:31:20","slug":"user-interface-design-engineering-eine-neue-disziplin-mit-zukunft","status":"publish","type":"blog","link":"https:\/\/www.centigrade.de\/de\/blog\/user-interface-design-engineering-eine-neue-disziplin-mit-zukunft\/","title":{"rendered":"User Interface Design Engineering \u2013 eine neue Disziplin mit Zukunft"},"content":{"rendered":"

Dieser Artikel wurde inspiriert durch zwei interessante Tage bei der GUI+Design Konferenz<\/a> am 8. und 9. Dezember in F\u00fcrth. Die Konferenz f\u00fcr professionelle User Experience Designer und Entwickler wartete mit Themen rundum Microsoft User Interface Technologien wie WPF und Silverlight auf.<\/p>\n

Nicht nur der Artikel selbst entstand spontaner als gew\u00f6hnlich \u2013 auch eine der Aktivit\u00e4ten, an der ich w\u00e4hrend der Konferenz teilnahm, war spontan: Clemens Lutsch, User Experience Manager bei Microsoft Deutschland hat mich gefragt, ob ich bei einem Diskussions-Panel teilnehmen m\u00f6chte, welches den ersten Konferenztag ausklingen lassen sollte. Ich habe nat\u00fcrlich ja gesagt, denn es ging um ein sehr interessantes Thema: \u201eBegriffe und Rollen \u2013 was uns die Arbeit schwer macht\u201c.<\/p>\n

F\u00fcr mich war es eine exzellente Gelegenheit, einen Begriff in die Runde zu werfen, den wir schon vor einigen Monaten bei Centigrade eingef\u00fchrt haben: \u201eUser Interface Design Engineering\u201c, oder kurz: \u201eUI Design Engineering\u201c. Zun\u00e4chst haben wir den Begriff ausschlie\u00dflich intern verwendet, haben ihn aber mit der Zeit auch immer h\u00e4ufiger bei unseren Kunden und Partnerunternehmen angebracht und sind dabei auf gro\u00dfe Akzeptanz gesto\u00dfen. Als ich den Begriff bei dem Diskussions-Panel fallen lie\u00df, habe ich eine \u00e4hnliche Akzeptanz vom Publikum und den anderen Diskussionspartnern beobachtet \u2013 fast so als w\u00fcrde der Begriff eine L\u00fccke schlie\u00dfen, die bereits eine Weile existiert. Schon am n\u00e4chsten Konferenztag wurde der Begriff sogar in einer Session direkt wieder aufgegriffen.<\/p>\n

<\/p>\n

Was ist denn nun dieses \u201eUI Design Engineering\u201c?<\/h3>\n

F\u00fcr uns ist UI Design Engineering ein fundamentaler Baustein in einem Prozess, der letztendlich zu einem erfolgreichen User Interface f\u00fchrt. Beim UI Design Engineering geht es darum, diejenigen Konzepte zum Leben zu erwecken, die andernfalls in der Kommunikationsw\u00fcste zwischen Designern und Entwicklern versickern w\u00fcrden (wenn es auch pathetisch klingen mag, passt das Bild sehr gut). Es geht also um all die Dinge, die schneller und pr\u00e4ziser umgesetzt sind als sie jemals in Form eines Spezifikationsdokumentes weitervermittelt werden k\u00f6nnten. Der UI Design Engineer wird mit Aufgaben konfrontiert, die u.a. das Erstellen von Mikro-Interaktions-Prototypen, das Storyboarden von Animationen, die Definition von dynamischem Layoutverhalten und die Integration von visuellen Designs in echte Software umfassen.<\/p>\n

Traditionelle Bedeutung<\/h3>\n

Der Unterbegriff \u201eDesign Engineering\u201c ist nicht neu. Er wird gel\u00e4ufig im elektrischen, mechanischen und industriellem Design und sogar im Bauingenieurwesen genutzt. Selbst Wikipedia hat eine umfassende Definition zur Rolle des Design Engineers<\/a> parat. Wikipedia erw\u00e4hnt dabei aber mit keinem Wort \u201eSoftware\u201c oder gar \u201eUser Interfaces\u201c.<\/p>\n

Interessanterweise finden sich aber jede Menge \u00dcberschneidungen, wenn man die Wikipedia-Definition mit User Interfaces im Hinterkopf liest. Um nur einige zu nennen:<\/p>\n

\u201eDer Design Engineer k\u00fcmmert sich um das gesamte System genauso wie das innere Verhalten eines Designs.\u201c<\/em> Dies ist definitiv eine Aussage, die auf das Design eines Softwaresystems und dessen UI angewendet werden kann. Ein UI Design Engineer muss einen Blick auf die Strukturierung und Benennung von Design Assets haben (z.B. Farb oder Fontressourcen) so dass diese sich mit der gesamten System Architektur vereinbaren lassen, muss aber gleichzeitig Wissen \u00fcber einzelne Details im UI haben (z.B. wie sich der Mouseover Zustand eines Buttons auf Mikro-Ebene verh\u00e4lt).<\/p>\n

\u201eDer Design Engineer arbeitet normalerweise in einem Team von Ingenieuren und Designern und entwickelt das konzeptuelle, vorl\u00e4ufige und detaillierte Design der kritischsten Systemteile.\u201c<\/em> Betrachtet man die Entwicklung eines User Interface, sollte der UI Design Engineer sowohl mit Interaktionsdesignern und visuellen Designern als auch mit \u201eechten\u201c Software Engineers w\u00e4hrend des gesamten UI Entwicklungsprozesses zusammenarbeiten. UI Design Engineers sollten ferner nicht nur bereits in fr\u00fchen Projektphasen ein Auge darauf haben, ob Konzepte wirklich umsetzbar sind, sie sollten zudem aktiv involviert sein, wenn es darum geht, \u201ekritische Teile des Systems\u201c, in diesem Fall des User Interface, zu implementieren. Hierbei sind dynamische Aspekte des User Interface auch definitiv die kritischsten.<\/p>\n

\u201e\u2026Synthese steht f\u00fcr Design Engineers an erster Stelle.“<\/em> Dinge zusammenzuf\u00fcgen, die lose \u201eirgendwo\u201c existieren ist definitiv eine Aufgabe, der sich jeder UI Design Engineer stellen muss. Er\/sie muss Dinge implementieren oder integrieren, die andere Personen geplant haben (z.B. Screen Mocks oder Interaktionsparadigmen), so dass diese technisch kompatibel mit allen anderen Dingen sind, die bereits im System existieren.<\/p>\n

\u201eEine weitere Verantwortlichkeit eines Design Engineers ist das Prototyping. Ein Modell eines Produktes wird erschaffen und bewertet.\u201c<\/em> Hierzu gibt es eigentlich nicht viel Erkl\u00e4rungsbedarf. Das Modell eines Produktes im UI Kontext ist nat\u00fcrlich ein interaktiver Software Prototyp, der relevante Interaktionsmechanismen greifbar macht. Die Bewertung (und die potenzielle Verfeinerung) des Prototypen sollte ein integraler Bestandteil eines jeden professionellen User Interface Design Prozesses sein.<\/p>\n

\u201eDer Design Engineer ist w\u00e4hrend des gesamten Produkt Lebenszyklus anwesend und f\u00fchrt w\u00e4hrend dieser gesamten Zeit \u00c4nderungen durch. Dies wird auch augenzwinkernd als \u201evon der Wiege bis zur Bahre\u201c Engineering bezeichnet.\u201c<\/em> Software ist niemals fertig und genauso wenig ist es das User Interface. Daher macht es Sinn, dass ein UI Design Engineer den gesamten Prozess von Anfang bis Ende begleitet. Er\/sie ist sozusagen das \u201eDesign Ged\u00e4chtnis\u201c, das zu jedem Zeitpunkt sagen k\u00f6nnen sollte, wann sich bestimmte Designs im System ge\u00e4ndert haben und warum \u2013 nicht zuletzt deshalb, weil er\/sie wei\u00df, wie mit modernen Versionierungs-Tools wie SVN, Git oder TFS umzugehen ist.<\/p>\n

Abgrenzung von \u201eUser Interface Engineering\u201c<\/h3>\n

Manchmal f\u00e4llt im Kontext der UI Entwicklung der Begriff \u201eUser Interface Engineering\u201c. Dieser ist nicht zu verwechseln mit \u201eUser Interface Design<\/em> Engineering\u201c. Es gibt zwar einige Gemeinsamkeiten, aber eben auch gro\u00dfe Unterschiede. Es folgen einige Punkte in denen sich die beiden Begriffe unterscheiden:
\nUI Engineers schreiben objekt-orientierten Code (z.B. in C#) w\u00e4hrend UI Design Engineers deklarativen Code schreiben (z.B. in XAML).<\/p>\n

UI Engineers m\u00fcssen Business Objekte im Detail kennen (z.B. Datenmodelle oder DTOs) und sind verantwortlich daf\u00fcr Datenbindungen zu etablieren, die die View-Schicht an die Pr\u00e4sentationslogik koppeln.<\/p>\n

In dieser Hinsicht m\u00fcssen UI Engineers auch ein Auge auf Performanz-Aspekte haben: Datenbindungen sind elegant und einfach zu etablieren, k\u00f6nnen aber einen ausgesprochen negativen Einfluss auf die Gesamtperformanz des Systems haben, was manchmal nur durch ausgiebiges Profiling identifiziert werden kann. Der UI Design Engineer k\u00fcmmert sich ebenfalls um Performanz \u2013 allerdings eher in Bezug auf das visuelle Erscheinungsbild und nicht in Bezug auf die Logik des UIs. Wenn z.B. ein visueller Effekt sowohl durch eine einfache Linie als auch durch einen Pixelshader-basierten Schatteneffekt realisiert werden kann, entscheidet sich der UI Design Engineer eher f\u00fcr erstere L\u00f6sung, um auch auf alten Maschinen mit schw\u00e4cheren Grafikkarten immer noch eine akzeptable Laufzeitperformanz garantieren zu k\u00f6nnen.<\/p>\n

UI Engineers m\u00fcssen sich Gedanken um Speicherl\u00f6cher machen. Da sie objekt-orientierten Code schreiben (und dabei relativ frei Objekte instanziieren oder referenzieren), k\u00f6nnen sie jederzeit in eine Situation kommen, in der sie potenzielle Speicherl\u00f6cher aufrei\u00dfen (z.B. durch zyklische Objektreferenzen). F\u00fcr UI Design Engineers ist der Umgang mit Objekten weitaus restriktiver, da sie lediglich die M\u00f6glichkeiten der deklarativen Sprache aussch\u00f6pfen k\u00f6nnen und damit jede Menge potenzieller Gefahren vor ihnen versteckt bleibt (z.B. der Umstand, dass UI Elemente immer nur in einer gerichteten 1:n Eltern-Kind-Beziehung existieren k\u00f6nnen).<\/p>\n

Es ist gemeinhin akzeptiert, dass moderne Software-Programmierung auch immer die Produktion von Test Code involviert. Daher m\u00fcssen UI Engineers immer auch Unit Tests und automatisierte UI Tests implementieren. Im Gegensatz dazu k\u00f6nnen UI Design Engineers gar keine Test Cases schreiben, da sie nur \u00fcber die eingeschr\u00e4nkten Mittel der deklarativen Sprache verf\u00fcgen. Zuk\u00fcnftig kann jedoch immer h\u00e4ufiger der Fall eintreten, dass UI Design Engineers auch UI Interaktionen aufzeichnen und Annahmen (\u201eAssertions\u201c) definieren, die dann bei einer sp\u00e4teren Testsession wieder revalidiert werden. Dieser letzte Ansatz setzt nat\u00fcrlich ein leistungsf\u00e4higes Authoring-Werkzeug zur Erzeugung solcher Tests voraus \u2013 und diese sind zur Zeit schwerlich zu finden.<\/p>\n

Um diese kurze Gegen\u00fcberstellung in kurzen Worten zusammenzufassen: der UI Engineer ist ein Softwareentwickler w\u00e4hrend der UI Design Engineer ein Designer mit einigen Softwareentwickler-F\u00e4higkeiten ist.<\/p>\n

Welche Skills muss ein UI Design Engineer besitzen?<\/h3>\n

Um nur ein typisches Talent des Design Engineers zu nennen: die F\u00e4higkeit, ein dynamisches, aufl\u00f6sungsunabh\u00e4ngiges Layoutverhaltens, welches in vielf\u00e4ltigsten Kontexten mit verschiedenen Lokalisierungen und Displaygr\u00f6\u00dfen zurechtkommt zu definieren. Dies erfordert auf der einen Seite ein scharfes Verst\u00e4ndnis komplexer logischer Ketten, auf der anderen Seite aber auch die F\u00e4higkeit, gut proportioniertes Layout von schlecht proportioniertem zu unterscheiden und vor allen Dingen diejenigen Spezifikationsl\u00fccken zu f\u00fcllen, die der visuelle Designer oder Interaktionsdesigner evtl. hinterlassen hat, da dieser nicht alle Implikationen vorausgesehen hat. Nicht, dass visuelle Designer oder Interaktionsdesigner nicht die F\u00e4higkeiten h\u00e4tten, solche Situationen zu identifizieren \u2013 der Punkt ist, dass sie sie praktisch nicht identifizieren k\u00f6nnen<\/em>, da sie nicht an der \u201eechten\u201c Software arbeiten. Gemeint ist der deklarative Code, der das Design lebendig macht und dabei direktes Feedback und eine greifbare User Experience liefert. W\u00e4hrend der direkten Zusammenarbeit zwischen Designern und Entwicklern am gleichen Projekt k\u00f6nnen grobe konzeptuelle Schnitzer oder unpassende Interaktionsmechanismen daher bereits w\u00e4hrend der Entwicklung aufgedeckt werden. Nat\u00fcrlich macht dieser Umstand Usability Tests nicht hinf\u00e4llig, er \u201eschmiert\u201c aber in jedem Fall den gesamten Entwicklungsprozess.<\/p>\n

Neu, aber zeitlos<\/h3>\n

Der Begriff UI Design Engineering ist relativ neu, aufgrund der Tatsache, dass wir ihn als Konsequenz eines immer noch sehr modernen User Interface Entwicklungs-\u00d6kosystems rundum WPF und Silverlight ins Leben gerufen haben.<\/p>\n

Zugegebenerma\u00dfen: die Werkzeuge, die im allgemeinen genutzt werden, um diese modernen technischen M\u00f6glichkeiten auszunutzen \u2013 Expression Blend und Visual Studio \u2013 sind bereits seit einiger Zeit verf\u00fcgbar. Trotzdem existierte niemals eine gr\u00f6\u00dfere \u00dcbereinstimmung dar\u00fcber, welche F\u00e4higkeiten und Verantwortlichkeiten mit einer Person verkn\u00fcpft sein m\u00fcssen, die effektiv mit Expression Blend arbeiten k\u00f6nnen soll. Eine starke und meiner Meinung nach sehr vorteilhafte Entwicklung ist, dass Expression Blend nicht l\u00e4nger als reines Design Tool betrachtet wird. Es wird endlich als ein Werkzeug betrachtet, dass nur von Designern mit \u201eSpezialkr\u00e4ften\u201c beherrscht werden kann \u2013 Design-Entwickler-Hybride, die in ihrem Denken und Handeln zwischen linker und rechter Gehirnh\u00e4lfte umschalten k\u00f6nnen. Oder eben kurz: UI Design Engineers.<\/p>\n

Ausblick in die Zukunft<\/h3>\n

Ich bin der festen \u00dcberzeugung, dass es keinen Weg zur\u00fcck zu einer rigiden Abgrenzung zwischen Entwickler- und Designert\u00e4tigkeiten. Selbst andere Technologien als WPF und Silverlight werden in Zukunft anhand ihrer F\u00e4higkeit gemessen werden, wie sie Designer und Entwickler zusammenzubringen, nicht blo\u00df lediglich anhand ihrer \u201eharten\u201c Merkmale wie z.B. Performanz oder Plattformunabh\u00e4ngigkeit. Es ist kein Zufall, dass Nokias neues Qt Quick mit zwei Tools (QML und Qt Creator) aufwartet, die UI Design Engineering Aktivit\u00e4ten umfassend abdecken. Offensichtlich ist die Kombination aus deklarativer Sprache (XAML oder QML) und einer starken WYSIWIG Umgebung (Expression Blend oder Qt Creator) ein Schl\u00fcssel f\u00fcr diese neue Disziplin, mehr als es die eigentliche Syntax der Sprache oder die unterst\u00fctzte Zielplattform ist.<\/p>\n

Vor diesem Hintergrund habe ich die starke Vermutung, dass die Idee, die wir mit der Bezeichnung \u201eUI Design Engineering\u201c beschreiben, von Dauer ist und dass der Begriff \u00fcber die Technologien hinausgeht, die ihn bei Centigrade urspr\u00fcnglich hervorgerufen haben. In jedem Fall, finde ich es sehr sch\u00f6n zu beobachten, dass beide Disziplinen \u2013 traditionelles Software Engineering und traditionelles User Interface Design \u2013 in Zukunft weiterhin n\u00e4her zueinanderr\u00fccken werden. Und UI Design Engineering wird dabei die Verbindung sein, die die beiden Disziplinen auf Dauer zusammenh\u00e4lt.<\/p>\n


\nAlle genannten Marken oder eingetragene Marken sind Eigentum der jeweiligen Markeninhaber.
\n<\/span><\/p>\n","protected":false},"author":5,"featured_media":0,"template":"","tags":[],"class_list":["post-2323","blog","type-blog","status-publish","hentry"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/2323","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog"}],"about":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/types\/blog"}],"author":[{"embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/users\/5"}],"version-history":[{"count":0,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/blog\/2323\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/media?parent=2323"}],"wp:term":[{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.centigrade.de\/de\/wp-json\/wp\/v2\/tags?post=2323"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}