Kategorien
Schlagwort: HTML
Kategorien
DRM in HTML5
In Sachen DRM bin ich ja grundsätzlich geneigt, jegliche DRM-Techniken abzulehnen. Daher wollte ich ich Alex auch gar nicht wiedersprechen, als er (genau wie ich auch schon) über das möglicherweise kommende HTML5-DRM gerantet hat.
Nun ist seitdem etwas Zeit vergangen und ich habe mir ein paar mehr Gedanken dazu gemacht.
Wenn man davon ausgeht, dass das DRM in HTML5 ein Standard sein soll, der es ermöglicht, Content (z.B. Streaming-Musik oder Filme) “sicher” vor Mitschnitt anzubieten, könnte das durchaus genug Potential bieten um lästigen Brückentechnologien wie Flash und Silverlight endlich den Gar auszumachen. Voraussetzung ist dabei natürlich, dass die Inhalte in möglichst offenen bzw. Plattformübergreifend funktionierenden Formaten übertragen werden.
Wenn ich mit plattformübergreifenden Standards das gleiche erreichen kann, wie aktuell mit Flash oder Silverlight, dann werden auch Nischenplattformen attraktiv. Ich kann auf Linuxrechnern mit einfachsten Mitteln Streaming-Angebote wahrnehmen, die sonst proprietäre Browser-Plugins benötigen. Oder mit BSD. Im Endeffekt: Meine Zielgruppe wächst um vermutlich 5-10% in eine Nische, die in der Regel als “nicht wirtschaftlich” eingeordnet wurde. Bietet dieser Nische die Möglichkeit, Paid Content wahrzunehmen. Kickstarter und andere Crowdfunding-Plattformen haben es gezeigt, dass hier ein Markt ist, der auch Geld auszugeben bereit ist.
Ich persönlich würde mich über eine flashfreie Version von z.B. RDIO oder Spotify mehr freuen als über eine Linux-App dafür. Und um hier mal einen Stallman zu pullen: Mir ist ein standardisiertes DRM, welches allen die Möglichkeit gibt, den Content zu nutzen lieber, als dieser Plugin-Wildwuchs mit vorprogrammierten (sic!) Sicherheitslücken.
[red_box]Lieber wäre mir auch, wenn gar kein DRM eingesetzt würde. Aber ich bin Realist genug, um zu sehen, dass das auf längere Zeit nicht verschwinden wird. Und dann lieber auf diese Weise.[/red_box]
Links
Wenn die Zeit oder das Budget bei einem Kunden knapp ist, greife ich gerne zu Lösungen “von der Stange”. Das muss auch nicht zwingend etwas schlechtes sein. Viele Templates sind mit wenigen CSS-Änderungen durchaus Wandlungsfähig. Und wenn man nach Stunden abrechnet und die nicht komplett exklusive Lösung dem Kunden auch passt, ist das nicht mal ein oder anrüchig: Es verbessert das Preis-Leistungsverhältnis stellenweise enorm.
Zusätzlich zu einem Theme-Fundus für WordPress kann ich folgende Seiten für die Templatesuche empfehlen:
- Free CSS Templates – der Klassiker
- HTML5UP!
- HTML5 Templates
Die Templates sind, was den Funktionsumfang angeht sehr unterschiedlich. Die HTML5-Seiten haben sich allerdings fertige Responsive-Templates auf die Fahne geschrieben. Während diese die Templates zumindest auf den Seiten nur als CC-Lizenz anbieten, bietet Free CSS Templates auch die Möglichkeit, die Quellenangabe ab einer Spende von 5 Dollar zu entfernen. Die drei Seiten würde ich übrigens als prinzipiell seriös einstufen.
Weitere Links:
- Stackoverflow beantwortet die Frage nach Freien Templates. auch
- Open Source Webdesign bietet einen große Fundus mit unterschiedlichen Lizenzen und Quellen
Kategorien
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:
- Code-Organisation / Ordnerstrukturen
- 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:
- Minifying
- Compressing
- 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.
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.