640x480.de

Beiträge aus dem Was-mit-Medien-Alltag

Websites als Gemeinschaften

Eine Website zu betreiben, heißt eine soziale Gemeinschaft zu bilden und zu pflegen.

Egal ob Verein, Berufsverband, Schraubenhersteller, Verlag, Schule oder privater Blog - die Zeiten sind lange vorbei, in denen sich ein Sender an eine Zielgruppe gewendet hat. Im Web 2.0 wollen alle etwas voneinander.

Der Verein (also die Mitglieder, die aktiv sind) gibt Informationen an die Mitglieder und wünscht sich dafür Beteiligung. Ein Hersteller veröffentlicht Produktinformationen auf der Suche nach Käufern oder Rückmeldung in Form von Bewertungen, Likes oder Empfehlungen. Ein Verlag ist Mittler zwischen Autoren und Lesern.

Das hört sich im ersten Moment vielleicht etwas banal an. Tatsächlich – in meiner Webentwickler-Realität – werden Websites als technische Konstrukte wahrgenommen – als eine Ansammlung von Funktionalität – und nicht als soziale Gebilde. Das ist ein Problem. Als Dienstleister merken wir das bei Ausschreibungen und in der langfristigen Betreuung.

Ausschreibungen lesen sich wie der Weihnachtswunschzettel meiner Kinder. Sie sind Ansammlungen von konkreten Produktwünschen, gerne mit Stückzahl und Bestellnummer:

  • „Wir brauchen eine Typo3-Website …“,
  • „Ich will eine Lightbox …“,
  • „Da muss ein Karussell rein …“,
  • „Wir wollen einen Blog …“.

Selten bis nie liest man inhaltliche Wünsche nach dem Motto:

  • Wir möchten regelmäßig über neue Produkte informieren und dazu die Meinung unserer Kunden hören.
  • Wir möchten Lehrern, Schülern und Eltern eine geschlossene Plattform zum Austausch von Erfahrungen geben.
  • Unsere Mitgliedern möchten Ihre Erlebnisse bei Vereinsaktivitäten austauschen.
  • Wir möchten, dass unsere zufriedenen Kunden unsere Produkte weiterempfehlen.

Aus solchen Wünschen lassen sich konkrete Aufgabenstellungen ableiten. Wer ist „Wir“? Um welche Informationen geht es? Wie oft und wie viele? Wer erstellt die Inhalte? Wer liest die Antworten? Und so weiter. Daraus ergeben sich dann Anforderungen, welche Technik zum Einsatz kommen kann, ob die eigene Website der richtige Platz ist oder vielleicht ein offenes Forum oder ein soziales Netz?

Wenn Websites scheitern, ist das oft keine Frage der Technik, sondern eine Frage falscher Erwartungen oder Ausgangsbedingungen. Wie oft haben wir schon Foren installiert, weil ein Verband offensichtlich vorhandene Probleme zur Diskussion bringen wollte. Wie oft haben wir diese Foren nach einer Weile wieder abgeschaltet, weil nach zehn Wortmeldungen die Aktivität einschlief. Das ist – in erster Linie – keine Frage von gutem Forum oder schlechtem Forum, von Benutzbarkeit oder nicht (einige der aktivsten Foren, die ich kenne sind grottenhässlich und fast unbedienbar). Es ist eine Frage von Ansprache, davon dass die Initiatoren selbst diskutieren, dass auf Fragen geantwortet wird (zeitnah!), dass aus Diskussionen im Forum echte Aktivitäten in Gremien und daraus echte Entscheidungen werden.

Blogs scheitern nicht, weil sie nicht in Wordpress programmiert sind. Blogs scheitern, weil einen Blog installiert zu haben nicht heißt, dass man fertig ist. Es geht um erkennbare Autorschaft, um nützliche Inhalte, um Stetigkeit.

Online-Shops scheitern nicht, weil die Software doof ist. Sie scheitern, weil das Umfeld nicht stimmt, weil es vielleicht kein Verkaufskonzept gibt? Weil keiner die Produkte pflegt und das Schaufenster täglich liebevoll bestückt? Weil die Tatsache, dass man einen Online-Shop installiert hat, nicht heißt, dass die Käufer plötzlich Schlange stehen.

Wenn die Entwicklung einer Website nicht als technische sondern als soziale Frage betrachtet wird, dann besteht auf lange Sicht auch Aussicht auf Erfolg. Dann kommt auch nicht als erste Reaktion auf die Reaktion des Dienstleisters auf den „Wunschszettel“: „Oh – so teuer?“. Denn dann ist selbstverständlich, dass die technischen Fragen – also die Herstellung der technischen und formalen Infrastruktur – nur einen Bruchteil in der Gesamtaufgabe ausmachen. Und mit Sicherheit werden viele der technischen Wünsche nicht sofort gebraucht. Und müssen auch nicht alle Kosten sofort entstehen.

Ich wünsche mir mehr Auftraggeber die erkennen, dass die größten Arbeitsanteile vor und nach der Websiteproduktion liegen.

24.06.2014 | 1 Kommentar

SVG-Header reloaded

Neues Template – Neuer Header. Unser Blog hat ein neues Layout bekommen und der SVG-Header ein neues Farbschema, welches auf die Inhalte der Website reagiert.

Die Headergrafik bildet wenn sie ohne Parameter verwendet wird die vier Rubriken (Feldforschung, Lab, Recherche, Webmontag) ab.

Innerhalb der Rubrik wird die Grafik eingefärbt (hier das Beispiel der Rubrik „Lab“). Neben der Grundfarbe wird ein Teil der Kacheln zufällig abgetönt, so dass das Ganze etwas abwechslungsreicher aussieht.

Hinter der SVG steckt ein PHP-Script, welches Zugriff auf die Parameter der Website hat und daraus den Code der Zeichnung generiert. Damit kann bei jedem Aufruf der Seite eine individuelle Zusammenstellung erzeugt werden.

14.11.2013 | 2 Kommentare

Wie kommen Zugangsdaten sicher und effizient zum Kunden?

Wer mit Support zu tun hat kennt das Problem: der Kunde braucht ganz schnell sensible Zugangsdaten und hat sie nicht, weil die Kollegin, die diese Daten normalerweise verwaltet krank ist oder Urlaub hat oder er findet die Zugangsdaten einfach nicht mehr. Oder es wurde eine neue Mailbox eingerichtet und nun muss das Passwort irgendwie – am besten abhörsicher – zum Kunden. Wie gehen wir da vor? Klartext-Email oder im Skype macht Bauchschmerzen. Also?

Variante 1: Anrufen, durchsagen.

Das ist schonmal ganz gut und sicher, aber leider hat diese Variante einige Nachteile. Zum Einen geht das nicht immer, weil der Kunde z.B. gerade nicht telefonisch erreichbar ist. Daneben kann ein solches Telefonat auch anstrengend sein, wenn es um sichere Passworte geht (z.B: IuuhGZTgff567&%rrtfg), dann dauert die Transkription vom Geschriebenen ins Gesagte, ins Gehörte und zurück ins Geschrieben eine Weile und ist Fehleranfällig.

Fazit: Relativ sicher ist das, aber Effizient geht anders.

Variante 2: verschlüsselte Datei versenden. 

Diese Variante geht eigentlich nur bei Kunden oder Partnern, mit denen man sich vorher auf ein Generalpasswort zur Verschlüsselung dieser solcher Dateien geeinigt hat. Und die Gegenseite muss dieses Passwort auch noch erinnern. Daneben wird eine Software gebraucht, die auf beiden Seiten vorhanden ist und dort im günstigsten Fall auch bereits anderweitig eingesetzt wird, damit der Umgang damit klappt.

Fazit: Fällt also eigentlich auch aus.

Variante 3 PGP verschlüsselte Emails

Im Prinzip zählt hierzu auch S/MIME, wobei dafür Zertifikate benötigt werden, die das Setup noch komplizierter machen. Um PGP einzusetzen muss man auch ein bisschen Zeit mitbringen: ich habe gestern ungefähr 10 Minuten gebraucht, bis ich mir selbst die erste verschlüsselte Email geschickt hatte. Wen es interessiert, ich habe mich im Wesentlichen hier orientiert: enigmail.net 

Fazit: kompliziertes Setup, geht nicht für schnelle Kommunikation mit neuem Kunde, weil der Sender zunächst einmal den öffentlichen Schlüssel des Empfängers benötigt. Ansonsten aber prima in die normalen Arbeitsabläufe integrierbar.

Variante 4 NoteShred

Gottseidank gibts ja Google, und es hätte mich gewundert, wenn nicht irgendjemand schonmal eine Applikation gebastelt hätte, die genau diesen Zweck erfüllt. Noteshred ist ein Dienst, der Notizen (z.B. Passwörter) verschlüsselt ablegt und nach Abruf zerstört. Zusammen mit der SSL-Verbindung zum Server ist das eigentlcih eine runde Sache - probierts mal aus https://www.noteshred.com/.

Der Wermutstropfen ist ist natürlich, das dieser Service von irgendwem in Kalifornien betrieben wird. Gut - er versichert zwar, das das alles so gemacht wird, wie beschrieben, aber ein bisschen Bauchschmerzen habe ich da trotzdem.

Natürlich habe ich dann auch eine Open-Source Implementation dafür gefunden (passtunnel.com / guithub/passtunnel). Leider ist die entsprechende Website grad nicht erreichbar.

Fazit: Das wäre was, wenn wir das selber betreiben würden.

Variante 5 Akira

Ja. So kompliziert ist das ja nicht, also könnten wir das auch mal selber mit Akira implementieren.

Aber vielleicht gibt es ja noch die andere ultimative Lösung. Gibts Ideen/ Vorschläge?

11.07.2013 | 3 Kommentare

Akira-CMS: Interface beeinflussen und erweitern

Ziel ist es, in jedem Projekt eine möglichst individuell zugeschnittene Redaktionsumgebung zu haben. Es gibt verschiedene Mittel, als Entwickler von außen Anpassungen im CMS vorzunehmen, ohne an den Kern zu müssen.

widgets

Kleine Scripte, die im Dashboard für Ordnung sorgen. Nutzergruppenspezifisch. Links zu häufig benutzten Modulen, Deep-Links zu Spezialaufgaben, Einbindung externer Widgets (z.B. Piwik-Statistik) oder ganze Assistenten.

page sections

sind einerseits zentraler Bestandteil der templates. Innerhalb des Gesamtlayouts einer Seite (definiert durch header und footer) ermöglichen Sie die Platzierung unterschiedlichster Inhaltsformate. Über ein PHP-Array mit Optionen lassen sich unkompliziert Interface-Elemente auf der Edit-Seite der Section platzieren und damit dem Redakteur Auswahlmöglichkeiten geben, die dann im Skript ausgewertet und für die individuelle Darstellung der Inhalte genutzt werden können.

extensions

Akira-Module stellen eine Grundfunktionalität bereit. Einträge hinzufügen, bearbeiten, löschen und die verschiedenen Such-, Sortier- und Filterfunktionen. Projektspezifisch können aber sehr spezielle Aufgaben hinzukommen (zum Beispiel regelmäßiger Export bestimmter Daten-Subsets, bestimmte Datenbereinigungs-Aufgaben, etc.) Mit einer extension kann ich mich direkt in die Optionspalette der Modul-Itemtable einklinken und die benötigte Funktionalität bereitstellen.

08.07.2013 | Noch keine Kommentare

Akira-CMS: Labels

Die gesamte Oberfläche von Akira ist mit Hilfe von Labels beschriftet und damit in verschiedenen Sprachversionen nutzbar.

Alle Elemente sind in Akira englisch bezeichnet (englisches Master-Label-Set). Darüber hinaus gibt es ein Label-Set für eine deutsche Sprachversion. Weitere Label-Sets für andere Sprachen können ergänzt werden. Bei Funktionserweiterungen an Akira werden neue Labels zentral für die verschiedenen Sprachversionen eingerichtet und dann von den einzelnen Installationen importiert.

Auf Basis dieser Label-Sets können website-spezifische Änderungen/Überschreibungen vorgenommen werden. Lauten beispielsweise im Modul „Meldungen“ die deutschen Labels „Titel“, „Kurztext“ und „Haupttext“, so könnten diese Bezeichnungen in einem Projekt in „Titel des Blog-Beitrages“, „Intro“ und „Langfassung“ angepasst werden, um den Nutzergewohnheiten oder Unternehmens-Bezeichnungen zu entsprechen.

CMS-Labels lassen sich aber auch auf öffentlichen Websites nutzen, um für Konsistenz zu sorgen. Im PHP-Quelltext wird durch den Funktionsaufruf getLabel('LABEL_KEY') der entsprechende Inhalt angezeigt. Es ist damit möglich, Feldbezeichnungen – beispielsweise in einem Produktkatalog – im CMS und auf der öffentlichen Website (Suchformulare, Detailseiten etc.) gleich zu halten. Wird dann z.B. eine Bezeichnung „Abmessungen“ in „Abmessungen (Breite, Höhe, Tiefe in cm)“ aktualisiert, so wirkt sich diese Änderung an allen relevanten Stellen aus. Wird ein Kontaktformular sowohl auf der deutschen als auch der englischen Sprachversion einer Website eingesetzt, dann muss am Quelltext des Formularskriptes nichts geändert, sondern einfach das andere Label-Set benutzt werden.

Für die Anzeige von Labels gibt es eine definierte Fallback-Hirarchie:

  1. Anzeige des lokal in der Website definierten Labeltextes
  2. Anzeige des Labels der gewählten Sprachversion (z.B. Deutsch)
  3. Anzeige des Default-Labels (englisch)
  4. Anzeige des Label-Keys, wenn kein Default-Label vorhanden ist.

01.07.2013 | Noch keine Kommentare

Akira-CMS: Datenstruktur

Wie ist ein Projekt aufgebaut? Wo liegt was? Was muss ich transportieren zwischen lokaler Entwicklungsumgebung und Live-System?

Dieser Artikel ist der Erste in einer kleinen Serie von Einblicken in die Ideen hinter Akira.

Kern (Installation)

akira/
-- _cms/
-- _db.[projekt]/

Der CMS-Ordner und der Projekt-Ordner liegen im Dateisystem parallel. Der CMS-Ordner wird im Rahmen von CMS-Updates vom Zentralsystem aus überschrieben. Alle Projektdaten liegen unterhalb des Datenbank-Ordners db.[projekt]

Projektordner (Datenbank)

-- _db.[projekt]/
---- _log/
---- _db.backups/
---- _media/
---- config.php
---- [www.meinprojekt.de]/

Der Projektordner ist einer Datenbank zugeordnet (config) und enthält das Verzeichnis für Protokolldateien (_log), das Verzeichnis für Projekt-Backups (_db.backups) und das Verzeichnis für alle Medien (Bilder, Videos, Audios, sonst. Dateien: _media). Diese Ordner sind von der Website aus nicht zugänglich, da die Domain auf den Website-Ordner [www.meinprojekt.de] zeigt.

Website-Ordner

---- [www.meinprojekt.de]/
------ _templates/
------ _scripts/
------ _configs/
------ _plugins/
------ _widgets/
------ _styles/
------ _images/
------ index.php
------ getmedia.php
------ .htaccess

Im Website-Ordner befinden sich dann alle für die öffentliche Website notwendigen Dateien, wie Templates, Stylesheets, Grafiken für das Layout (Logos, etc.) sowie website-spezifische Skripte und Erweiterungen (_scripts/, _plugins/, _widgets/). Die Darstellung der Website erfolgt ausschließlich über die index.html. Alle sichtbaren Pfade werden virtuell über Akira verwaltet und mittels .htacess weitergeleitet. Die datei getmedia.html sorgt für die Darstellung der Medien, die außerhalb des Website-Pfades liegen und für die Erzeugung unterschiedlicher Bildgrößen im responsiven Design.

Akira-Installation

Innerhalb einer Akira-Installation können verschiedene Datenbanken verwaltet werden:

akira/
-- db.[projekt1]/
-- db.[projekt2]/
-- db.[projekt3]/

Das ist für die lokale Entwicklungsumgebung wichtig, aber auch für den Agentur-Einsatz, wenn mehrere Kundenprojekte auf dem Webserver der Agentur gehostet werden.

Projekt

Innerhalb einer Datenbank können mehrere Websites verwaltet werden:

db.[projekt]/
-- [www.website1.de]/
-- [www.website2.de]/
-- [www.website3.de]/

Das ist angebracht, wenn ein Auftraggeber beispielsweise eine zentrale Unternehmensseite und zusätzlich noch Microsites zu einzelnen Produkten verwaltet. Werden mehrere dieser Websites untereinander als friends definiert, so kann innerhalb von Akira auf Daten aus den jeweils anderen Websites zugegriffen werden (z.B. gemeinsamer Pool von Nutzern, Newsletter-Abonnenten, News, Medien).

Bei der Arbeit zwischen lokaler Version und Live-Website ist im Normalfall nur der Website-Ordner zu übertragen (via FTP) und das entsprechende Datenbank-Backup auf der einen Seite zu erstellen und auf der anderen Seite einzuspielen (via Akira-CMS).

14.06.2013 | Noch keine Kommentare