Seit einiger Zeit unterstützen wir schon den +1-Button von Google. Seit heute kann auch das neue Google+-Page-Profil-Badge zur Website hinzugefügt werden. Die zwei Funktionen im Überblick.

Da das Social Media Kit als Software as a Service angeboten wird, sind die Funktionen schon bei allen Kunden freigeschaltet. Unter „Einstellungen SMK“ > „Dienste“ kann ganz unten der Google+-Dienst hinzugefügt werden. Nach dem Klick auf „Hinzufügen“ wird man aufgefordert die URL des Google+-Profils (also der Seite, nicht des persönlichen Profils) einzugeben. Beim nächsten Besuch des Google Crawlers wird die Website mit dem Google+-Profil von Google verknüpft.

Sobald der Google+-Dienst aktiviert wurde, kann unter „Einstellungen Web“ > „Empfehlungsbuttons“ der Google+-Button zur Website hinzugefügt werden. Der Button wird unter den Artikeln angezeigt und es kann ausgewählt werden, ob mit oder ohne Anzahl der +1-Klicks.

Neu seit heute ist die Möglichkeit auch das Google+-Profil-Badge als Widget einer Sidebar hinzuzufügen. Sobald das Widget per Drag&Drop einer Sidebar hinzugefügt wurde, muss nur noch der Titel sowie die Grösse des Badges ausgewählt werden (Google stellt zwei unterschiedliche Grössen zur Verfügung) und der richtige Google+-Dienst ausgewählt werden. Damit das Widget angezeigt wird, muss abgesehen davon, dass ein Google+-Dienst aktiviert ist, auch mindestens eine Sidebar mit einer Breite von wenigstens 300 Pixeln angelegt sein, weil das Badge so breit ist.

Abgesehen von den neuen Google+-Funktionen haben wir diese Woche das unterliegende WordPress auf die Version 3.2.1 aktualisiert und kleine Bugs im Social Media Kit ausgebessert. Alle Infos zum Social Media Kit von Blogwerk gibt’s hier.

Das Social Media Kit von Blogwerk ist «Software as a service» – unsere Kunden arbeiten immer mit der neuesten Version der Applikation und verfügen über die neuesten Features. In Zukunft werden wir regelmässig neue Funktionen im Social Media Kit vorstellen.

Diese Woche stellen wir zwei neue Funktionen vor: Zum einen haben wir unsere Lightbox erweitert, dass das öffnen selbiger und das Blättern innerhalb ein Pageview-Event in den verknüpften Statistikdiensten auslöst und zum anderen haben wir das Textwidget für die Sidebars erweitert, so dass von dort direkt Bilder hochgeladen werden können und aus der Mediathek eingefügt werden können.

Lightbox
Wenn im Social Media Kit die Lightbox-Funktion aktiviert ist, wie z.B. beim Blog unseres Mitarbeiters Michael oder in diesem Blog, löst jede Aktion in der Lightbox in den verknüpften Statistikdiensten ein Seitenaufruf aus. Wir unterstützen im Moment folgende Statistikdienste: Google Analytics, WEMF netmetrix und Chartbeat. Die Dienste können durch den Kunden selbst verbunden werden. Im Backend unter “Einstellungen SMK” > “Dienste”. Nachdem Verknüpfen muss nichts mehr konfiguriert werden.

Die Lightbox-Funktion ist einen Standardfunktion vom Social Media Kit, sie muss aber für jede Seite freigeschaltet werden. Bitte spreche mit deinem Account Manager, wenn die Funktion auf deiner Website aktiviert werden soll.

Erweitertes Textwidget
Das Standard-Textwidget von WordPress erlaubt die Eingabe von beliebigem HTML-Code. Wir haben das Widget ein bisschen erweitert. Oberhalb der Eingabebox (rot makiert) gibt es die Liste der Upload-Möglichkeiten. Mit einem Klick darauf kommt man in den bekannten Upload-Dialog von der Artikel- oder Seiten-Schreiben-Maske und man kann Bilder von der Festplatte hochladen oder aus der Mediathek auswählen und direkt in das Widget einfügen.

Dieses neue Widget ist automatisch bei allen Social Media Kits verfügbar und kann genutzt werden.

Abgesehen von diesen beiden Funktionen haben wir in den letzten Woche viele kleine Verbesserungen und Bugfixes eingespielt.

» Detaillierte Informationen zum Social Media Kit

Im zweiten Teil des WordPress-Artikels geht es um den richtigen Einsatz von Plugins und den optimalen Einbau der Like-Box oder Tweet-Buttons.

Dieser Artikel ist in der Ausgabe 25 des t3n-Magazins vom 31. August 2011 erschienen. Wir veröffentlichen ihn hier mit freundlicher Genehmigung von t3n in zwei Teilen.

Langsame Plug-ins
Oft ist für ein lahmende WordPress-Installation ein Plug-in verantwortlich: Der Autor hat nicht über die Performanceimplikationen seines Codes nachgedacht, und auf seinem kleinen Blog fielen die Probleme nicht auf. Es gibt kein Patentrezept, um solche Plug-ins bereits vor der Installation zu erkennen; trotzdem lässt sich mit zwei Regeln ein bisschen Zeit sparen und mit gutem Codeverständnis schon manches Problem frühzeitig erkennen:

• Es sollten nicht bei jedem Aufruf des Plug-ins/der Webseite Schreiboperationen auf der Datenbank durchgeführt werden. Das ist oft der Fall bei schlecht geschriebenen Statistik-Plug-ins, die jeden Aufruf in der Datenbank mitschreiben. MySQL ist vor allem auf Leseoperationen optimiert. Schreibzugriffe sind vergleichsweise langsam, erzeugen viel Last, und wirken deswegen als Bremse, wenn sie bei jedem Seitenaufruf stattfinden.
• Der Code für die Administration des Plug-ins sollte in eine eigenen Datei ausgelagert werden. PHP ohne «Op-Code-Cache» liest bei jedem Aufruf alle PHP-Dateien neu ein und führt den Code sequentiell aus. Bei den meisten Aufrufen der Webseite wird der Code für die Administration nicht benötigt – warum sollte er also geladen werden?

Doppeltes Laden von jQuery
Durch unsachgemässen Gebrauch von WordPress-Funktionen kann es auch schnell passieren, dass das JavaScript-Framework jQuery zweimal geladen wird. Beispielsweise wird einmal die in WordPress integrierte Version geladen, und zum anderen eine ältere Version durch das verwendete Theme oder Googles CDN, dass auch eine jQuery zur Verfügung stellt. Durch das doppelte Laden entsteht kein JavaScript-Fehler, deswegen fällt die Verschwendung nicht von alleine auf.

Am einfachsten erkennt man den Fehler mit einem kurzen Blick in den ausgelieferten Quellcode, und mit der Suche nach «jquery»: Wird nur eine Stelle im Code gefunden, ist alles ok, gibt es zwei Referenzen, beginnt die Suche. Mögliche Stelle sind die Theme-Dateien header.php und footer.php oder installierte Plug-ins.

Browser Cache nutzen
Statische Dateien wie Bilder, CSS-Styles und JavaScript-Dateien in Themes, Plug-ins und dem Upload-Ordner von WordPress ändern sich nicht mehr. Deswegen können sie sehr aggressiv im Browser gecacht werden. Das Ziel ist, dass der Browser gar keinen HTTP-Request für diese Dateien absendet. Das kann beim Einsatz des Apache-Webservers mit einer .htaccess-Datei im wp-content forciert werden. Quellcode 1 zeigt den Inhalt dieser .htaccess-Datei.

<IfModule mod_expires.c>
  <FilesMatch "\.(gif|jpg|png|js|css)$">
    ExpiresDefault "access plus 10 years"
  </FilesMatch>
</IfModule>

Wenn ausnahmsweise doch eine Modifikation einer Datei nötig wird, muss die URL zu dieser Datei geändert werden, damit der Browser die Datei nicht aus dem Cache holt. Das geht am einfachsten, wenn hinter den Dateinamen ein Fragezeichen zusammen mit einer für jede Änderung hochzählenden Nummer angehängt wird. Beispiel: Aus dem folgenden img-Tag:

<img src=“http://testblog.de/wp-content/themes/theme1/gfx/logo.png“>

wird:

<img src=“http://testblog.de/wp-content/themes/theme1/gfx/logo.png?1“>

Der Dateiname der logo.png-Datei auf dem Server ändert sich nicht und bleibt gleich. Der Apache-Webserver wird beim Bestimmen, welche Datei er ausliefern muss, alles ab dem Fragezeichen im Dateinamen abschneiden.

Facebook, Twitter und andere Social Networks
Ein Blogbetreiber möchte, dass seine Artikel über Likes und ReTweets den Weg in alle gängigen Social Networks finden – deswegen ist so schön praktisch, wenn der Facebook-Like-Button, die Like-Box, der Tweet-Button und alle anderen integrierbaren Scripte eingebaut werden. Das Problem ist, dass jeder dieser Buttons die Ladezeit für den Besucher verlängert. Es gibt zwei verschiedene Technologien, wie solche Buttons eingebaut werden können:

1. Mit JavaScript (bei Facebook XFBML genannt)
2. Per Iframe

Wenn die Wahl besteht, wie z.B. bei Facebook, sollte zum unflexibleren iFrame gegriffen werden. Abgesehen von der modernsten Generation unterbrechen alle Browser den Aufbau der Seite, bis JavaScript-Dateien geladen wurden. Wenn der Server des Social Networks offline oder falsch konfiguriert ist, kann das eine signifikante Zeit dauern.

Auch beim Einsatz des Iframes ist aber mit einem Performancenachlass zu rechnen. Der HTML-Code dieser kleinen Buttons ist verhältnismässig komplex und erfordert Rechenleistung auf dem Computer des Besuchers.

Fazit
Unter Beachtung dieser einfachen Punkte wird die eigene WordPress-Site schon beträchtlich schneller; es gibt aber noch wesentlich mehr Möglichkeiten. Denn alle generellen Tipps zur Steigerung der Performance von Webseiten lassen sich auch auf WordPress übertragen. Hier seien beispielsweise das Vermeiden von HTTP-Requests durch zusammenlegen von Bildern in sogenannten Sprites oder der Einsatz eines Content Delivery Networks (wie Amazon S3) zum Speichern und Ausliefern der hochgeladenen Bilder erwähnt.

Bei allen Arbeiten an der Performance von Webseiten sollte man indessen nie das Ziel, den Besucher optimal zu bedienen, aus den Augen verlieren. Man kann sich leicht verzetteln: Hier noch 20 Millisekunden durch Optimieren von Einstellung X auf dem Server eingespart bringt wenig, wenn man gleichzeitig alle Share-Buttons noch als JavaScript eingebunden hat und damit den Seitenaufbau um mehrere Sekunden verlangsamt.

Die Performance beruht immer auf einer Kombination aus der Auslieferungsverzögerung des Webservers, der Verbindung zum Besucher und der Komplexität beim Rendern der Webseite. Das Firefox-Addon Firebug hilft dabei, die Gesamtsicht nicht zu verlieren.

Das CMS WordPress wird längst für weit mehr als nur Blogs verwendet. Allerdings ist es auf dem Server ressourcenhungrig – und eine schnelle Seitenauslieferung ist inzwischen sogar ein Kriterium für die Suchmaschinenplatzierung einer Website. Mit einigen WordPress-Expertentipps kann man das System optimieren und beschleunigen.

Dieser Artikel ist in der Ausgabe 25 des t3n-Magazins vom 31. August 2011 erschienen. Wir veröffentlichen ihn hier mit freundlicher Genehmigung von t3n in zwei Teilen.

Die Darstellungsgeschwindigkeit einer Webseite ist ein Erfolgsfaktor: Eine Grosszahl der Besucher gelangen via Suchmaschinen auf die Site – Google und co. berücksichtigen im Ranking-Algorithmus inzwischen aber auch die Auslieferungsgeschwindigkeit der Webseite. Ihr Argument: Langsame Websites sind schlecht gepflegt und bieten eine mangelhafte User-Experience.

WordPress ist bereits in der Grundeinstellung relativ langsam und generiert mit jedem Seitenaufruf viel Last auf dem Server. Allerdings bietet das Blog-CMS viele Optimierungsmöglichkeiten und lässt sich durch Plug-Ins leicht beschleunigen.
Ein Blick auf den Tacho:

Zunächst muss sich der Webmaster einer WordPress-Seite über die aktuelle Performance klar werden und Engpässe eruieren. Wenn das Blog in den «Google Webmaster Tools» registriert ist, sollte der erste Weg dorthin führen. Mit Hilfe der Browser-Erweiterung «Google Toolbar» bezieht Google die durchschnittliche Ladegeschwindigkeit von Webseiten bis zum «JavaScript-onload-Event», also bis der Besucher die Webseite nutzen kann. Die Informationen können unter «Google Labs» – «Website-Leistung» gefunden werden.

Genauere Daten, was den Performanceengpass verursacht, liefern die Firefox-Erweiterung «Firebug». Auf dem «Netzwerk»-Reiter wird detailliert darüber Auskunft gegeben, wie lange das Laden welcher Datei gebraucht hat. Automatisierte Analysen inklusive Verbesserungsvorschlage bieten die beiden Firebug-Addons «YSlow» und «Google PageSpeed». Sie sind über einen entsprechenden Reiter innerhalb Firebugs aufrufbar und analysieren die Webseite.

Beide Tools beziehen sich nicht auf WordPress im Speziellen. Sie geben generelle Empfehlungen, was vorgenommen werden soll. Die können teilweise schnell umgesetzt werden. Die Webmaster-Tools-Daten sind zu grob, um Rückschlüsse auf die Performance von der WordPress-Installation zu ziehen. Anders sieht es in Firebug aus. Der erste Eintrag mit der URL der Webseite gibt die Ladezeit der HTML-Daten an – und dafür ist die Performance von WordPress verantwortlich.

Der erste Eintrag auf dem Netwerk-Reiter in Firebug zeigt die Auslieferungsgeschwindigkeit der HTML-Daten und damit die Geschwindigkeit der WordPressInstallation.

Dynamisch bleiben, aber statisch ausliefern
Ohne spezielle Plug-ins werden bei jedem Aufruf einer von WordPress generierten Seite PHP und die WordPress-Dateien geladen. WordPress generiert den HTML-Code für die Seite, schickt ihn an den Webserver-Prozess, und dieser wiederum an den Browser des Besuchers. Beim nächsten Aufruf wird der Vorgang komplett wiederholt, als wäre vorher nichts gewesen. Und zwar auch dann, wenn sich and er Seite nichts verändert hat.

Der grösste Geschwindigkeitszuwachs auf der Serverseite lässt sich deswegen erzielen, wenn der Generierungsprozess z.B. durch zwischenspeichern des HTML-Ergebnisses abgekürzt werden kann. Dies kann entweder durch einen Caching-Server wie Varnish oder Squid geschehen, was aber Erfahrung im Konfigurieren von Linux erfordert und nicht auf günstigen Shared-Hosting-Angeboten möglich ist, oder durch WordPress-Plug-ins wie WP-Super-Cache oder W3-Total-Cache.

Die Plug-ins funktionieren so, dass sie den einmal generierten HTML-Code auf der Festplatte des Webservers abspeichern und beim nächsten Aufruf ausgeben lassen. Beide Plug-ins haben den Vorteil, dass sie durch die Integration in WordPress automatisch darüber informiert werden, wenn der Cache neuerstellt werden muss. Dies ist beispielsweise nötig, wenn ein neuer Artikel veröffentlicht wird oder ein Kommentar geschrieben wurde. Die Konfiguration und Benutzung ist sehr einfach und erfordert in der Regel keine manuellen Eingriffe. Im optimalen Fall wird durch diese Plug-ins für einen Grossteil der Anfragen gar kein PHP mehr auf dem Webserver gestartet, und die Ausgabe des HTML-Codes an den Client geschieht statisch durch den Webserver-Prozess, was enormen Tempogewinn zur Folge hat.

Für Profis: Der Object Cache
Wenn viele Plug-ins in einer WordPress-Installation aktiv sind oder WordPress für mehr als ein simples Blog verwendet wird, werden schnell viele Daten pro Aufruf aus der Datenbank abgefragt. Diese abgerufenen Daten werden vor dem Weiterverarbeiten innerhalb von WordPress aggregiert und in Objekten gespeichert. Da Datenbankanfragen relativ viel Zeit in Anspruch nehmen, bietet WordPress ein Interface an, den sogenannten «Object Cache», um diese Daten in einem flüchtigen, schnellen Cache zwischen zu speichern. Der Einsatz des Object Caches macht aber nur auf eigenen Servern Sinn und ist auf shared-Hosting-Systemen meist gar nicht möglich – er wäre mit grosser Wahrscheinlichkeit auch ein Sicherheitsrisiko, da alle gehosteten Websites den gleichen Cache auf dem Server verwenden könnten.

Der Object Cache erfordert ein sogenanntes Cache-Backend. Dazu wird eine Caching-Software auf dem Server verwendet. Es empfiehlt sich, memcached zu verwenden; aber auch andere Systeme, wie der User-Cache in APC, wären möglich. Nachdem die Software auf dem Server installiert ist, muss WordPress mitgeteilt werden, dass es den Cache nun verwenden soll. Dazu muss eine Datei namens object-cache.php in dem Verzeichnis wp-content angelegt werden. Diese Datei muss eine bestimmte Schnittstelle implementieren und die Daten an das Caching-Backend weiterreichen. Eine Implementierung für memcached kann von mohanjith.net heruntergeladen werden. Für alle anderen Backends bringt eine Google-Suche nach «wordpress object cache » das gewünschte Ergebnis.

Das im vorherigen Abschnitt vorgestellte Plug-in W3-Total-Cache beinhaltet verschiedene, einfach zu aktivierende Object-Cache-Implementierungen. Es kann auch verwendet werden, um die Cache-Backends anzusprechen. Neben den vorgestellten Backend bietet Total-Cache auch ein Backend, das die Daten als Dateien auf der Festplatte des Servers ablegt. Die Performance ist nicht so gut wie mit einem richtigen Cache-Backend, aber dafür auch für Shared-Hosting-Angebote geeignet.

Aktiviertes WP-Super-Cache-Plugin: Die Einstellung „Cache An (Empfohlen)“ reicht meistens schon

Morgen veröffentlichen wir hier den zweiten Teil mit weiteren Tipps.

Uns geht es vor allem um Unterstützung beim Entwickeln von WordPress-Plugins und Erweiterungen des Social Media Kits von Blogwerk.

Wir brauchen Leute mit vertieften Kenntnissen in PHP5, JavaScript, Software-Engineering, objektorientierte Programmierung und WordPress. Die API von WordPress lässt sich leicht erlernen.

Wir freuen uns auf Kontakte zu Entwicklern aus dem ganzen deutschsprachigen Raum. Hast du noch Fragen, schreibe mir (philip.hetjens@blogwerk.com) oder rufe mich an (+41 44 533 30 07). Wenn nicht – melde Dich via Formular bei uns. Wir freuen uns, von Dir zu hören.

Claudio hat eine kaufmännische Ausbildung absolviert und schon früh erste Erfahrungen mit Webseiten gemacht. 2005 hat er sein erstes WordPress-Blog aufgesetzt. Weil ihm das Standard-Theme zu langweilig erschien, begann er mit dem Code zu experimentieren und lernte dadurch HTML, CSS und PHP. Inzwischen interessiert er sich vor allem für die technischen Angelegenheiten, aber durch seine Ausbildung kann er sich auch in Kunden versetzen und ihre Bedürfnisse analysieren.

In seiner Freizeit packt er den Rechner bei Seite und interessiert sich aktiv und passiv für Unihockey. Wir sind schon gespannt, ob das Büro dadurch etwas sportlicher wird. Herzlich Willkommen, Claudio.

Frontendentwicklerin oder Frontendentwickler
HTML5, CSS und Javascript.

Deine Aufgaben
Als Frontend-Entwickler liegt das Schwergewicht Deiner Arbeit auf der Umsetzung von Projekten für unsere Kunden. Du setzt Lösungen auf Basis des Social Media Kits und WordPress um, zusammen mit Grafikern und Usability-Spezialisten.

Durch Deine Arbeit stellst Du sicher, dass die Web-Präsenz unserer Kunden auf allen Geräteplattfomen (mobil, Tablet, Desktop) optimal dargestellt wird. Daneben wollen wir dank Deiner Expertise auch das Social Media Kit für Entwickler ständig verbessern. Du verfolgst die Entwicklung in Deinen Kernthemen und bringst Neuerungen ins Team ein.

Dein Profil

• Die Basistechnologien sind HTML5, CSS und JavaScript mit jQuery. Du hast mehrere Jahre Erfahrung mit diesen Technologien und kennst den State of the Art.
• Du hast eine fundierte Informatik- oder Designausbildung. Hochschulausbildung ist ein Plus, aber nicht Voraussetzung.
• Wenn Du einen Entwicklerhintergrund besitzt, wirst du bei uns fortgeschrittene PHP- und JavaScript-Applikationen schreiben.
• Wenn Du einen Designhintergrund besitzt, wirst du bei uns Design- und Usabilityaufgaben übernehmen.
• Du hast Erfahrung in der Programmierung mit PHP. WordPress-Erfahrung ist ein Plus, setzen wir aber nicht voraus.
• Du kennst die aktuellen Browser und die Bedingungen für die jeweils optimale Darstellung von Webinhalten. Keine Angst, wir entwickeln nicht mehr für Internet Explorer 6.
• Unser Fokus liegt auf dialogbasierten Websites und Blogs. Du bist mit den aktuellen Entwicklungen im Social Media-Bereich vertraut und interessierst Dich dafür.
• Du kennst die Grundlagen des barrierefreien Webdesigns und Standards, wie WAI-ARIA, und hast Grundkenntnisse in der Gestaltung suchmaschinenfreundlicher Websites.

Bei Blogwerk arbeiten heisst:

• Du arbeitest selbständig und trägst die umfassende Verantwortung für Deinen Bereich.
• Du findest bei uns ein flexibles und sich ständig entwickelndes Umfeld in einem erfolgreichen Unternehmen. Du prägst unsere Unternehmenskultur mit, die sich durch Offenheit und Lebendigkeit auszeichnet.
• Deine Kolleginnen und Kollegen profitieren von Deinem Wissen und Deinen Erfahrungen: Voneinander lernen ist bei Blogwerk Programm.
• Unser Büro ist mitten in Zürich und hier wollen wir auch bleiben. Alles was man braucht ist in nur ein paar Gehminuten entfernt.

Wenn Du mehr erfahren möchtest, schick Deine Bewerbungsunterlagen an (bitte nur elektronisch): jobs@blogwerk.com, Blogwerk AG, Philip Hetjens, Leiter Technologie, Stauffacherstrasse 28, 8004 Zürich, Telefon +41 44 533 30 07.

(Wir akzeptieren keine Bewerbung über Personalvermittlungen, Copyright 2011 Blogwerk AG)

Das erste WordCamp Switzerland steht vor der Tür. Am Samstag, 7. Mai 2011, treffen sich WordPress-Interessierte – vom Anfänger bis zum Profi – zu dem Barcamp-artigen Event in Brugg. Wir von Blogwerk sind da und halten drei Sessions.

In der Schweiz werden immer mehr WordPress-Webseiten erstellt, da ist es logisch, dass es auch einen Schweizer Ableger des WordCamps gibt. Das Original findet jedes Jahr in San Francisco statt und auch in Deutschland sind schon mehrere WordCamps veranstaltet worden. Ein WordCamp ist eine so genannte Unkonferenz, ähnlich dem Blogcamp in Zürich. Am Morgen wird entschieden welche Vorträge stattfinden, jeder der Teilnehmer kann einen Workshop vorschlagen, danach geht’s los.

Um die Planung zu erleichtern, können bereits vor dem WordCamp Vorträge und Workshops vorgeschlagen werden. Wir von Blogwerk haben drei Vorträge eingereicht:

Ich werde einen Vortrag über Performanceoptimierung von WordPress halten. Ein technischer Vortrag für Leute, die bereits mit WordPress arbeiten. Ich werde die verschiedenen Caching-Mechanismen vorstellen und zeigen, welche davon wir bei Blogwerk einsetzen. Da man zu diesem Thema nie genug wissen kann, freue ich mich auch auf die Diskussion.

Michael hält den zweiten Vortrag über Pluginprogrammierung für WordPress. WordPress-Einsteiger erfahren in dieser Session, welche APIs WordPress zur Verfügung stellt und wie sie effizient eingesetzt werden können.

Der dritte Vortrag von uns ist ein Impulsreferat zum Thema «Programmierung ist Kunst!». Blogartikel wie «10 Code-Snippets you have missed» erwecken den Eindruck, dass Programmierung ein Handwerk sei. MIt dem Impuls wollen wir vor allem die Diskussion anregen – wir freuen uns auf Widerspruch und andere Perspektiven!

Das WordCamp Switzerland findet an der Fachhochschule Nordwestschweiz in Brugg statt. Der Eintritt ist kostenlos und wir freuen uns auf viele interessante Diskussionen.

» WordCamp Switzerland

Er baut bereits seit acht Jahren Websites, die vier letzten davon verbrachte er bei einer anderen Web-Agentur, wo er Internet- und Intranetlösungen für KMU und Grossunternehmen konzipierte und umsetzte. Zuletzt leitete er ausserdem die Entwicklung eines Content Management Frameworks.

Wir, und ich, freuen uns, dass Michael nun bei uns ist, und wir hoffen, dass wir noch viele, viele Projekte zusammen bearbeiten werden.

Im ausgebuchte Referat wurde zunächst die Frage geklärt, ob eine Website heutzutage überhaupt noch wichtig ist, danach wurden die Zielgruppen einer Unternehmenswebsite definiert und deren Anforderungen analysiert.

Für alle, die das Refertat verpasst haben, gibt es die Präsentation hier zum Nachlesen. Falls offene Fragen bleiben, freuen wir uns über eine unverbindliche Anfrage.

.