Kategorien
Releases Webentwicklung

Fragmentiert Microsoft die eigene Browserlandschaft?

Microsoft lässt Details zu Windows 8.1 aus dem Sack. Webentwickler werden sich freuen: Die Zersplitterung nach Browsern und Plattformen in der MS-Browser-Welt wird wohl zunehmen (siehe “Internet Explorer 11”). Da hatte man 10 Jahre lang einfach nur einen einzigen Browser aus Redmond, so haben Windows7-User vermutlich maximal IE10. Und User von älteren Versionen wohl noch IE9 maximal. Damit wären, wenn man XP ausnimmt, mindestens 3 Browserversionen mit extrem unterschiedlichen Abilities unterwegs.

Sollte MS eine erneute Marktbedeutung anstreben: So wird das jedenfalls nichts.

PS: Das ganze basiert gerade auf einer Vermutung

Kategorien
Webentwicklung

File-Based-CMS: Kirby vs. Stacey

Ich habe mich in der Vergangenheit mal ein bisschen mit so genannten “Static Web Page Generators” auseinandergesetzt, also Systeme wie Jekyll, Hyde, “Octopress” und vor allem Docpad. Docpad ist ja bei allen genannten mein Favorit. Es basiert auf Node.js und läuft auch unter Windows ohne große Mühen. Allerdings gibt es noch eine Zwischenlösung zwischen komplett statisch ausgelieferten Seiten und den “großen” Playern wie z.B. WordPress, TYPO3 und Joomla.

Dazwischen liegen ein paar kleine Perlen, die so genannten “file based CMS”. Dazu habe ich mal zwei der CMSe angeschaut: Kirby und Stacey. Wie ich auf Kirby gekommen bin weiß ich nicht mehr genau, vermutlich über einen Artikel bei Dr. Web Magazin.

Stacey habe ich dann über Kirby entdeckt. Während ein Bekannter von mir mit Kirby recht schnell Ergebnisse produziert hat, bin ich mit Stacey nur langsam warm geworden. Zuviele Fragen bleiben offen in der aktuellen Phase.

Daran kann man eines sehr gut erkennen: eine gefällige Präsentation und eine auf den ersten Blick sehr gute Dokumentation, die auch ohne große Hürden Rückfragen bietet, hilft Einsteigern und Interessierten, sehr schnell in die Materie hineinzukommen.

Im Gegensatz dazu ist Stacey eher spartanisch präsentiert und schreckt auf den ersten Blick ab. Die Ideen, die in dem CMS stecken sind aber durchaus gut, die Referenzenliste ist beeindruckend vielfältig.

Gemeinsamkeiten

Beide Systeme haben trotz aller äußerlichen Unterschiede den gleichen Ansatz und ein fast identisches Konzept: Nur soviel wie nötig. In der Standard-Ausführungen haben beide Systeme kein Frontend, das Bearbeiten der Dateien geschieht via FTP und Texteditoren. Kirby bietet hier auch noch eine Erweiterung, die das ganze auch teilweise in einem Webfrontend ermöglicht, aber eigentlich ist das nicht die Standard-Funktionalität.

Ausblick

Kirby hat eine bestehende Nutzerschaft und einen aktiven Entwickler, der sich über Production Lizenzen finanziert. Interessant wird, ob Kirby 2 einen ähnlichen Bruch produzieren wird, wie Stacey 3.0, das aktuell noch sehr unfertig ist. Kirby bietet aktuell mehr Möglichkeiten, das System “Endkundentauglicher” zu konfigurieren, unter anderem auch durch Dinge wie das Kontaktformular-Plugin.

Trotzdem werde ich beide Systeme für die Zukunft im Auge behalten.

Kategorien
Code Webentwicklung

Wie sollte man Prototypen bauen?

Konzept: Von der Skizze zum Prototypen

Wir gehen in diesem Artikel davon aus, dass für ein neues Projekt Skizzen bestehen, die zeigen, wie die fertige (Web-)Anwendung etwa aussehen und sich verhalten soll. Basierend auf diesen Skizzen möchte der Kunde sehen, wie sich das “anfühlt”, wenn man es im Browser bedient. Wir gehen im folgenden davon aus, dass der Prototyp keinerlei Datenverbindungen oder serverseitige Entwicklung benötigt, also ein reiner “Klick-Dummy” ist.

Grundüberlegungen

Bevor die erste Code-Zeile entsteht sollte man sich schon über einige Dinge Gedanken gemacht haben:

  1. Code-Organisation / Ordnerstrukturen
  2. Zu verwendende Libraries und deren Lizenzen

Was davon in der Entwicklung davon übrig bleibt, ist egal, aber ein Plan sollte vorhanden sein. Mit am wichtigsten ist, dass alle “Screens” auf Atomisierbarkeit gecheckt werden:

  • Habe ich oft gleiche Strukturen?
  • Kann ich die kombinieren?

Dabei sind z.B. Dinge wie immer wiederkehrende Dinge wie Tabellen mit gleichem Aufbau. Hier lohnt sich unter Umständen recht schnell der Einsatz einer Templating-Engine wie Handlebarsjs oder Mustache.

Weitere Dinge: Welche Präprozessoren / DRY-Tools benutze ich, z.B. LESS, SASS und/oder Ajax (um Teile der Oberfläche nachzuladen).

Umsetzung: Was sollte bei der Entwicklung des Prototypen beachtet werden?

[red_box]Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle, Versionskontrolle![/red_box]

Man kann es gar nicht oft genug sagen. Jeder nachvollziehbare Schritt ist ein sinnvoller Schritt in die richtige Richtung. Insbesondere, wenn mehrere Personen am gleichen Code arbeiten, ist ein SCM-Tool richtig wichtig.

Der Code sollte dabei im Code selbst gut dokumentiert sein, zusätzliche Dokumentation in einem Wiki oder ähnlichem wäre optimal. Nutzt eine Toolchain wie Grunt.js um Produktionsreifen Code zu erzeugen:

  1. Minifying
  2. Compressing
  3. Entkommentarisierung 😉

Request-Lagging

Wenn im Klick-Dummy Requests simuliert werden, die im Prototyp nicht oder lokal stattfinden, verzögert Sie im Prototypen mit JavaScript-

Diskussion: quick’n’dirty vs. Produktionsreife

Wieviel produktionsreifen Code soll eurer Meinung ein Prototyp enthalten? Werdet euch mit den Kunden einig darüber, was ihr unter einem Prototyp versteht und was der Übergang vom Prototypen zur “live”-Version bedeutet. Je nachdem sollten natürlich auch unterschiedliche Aufwände in den Prototypen gesteckt werden.

Kategorien
Code Webentwicklung

Warum man bei dynamischen Elementen auf feste IDs verzichten sollte

Wenn man ein Plugin beispielsweise für jQuery entwickelt, welches die Oberfläche einer Webanwendung modifiziert, wie beispielsweise jQuery.FancySelect, dann sieht man häufig, dass Entwickler mit IDs arbeiten. Das ist prinzipiell auch nicht schlecht, da die ID-basierte Selektor-Performance in JavaScript und CSS immer noch die beste ist.

Kategorien
Webentwicklung

Der nächste Browserkrieg

Ich schrieb ja schon über den nächsten Browserkrieg. Nund gibt es Neuigkeiten: Opera stellt auf WebKit um, bzw. (wie jetzt herauskam) auf die zukünftige Google-Engine “Blink”, die ein Fork von WebKit ist. Google baut mit Blink einfach sein eigenes Ding; Samsung und Mozilla bauen zusammen die neue Engine “Servo”, die “eines Tages” die Gecko-Engine ablösen soll und Microsoft kocht sein Süppchen weiter. Das wird sehr spannend, denn es verschwindet eine kleine, feine (Operas Presto-Engine), dafür werfen zwei große Player mit Marktanteil neue Engines in den Ring.