Hallo Welt

3D

Mir hat es schon immer irgendwie interessiert 3D-Objekte und virtuelle Welten zu konstruieren bzw. zu kreieren und natürlich auch zu animieren. Anfang der 90er war das auf einem Heim-PC noch gar nicht so einfach brauchbare und v.a. bezahlbare bzw. kostenlose Programme dafür zu finden. Ende der 90er habe ich dann Cinema 4D für mich entdeckt und bin bis heute dabei geblieben. Natürlich habe ich die Version immer mal wieder aktualisiert, was mittler­weile leider nicht mehr ganz so günstig ist, v.a. wenn man gleich die Studio-Variante nutzen will.

Mit der Zeit kam das Erstellen von Expressions (auch für Thinking Particles usw.), physika­lischen Simula­tionen, das Anpassen der UV-Maps, Global Illumi­nation und vieles mehr hinzu. Wobei GI, je nachdem wie realis­tisch es aus­sehen soll, immer noch extrem viel Rechenpower benötigt. Aller­dings ist dieser Bereich inzwi­schen etwas in den Hinter­grund gerückt.

Heutzutage kann man sich kaum mehr vorstellen wie lange es anfangs gedauert hat, bis ein Bild in guter aber schlichter Qualität und auch nur in TV-Auflösung (PAL 720x576) fertig berechnet war. In ähnlicher oder sogar besserer Qualität und viel höherer Auflösung (Full-HD 1920x1080) werden 3D-Welten, inkl. physikalischer Simulation, selbst auf einem Smartphone heutzutage in Echtzeit dargestellt. Das ist auch der Grund, warum mich 3D-Anwendungen in Echtzeit mittler­weile viel mehr reizen. Damit meine ich übrigens nicht nur Spiele. Technische Illustra­tionen, interaktive Visualisie­rungen und Simula­tionen sind mir irgendwie am liebsten.

2012 bin ich durch Zufall auf Three.js gestoßen. Ein JS-Framework mit dem man recht komfortabel virtuelle Welten im Browser darstellen kann, ohne die durchaus gewöhnungs­bedürftige WebGL-Syntax verstehen zu müssen. War natürlich von Anfang an hellauf begeistert und habe auch gleich einige Experimente umgesetzt. Damals aller­dings noch so gut wie ohne API-Dokumen­tation. So musste ich mich mühsam durch die einzelnen JS-Module bzw. -Objekte kämpfen um überhaupt was darzu­stellen zu können. So um 2014 entdeckte ich die kostenlose Version von Unity. Eine Game-Engine, bei der die physi­kalischen Simula­tionen in Echtzeit schon integriert sind. Das war auch der Grund warum ich auch gleich 4 Spiele erstellt habe bzw. fast schon erstellen musste. Zwar nur mit mäßigem Erfolg, habe aber trotzdem, v.a. in der Programmierung bzw. Entwicklung von (3D-)Anwen­dungen sehr viel dazugelernt.

In Cinema 4D erstelle ich meist nur mehr die 3D-Objekte inkl. Texturen und angepasster UV-Maps. Auch die zahl­reichen Export­funktionen sind sehr hilfreich. Außerdem macht es mir mittler­weile fast mehr Spaß, die Logik und Inter­aktionen zu program­mieren, als sich nur um die Grafik zu kümmern. Wobei ich die Kombi­nation aus beiden durchaus angenehm finde. Mir macht es einfach Spaß etwas zu entwickeln, bei dem sich was am Bildschirm bewegt und am besten noch was simuliert bzw. visualisiert wird, als sich nur um reine Daten bzw. Zahlen zu kümmern. Wobei ich aber ehrlich gestehen muss, dass ich in meinem Job doch eher in die Datenrichtung gehe, welche übrigens auch nicht ohne ist. Aber dafür eben mehr im Frontend. Würde gerne schon noch mehr in dieser Richtung (auch VR und AR) ausprobieren, komme aber leider einfach nicht mehr dazu.

CSS

Auch wenn auf dieser Seite der Quell­code meiner (historisch gewachsenen) CSS-Style­sheets auf den ersten Blick viel­leicht nicht wirk­lich aufge­räumt wirken, kenne ich mich mit den ganzen, aktuellen Attri­buten, Selek­toren, Pseudo­elemente, Media Queries usw., doch ganz gut aus. Da ich ja doch seit Anfang der Jahrtausendwende meine Stylesheets in der Regel komplett selbst erstelle. Es ist zwar zu Beginn relativ viel Arbeit, aber dafür habe ich dann auch wieder einige Jahre meine Ruhe. Natürlich verwende ich dieses gleich auch für mehrere Applikationen und erweitere das Stylesheet vielleicht nur noch um die ein oder anderen Klassen.

Sobald die Browser­unterstützung soweit fort­geschritten ist, dass (endlich) neue Attribute verwendet werden können, wird es Zeit auch ein komplett neues, modernes Stylesheet zu erstellen. Mittler­weile selbst­ver­ständlich mit Flex­boxen, Layout­grids, CSS-Transitions, -Animationen, Pseudo­elemente usw.. Im Grunde alles was heutzutage modern, praktisch und von (fast) allen modernen Browsern unterstützt wird. Natürlich das Ganze auch responsive. Und zwar so automatisch, dass man sich später nicht mehr viel Gedanken machen muss, wie die Anwendungen auf den verschiedenen Geräten aussehen und bedient werden können. Bei unseren (internen) Verwaltungs­applikationen gehe ich in der Regel von der Desktop­ansicht (Desktop first) aus, da diese meist immer noch auf diesem verwendet werden. Wenn es sich allerdings um Anwendungen handelt die im wilden Web veröffentlicht werden, verwende ich selbstverständlich den mobile first Ansatz. Vor allem auch deswegen, da sich so die Auftraggeber damit auseinander setzen müssen, wie die Seite auf einem Smartphone praktisch und sinnvoll benutzt werden kann. Der Rest ergibt sich dann meist automatisch.

Mit CSS-Präpro­zessoren wie SASS/SCSS und Less habe ich mich zwar schon beschäftigt, bin aber zu dem Schuss gekommen, dass ich sie nicht wirklich benötige, da ich mich einfach schon zu sehr an die normale CSS Syntax gewöhnt habe. Was nicht heißen soll, dass ich SASS/SCSS und Less grundsätzlich ablehne. Es ist einfach nur Geschmackssache. Der Code ist zwar etwas schöner und vielleicht übersicht­licher, allerdings ist die Fehlersuche hier nicht mehr ganz so einfach, da der Browser ja nur das normale CSS verarbeitet. Einer der größten Vorteile waren meiner Meinung nach die Variablen. Da aber mittler­weile alle modernen Browser mit echten CSS-Variablen umgehen können, verwende ich auch gleich diese.

Auch wenn das heutzutage nicht mehr ganz so eine große Rolle Spielt, achte ich trotzdem auf eine möglichst geringe Dateigröße, selbst wenn das Stylesheet noch nicht minifiziert ist. In der Regel schreibe ich auch nur Klassen, welche auch wirklich benötigt werden. Das finde ich auch eines der größten Nachteile der gängigen CSS-Frameworks, von welchen man oft nur einen Bruchteil benötigt, aber trotzdem die ganze Stylesheet Datei geladen werden muss. Außerdem finde ich es bei den Frameworks ein bisschen übertrieben, dass es für fast alle CSS-Styles jeweils eine Klasse gibt und das noch mit unter­schied­lichen Werten. So wird meiner Meinung nach die flexible und ursprünglich angedachte Kaskadierung untergraben.

Allerdings sollte man den größten Vorteil dieser Frame­works auch nicht ganz verschweigen. Es gibt für diese mittler­weile so viele tolle Steuer­elemente, welche von sehr großen Communities erstellt und unter­stützt werden, so dass es mittler­weile wirklich sehr schwer ist, diese zu ignorieren. Außerdem habe ich festgestellt, dass viele reinen Coder oft mit diesen Frameworks einfach schneller zurecht­kommen, da sie sich verständ­licher­weise lieber mehr um die Logik als um das Aussehen und Layout kümmern wollen.

Frontend

In meiner Arbeit bin ich für die Erstel­lung des kompletten HTML-Layouts unserer mittlerweile meist respon­siven Webanwen­dungen verant­wortlich, egal ob es sich um interne Anwendungen oder um Kunden­projekte handelt. Egal ob für deren Intranet oder fürs Web selbst. Neben der HTML Struktur kümmere ich mich natürlich auch um die ganzen CSS-Style­sheets. Da wir schon sehr lange mit WebForms arbeiten sind mir hier die meisten Controls und deren Eigen­heiten durchaus vertraut. Nur der Vollstän­digkeit halber soll erwähnt sein, dass ich auch Layouts für WinForm- und WPF-Applika­tionen erstellt habe. Für WPF auch in XAML selbst und nicht nur über Expression Studio/-Blend.

Neben den ganzen Markups (HTML und CSS) entwickle ich auch viele client­seitige Funk­tionen mit Java­Script selbst. Nicht nur für die Validierung und Verein­fachung der Eingaben, sondern auch für client­seitige Business­logiken, Ajax-Requests z.B. für Autocompletes usw. oder erstelle auch gerne mal eigene Steuer­elemente bzw. passe vorhan­dene an. Obwohl WebForms aber auch MVC bzw. Razor-Pages manchmal keine wirk­lich gute Unter­stützung für client­seitige Aktionen bieten, haben wir trotzdem die eine oder andere Funktio­nalität mit Java­Script ganz gut hinbekommen.

Seit einigen Jahren beschäftige ich mich privat mit Vue.js. Habe mir zwar auch kurz Angular und React angesehen, bin aber mit Vue irgendwie sehr schnell zurecht­gekommen und deshalb dabei geblieben. Würde behaupten, dass ich über die Grundlagen schon weit hinaus bin, da bei Vue die Lernkurve, zumindest für mich, sehr steil war. Natürlich mit sehr viel Hilfe aus dem Internet, da sich zum Glück rund um Vue.js eine große Community gebildet hat. Das Schwierigste war für mich eher, sich die Grundlagen von Webpack und NPM anzueignen. Auch das im- und exportieren der ganzen Komponenten, Klassen, Interfaces usw. habe ich an sich schon ganz gut drauf. Nur mit TypeScript habe ich ehrlich gesagt noch ein bisschen Schwierig­keiten, aber das wird sich auch noch legen.

Mittlerweile schwenken bei uns in der Arbeit auch immer mehr Entwickler zu Vue.js um. Wobei sie sich am liebsten noch eher um das Schreiben der REST-APIs kümmern. Den cienseitigen Part übernehme dann größtenteils ich. Bisher haben wir schon ein größeres Verwaltungs- und Erfassungs­portal (inkl. Security­context, also mit Login und Berechtigungs­system), eine Assesment-Applikation, sowie einige Antragsstrecken mit Vue.js realisiert. Wobei ich für die Antrags­strecken, bis auf die REST-Services, im Grunde alleine Verantwortlich bin. Bei allen anderen erstellte ich das Grundgerüst, wirke weiterhin tatkräftig mit und berate auch die Entwickler, die damit erst anfangen. Bisher haben wir noch nicht einmal irgendwelche Steuer­element­biblio­theken oder andere CSS-Frameworks benötigt, da ich die für uns erstmal wichtigsten Steuer­elemente, wie dynamische Tabellen inkl. Pager und Sortierung, (modale) Dialoge, Eingabefelder inkl. Validierung usw. selbst erstellt habe. Die Tabellen und Dialoge kann man sogar komplett frei anpassen, indem man einfach nur Slots verwendet.

Muss leider ganz ehrlich, zu meiner Schande gestehen, dass ich mit dem server­seitigen Code eher weniger zu tun habe. Trotzdem fließen viele meiner Ideen und Gedanken bei den Backend-Entwick­lern ein. Ein ganz gutes Grund­verständnis ist dafür durchaus vorhanden. Es kommt auch schon mal vor, dass ich im Servercode, selbst kleine Ände­rungen oder Anpassungen vornehme. Bei den REST-APIs fällt es mir sogar noch ein bisschen leichter als bei den Anderen.

Grafik

Da ich ehrlich gesagt nicht wirk­lich gut mit der Hand zeichnen kann, hat es mich schon immer gereizt, meine Ein­fälle mit Hilfe des Computers irgendwie optisch darzu­stellen. Am liebsten mit Hilfe eines 3D-Programms, wie z.B. Cinema 4D, mit dem ich meine Vorstel­lungen virtuell abbilden kann. Wobei bei meinen Arbeiten eher klare, oft tech­nische Konstruk­tionen oder frak­tale Formen im Vorder­grund stehen. Aller­dings sind die Beispiele auf dieser Webseite auch oft schon etwas in die Jahre gekommen. Leider komme ich aufgrund meiner anderen Inter­essen (Arbeit, Echtzeit-3D oder Java­Script) so gut wie gar nicht mehr dazu neue Arbeiten zu erstellen.

Sowohl privat, als auch in der Arbeit verwende ich ganz selbst­verständlich Photo­shop um Bilder, Logos, Icons, Charts, Fotos usw. nachzube­arbeiten und vor allem für's Web zu opti­mieren. Das gilt auch für Illustrator Vektor­grafiken. Wobei ich früher auch öfters Collagen, Komposi­tionen, kleine Werbe­prospekte und Flyer mit Photo­shop erstellt habe. Mit InDesign habe ich später auch noch ein paar Flyer, kleine Broschüren und andere Print­produkte erstellt. Das Ganze ist aller­dings auch ein bisschen in den Hintergrund geraten.

Mittlerweile kommt fürs Web auch wieder öfters SVG dazu. Vor allem für Vektor­icons aber auch vielen anderen, interes­santen Möglich­keiten der (inter­aktiven) Visuali­sierung. Da dank HTML5 mittler­weile so gut wie alle Browser auch inline SVG-Grafiken unter­stützen. Übrigens ist mir das XML-Markup, welches sich hinter SVG verbirgt, durchaus vertraut. So dass ich es rein theore­tisch mit Java­Script, für eine gewisse Inter­aktivität, aber auch für Anima­tionen usw., manipu­lieren könnte. Übrigens kann man mit Vue.js und SVG hervorragend interaktive Grafiken erstellen.

HTML5

Auch wenn der Quell­code dieser Seite histo­risch gewachsen ist, sind mir die meisten Tags und deren Verwendung durchaus vertraut. Das gilt auch für die neuen (sema­ntischen) HTML5 Tags, die man heutzu­tage ohne weiteres verwenden kann, sofern man nicht mehr ältere Browser wie den IE8 unterstützt. Was auf dieser Webseite noch größten­teils der Fall ist.

Außerdem versuche ich den HTML-Quell­code, auch wenn er dynamisch gene­riert wird, so schlicht wie mög­lich zu halten. Was allerdings nicht wirklich einfach ist und auch nicht immer so ganz gelingt. HTML ist ja jetzt auch nicht unbe­dingt ein Hexenwerk, da das Aus­sehen einer Webseite bzw. -Appli­kation sowieso meist über die CSS-Klassen gesteuert wird.

In meinem Job erstelle ich für viele unserer (respon­siven) Webanwen­dungen das gesamte Layout in HTML. Das bein­haltet zum einen den Rahmen, also das globale Layout der Appli­kation, inkl. Menüs etc. und zum anderen so gut wie alle Formu­lare, Listen, Statis­tiken usw. auf den einzelnen Seiten. Natür­lich inkl. CSS-Style­sheets und den dazu gehö­renden Java­Script Funktiona­litäten. Da so im Grunde alles selbst per Hand erstellt wurde, können wir dadurch sehr gut auf spe­zielle Kunden­wünsche eingehen und auf kurz­fristige Ände­rungen relativ schnell reagieren. Mit dieser Vorgehens­weise sind wir einfach extrem flexibel.

Ich bin übrigens auch kein Verfechter, dass man HTML für normale Web­seiten nur mit der Hand erstellen darf. Es spricht über­haupt nichts dagegen auch einen grafischen Editor oder ein vernünf­tiges CMS zu verwenden, da man mit diesen mittler­weile, je nach dem was man verwendet, auch schlanken und sauberen HTML-Code gene­rieren kann. Da ich aller­dings HTML in einem Code­editor ganz gut selbst erstelle, verzichte ich selbst bei reinen Webpräsentationen auf diese Hilfsmittel.

JavaScript

Wer sich im Web mit HTML und CSS beschäftigt kommt früher oder später nicht um JavaScript herum. Obwohl man viele Effekte mittlerweile sehr gut mit CSS realisieren kann. Sobald es aber etwas anspruchs­voller wird benötigt man dazu JavaScript. JavaScript wird übrigens schon lange nicht mehr nur für dynamisches HTML benötigt, sondern auch für den ganzen Daten­austausch via AJAX-Requests sowie viele Business­logiken welche direkt am Client ausgeführt werden. Das Backend, also der Server kümmert sich dann nur mehr um das bereitstellen und empfangen der Daten.

In meinem Job war ich bis vor einigen Jahren hauptsächlich für die Manipulation des DOM-Baums, dynamische Interaktionen, clientseitige Validierungen, einfache Businesslogiken und die Erstellung eigener Steuerelemente verantwortlich. Da wir in der Zwischenzeit auch immer mehr Single Page Application (SPA) mit Vue.js erstellen, habe ich mir hier schon ganz gute Kenntnisse angeeignet. Da sich bei uns die meisten Entwickler doch eher im Backend zuhause fühlen, bin ich in vielen Fällen auch für die komplette Realisierung des Frontends inkl. aller Businesslogiken usw. zuständig. Die Datenbindung, mit selbst erstellten, verschachtelten Komponenten, inkl. scoped Slots habe ich schon ganz gut raus. Das gilt auch für die Kommunikation via REST-Services mit dem Backend. Der Umgang mit dem Vue Router oder Vuex ist mit mittler­weile ebenfalls vertraut. Wobei Vuex mit Vue3 auch schon wieder als veraltetgilt. Auch die Handhabung mit npm, Webpack bzw. Vite fällt mir immer leichter. Der Umgang mit (JSON) Daten­objekten sowie das ganze Event­handling usw. gehört schon länger zu meinem täglichen Brot.

Seitdem wir Vue einsetzten verwenden wir übrigens auch schon TypeScript. Was selbst bei etwas kleineren Projekten durchaus sinnvoll ist, da reines JavaScript die Typsicherheit leider nicht immer ganz korrekt gewährleistet. Allerdings habe ich mit dem (sehr strengen) strikten Modus ehrlich gesagt noch so meine Schwierig­keiten, da ich ja doch eher von der JS-Seite komme und nicht von der reinen Programmierung z.B. mit C# wo der ganze Programmcode ja schon seit Anbeginn so geschrieben werden muss. Seit wir mit Vue und Webpack arbeiten, konnte ich meine Kenntnisse was ES6 betrifft ganz schön erweitern. In vielen Fällen bleibt einem ja auch gar nichts anderes übrig. Bei neuen Projekten werden wir übrigens auf Vue3 bzw. Nuxt3 umsteigen.

Kreativ

Ich hoffe, dass man auf dieser Web­seite wenig­stens ein bisschen erken­nen kann, dass ich viel­leicht nicht ganz einfallslos bin. Auch wenn hier viele Beispiele mittler­weile schon ziemlich viele Jahre auf dem Buckel haben.

Egal ob bei den 3D-Arbei­ten, den Spiele-Apps, den WebGL-Experi­menten oder bei mir in der Arbeit. Ich lasse mir einfach gerne was einfal­len bzw. mir fällt einfach mal was ein, wie man ja auf meiner Webseite viel­leicht sehen kann. Auch wenn es teil­weise absolut sinnfrei ist ;-).

In meinem Job freue ich mich immer wieder, wenn uns zu einem (kom­plexen oder kompli­zierten) Prozess ein einfacher Work­flow gelingt, den man am besten noch mit einer möglichst einfachen und über­sichtliche Eingabe­maske abarbeiten oder steuern und natürlich programmier­technisch gut umsetzen kann.

Ich glaube, dass mein Einfalls­reichtum, zumindest in manchen Teilen, zu einer meiner Stärken zählt. Auch wenn man es mir viel­leicht nicht gleich ansieht, (ticke ;-) ) denke ich gele­gentlich anscheinen doch irgendwie anders. Selbst wenn ich nicht unbedingt gleich die richtige Idee habe oder ich einfach nur ein paar Tage dafür benötige, inspi­riere ich mein Umfeld oft so, dass wir meistens gemeinsam zu einem sehr guten Ergebnis kommen. Das zum einen meist gut umzu­setzen und zum anderen vor allem für die Benutzer einfach zu bedienen ist. Ich mag es einfach nicht, wenn etwas zu kompliziert ist.

Es sind jetzt auch nicht gerade sensatio­nelle, heraus­ragende neuen Erfin­dungen, sonder eher Ideen im klei­neren Rahmen, welche einfach die Bedienung, selbst bei komplexen Prozes­sen, mitunter etwas erleichtern.

Wenn meinen Kolle­ginnen und Kolle­gen mal nichts einfällt oder einfach nur krea­tiven Input benö­tigen, kommen sie sehr gerne zu mir. Das gilt übrigens für alle Teams bzw. Bereiche in unserer Firma und nicht nur für das Entwickler Team.

Motion

Als man sich Mitte der 90er auf einem Rechner noch mit rucke­ligen Videos in Brief­marken­größe begnügen musste, erstellte ich schon die ersten computer­animierten (3D-)Intros für diverse Home­videos. Welche dann sogar auf einem normalen Fernseh­gerät (oder Video­recorder), über eine spezielle Hardware­karte, in PAL-Auflösung mit 25 (bzw. 50 Halb-)Bilder pro Sekunde, wieder­gegeben werden konnten. Ab diesem Zeit­punkt hat bei mir der non­lineare, digi­tale Video­schnitt inkl. Compo­siting (für Home­videos) einzug gehalten.

Natürlich versuchte ich mich damit auch selbst­ständig zu machen. Ende der 90er habe ich deswegen sogar meinen ersten und leider einzigen profes­sionellen Auftrag für eine 3D Computer­animation erhalten. Eine tech­nische Visuali­sierung, erstellt mit Cinema 4D, die das innere eines Flaschen­wäschers für Mehrweg­flaschen zeigt. Ich habe zwar danach weiterhin Home­videos mit Adobe Premiere geschnitten, dafür gerne (3D-)Intros erstellt, After Effects kam dann auch irgend­wann hinzu, aber irgendwie ist es dabei geblieben. Es kam einfach das Web und meine jetzige Arbeit dazwischen ;-).

Ich mag es einfach, wenn sich was auf dem Bild­schirm bewegt. Sei es als berech­nete 3D-(2D-)Anima­tionen, Video­kompo­sition, program­mierte (inter­aktive) (Micro-)Anima­tionen im Browser oder seit einiger Zeit (inter­aktives) Echtzeit 3D in Form von Spielen oder ähnliches. Würde am lieb­sten immer noch irgend­was mit inter­aktiver, tech­nischer (3D-)Visuali­sierung machen. Gerne auch auf Basis von (Live-)Daten.

SQL

Ein ganz gutes grund­legendes Verständ­nis für Daten­banken ist durchaus vorhanden. Die Zusammen­hänge zwi­schen den einzelnen Tabel­len bekomme ich in vielen Fällen auch ganz gut raus. Das kommt aller­dings auch sehr darauf an, wie gut diese ursprüng­lich geplant wurden, wie viel histo­risch dazu gekommen ist und welche selt­samen Ausnahmen es gibt.

Ganz normale SQL-Abfra­gen mit ein paar Joins, einfachen Verschach­telungen und Gruppie­rungen bekomme ich auch irgendwie hin. Beim Einfügen, Updaten oder Löschen (inkl. der ganzen Abhängig­keiten) wird es dann oft schon schwie­riger. Wobei mir Views, Proze­duren und Funk­tionen durchaus bekannt sind. Das gilt auch für die meis­ten Daten­typen oder Eigen­heiten verschie­dener Code­pages usw..

Wenn ich jedoch sehe was meine Kolle­ginnen und Kolle­gen mit den Daten so alles anstellen, merke ich, dass ich in diesem Bereich eigent­lich nicht wirk­lich viel weiß. Ab einer gewis­sen Komplex­ität setzt es bei mir einfach aus, dann bin ich froh, dass es Leute gibt, die das ein­fach besser und vor allem schnel­ler können. Aller­dings kann ich ihnen genau sagen wie die Struk­tur der Erge­bnisse aus­sehen soll, wenn ich diese z.B. für einen Report oder ähn­liches benötige.

UI-/ UX

In meinem Job entwerfe ich oft bei neuen Pro­jekten oder größe­ren Erweiter­ungen, meist in enger Zusammen­arbeit mit meinen Kolle­gen, Projekt­leitern und Kunden, die komplette Struk­tur der Anwen­dungen, sowie die Vor­schläge der einzelnen Bereiche und Eingabe­masken. Da ich im Großen und Ganzen auch ein ganz gutes Grund­verständnis für das dahinter­liegende Daten­bank­modell habe, kann ich die Mockups meist auch so präsen­tieren, dass sie zum einen der Auftrag­geber gut versteht und zum anderen, dass wir sie auch gut um­setzen können.

In vielen Fäl­len erstel­le ich diese Vorschläge übri­gens auch gleich in HTML und auch gleich als richt­iges Visual­Studio Projekt inkl. Master­page bzw. Layout­page, funktionie­render Navi­gation, Klick­dummys, Bildern, Logos, CSS usw., so dass ich nach möglichen Ände­rungen und Anpas­sungen bzw. der zustän­dige Entwickler sofort dieses Projekt über­nehmen und los­legen kann. Oft werden diese Proto­typen auch gleich den Auftrag­gebern, auf unserem Integrations­system, zur Verfü­gung gestellt. Das ist unsere Art des rapid Prototyping. Wobei das leider oft auch den Nach­teil hat, dass die Kunden der Meinung sind, dass die Appli­kation im Prinzip komplett fertig ist. Wir müssen in diesem Fall immer darauf hinweisen, dass jetzt erst die eigent­liche Arbeit dafür beginnt.

Da es sich bei uns in der Regel um interne Verwal­tungs­anwen­dungen der Auftrag­geber handelt, verzichten wir meist auf wissen­schaftliche Studien wie eyetracking Experi­mente usw.. Aber auch bei solchen Anwen­dungen ist es extrem wichtig eine möglichst gute UX bzw. Usabi­lity zu gewähr­leisten, da sonst die Daten­qualität bzw. der komplette Work­flow darunter leidet. Wer möchte sich schon durch unzählig viele Bereiche klicken um z.B. nur kleine Ände­rungen vorzunehmen.

Obwohl der Prozess oft vom Kunden komplett vorge­geben wird und es eigent­lich nicht wirk­lich viel Spiel­raum dafür gibt, versu­chen wir trotz­dem die Bedienung so einfach und intu­itiv wie möglich zu gestalten.

Webdesign

Zum Webdesign bin ich eher zufäl­lig gekom­men und zwar als ich im Jahr 2000 diese Web­seite erstellte um meine 3D-Bilder und -Anima­tionen einem brei­ten Publikum zu präsen­tieren. Selbst in der ersten Version dieser Web­seite konnte man damals schon die Anima­tionen als Video, aller­dings nur mit dem system­eigenen Video­player bzw. dem system­unabhängigen Real­player, streamen bzw. down­loaden. Das ging übri­gens zu dieser Zeit noch nicht mal mit Flash. Aller­dings war der Stiel meiner Web­seiten schon immer sehr ein­fach und schlicht, da es mir in erster Linie darauf ankommt, dass der Besu­cher die gewünschten Infor­mationen schnell findet, sich gut orien­tieren kann und die Seite möglichst schnell geladen wird. OK - über die Far­bwahl kann man durch­aus disku­tieren ;-). Wobei diese Seite, in manchen Berei­chen, mittler­weile auch schon sehr in die Jahre gekommen ist.

Anfang der 0er Jahre habe ich auch mehrere Web­seiten, ganz offi­ziell als Gewerbe, erstellt. Das war auch irgend­wann der Grund dafür, warum ich jetzt dort arbeite wo ich jetzt arbeite. Ab diesem Zeit­punkt hatte ich nur leider nicht mehr so viel Zeit, Web­seiten für andere zu erstel­len. Außer­dem wurden die Webbau­kästen für klei­nere Präsenta­tionen und die ganzen Content­management­systeme immer besser und vor allem immer leichter zu bedienen. Wenn man hier ein­fach das rich­tige Temp­late wählt, bekommt das Ganze auch gleich einen profes­sionellen Look. Aller­dings ähneln sich dadurch auch immer mehr Web­seiten. Außer­dem hat man auch nicht immer die volle Kon­trolle. Das reicht aber in den meis­ten Fällen völlig aus.

In meinem jetzi­gen Job bin ich im Grunde für das Aus­sehen vieler unserer Web­portale bzw. -Anwen­dungen verant­wortlich. Dabei erstelle ich haupt­sächlich das opti­sche Grund­gerüst und das Layout der (einfach zu bedie­nenden) Benutzer­oberflächen für unsere Webanwen­dungen unter Einhal­tung der CI-Vor­gaben (sofern vorhan­den), inkl. der meisten client­seitigen Java­Script Funktio­nalitäten. Das Ganze ohne irgend­welche grafi­schen HTML-Edito­ren und natür­lich auch respon­sive. Meine Kolle­gen sind meist heil froh, dass sie sich nicht auch noch um das gesamte Layout kümmern müssen.