Hallo Welt

3D

Ich fand es schon immer sehr spannend, das was mir (oder auch Anderen) so im Kopf rum­schwirrt mit Hilfe eines Computers zu simulieren bzw. darzu­stellen. Dazu verwende ich seit Ende der 90er am liebsten Cinema 4D.

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 aussehen soll, immer noch extrem viele Ressourcen benötigt. Muss aller­dings auch ehrlich gestehen, dass ich viele Funk­tionen, die dieses Programm mittler­weile bietet, nur sehr selten bis gar nicht genutzt habe (Wer kennt schon wirklich alle Funk­tionen von Word oder Excel usw.).

Heutzutage kann man sich kaum mehr vorstel­len 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 Qualität, mehr als doppelter Auflösung (Full-HD 1920x1080) und inkl. physika­lischer Simulation werden 3D-Welten selbst auf einem Smart­phone heut­zutage in Echtzeit dargestellt.

Das ist auch einer der Gründe, weshalb mich 3D-Anwen­dungen in Echtzeit mittler­weile mehr reizen. Damit meine ich übrigens nicht nur Spiele. 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.

CSS3

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, so kenne ich mich mit den ganzen Attri­buten inkl. Selek­toren, Pseudo­elemente, Media Queries usw., doch ganz gut aus.

Da ich in meinem jetzigen Job für die Erstel­lung des kompletten HTML-Layouts unserer meist respon­siven Webanwen­dungen verant­wortlich bin, muss ich mich natürlich auch um die entsprech­enden CSS-Klassen und -Style­sheets selbst kümmern. Sofern sie einmal erstellt worden sind, können diese logischer­weise auch für weitere Projekte des Kunden verwendet werden. Im Grunde erstelle ich so nur unser eigenes, schlankes CSS-Framework, welches auch mit eigenen JS-Biblio­theken ergänzt wird.

Da wir uns auch hier meistens an die bereits beste­henden CI-Vorgaben unserer Kunden (so) strikt (wie möglich) halten sollten, fällt es mir in der Regel leichter die Vorgaben bzw. die CSS-Werte mit [F12] im Browser aus deren Internet­auftritte zu extra­hieren, als Kata­loge mit Style­vorgaben (sofern überhaupt vorhanden) zu wälzen. Wobei die Do's and Dont's in den schrift­lichen Vorgaben meistens doch sehr hilfreich sind.

Eine große Heraus­forderung ist es oft auch, die WebForm Steuer­elemente mit CSS einiger­maßen an die CI-Vorgaben anzunähern, da meist in deren Internet­auftritte eigene Steuer­elemente verwendet werden, welche mit WebForms, auf den ersten Blick, nicht wirklich einfach zu reali­sieren sind.

Außerdem versuche ich möglichst viel (v.a. dynamische Effekte, autom. Inhalt usw.) über CSS-Klassen zu lösen und so JavaScript für diese Dinge so gut es geht zu vermeiden. Da ja manche browser­eigenen Steuer­elemente in der Gestaltungs­möglichkeit mit CSS leider immer noch nicht viel hergeben, verwende ich, wenn möglich, reines CSS (v.a. Selek­toren mit unter­schied­lichen Eigen­schaften) um z.B. Check­boxen oder Radio­buttons dynamisch selbst zu gestalten.

Ehrlich gesagt erstelle ich meine Klassen am liebsten komplett selbst ohne irgend­welche grafischen Editoren. Das reizt mich in diesem Bereich wirklich am meisten. Obwohl mir durchaus die ein oder anderen CSS-Frameworks bekannt sind, versuche ich diese möglichst zu vermeiden, da ich so am flexi­belsten bin. Wobei ich mir den Einsatz von CSS-Präpro­zessoren für sehr große Webappli­kationen durchaus vorstellen kann. Habe diese aber bisher noch nicht wirklich benötigt.

Frontend

In meiner Arbeit bin ich für die Erstel­lung des kompletten HTML-Layouts unserer meist respon­siven Webanwen­dungen verant­wortlich, egal ob es sich um interne Anwendungen oder um Kunden­projekte handelt. 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.

Neben den ganzen Markups (HTML und CSS) entwickle ich auch viele client­seitige Funk­tionen mit Java­Script selbst. Nicht nur für die Über­prüfung und Verein­fachung der Eingaben, sondern auch (soweit möglich) für client­seitige Business­logiken oder erstelle auch gerne mal eigene Steuer­elemente bzw. passe die vorhan­denen von jQuery-UI an, welche dann sehr gut mit WebForms zusammen­arbeiten. 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.

Auch wenn wir momentan fast nur Server rendered pages, auf Basis von ASP.Net Web-Forms, MVC bzw. Razor-Pages verwenden, wird man zukünftig um die modernen JS-Frame­works nicht ganz herum kommen. Für einen ersten Einstieg in diese Thematik habe ich mir Vue.js ausgesucht, da ich glaube, dass man es mit unserer Vorgehens­weise ganz gut kombinieren kann. Hier habe ich mir mittler­weile auch schon relativ gute Grund­lagen angeeignet, indem ich ein paar verschach­telte Kompo­nenten, inkl. sog. scoped Slots, selbst erstellte, welche dann als wider­verwendbare User Controls dienen. Allerdings ohne das Ganze mit WebPack zu einer Single Page Appli­cation (SPA) zusammen­zuführen. Bisher wurden die einzelnen Kompo­nenten nur manuell in einer oder mehreren JS-Dateien zusammen­gefasst, was für uns aber erst mal völlig ausreicht.

Muss auch 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 Code-behind, selbst kleine Ände­rungen oder Anpassungen vornehme.

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 und 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ür's 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 bekannt. 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.

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 unter­stützen muss. 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 alle 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 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 mei­stens auf diese Hilfsmittel.

JavaScript

Obwohl man es dem JS-Quell­code auf dieser Web­seite viell­eicht nicht wirklich ansieht, versuche ich mittler­weile meinen Code deutlich sauberer, gekapselter und modu­larer zu schreiben. Dazu verwende ich logischer­weise immer öfters Objekte sowie Konstruktor­funktionen (also ECMA5-Klassen). Die Möglich­keit der Vererbung bzw. einen Konstruktor mit myFunction.call(this) zu erweitern ist mir inzwischen ebenfalls bekannt. Genauso wie die prototypische Erweiterung von Konstruktor­funktionen. Nur hat sich mir hier der eigent­liche Vorteil noch nicht ganz erschlossen. Da man damit, meines (beschei­denen) Wissens, ja nur einen Konstuktor und nicht gleich mehrere erweitern kann. Das ganze Event­handling usw. gehört übrigens zu meinem täglichen Brot.

In meinem Job bin ich haupt­sächlich für die Manipu­lation des DOM-Baums, dyna­mische Inter­aktionen, client­seitige Validier­ungen, einfache Business­logiken und die Erstellung eigener Steuer­elemente verant­wortlich. Aller­dings habe ich mir in der Zwischen­zeit auch ganz gute Grund­lagen in Vue.js angeeignet. Die Daten­bindung, selbst mit verschach­telten Komponenten, inkl. scoped Slots habe ich schon ganz gut raus. Aller­dings erst mal ohne das Ganze mit Web­Pack zu einer Single Page Appli­cation (SPA) zusammen­zuführen. Ich finde es tatsächlich etwas schade, dass Vue.js meist nur mit SPAs in Verbin­dung gebracht wird. Was die meisten Beispiele, zumindest die ich im Web gefunden habe, zeigen. Ich bin der Meinung, dass man damit auch ganz tolle, normale Webanwen­dungen entwickeln kann.

Manuell erstellte Ajax-Request haben wir in meinem Job bisher nur sehr selten benötigt. Da mir aber die grund­legenden Funktionen eines Ajax-Requests, aller­dings noch mit jQuery bzw. Vanilla (XHR1), durchaus vertraut sind, wäre es mir im Grunde egal welcher Web­service die JSON-Daten sendet bzw. empfängt.

Da wir in der Arbeit leider noch den IE11 berück­sichtigen müssen, sind meine Kennt­nisse momentan noch eher auf ECMA5 beschränkt. Aber selbst hier (PWA, Web­Sockets, Web­Worker, I-DB, Geolo­cation usw.) gäbe es noch sehr viel zu entdecken. Mit I-DB und Geolo­cation habe zumin­dest schon mal zuhause experi­mentiert. Über die neuen Möglich­keiten von ECMA6 (Klassen, Promises, =>, Module usw.) habe ich zwar auch schon einiges gelesen, weiß auch einiger­maßen was sie bedeuten, aber konnte sie (wegen dem IE11) bisher leider noch nicht anwenden. Mit Type­Script habe ich übrigens auch schon erste Schritte unter­nommen. Ich finde sogar, dass es dem JS von Unity durchaus ein bisschen ähnelt.

JavaScript, inkl. der vielen neuen, interes­santen und prakti­schen APIs, ist in der Zwischen­zeit so extrem umfang­reich geworden, so dass ich trotz meiner eigent­lich ganz guten Kennt­nisse, inzwischen teil­weise ganz schön alt aussehe. Wobei ich Defizite in der Regel relativ schnell aufhole. In meinem Job benö­tigen wir es einfach nicht und privat fehlt mir auch etwas die Zeit. Hier kümmere ich mich ehrlich gesagt auch lieber (wer hätte das gedacht) mehr um visuelle Dinge wie z.B. optische Effekte, Anima­tionen, Inter­aktive Client­anwendungen wie Spiele oder andere grafische Visuali­sierungen, welche ich gerne mit Three.js (also WebGL) reali­siere. Wie man viel­leicht auf dieser Webseite sehen kann.

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 irgendwie anders, gerne auch mal quer oder ... ich weiß nicht. 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.

Reporting

In meinen Job arbeite ich oft mit den Micro­soft Reporting Services, da wir in fast allen unseren Anwen­dungen Statis­tiken jeglicher Art benö­tigen. Die Date­nbank­abfragen, inkl. Filter­parameter, liefern mir meist die zustän­digen Entwickler selbst. Aller­dings in enger Absprache mit mir, da die Berichte ja spe­ziell mit Daten versorgt werden müssen. Außer­dem habe ich auch nicht die Tabellen­struktur von allen unseren Anwen­dungen im Kopf ;-). Ich kümmere mich deswegen haupt­sächlich um die optische Aufbe­reitung und möglicher Interaktivität.

Die meisten Express­ions die wir in den Berichten benö­tigen, schreibe ich übrigens selbst. Geo-Shape-Dateien habe ich auch schon verwendet um Statis­tiken in Form einer Land­karte mit verschie­denen Einfär­bungen darzu­stellen. Einige Berichte haben wir sogar mit inter­aktiven Eigen­schaften versehen, für die sie ursprüng­lich gar nicht gedacht waren, indem wir diese nachträ­glich, also wenn sie im Browser ange­zeigt werden, einfach mit Java­Script erweitert haben. Selbst für dyna­misch erzeugte Emails oder Briefe nutzen wir diese Reports.

Obwohl der Berichts­generator in Visual­Studio leider etwas labil ist, verwenden wir die Reporting Services von Microsoft, da sie sich sehr gut in unsere Infra­struktur integrierten. Es ist auch sehr prak­tisch, dass sich alle Reports zentral auf einem Server befinden. Das gilt auch für die automa­tisch vorhan­denen Export­funktionen (meist PDF, Excel, Word oder HTML(-Mail)), die sogar via Web­service gleich für den Down­load bzw. die Erstellung in diesen Forma­ten genutzt werden können. Außer­dem gibt es dieses System automa­tisch zum MS SQL-Server dazu.

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 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.

Unity

Nicht dass mir Program­mieren sonst keinen Spaß machen würde, aber so gefällt es mir ehrlich gesagt fast am besten. Da ich das Ganze einfach in irgend­einer Form, mit Hilfe des Programm­codes, sofort irgend­wie zum Leben erwecken kann. Das trifft natür­lich auch auf WegGL zu.

Das Schöne ist auch, dass ich meine grafi­schen (3D) Fähig­keiten wunder­bar mit meinen Program­mier­kennt­nissen kombi­nieren kann. Ein bisschen Audio ist übrigens auch dabei. Wenn ich mal beim Program­mieren irgend­wie nicht weiter komme mache ich einfach zwischen­durch was Opti­sches oder was am Sound (oder Bau einen neuen Level), bis mir wieder eine mögliche Lösung ein­fällt. Neben der Program­mierung gibt es tatsäch­lich noch genug anderes zu erle­digen. Mir gefällt diese Abwechs­lung. Dass man den vorhan­denen grafi­schen Editor gewisser­maßen zu einem eigenen Level­editor umbaut, fand ich übri­gens auf Anhieb super praktisch.

Da ich ja durch meine Tätig­keiten für das Web schon Erfah­rung in Java­Script sammeln konnte, habe ich die Logik meiner Apps auch in dem typsich­eren JS von Unity geschrieben. Natür­lich musste ich oft auch im Inter­net (v.a. in Stack­overflow) nach Lösun­gen für verschie­dene Pro­bleme suchen. Dabei ist mir aufge­fallen, dass ich viele Bei­spiele, welche oft nur in C# vorlagen, relativ ein­fach in Java­Script um­schrei­ben konnte.

Es geht ganz sicher noch bes­ser, aber ich musste die Quali­tät für mobile Geräte doch ganz schön runter­schrau­ben, damit die Spiele auch auf einem Android 4.0 Gerät einiger­maßen flüs­sig lau­fen. Außer­dem wollte ich die Datei­größe für den Down­load so gering wie möglich hal­ten. Der Akku sollte auch nicht gleich nach 10 Min. über­hitzen oder zu schnell leer sein, was tatsäch­lich immer noch sehr grenz­wertig ist.

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 etwas 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 fast all 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.

WebGL

Diese Techno­logie ist für mich des­halb so interes­sant, weil ich hier mein Wis­sen im Bereich Java­Script und 3D sehr gut kombi­nieren kann. Das Schöne daran ist auch, dass das (inter­aktive) Resultat sofort in jedem belie­bigen Browser, unab­hängig vom Betriebs­system, betrachtet werden kann. Da ja alles in Java­Script program­miert wird, können auch fast alle Möglich­keiten, APIs, Daten­schnitt­stellen usw., welche Java­Script bzw. die Web­browser zu bieten haben, verwendet werden.

Aller­dings spare ich mir die durchaus gewöhnungs­bedürftige und ziemlich komplexe (Low-Level) Syntax von WegGL, indem ich meist Three.js verwende, welches einfach die Hand­habung der Objekte und Shader sehr stark vereinfacht. Es gibt zwar mittler­weile auch schon andere 3D-Frame­works, aber Three.js habe ich als erstes ent­deckt und bin ein­fach dabei geblieben.

Web-AR oder -VR oder wie es jetzt heißt Web-XR werden auch noch sehr span­nende Themen in diesem Bereich. Am besten in Kombi­nation mit der Sensor-API.

Auch wenn man mit Unity seine Projekte in WebGL kompi­lieren kann, so ist die Download­größe des nor­malen Java­Scripts inkl. Frame­works, v.a. bei einfach­eren Projek­ten, immer noch viel gerin­ger, als die mit Unity erstellten.