Ich habe mir überlegt, dass ich für die Projekte in diesem Blog ein einfaches, für alle Themen im Blog geeignetes Theme entwickle, so dass man zu Beginn eines neuen Projekts einfach diese Ressource herunterlädt und schon kann man sich auf die wesentlichen Punkte beim Nachvollziehen eines neuen Beitrags beschränken.
Das Theme, dass ich hier vorstelle, soll genau drei Zwecke erfüllen. Es soll geeignet sein für
- statische und responsive Portale (später auch als Drupal- oder Typo3-Themes),
- als Basis-Layout für hybride Apps als Alternative zu jQuery-Mobile und ähnlichen Frameworks und
- als GUI-Konsole für lokale NodeJS-Projekte.
Ich nenne es deshalb das 3-Purpose-Grid (Demo).
Das gesamte Projekt ist jetzt etwas aufwändiger geworden, zumal die notwendigen Überlegungen recht grundlegend waren. Den Aufbau beschreibe ich deshalb in mehreren Beiträgen. In diesem Beitrag erfolgt zunächst ein Überblick.
Warum ein eigenes Layout-System?
Es gibt doch schon viele Systeme, mit denen man loslegen kann. Man muss das Rad doch nicht wieder neu erfinden.
Das ist richtig und ich habe mich mit einigen dieser Layout-Systeme beschäftigt. Empfehlenswert ist z.B. Bootstrap, das für dieses Blog hier eingesetzt wird. Eine gleichwertige Alternative ist z.B. Foundation, das meiner Meinung nach aufgrund seiner stärker an Desktop-Applikationen angelehnten GUI-Elemente vor allem für Intranet-Projekte oder Anwendungen mit komplexer Funktionalität (z.B. Office-Programme, betriebliche Administrationssysteme) geeignet ist.
Der entscheidende Punkt für die Entwicklung eines eigenen Systems war jetzt für mich, dass all diese Systeme nicht schlank genug sind, um am Ende auch den Performance-Flaschenhals Hybride Apps (Punkt 2 in meiner Purpose-Liste oben) bewältigen zu können. Als Framework für NodeJS-Konsolen sind sie außerdem oversized.
Außerdem glaube ich, dass man mehr Gestaltungsspielraum und Flexibilität bei der Entwicklung einer GUI hat, je weniger Design in solchen Framework steckt.
Oft erkennt man auf den ersten Blick, wenn Bootstrap die Grundlage für die Entwicklung eines Portals bildet, dies umso stärker, je mehr ich von den vorgefertigten GUI-Elemente verwende, z.B. Breadcrumbs, Pagination, Icon-Bar, Side-Bar, Sliders, Forms, Buttons, Tabs, Tooltips, .... Wozu habe ich eigentlich Html5/CSS3?
Abgesehen davon, dass ich für die Anwendung eine Menge Skills erwerben muss, um wirklich effizient damit entwickeln zu können.
Mein System kommt mit einigen grundlegenden Features aus. Dazu mehr im nächsten Abschnitt. Die Umsetzung der vielen GUI-Elemente dagegen obliegt bei meinem System dem Entwickler bzw. Designer mit klassischem Html5/CSS3.
Trotzdem ist der Anspruch des 3-Purpose-Grids hoch. Es ist eine Eier-legende Wollmilchsau unter den Web-Layouts. Der Schwerpunkt liegt nicht in der Vielzahl der veröffentlichten GUI-Elemente, sondern im klaren Aufbau und einigen Ressourcen, die einem effizienten Workflow geschuldet sind.
Das Ergebnis kann sich - glaube ich - sehen lassen (vgl. Abb. 1). Zwar werde ich den Beweis noch erbringen müssen, aber der Einsatz empfiehlt sich vielleicht sogar deutlich gegenüber den immer mehr werdenden komplexen, damit natürlich weniger performanten Frameworks, mit denen Entwickler heutzutage konfrontiert sind.
Wir können z.B. gut auf Modernizr verzichten. Beurteilt selbst am Ende dieser Reihe, ob ihr sowas noch braucht. Ich will hier nicht zu viele Systeme auflisten, die man eigentlich gar nicht benötigt, denn ich weiß, dass diese Frameworks alle ihre Fans haben und sicherlich auch ihre sinnvollen Einsatzbereiche. Mein Gefühl ist nur, dass es heute mit der Toolerities ziemlich übertrieben wird.
Abb. 1: Ein erster Eindruck des 3-Purpose-Grid-Systems
Ich wurde im Rahmen einer Auftragsakquise einmal anhand einer 15-Punkte-Liste gefragt, ob ich das jeweilige Framework kenne. Auf mein Nachfragen etwa bei jedem dritten Framework, ob das Unternehmen dieses Framework auch selbst einsetzt, wurde mir geantwortet "Nein, noch nicht, aber das haben wir eventuell vor". So etwas ist natürlich kompletter Unsinn.
Was benötigen wir für unser 3-Purpose-Grid?
Das 3-Purpose-Basis-System besteht aus folgenden Elementen:
- das eigentliche Layoutsystem für statische und responsive Seiten verschiedener Breiten und Spaltenzahlen,
- eine responsive Navigationsalternative für mobile Endgeräte (Collapsible Navigation) - allerdings in der Basis-Variante nicht-hierarchisch,
- ein responsives Paginierungs-System (nicht von mir, jQuery-Plugin),
- etwas CSS-Unterstützung für responsive Medien und Formulare,
- 2 bis 3 Header- und Footer-Varianten,
- einige Skripte (Bash, Grunt), die den Workflow für die Entwicklung als Cordova-App unterstützen, etwa für die Entwicklung mit Hilfe des Chrome-Ripple-Emulators,
- eine flexible Organisationsstruktur (Konventionen für Ordner und Dateinamen).
Die ausgebaute 3-Purpose-Premium-Version enthielte dann später noch folgende zusätzliche Features:
- eine hierarchische responsive Navigationshilfe für mehrere Menus auf einer Seite (im Gegensatz zu der einfachen nicht hierarchischen für ein Menu auf jeder Seite im Basis-System) und
- ein Popup-User-Interface (PopupUI) für spezielle Aufgaben wie Karten, Listen und Medienwiedergabe.
Die Basis-Variante ist hier im Weblog ausreichend als Startpunkt für alle Projekte.
Ich bin jetzt kein Fan der ganzen CC-Lizenzen (mir zu kompliziert) und habe diesbezüglich noch keine Zeit gehabt, mir genaue Lizenzbedingungen zu überlegen. Ich sag einfach mal so. Jeder darf die Basis-Version für private und kommerzielle Projekte verwenden. Wer aber den Source-Code oder wesentliche Teile des Source-Codes irgendwo publiziert, sollte immer im Kopf des Abschnitts oder der Datei, der/die verwendet wurde, mein Copyright aufführen und gerne - aber nicht zwingend - einen Link auf den jeweiligen Beitrag in meinem Blog setzen.
Ansonsten nicht groß Gedanken machen (wenn man nicht publiziert), einfach Download oder Copy und Paste und man kann sich auf die Implementierung der wesentlichen Aspekte in einem neuen Weblog-Beitrag von mir konzentrieren.
So eine Philosophie könnte ich mir übrigens auch innerhalb von Projektentwicklungsteams vorstellen. Es muss nicht immer dieses neue coole Workflow-Framework namens wie-hieß-das-nochmal sein.
Die Premium-Version habe ich in großen Teilen auch schon fertig, aber ich muss ja auch noch etwas Geld verdienen und kann nicht mein ganzes Know-How für Umme in die Welt entlassen. Das muss ich mir nochmal gründlich überlegen, ob ich dafür nicht ein paar €uronen verlangen soll. Mal schaun.
Ausblick
Im nächsten Beitrag geht es zunächst nur um das Grid-Layout. Dort wird ein dreispaltiges 855 Pixel-breites fixe Layout ausführlich erkläutert. Es werden Varianten für 912- und 960-breite Layouts diskutiert sowie ein 4-spaltiges Layout für die 912-Variante.
In den dann folgenden Beiträgen werden die Features der Basis-Variante sukzessiv vorgestellt. Zunächst wird das Layout durch eine einzige Datei responsive gemacht, dann werden Header- und Footer-Alternativen vorgestellt, jQuery kommt in's Spiel im Zusammenhang mit der Paginierung und dem Collapsible Menu, und so weiter.
Hier eine erste Demo, durch die man sich durchklicken kann. Die Demo enthält schon das Responsive-Feature, aber noch kein Javascript.