... auf meiner kleinen Webseite. (Welche übrigens schon längst überarbeitet gehört)
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 (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 feinen Marketing Service Agentur in München. Hier erstellen wir im IT-Team 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, Antragsstrecken, eine Gebrauchtmotorradbörse uva., realisiert. Seit Anfang/Mitte der 2010-er Jahre natürlich schon komplett responsive, inkl. Berücksichtigung von Tabletts im Hochvormat. Was meiner Meinung nach immer noch nicht wirklich oft vorkommt. Lange haben wir dafür ASP.Net WebForms von Microsoft verwendet. Seit einiger Zeit kommen aber auch immer mehr MVC/Razor Applikationen hinzu. Mittlerweile aber auch immer mehr Vue.js Anwendungen inkl. Web-Api. Was mir als Frontendentwickler, mit an sich ganz guten JavaScriptkenntnissen, natürlich sehr entgegend kommt.
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 mittlerweile 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.), 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 viel Rechenpower benötigt. Allerdings ist dieser Bereich inzwischen etwas in den Hintergrund 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 mittlerweile viel mehr reizen. Damit meine ich übrigens nicht nur Spiele. Technische Illustrationen, interaktive Visualisierungen und Simulationen 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öhnungsbedürftige WebGL-Syntax verstehen zu müssen. War natürlich von Anfang an hellauf begeistert und habe auch gleich einige Experimente umgesetzt. Damals allerdings noch so gut wie ohne API-Dokumentation. So musste ich mich mühsam durch die einzelnen JS-Module bzw. -Objekte kämpfen um überhaupt was darzustellen zu können. So um 2014 entdeckte ich die kostenlose Version von Unity. Eine Game-Engine, bei der die physikalischen Simulationen 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-)Anwendungen sehr viel dazugelernt.
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. 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.
Auch wenn auf dieser Seite der Quellcode meiner (historisch gewachsenen) CSS-Stylesheets auf den ersten Blick vielleicht nicht wirklich aufgeräumt wirken, kenne ich mich mit den ganzen, aktuellen Attributen, Selektoren, Pseudoelemente, 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 Browserunterstützung soweit fortgeschritten ist, dass (endlich) neue Attribute verwendet werden können, wird es Zeit auch ein komplett neues, modernes
Stylesheet zu erstellen.
Mittlerweile selbstverständlich mit Flexboxen, Layoutgrids, CSS-Transitions, -Animationen, Pseudoelemente 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) Verwaltungsapplikationen gehe ich in der Regel von der Desktopansicht (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äprozessoren 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 übersichtlicher, 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 mittlerweile 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 unterschiedlichen Werten.
So wird meiner Meinung nach die flexible und ursprünglich angedachte Kaskadierung untergraben.
Allerdings sollte man den größten Vorteil dieser Frameworks auch nicht ganz verschweigen.
Es gibt für diese mittlerweile so viele tolle Steuerelemente, welche von sehr großen
Communities erstellt und unterstützt werden, so dass es mittlerweile wirklich sehr schwer ist, diese zu ignorieren.
Außerdem habe ich festgestellt, dass viele reinen Coder
oft mit diesen Frameworks einfach schneller zurechtkommen,
da sie sich verständlicherweise lieber mehr um die Logik als um das Aussehen und Layout kümmern wollen.
In meiner Arbeit bin ich für die Erstellung des kompletten HTML-Layouts unserer mittlerweile meist responsiven Webanwendungen verantwortlich, egal ob es sich um interne Anwendungen oder um Kundenprojekte 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-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. 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 clientseitige Funktionen mit JavaScript selbst. Nicht nur für die Validierung und Vereinfachung der Eingaben, sondern auch für clientseitige Businesslogiken, Ajax-Requests z.B. für Autocompletes usw. oder erstelle auch gerne mal eigene Steuerelemente bzw. passe vorhandene an. 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.
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 zurechtgekommen 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 Schwierigkeiten, 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 Erfassungsportal (inkl. Securitycontext, also mit Login und Berechtigungssystem), eine Assesment-Applikation, sowie einige Antragsstrecken mit Vue.js realisiert. Wobei ich für die Antragsstrecken, 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 Steuerelementbibliotheken oder andere CSS-Frameworks benötigt, da ich die für uns erstmal wichtigsten Steuerelemente, 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 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 Servercode, selbst kleine Änderungen oder Anpassungen vornehme. Bei den REST-APIs fällt es mir sogar noch ein bisschen leichter als bei den Anderen.
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 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ürs 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 vertraut. So dass ich es rein theoretisch mit JavaScript, für eine gewisse Interaktivität, aber auch für Animationen usw., manipulieren könnte. Übrigens kann man mit Vue.js und SVG hervorragend interaktive Grafiken erstellen.
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ützt. 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 viele 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 normale
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 selbst bei reinen Webpräsentationen auf diese Hilfsmittel.
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 anspruchsvoller 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 Datenaustausch via AJAX-Requests sowie
viele Businesslogiken 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 mittlerweile ebenfalls vertraut. Wobei Vuex mit Vue3 auch schon wieder als veraltet
gilt.
Auch die Handhabung mit npm, Webpack bzw. Vite fällt mir immer leichter.
Der Umgang mit (JSON) Datenobjekten sowie das ganze Eventhandling 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 Schwierigkeiten, 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.
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 doch irgendwie anders. 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.
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 oft 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.
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 sehr 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 vieler 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.
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.