Du willst also ein riesiges neues Webprojekt starten?

Vor einigen Wochen wurde ich von einer großen Firma gebeten, ein Redesign (auch im technischen Hinblick) ihrer Website durchzuführen. Nun möchte ich mit euch meine Gedanken dazu teilen, evtl. kommen ja weitere Vorschläge von Leuten, die an einem ähnlichen Punkt stehen, dazu 🙂

Man kann keine mobilen Endgeräte vernachlässigen

Schaut man sich den folgenden Graphen an – er erzählt seine eigene Geschichte. Millionen von mobilen Geräten surfen jeden Tag durchs Internet. Ignoriereren auf eigene Gefahr..!

Entscheide, ob du direkt eine mobile Website baust

Das mobile Internet ist eine ganz andere Welt. Es gibt viel zu wenig Platz auf einem kleinen Bildschirm. Oft gibt es viel weniger Bandbreite als auf einem stationären PC oder Mac. Zudem gibt es viele Eingabegeräte nicht, die man von Desktop-Rechnern kennt (denke an den Maus-Cursor, an ein Rechtsklick, ..) – umgekehrt kennt ein Rechner kein Swipe-, Pinch- oder Shake-Event.

Möglicherweise kommt man mit einem Single-Site-Design ans Ziel. Reponsives designen kann dabei helfen – es ist eine tolle Lösung für viele Seiten.
Aber bloß nicht die mobile Website so voll packen wie die für Desktops! Manchmal gibt es Fälle, da braucht man einfach zwei verschiedene Websites (siehe m.facebook.com und facebook.com). Dort ist es allerdings wieder schwieriger, beide Websiten möglichst synchron zu halten.

Gutes CMS – schon einmal drüber nachgedacht?

Das eigene CMS sollte möglichst alles können, wonach man fragt. Ich brauche das Bild eines Produks in Originalgröße – here you go. Nun brauche ich nur die Thumbnails von allen relevanten Produkten – here you go. Ich brauche Titel, SubTitel und den Einführungstext eines Artikels – here you go. Ich möchte den Content eines Artikels via AJAX als JSON abfragen, bitte unformatiert – here you go. Am Anfang eines Projekts sollte man sich über solche Sachen gedanken machen – und ein CMS bauen oder ein bestehendes modifizieren, welches genau nach den eigenen Vorstellungen arbeitet.

Um sich weiter mit diesem Thema zu beschäftigen, kann ich dir das Buch „Content Strategy for Mobile“ von Karen McGrane empfehlen.

Entwickel einen Plan für’s CSS

Für dein Projekt kannst du dir jegliche Technologie aussuchen die du kennst – aber du wirst immer CSS brauchen. CSS ist gleichzeitig sehr einfach und unglaublich schwer („day to learn – lifetime to master“). Bei einem großen Projekt sollte man sich überlegen ein eigenes Design-System zu schreiben. Dieses System soll dabei helfen, oft genutzte Parts und CSS-Pattern konsisten zu halten um so Zeit und Geld zu sparen.

Auch für diesen Bereich wieder ein Tipp von mir – wirf einen Blick auf SMACSS (es ist auch ein Blick ins Buch verfügbar!).

Programmiere sauber

Damit meine ich nicht nur das tolle Kommentieren von betimmten Codezeilen. Für mich ist es immer wichtig konsistent zu programmieren – auch wenn jeder Entwickler mit der Zeit seinen eigenen Stil entwickelt – behalte ihn bei!

Man kann nicht nur unsauber programmieren sondern auch unsauberen Markup und CSS erzeugen. Dagegen hilft z.B. der CSS-Guide von Github oder der von HTML-/CSS Guide von Google. Sollte man beides mal gelesen haben.

Benutze CSS-Vorarbeiter wie SASS oder LESS

Design (und CSS) ist viel einfach zu schreiben, wenn man PreProzessoren wie SASS oder LESS benutzt. Man kann Variablen z.B. für Farben setzen um diese – ihr ahnt es – konsistent zu halten. Es gibt so genannte CSS3-Mixings, mit denen es einfach ist oft genutzte CSS3-Styles für alle Browser nutzbar zu machen (siehe Compass oder Bourbon). Es ist möglich die Stylesheets über mehrere Dateien zu verteilen (Organisation!) um sie später komprimiert als eine CSS-Datei an den Browser zu senden.

Javascript-Architektur

jQuery ist in den letzten Jahren fast normal geworden. Man braucht es häufig um den DOM zu manipulieren und um AJAX browserübergreifend zu nutzen. Aber es hilft nicht, eine bestimmte Javascript-Struktur anzulegen.

Man sollte sich fragen: welche Seiten benötigen welches Javascript? Was sollte in eine globale Javascript-Datei und was in eine seitenspezifische? Wie regelt man diese Abhängigkeiten? Wie schreibt man ein großes Javascript-Projekt ohne das man später etliche globale Variablen und Funktionen definiert hat?

Eventuell könnte backbone.js helfen. Eventuell auch require.js. Wenn du Ruby on Rails serverseitig einsetzt, kann dir pipeline helfen.

Für alle Mac-Leute sollte auch CodeKit nicht unerwähnt bleiben. Und wer mehr über sturktuierte Javascript-Apps wissen will, sollte sich mal den Beitrag von Rebecca Murphey durchlesen.

Versionen-Kontrolle

Wer im Team entwicklelt braucht ein Versions-Kontrollprogramm. Unter Windows geht bestimmt kein Weg an Microsoft’s SourceSafe (bzw. dem neuen Team Foundation Server) vorbei. Unter *NIX-Systemen ist und bleibt GIT mein Favorit.

Ich bin bestimmt kein Profi in diesem Gebiet, aber das Web ist voll mit Tutorials rund um das Thema. Zugegen: bis man erst einmal „drin“ ist, vergeht einige Zeit. Später läuft aber alles – und das wirklich zuverlässig.

Zum Beispiel hast du einen unberührten Versions-Zweig („prestine branch“). Auf diesem arbeitet keiner. Zudem hast du einen staging branch. Alles das was direkt public geht. Dazu kommen Features- oder Plugin-Äste. Fährt man seine Entwicklung nach diesem Prinzip, ist es kein Problem zu „upmergen“, sprich die Äste der staging- mit der features-branch synchron zusammenzuführen. Wenn man fertig ist geht’s ans „downmergen“ in die staging-branch, um Features zu testen die neu dazugekommen sind. Wenn alles gut ist, geht’s nach vorne in die Masterbranch und wird von dortaus publiziert.

Wenn alle im Team dann noch vernünftig kommentieren (commit) steht einem sauber geschriebenem Projekt nichts mehr im Weg.

Und ab auf den Live-Server

Wenn man, wie ich oben beschrieben habe, seinen Code vernünftig in Äste aufteilt, kann man seinen Master-Zweig (möglichst automatisch) auf einen Testserver schieben. Idealerweise ist dieser hard- & softwaremäßig (LAMPP-Verbund) identisch aufgebaut spätere Produktiv-Server. Wenn auf diesem Testserver ebenfalls alle Tests erfolgreich und wie geplant ablaufen, geht es rüber ins Produktivsystem.

Projekte die einem dieses Prozedere Abnehmen, nennen sich z.B. Beanstalk (GIT Deployment) oder Capistrano (eigenes Deployment aufbauen).

Hosting

Für alles was jetzt noch schief geht sind die Anderen schuld. Oder wie war das noch? 😉 Nein, aber mal im Ernst: hast du dir mal folgende Fragen gestellt?

Kannst du / kann man den Server on-thy-fly updaten? Was tun bei heavy-load / bist du dafür oder dagegen gewappnet? Wie schauts aus mit load-balancing? Wie schaut es aus mit dem Kundensupport bei deinem Hosting-Provider? Wird er 24 Stunden / 7 Tage die Woche für dich da sein? Wer übernimmt die Kosten dafür? Wer überwacht den Server oder bist du vllt. dafür zuständig? Wenn du die letzte Frage mit „ja“ beantwortest, schau dir mal New Relic an.

Viele große Websiten haben ganze Teams um Server zu überwachen – es ist ein ganz anderer Themenbereich als das Deployment. Hier muss man sich gut selbst einschätzen können…

Performance-Probleme? Wir doch nicht!

Performance ist ein Thema, welches man als Entwickler gerne auf „später“ verschiebt. Trotzdem sollte man sich diesem Bereich möglichst schon „vor dem Anfang“ eines Projekts widmen. Mache so viele Stresstests auf verschiedene Seitentypen wie es nun geht. Dabei hilft Apache Bench. Komprimiere Seiteninhalte so oft und so stark es geht. Nutze den Browserchace eines Nutzes. Die meisten Stylesheets und JS-Files sind sowieso statisch und müssen nur 1x geladen werden.

Das Team ist entscheidend

Wenn aller technischer Kram geklärt ist entscheidet letztlich nur eins: das Team. Es sollte möglichst ab Start durchgehend am Projekt (möglichst vollzeit wie du auch) beteiligt sein. Klar: es braucht Zeit und Geld. Aber man muss von seinen Leuten überzeugt sein. Und die von einem selbst.

Und du musst überzeugt sein von dem was du baust. Ist das nicht der Fall wird es dir nicht leicht fallen Entscheidungen zu treffen.

Fazit

Natürlich muss man nicht alle Punkte bei jedem Projekt beachten. Ob es für ein kleines Projekt sinnvoll ist eine große Versionskontrolle einzurichten ist fraglich. Natürlich sollte man Backups trotzdem nie vergessen..

Und jetzt gehts ans Durchführen.. viel Erfolg. Ich hoffe dem einen oder anderen ist ein Tool noch völlig neu aber dennoch brauchbar 🙂 Für Kommentare bin ich immer dankbar.

Und danke fürs Lesen!

Flattr this!

3 Kommentare

      1. Bisher nur OpenGL – im Bezug auf’s Web mit WebGL noch nicht. Hast du da schon Erfahrungen gesammelt, was sich besser für schnelles Darstellen und Rendern von animierten Objekten eignet? WebGL, Flash, HTML5 z.B.?

        Antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.