... auf meiner kleinen Webseite.
Wie man auf dieser Webseite unschwer erkennen kann, beschäftige ich mich in meiner Freizeit gerne mit virtuellen 3D Welten. Sei es als gerenderte raytracing Bilder bzw. Computeranimationen die ich hauptsächlich mit Cinema 4D kreiere oder neuerdings auch mit interaktiven Echtzeitapplikationen in Form von WebGL, mit Hilfe von Three.js oder mit Spiele-Apps, die ich mit Unity erstelle. Hier kam mir übrigens meine Erfahrung, die ich mit JavaScript im Web sammeln konnte, sehr gelegen. Allerdings habe ich beim Erstellen dieser Anwendungen im Bereich der Programmierung sehr viel dazu gelernt. Das schöne an dieser Art der Softwareentwicklung ist, dass ich meine Erfahrungen im Bereich Grafik und der Programmierung wunderbar kombinieren kann.
Egal ob gut oder schlecht, hier kann ich mich nach Herzenslust austoben und zumindest immer etwas dazulernen.
Unabhängig von irgendwelchen Vorgaben oder seltsamen
Kundenwünschen ;-),
die allerdings auch ihren Reiz haben können, sich dieser Herausforderungen zu stellen.
Meine Brötchen verdiene ich übrigens bei einer kleinen aber sehr feinen Marketing Service Agentur in München. Hier erstellen wir im IT-Team mit 12 Softwareentwicklern neben ein paar Desktopanwendungen hauptsächlich Webapplikationen für diverse Verwaltungsaufgaben namhafter Unternehmen bzw. Konzerne, welche dann meist in deren Intra- bzw. Extranetstruktur eingebunden werden. Im Auftrag dieser Firmen haben wir aber auch schon einige Landingpages inkl. diverser Eingabemöglichkeiten für Endkunden und eine Gebrauchtmotorradbörse, die auch schon auf mobilen Geräten funktionieren mussten, realisiert. Für all unsere Anwendungen verwenden wir in den meisten Fällen die ASP.Net Technologie bzw. WebForms von Microsoft. Es kommen aber auch immer mehr MVC/Razor Applikationen hinzu.
Ich fand es schon immer sehr spannend, das was mir (oder auch Anderen) so im Kopf rumschwirrt mit Hilfe eines Computers zu simulieren bzw. darzustellen. 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.), physikalischen Simulationen, das Anpassen der UV-Maps, Global Illumination und vieles mehr hinzu. Wobei GI, je nachdem wie realistisch es aussehen soll, immer noch extrem viele Ressourcen benötigt. Muss allerdings auch ehrlich gestehen, dass ich viele Funktionen, die dieses Programm mittlerweile bietet, nur sehr selten bis gar nicht genutzt habe (Wer kennt schon wirklich alle Funktionen von Word oder Excel usw.).
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 Qualität, mehr als doppelter Auflösung (Full-HD 1920x1080) und inkl. physikalischer Simulation werden 3D-Welten selbst auf einem Smartphone heutzutage in Echtzeit dargestellt.
Das ist auch einer der Gründe, weshalb mich 3D-Anwendungen in Echtzeit mittlerweile 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 zahlreichen Exportfunktionen sind sehr hilfreich. Außerdem macht es mir mittlerweile fast mehr Spaß, die Logik und Interaktionen zu programmieren, als sich nur um die Grafik zu kümmern. Wobei ich die Kombination aus beiden durchaus angenehm finde.
Auch wenn auf dieser Seite der Quellcode meiner (historisch gewachsenen) CSS-Stylesheets auf den ersten Blick vielleicht nicht wirklich aufgeräumt wirken, so kenne ich mich mit den ganzen Attributen inkl. Selektoren, Pseudoelemente, Media Queries usw., doch ganz gut aus.
Da ich in meinem jetzigen Job für die Erstellung des kompletten HTML-Layouts unserer meist responsiven Webanwendungen verantwortlich bin, muss ich mich natürlich auch um die entsprechenden CSS-Klassen und -Stylesheets selbst kümmern. Sofern sie einmal erstellt worden sind, können diese logischerweise 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-Bibliotheken ergänzt wird.
Da wir uns auch hier meistens an die bereits bestehenden 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 Internetauftritte zu extrahieren, als Kataloge mit Stylevorgaben (sofern überhaupt vorhanden) zu wälzen. Wobei die Do's and Dont's in den schriftlichen Vorgaben meistens doch sehr hilfreich sind.
Eine große Herausforderung ist es oft auch, die WebForm Steuerelemente mit CSS einigermaßen an die CI-Vorgaben anzunähern, da meist in deren Internetauftritte eigene Steuerelemente verwendet werden, welche mit WebForms, auf den ersten Blick, nicht wirklich einfach zu realisieren 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 browsereigenen Steuerelemente in der Gestaltungsmöglichkeit mit CSS leider immer noch nicht viel hergeben, verwende ich, wenn möglich, reines CSS (v.a. Selektoren mit unterschiedlichen Eigenschaften) um z.B. Checkboxen oder Radiobuttons dynamisch selbst zu gestalten.
Ehrlich gesagt erstelle ich meine Klassen am liebsten komplett selbst ohne irgendwelche 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 flexibelsten bin. Wobei ich mir den Einsatz von CSS-Präprozessoren für sehr große Webapplikationen durchaus vorstellen kann. Habe diese aber bisher noch nicht wirklich benötigt.
In meiner Arbeit bin ich für die Erstellung des kompletten HTML-Layouts unserer meist responsiven Webanwendungen verantwortlich, egal ob es sich um interne Anwendungen oder um Kundenprojekte handelt. Neben der HTML Struktur kümmere ich mich natürlich auch um die ganzen CSS-Stylesheets. Da wir schon sehr lange mit WebForms arbeiten sind mir hier die meisten Controls und deren Eigenheiten durchaus vertraut. Nur der Vollständigkeit halber soll erwähnt sein, dass ich auch Layouts für WinForm- und WPF-Applikationen erstellt habe.
Neben den ganzen Markups (HTML und CSS) entwickle ich auch viele clientseitige Funktionen mit JavaScript selbst. Nicht nur für die Überprüfung und Vereinfachung der Eingaben, sondern auch (soweit möglich) für clientseitige Businesslogiken oder erstelle auch gerne mal eigene Steuerelemente bzw. passe die vorhandenen von jQuery-UI an, welche dann sehr gut mit WebForms zusammenarbeiten. Obwohl WebForms aber auch MVC bzw. Razor-Pages manchmal keine wirklich gute Unterstützung für clientseitige Aktionen bieten, haben wir trotzdem die eine oder andere Funktionalität mit JavaScript 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-Frameworks 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 Vorgehensweise ganz gut kombinieren kann. Hier habe ich mir mittlerweile auch schon relativ gute Grundlagen angeeignet, indem ich ein paar verschachtelte Komponenten, inkl. sog. scoped Slots, selbst erstellte, welche dann als widerverwendbare User Controls dienen. Allerdings ohne das Ganze mit WebPack zu einer Single Page Application (SPA) zusammenzuführen. Bisher wurden die einzelnen Komponenten nur manuell in einer oder mehreren JS-Dateien zusammengefasst, was für uns aber erst mal völlig ausreicht.
Muss auch ganz ehrlich, zu meiner Schande gestehen, dass ich mit dem serverseitigen Code eher weniger zu tun habe. Trotzdem fließen viele meiner Ideen und Gedanken bei den Backend-Entwicklern ein. Ein ganz gutes Grundverständnis ist dafür durchaus vorhanden. Es kommt auch schon mal vor, dass ich im Code-behind, selbst kleine Änderungen oder Anpassungen vornehme.
Da ich ehrlich gesagt nicht wirklich gut mit der Hand zeichnen kann, hat es mich schon immer gereizt, meine Einfälle mit Hilfe des Computers irgendwie optisch darzustellen. Am liebsten mit Hilfe eines 3D-Programms, wie z.B. Cinema 4D, mit dem ich meine Vorstellungen virtuell abbilden kann. Wobei bei meinen Arbeiten eher klare, oft technische Konstruktionen oder fraktale Formen im Vordergrund stehen. Allerdings sind die Beispiele auf dieser Webseite auch oft schon etwas in die Jahre gekommen. Leider komme ich aufgrund meiner anderen Interessen (Arbeit, Echtzeit-3D oder JavaScript) so gut wie gar nicht mehr dazu neue Arbeiten zu erstellen.
Sowohl privat, als auch in der Arbeit verwende ich ganz selbstverständlich Photoshop um Bilder, Logos, Icons, Charts, Fotos usw. nachzubearbeiten und vor allem für's Web zu optimieren. Das gilt auch für Illustrator und Vektorgrafiken. Wobei ich früher auch öfters Collagen, Kompositionen, kleine Werbeprospekte und Flyer mit Photoshop erstellt habe. Mit InDesign habe ich später auch noch ein paar Flyer, kleine Broschüren und andere Printprodukte erstellt. Das Ganze ist allerdings auch ein bisschen in den Hintergrund geraten.
Mittlerweile kommt für's Web auch wieder öfters SVG dazu. Vor allem für Vektoricons aber auch vielen anderen, interessanten Möglichkeiten der (interaktiven) Visualisierung. Da dank HTML5 mittlerweile so gut wie alle Browser auch inline SVG-Grafiken unterstützen. Übrigens ist mir das XML-Markup, welches sich hinter SVG verbirgt, durchaus bekannt. So dass ich es rein theoretisch mit JavaScript, für eine gewisse Interaktivität, aber auch für Animationen usw., manipulieren könnte.
Auch wenn der Quellcode dieser Seite historisch gewachsen
ist,
sind mir die meisten Tags und deren Verwendung durchaus vertraut.
Das gilt auch für die neuen (semantischen) HTML5 Tags, die man heutzutage ohne weiteres verwenden kann,
sofern man nicht mehr ältere Browser wie den IE8 unterstützen muss. Was auf dieser Webseite noch größtenteils der Fall ist.
Außerdem versuche ich den HTML-Quellcode, auch wenn er dynamisch generiert wird, so schlicht wie möglich zu halten. Was allerdings nicht wirklich einfach ist und auch nicht immer so ganz gelingt. HTML ist ja jetzt auch nicht unbedingt ein Hexenwerk, da das Aussehen einer Webseite bzw. -Applikation sowieso meist über die CSS-Klassen gesteuert wird.
In meinem Job erstelle ich für alle unserer (responsiven) Webanwendungen das gesamte Layout in HTML. Das beinhaltet zum einen den Rahmen, also das globale Layout der Applikation, inkl. Menüs etc. und zum anderen so gut wie alle Formulare, Listen, Statistiken usw. auf den einzelnen Seiten. Natürlich inkl. CSS-Stylesheets und den dazu gehörenden JavaScript Funktionalitäten. Da so im Grunde alles selbst per Hand erstellt wurde, können wir dadurch sehr gut auf spezielle Kundenwünsche eingehen und auf kurzfristige Änderungen relativ schnell reagieren. Mit dieser Vorgehensweise sind wir einfach extrem flexibel.
Ich bin übrigens auch kein Verfechter, dass man HTML für Webseiten nur mit der Hand erstellen darf. Es spricht überhaupt nichts dagegen auch einen grafischen Editor oder ein vernünftiges CMS zu verwenden, da man mit diesen mittlerweile, je nach dem was man verwendet, auch schlanken und sauberen HTML-Code generieren kann. Da ich allerdings HTML in einem Codeeditor ganz gut selbst erstelle verzichte ich meistens auf diese Hilfsmittel.
Obwohl man es dem JS-Quellcode auf dieser Webseite vielleicht nicht wirklich ansieht,
versuche ich mittlerweile meinen Code deutlich sauberer, gekapselter und modularer zu schreiben.
Dazu verwende ich logischerweise immer öfters Objekte sowie Konstruktorfunktionen (also ECMA5-Klassen
).
Die Möglichkeit der Vererbung bzw. einen Konstruktor mit myFunction.call(this)
zu erweitern ist mir inzwischen ebenfalls bekannt.
Genauso wie die prototypische Erweiterung
von Konstruktorfunktionen.
Nur hat sich mir hier der eigentliche Vorteil noch nicht ganz erschlossen.
Da man damit, meines (bescheidenen) Wissens, ja nur einen Konstuktor und nicht gleich mehrere erweitern kann.
Das ganze Eventhandling usw. gehört übrigens zu meinem täglichen Brot.
In meinem Job bin ich hauptsächlich für die Manipulation des DOM-Baums, dynamische Interaktionen,
clientseitige Validierungen, einfache Businesslogiken und die Erstellung eigener Steuerelemente verantwortlich.
Allerdings habe ich mir in der Zwischenzeit auch ganz gute Grundlagen in Vue.js angeeignet.
Die Datenbindung, selbst mit verschachtelten Komponenten, inkl. scoped Slots habe ich schon ganz gut raus.
Allerdings erst mal ohne das Ganze mit WebPack zu einer Single Page Application (SPA) zusammenzuführen.
Ich finde es tatsächlich etwas schade, dass Vue.js meist nur mit SPAs in Verbindung 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
Webanwendungen entwickeln kann.
Manuell erstellte Ajax-Request haben wir in meinem Job bisher nur sehr selten benötigt. Da mir aber die grundlegenden Funktionen eines Ajax-Requests, allerdings noch mit jQuery bzw. Vanilla (XHR1), durchaus vertraut sind, wäre es mir im Grunde egal welcher Webservice die JSON-Daten sendet bzw. empfängt.
Da wir in der Arbeit leider noch den IE11 berücksichtigen müssen, sind meine Kenntnisse momentan noch eher auf ECMA5 beschränkt. Aber selbst hier (PWA, WebSockets, WebWorker, I-DB, Geolocation usw.) gäbe es noch sehr viel zu entdecken. Mit I-DB und Geolocation habe zumindest schon mal zuhause experimentiert. Über die neuen Möglichkeiten von ECMA6 (Klassen, Promises, =>, Module usw.) habe ich zwar auch schon einiges gelesen, weiß auch einigermaßen was sie bedeuten, aber konnte sie (wegen dem IE11) bisher leider noch nicht anwenden. Mit TypeScript habe ich übrigens auch schon erste Schritte unternommen. Ich finde sogar, dass es dem JS von Unity durchaus ein bisschen ähnelt.
JavaScript, inkl. der vielen neuen, interessanten und praktischen APIs, ist in der Zwischenzeit so extrem umfangreich geworden, so dass ich trotz meiner eigentlich ganz guten Kenntnisse, inzwischen teilweise 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, Animationen, Interaktive Clientanwendungen wie Spiele oder andere grafische Visualisierungen, welche ich gerne mit Three.js (also WebGL) realisiere. Wie man vielleicht auf dieser Webseite sehen kann.
Ich hoffe, dass man auf dieser Webseite wenigstens ein bisschen erkennen kann, dass ich vielleicht nicht ganz einfallslos bin. Auch wenn hier viele Beispiele mittlerweile schon ziemlich viele Jahre auf dem Buckel haben.
Egal ob bei den 3D-Arbeiten, den Spiele-Apps, den WebGL-Experimenten oder bei mir in der Arbeit. Ich lasse mir einfach gerne was einfallen bzw. mir fällt einfach mal was ein, wie man ja auf meiner Webseite vielleicht sehen kann. Auch wenn es teilweise absolut sinnfrei ist ;-).
In meinem Job freue ich mich immer wieder, wenn uns zu einem (komplexen oder komplizierten) Prozess ein einfacher Workflow gelingt, den man am besten noch mit einer möglichst einfachen und übersichtliche Eingabemaske abarbeiten oder steuern und natürlich programmiertechnisch gut umsetzen kann.
Ich glaube, dass mein Einfallsreichtum, zumindest in manchen Teilen, zu einer meiner Stärken zählt. Auch wenn man es mir vielleicht nicht gleich ansieht, (ticke ;-) ) denke ich gelegentlich 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, inspiriere ich mein Umfeld oft so, dass wir meistens gemeinsam zu einem sehr guten Ergebnis kommen. Das zum einen meist gut umzusetzen 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 sensationelle, herausragende neuen Erfindungen, sonder eher Ideen im kleineren Rahmen, welche einfach die Bedienung, selbst bei komplexen Prozessen, mitunter etwas erleichtern.
Wenn meinen Kolleginnen und Kollegen mal nichts einfällt oder einfach nur kreativen 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.
Als man sich Mitte der 90er auf einem Rechner noch mit ruckeligen Videos in Briefmarkengröße begnügen musste, erstellte ich schon die ersten computeranimierten (3D-)Intros für diverse Homevideos. Welche dann sogar auf einem normalen Fernsehgerät (oder Videorecorder), über eine spezielle Hardwarekarte, in PAL-Auflösung mit 25 (bzw. 50 Halb-)Bilder pro Sekunde, wiedergegeben werden konnten. Ab diesem Zeitpunkt hat bei mir der nonlineare, digitale Videoschnitt inkl. Compositing (für Homevideos) einzug gehalten.
Natürlich versuchte ich mich damit auch selbstständig zu machen. Ende der 90er habe ich deswegen sogar meinen ersten und leider einzigen professionellen Auftrag für eine 3D Computeranimation erhalten. Eine technische Visualisierung, erstellt mit Cinema 4D, die das innere eines Flaschenwäschers für Mehrwegflaschen zeigt. Ich habe zwar danach weiterhin Homevideos mit Adobe Premiere geschnitten, dafür gerne (3D-)Intros erstellt, After Effects kam dann auch irgendwann 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 Bildschirm bewegt. Sei es als berechnete 3D-(2D-)Animationen, Videokomposition, programmierte (interaktive) (Micro-)Animationen im Browser oder seit einiger Zeit (interaktives) Echtzeit 3D in Form von Spielen oder ähnliches. Würde am liebsten immer noch irgendwas mit interaktiver, technischer (3D-)Visualisierung machen. Gerne auch auf Basis von (Live-)Daten.
In meinen Job arbeite ich oft mit den Microsoft Reporting Services, da wir in fast allen unseren Anwendungen Statistiken jeglicher Art benötigen. Die Datenbankabfragen, inkl. Filterparameter, liefern mir meist die zuständigen Entwickler selbst. Allerdings in enger Absprache mit mir, da die Berichte ja speziell mit Daten versorgt werden müssen. Außerdem habe ich auch nicht die Tabellenstruktur von allen unseren Anwendungen im Kopf ;-). Ich kümmere mich deswegen hauptsächlich um die optische Aufbereitung und möglicher Interaktivität.
Die meisten Expressions die wir in den Berichten benötigen, schreibe ich übrigens selbst.
Geo-Shape-Dateien habe ich auch schon verwendet um Statistiken in Form einer Landkarte mit verschiedenen Einfärbungen darzustellen.
Einige Berichte haben wir sogar mit interaktiven Eigenschaften versehen, für die sie ursprünglich gar nicht gedacht waren,
indem wir diese nachträglich, also wenn sie im Browser angezeigt werden, einfach
mit JavaScript erweitert haben.
Selbst für dynamisch erzeugte Emails oder Briefe nutzen wir diese Reports.
Obwohl der Berichtsgenerator in VisualStudio leider etwas labil ist, verwenden wir die Reporting Services von Microsoft, da sie sich sehr gut in unsere Infrastruktur integrierten. Es ist auch sehr praktisch, dass sich alle Reports zentral auf einem Server befinden. Das gilt auch für die automatisch vorhandenen Exportfunktionen (meist PDF, Excel, Word oder HTML(-Mail)), die sogar via Webservice gleich für den Download bzw. die Erstellung in diesen Formaten genutzt werden können. Außerdem gibt es dieses System automatisch zum MS SQL-Server dazu.
Ein ganz gutes grundlegendes Verständnis für Datenbanken ist durchaus vorhanden. Die Zusammenhänge zwischen den einzelnen Tabellen bekomme ich in vielen Fällen auch ganz gut raus. Das kommt allerdings auch sehr darauf an, wie gut diese ursprünglich geplant wurden, wie viel historisch dazu gekommen ist und welche seltsamen Ausnahmen es gibt.
Ganz normale SQL-Abfragen mit ein paar Joins
, einfachen Verschachtelungen und Gruppierungen bekomme ich auch irgendwie hin.
Beim Einfügen, Updaten oder Löschen (inkl. der ganzen Abhängigkeiten) wird es dann oft schon schwieriger.
Wobei mir Views, Prozeduren und Funktionen durchaus bekannt sind.
Das gilt auch für die meisten Datentypen oder Eigenheiten verschiedener Codepages usw..
Wenn ich jedoch sehe was meine Kolleginnen und Kollegen mit den Daten so alles anstellen, merke ich, dass ich in diesem Bereich eigentlich nicht wirklich viel weiß. Ab einer gewissen Komplexität setzt es bei mir einfach aus, dann bin ich froh, dass es Leute gibt, die das einfach besser und vor allem schneller können. Allerdings kann ich ihnen genau sagen wie die Struktur der Ergebnisse aussehen soll, wenn ich diese z.B. für einen Report oder ähnliches benötige.
In meinem Job entwerfe ich bei neuen Projekten oder größeren Erweiterungen, meist in enger Zusammenarbeit mit meinen Kollegen, Projektleitern und Kunden, die komplette Struktur der Anwendungen, sowie die Vorschläge der einzelnen Bereiche und Eingabemasken. Da ich im Großen und Ganzen auch ein ganz gutes Grundverständnis für das dahinterliegende Datenbankmodell habe, kann ich die Mockups meist auch so präsentieren, dass sie zum einen der Auftraggeber gut versteht und zum anderen, dass wir sie auch gut umsetzen können.
In vielen Fällen erstelle ich diese Vorschläge übrigens auch gleich in HTML
und auch gleich als richtiges VisualStudio Projekt inkl. Masterpage bzw. Layoutpage, funktionierender Navigation, Klickdummys, Bildern, Logos, CSS usw.,
so dass ich nach möglichen Änderungen und Anpassungen bzw. der zuständige Entwickler sofort dieses Projekt übernehmen und loslegen kann.
Oft werden diese Prototypen auch gleich den Auftraggebern, auf unserem Integrationssystem, zur Verfügung gestellt.
Das ist unsere Art des rapid Prototyping
.
Wobei das leider oft auch den Nachteil hat, dass die Kunden der Meinung sind, dass die Applikation im Prinzip komplett fertig ist.
Wir müssen in diesem Fall immer darauf hinweisen, dass jetzt erst die eigentliche Arbeit dafür beginnt.
Da es sich bei uns in der Regel um interne Verwaltungsanwendungen der Auftraggeber handelt, verzichten wir meist auf wissenschaftliche Studien wie eyetracking Experimente usw.. Aber auch bei solchen Anwendungen ist es extrem wichtig eine möglichst gute UX bzw. Usability zu gewährleisten, da sonst die Datenqualität bzw. der komplette Workflow darunter leidet. Wer möchte sich schon durch unzählig viele Bereiche klicken um z.B. nur kleine Änderungen vorzunehmen.
Obwohl der Prozess oft vom Kunden komplett vorgegeben wird und es eigentlich nicht wirklich viel Spielraum dafür gibt, versuchen wir trotzdem die Bedienung so einfach und intuitiv wie möglich zu gestalten.
Nicht dass mir Programmieren sonst keinen Spaß machen würde,
aber so gefällt es mir ehrlich gesagt fast am besten.
Da ich das Ganze einfach in irgendeiner Form, mit Hilfe des Programmcodes, sofort irgendwie zum Leben
erwecken kann.
Das trifft natürlich auch auf WegGL zu.
Das Schöne ist auch, dass ich meine grafischen (3D) Fähigkeiten wunderbar mit meinen Programmierkenntnissen kombinieren kann. Ein bisschen Audio ist übrigens auch dabei. Wenn ich mal beim Programmieren irgendwie nicht weiter komme mache ich einfach zwischendurch was Optisches oder was am Sound (oder Bau einen neuen Level), bis mir wieder eine mögliche Lösung einfällt. Neben der Programmierung gibt es tatsächlich noch genug anderes zu erledigen. Mir gefällt diese Abwechslung. Dass man den vorhandenen grafischen Editor gewissermaßen zu einem eigenen Leveleditor umbaut, fand ich übrigens auf Anhieb super praktisch.
Da ich ja durch meine Tätigkeiten für das Web schon Erfahrung in JavaScript sammeln konnte, habe ich die Logik meiner Apps auch in dem typsicheren JS von Unity geschrieben. Natürlich musste ich oft auch im Internet (v.a. in Stackoverflow) nach Lösungen für verschiedene Probleme suchen. Dabei ist mir aufgefallen, dass ich viele Beispiele, welche oft nur in C# vorlagen, relativ einfach in JavaScript umschreiben konnte.
Es geht ganz sicher noch besser, aber ich musste die Qualität für mobile Geräte doch ganz schön runterschrauben, damit die Spiele auch auf einem Android 4.0 Gerät einigermaßen flüssig laufen. Außerdem wollte ich die Dateigröße für den Download so gering wie möglich halten. Der Akku sollte auch nicht gleich nach 10 Min. überhitzen oder zu schnell leer sein, was tatsächlich immer noch sehr grenzwertig ist.
Zum Webdesign bin ich eher zufällig gekommen und zwar als ich im Jahr 2000 diese Webseite erstellte
um meine 3D-Bilder und -Animationen einem breiten Publikum
zu präsentieren.
Selbst in der ersten Version dieser Webseite konnte man damals schon die Animationen als Video,
allerdings nur mit dem systemeigenen Videoplayer bzw. dem systemunabhängigen Realplayer,
streamen bzw. downloaden. Das ging übrigens zu dieser Zeit noch nicht mal mit Flash.
Allerdings war der Stiel meiner Webseiten schon immer sehr einfach und schlicht, da es mir in erster Linie darauf ankommt,
dass der Besucher die gewünschten Informationen schnell findet,
sich gut orientieren kann
und die Seite möglichst schnell geladen wird.
OK - über die Farbwahl kann man durchaus diskutieren ;-).
Wobei diese Seite, in manchen Bereichen, mittlerweile auch schon etwas in die Jahre gekommen ist.
Anfang der 0er Jahre habe ich auch mehrere Webseiten, ganz offiziell als Gewerbe, erstellt. Das war auch irgendwann der Grund dafür, warum ich jetzt dort arbeite wo ich jetzt arbeite. Ab diesem Zeitpunkt hatte ich nur leider nicht mehr so viel Zeit, Webseiten für andere zu erstellen. Außerdem wurden die Webbaukästen für kleinere Präsentationen und die ganzen Contentmanagementsysteme immer besser und vor allem immer leichter zu bedienen. Wenn man hier einfach das richtige Template wählt, bekommt das Ganze auch gleich einen professionellen Look. Allerdings ähneln sich dadurch auch immer mehr Webseiten. Außerdem hat man auch nicht immer die volle Kontrolle. Das reicht aber in den meisten Fällen völlig aus.
In meinem jetzigen Job bin ich im Grunde für das Aussehen fast all unserer Webportale bzw. -Anwendungen verantwortlich. Dabei erstelle ich hauptsächlich das optische Grundgerüst und das Layout der (einfach zu bedienenden) Benutzeroberflächen für unsere Webanwendungen unter Einhaltung der CI-Vorgaben (sofern vorhanden), inkl. der meisten clientseitigen JavaScript Funktionalitäten. Das Ganze ohne irgendwelche grafischen HTML-Editoren und natürlich auch responsive. Meine Kollegen sind meist heil froh, dass sie sich nicht auch noch um das gesamte Layout kümmern müssen.
Diese Technologie ist für mich deshalb so interessant, weil ich hier mein Wissen im Bereich JavaScript und 3D sehr gut kombinieren kann. Das Schöne daran ist auch, dass das (interaktive) Resultat sofort in jedem beliebigen Browser, unabhängig vom Betriebssystem, betrachtet werden kann. Da ja alles in JavaScript programmiert wird, können auch fast alle Möglichkeiten, APIs, Datenschnittstellen usw., welche JavaScript bzw. die Webbrowser zu bieten haben, verwendet werden.
Allerdings spare ich mir die durchaus gewöhnungsbedürftige und ziemlich komplexe (Low-Level) Syntax von WegGL, indem ich meist Three.js verwende, welches einfach die Handhabung der Objekte und Shader sehr stark vereinfacht. Es gibt zwar mittlerweile auch schon andere 3D-Frameworks, aber Three.js habe ich als erstes entdeckt und bin einfach dabei geblieben.
Web-AR oder -VR oder wie es jetzt heißt Web-XR werden auch noch sehr spannende Themen in diesem Bereich. Am besten in Kombination mit der Sensor-API.
Auch wenn man mit Unity seine Projekte in WebGL kompilieren kann, so ist die Downloadgröße des normalen
JavaScripts inkl. Frameworks,
v.a. bei einfacheren Projekten, immer noch viel geringer, als die mit Unity erstellten.
Zu dieser Webseite selbst kann man vielleicht noch sagen, ausser dass Sie Designtechnisch vielleicht etwas in die Jahre gekommen ist, dass sie seit Ende 2012 mein erstes Experiment für responsives Design, HTML5, CSS3 etc. war. Die Seite selbst bzw. die Domain gibt es übrigens schon seit dem Jahr 2000.
Da ich nicht wollte, dass sich der Inhalt nur bis max. 1280 Pixel in der Horizontalen ausdehnt, habe ich mich zusätzlich für liquid Layout entschieden. Das bedeutet, dass sich der Inhalt immer komplett dem Browserfenster anpasst. Ich finde so viel Platzverschwendung einfach schade. Das macht sich allerdings erst so richtig bei einem Full-HD oder noch besser bei einem 4K Monitor bemerkbar.
Mein Ziel war es, dass die Seiten mit nur einer HTML-Version sowohl auf einem 4K Monitor, als auch auf einem Smartphone, gut lesbar dargestellt werden. Zusätzlich sollte die Webseite auch noch im IE8 einigermaßen funktionieren (deshalb auch kein semantisches HTML5) und auch Reste der Seite mit ausgeschaltetem JavaScript angezeigt werden. Wobei ich die letzten beiden Punkte mittlerweile bei der Weiterentwicklung dieser Webseite immer mehr ignoriere. Da hier kein CMS verwendet wird, war es mir übrigens auch wichtig, dass die Seiten im HTML-Code gut und einfach pflegbar sind.
Bei responsivem und vor allem liquid Design kann man allerdings nicht wirklich 100%ig Pixelgenau vorhersehen wie die Seiten beim Anwender am Ende aussehen werden, da es von zu vielen Faktoren abhängt und sei es nur die Größe des Browserfensters oder des eingestellten Zooms. Von den verschiedenen Browservarianten bzw. -versionen und Betriebssystemen ganz zu schweigen. Es sieht vielleicht nicht überall exakt gleich aus, aber man sollte diese Webseite auf allen aktuellen und gängigen Browsern gut lesen und bedienen können.
Viel Spaß beim durchstöbern, anschauen und ausprobieren.