Technik, Gothic und Anderes

Technik ist Spiel, Gothic ist ernst und Zeit hat man zuviel

Archiv für 'Web' Kategorie


PHP-UWA Widget Library

Geschrieben von skaldrom am 26. November 2007

Widgets and Web 2.0

Universal Widget ArchitectureWidgets are little miniapplications which show data in a clearly arranged way or perform a more or less simple task for the user. Widgets are present on Windows Vista, Mac, iPhone and also in a webbased form for iGoogle, Yahoo!, Netvibes and many other portals. To give a boost to widget development, Netvibes presented a new framework which shall facilate the coding of widgets. The child is called Universal Widget Architecture. Widgets coded with the help of this framework should work on all the mentioned plattforms.

UWA Standard

A widged, coded with UWA is basically a XML-Dokument. It contains metadata, settings and the active part, written in Javascript. Especially the Preferences are of interest, because they are dynamic and allow widgetspecific settings. There are also some convenience-functions in the UWA-library.

The UWA specification has its own homepage and is very well documented. There are examples, a code-skeleton with explanations, a step-by-step tutorial, a forum and even a cheat-sheet. The start is very easy with such a lot of documentation.

Widget Repository

Finished and released widgets can be made available for the public and published in the Widget Repository (Ecosystem). Widgets ion this website can be added to the different platforms with a single (or double) click). There are some widgets in the repository which are coded in the deprecated Mini-API standard, but these will dissappear soon (hopefully).

Implementations

That sounded fascinating and must have a use somewhere… I will implement some widgets later, I needed to make these widgets usable in our own projects first. So I wrote a little PHP-class which I called pretentious PHP-UWA Widget Library.Handling widged should be easy, using this class. A little bit more ambitious is the handling of widget dependend preferences.

A minimal example is included in the download-package and can also be checked online.

PHP-UWA Widget Library Example

Displaying a widget should be straight forward:

<?php
require_once('uwawidget.php');
$uwawidget=new uwawidget('http://www.netvibes.com/api/uwa/examples/digg.xhtml');
echo $uwawidget->getWidgetHTML();
?>

There are two classmembers which can give more information about the widget:

getMetaData()
Metadaten like author, keywörds, description, … See the docu.
getAdditionalData()
Additional info like icons, stylesheets, …

Basically, there are the following sections for settings:

general
The widgets URL.
configuration
Displayparameters, which described in the docs.
preferences
Widget dependent preferences, also mentioned in the docs

For all these settings, there are the following classmembers:

Setters and Getters
setModuleUrl(), setConfiguration(), setPreferences()
getModuleUrl(), getConfiguration(), getPreferences()
getSettingsFormData($section)
Returns the settings in a friendly array, from which a form can be generated. $section can be “general”, “configuration” or “preferences”
getSettingsHTML($section)
Returns the settings in an array with the format “Label” => “HTML”. $section can be “general”, “configuration” or “preferences”

For a test, I coded a Moodle block, which allows to use UWA Widgets inside the LMS. Heyo, Wordpress, Xoops, etc-Coderz, how about an integration of the Widgets in your system???

Examples from the Moodle block:

Moodle UWA Calculator Moodle UWA Converter Moodle UWA Translator
Moodle UWA Google Notes Moodle UWA Spider Moodle UWA ToDo
The configuration in Moodle:
Widget settings in Moodle

Uh, almost…

…I was almost faster than the german computer magazine c’t which has a short bit good introduction into UWA-Widgets.

Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Learninmanagement Systeme (lms), Web | 6 Komentare »

Drupal mit neuen Google AdSense Werbeblöcken (Serverbasiert)

Geschrieben von admin am 16. November 2007

Neues AdSense


(Affilliate Link :-) ) sind neuerdings Serverbasiert. Das heisst: Aussehen, Inhalt, etc kann grösstenteils von der AdSense-Seite aus gemanaged und muss nicht mehr mühsam von Hand auf jeder Seite eingepflegt, geftpt und gecheckt werden. Das geniale Drupal AdSense Modul beherrscht diese neue Variante leider (noch) nicht von Haus aus. Mit einem kleinen Patch geht das aber.

Vorgehen

  1. Die Datei adsense.module mit diesem Patch so patchen, wie in diesem Beitrag beschrieben.
  2. Auf der Google AdSense Seite AdSense-Setup → Anzeigen Verwalten aufrufen und eine neue Anzeige designen.
  3. Den Code anzeigen lassen und die Slot-Nummer notieren. Es sollte etwas sein wie 2666876213.
  4. In Dupal als Administrator Administer → Site configuration → Google AdSense aufrufen und Custom Channels aufklappen.
  5. Die Slotnummer in einen Channel schreiben.
  6. Diesen Channel beim Block für die Anzeige einsetzen.
  7. Warten… Und sich freuen…
Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Theorie und Schnipsel, Web | Keine Kommentare »

Erstellen eines Timers in Xoops

Geschrieben von skaldrom am 1. November 2007

Xoops ist ein geniales CMS, auch wenn es in letzter Zeit durch administrative Querelen nicht sehr gute Schlagzeilen gemacht hat. Wir benutzen es in einer erweiterten Version als Intranet.

Nun braucht ein Modul plötzlich unendlich lange um sich darzustellen. Das hindert unseren rasanten Arbeitsfluss und darum muss darum korrigiert werden. Statt rumzufrickeln lohnt es sich, die Sache seriös anzugehen.

Xoops bietet eine sehr gute Debugfunktion an: Adminsitration → Systemeinstellungen → Voreinstellungen → Allgemeine Einstellungen → Debug-Modus kann auf PHP-Debug gesetzt werden. Danach werden unten an der Seite viele Infos dargestellt, unter Anderem SQL-Befehle und Timer.

Xoops Debug

Genau solche Timer kann man selber einfach erstellen. Zuerst muss der XoopsLogger eingebunden werden:

include_once(XOOPS_ROOT_PATH . '/class/logger.php');

Um einen Timer zu starten:

$xoopsLogger->startTime( 'absence_count_query' );

Um ihn wieder zu stoppen:

$xoopsLogger->stopTime( 'absence_count_query' );

Diese Timer wird nun - wie oben ersichtlich - wunderschön in die Debugfunktion eingereiht.

Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Theorie und Schnipsel, Web | 1 Kommentar »

Moodle Block Resource-Download

Geschrieben von skaldrom am 22. October 2007

Der Moodle Resource Download Block

Moodle Resource Download Block Auf vielfachen Schülerwunsch hin habe ich einen Block für unser Learning Management System Moodle codiert: Den Resource Download Block. Er erlaubt den Download aller Kursdateien und Verzeichnisse in einem ZIP-Archiv. Dieses Zip-Archiv wird wie im Beitrag Zipdateien on-the-fly erstellen mit PHP dynamisch erstellt, da (in der Theorie) jeder Lernende eine andere Kursansicht haben kann.

Einen Block erstellen ist relativ einfach, wenn man dem Block Howto folgt, aber der Teufel liegt wie immer im Detail.

Configwerte

Jeder Block kann verschiedene Konfigurationswerte erfragen und erhalten. Diese unterscheiden sich aber, ob der Block global (pinned, sticky) ist, in welchem er nur von einem Ort aus konfiguruiert wird oder ob er den individuellen Kursen hinzugefügt wurde, wobei dann jede Instanz ihre eigene Konfiguration hat. Ich habe mich für den zweiten Weg entschieden.

Um die Konfigurationsvariablen mit einem Defaultwert zu versehen, muss man sich in der instance_config_print() Methode darum kümmern:

if (!isset ($this->config)) {
    // ... teacher has not yet configured the block, let's put some default values here to explain things
    $this->config->exclusionregexp= block_downloader_default_exclusionregexp();
    $this->config->compression= block_downloader_default_compression();
    $this->config->maxsize= block_downloader_default_maxsize();
}

Die Datei, die das Zip zusammenstellt ist mehr oder weniger ausserhalb von Moodle, da sie nicht “als Block” erscheinen kann. Um da an die Konfigurationsdaten zu kommen, muss man etwas mehr Aufwand treiben. Sie befinden sich base64 codiert in den Tabellen block_instance respektive blocks_pinned für globale Blocks. courseid und instanceid werden dabei vom Link im Block übergeben.

<?php

/**
 * Create the zip on the fly and push it to the browser.
 */


require_once ('../../config.php');
require_once ($CFG->dirroot . '/blocks/downloader/lib/archive.php');
require_once ($CFG->dirroot . '/blocks/downloader/lib/downloadlib.php');
require_once ($CFG->dirroot . '/lib/filelib.php');
require_once ($CFG->dirroot . '/lib/moodlelib.php');
require_once ($CFG->dirroot . '/blocks/downloader/lib/downloadlib.php');

$courseid= required_param('courseid', PARAM_INT); // Course identification
$instanceid= required_param('instanceid', PARAM_INT); // Instance of the block

// Securitycheck
[SNIP]

// Get Config Data
$where= "pagetype = 'course-view' AND visible = 1 AND id=" . addslashes($instanceid);

// Instance?
$blockarr= get_records_select('block_instance', $where . " AND pageid=" . addslashes($courseid));

// Maybe pinned? In this case we have no courseid
if (!$blockarr) {
    $blockarr= get_records_select('block_pinned', $where);
}

if (!$blockarr) {
    error("cannot find block with: " . $where . " AND pageid=" . addslashes($courseid));
    exit ();
}

// Take the first result
$block= array_pop($blockarr);

$configdata= unserialize(base64_decode($block->configdata));

print_r($configdata);

[...]

Dateien pro Kurs abholen

Das Zusammenstellen aller Pfade für Dateien, die ein Benutzer sieht und auf die er Zugriff hat ist echt mühsam. Ich wünsche mir hier ein Bisschen den Servicegedanken: Beispielsweise würde man viel Zeit sparen, wenn der Entwickler mit dem entsprechenden Wissen Funktionen wie can_read($userid, $resourceid) implementieren würde. Zusätzlich wäre man unabhängig vom verwendeten Absicherungsschema. Ich werde das zukünftig in meinen Programmen berücksichtigen.

Reaktionen

Die Community hat - wie meistens bei Moodle - sehr nett auf die Veröffentlichung reagiert. Zwei Tage nach Version 1.0.0 habe ich schon eine Slovakische Übersetzung und diverse Hinweise auf Bugs erhalten.

Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Theorie und Schnipsel, Web | Keine Kommentare »

Installation von Drupal ohne “CREATE TEMPORARY TABLE” Rechte unter MySQL

Geschrieben von skaldrom am 27. September 2007

Problem

Drupal

Some hosting providers do not grant the MySQL-userright CREATE TEMPORARY TABLES to their customers. Maybe because it’s full moon at the moment and everyone seems a bit crazy. But a href=”http://drupal.org/”>Drupal really wants this right and so a workaround is needed :-(

The error during the installation could be something like this:

user warning: Access denied for user: 'drupal@%' to database 'drupal' query: CREATE
TEMPORARY TABLE missing_nids SELECT n.nid, n.created, n.uid FROM node n LEFT
JOIN node_comment_statistics c ON n.nid = c.nid WHERE c.comment_count IS NULL in
/var/websites/drupal/includes/database.mysql.inc on line 167.

Kind of a Solution

I have written a patch for Drupal 5.2 which should kinda solve the problem. In Drupal, CREATE TEMPORARY TABLES is only used in the db_query_temporary function, found in the file includes/database.mysql.inc, which is a very clean progamming style! Basically, this patch creates a real table instead of a temporary one. The name and the creationdate is stored in an extra table called temporary_table. The cron.php removes these tables on a regular base. If the table already exists, it is dropped.

This patch only works for MySQL and MySQLI and may be a performance loss. I have tested this patch only on a low traffic site and I do not know if there are race conditions. Use it on your own risk…

Addendum

Another solution has been posted at Drupal.org.

Here it is: Patch to use Drupal without the CREATE TEMPORARY TABLES.

To apply it, change into the Drupal base directory and issue patch -p0<drupalwotemptables.patch on the commandline.

Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Web | Keine Kommentare »

CMS? Erschlag mich!

Geschrieben von skaldrom am 24. September 2007

Der Auftrag

desperateIch möchte für die Website www.oncode.info ein schnuggeliges opensource CMS, das mir ermöglicht, meinen abgesonderten Code irgendwie halbwegs schön zu präsentieren und zum Download anzubieten. Als besondere Extremhürde würde ich zusätzlich gerne den RSS-Feed dieses Blogs anzeigen und irgendein schönes Design übernehmen, da ich die Fähigkeit habe, alles hässlich aussehen zu lassen wenn ich es selbst in die Hand nehme. In Java hingegen möcht ichs nicht, da Tomcat mich nicht mag…

Die Ausführung

Das kann doch nicht so schwer sein! hat sichs gedacht, obwohl mans doch besser weiss. Xoops kenne ich schon und mit Typo3 habe ich auch schon Erfahrungen gesammelt, was Neues sollts schon sein irgendwie. Bei opensourcecms kann man verschiedene OSS CMS ausprobieren (genial! Mit Adminfrontend!) und bei cmsmatrix können ebendiese verglichen werden. Es scheinen also auch schon andere arme Kerle mit diesem Problem konfrontiert worden zu sein. Obwohl Joomla! unterschiedlich gute Schlagzeilen macht, hat es auf den ersten Blick doch gut und vielseitig ausgesehen. Nundenn: Fröhlich eingerichtet, ein Template gesucht und installiert. Das erste Template ging nicht, weil es irgendeine %#*(/+ Sublib brauchte. Ich wollte nicht die nächsten 24 Stunden wirklich nicht mit Suchen verbringen und so habe ich wohl oder übel die zweite Wahl eingesetzt. In dieser zweiten Wahl hatte es ein wunderbares Bildchen, das ich natürlich in liebevoller Kleinarbeit angepasst und verschandelt habe. Tja, nach dem ersten mal herumschrauben im Adminpanel ist es dann leider - wohl von sich selbst angewiedert - verschwunden… Nunja, ok. Man kann in ebendiesem Adminpanel RSS-Feed-URLs eintippen: Hab ich gemacht, aber darstellen ist nicht… Nunja. Ich lade dann halt mal ein Modul herunter und installiere es mit dem Installer. Es erscheint, aber nur genügend lange bis ich es konfigurieren konnte. Danach verschwindet es (wohl zum hässlichen Bildchen) und meine Website wird nur noch halb angezeigt, ohne Fehlermeldung, (sogar im Debug-Modus)… Wahrscheinlich die Rache des J’s im Namen des RSS Aggregatormoduls. Das hat mir gereicht: Ich bin zu dumm… Bin ich schon raus oder was?

Auch von PHPWCMS hört man viel Gutes. Dass aber im Titel der Dokumentationsseite eine Art HTML-Tags dargestellt werden, hat mich doch eher abgeschreckt… Nunja, wahrscheinlich ist es ein designerisches Mittel und absichtlich, aber ich hab auch echt keine Nerven dafür das herauszufinden nach dem Joomla!-Debakel… AddOns gibt es leider auch noch nicht viele… PHPWCMS ist wirklich gut und hat sich im Einsatz bewährt, für mich scheints aber nicht zu sein…

Dritter Versuch: e107. Geiler Name, schöne Site, viele Erweiterungen, aber leider ist die Theme-Site nicht erreichbar. Nunja, vielleicht kommt sie ja wieder (nachdem sie sich mit dem hässlichen Bild und dem J-Aggregatormodul genügend unterhalten hat), aber nachdem ich auf der Pluginsite eine Entschuldigung für die lange Downtime gelesen habe, hats mir gereicht. (Ok, ich gebs zu, viel geschlafen habe ich in letzter Zeit nicht, darum bin ich auch nicht so geduldig, aber das ist eine GANZ andere Geschichte :-) ).

Naja, dann suche ich halt mal weiter… Die Verlockung, selber was Kleines zu schreiben wird aber immer grösser…. Das wäre dann wohl das gazillionste CMS…

Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Web | 5 Komentare »

Mediawiki im Intranet: Nur angemeldete Benutzer zulassen

Geschrieben von skaldrom am 18. September 2007

Geschlossenes Mediawiki

restricted Ein Mediawiki im Intranet muss unter Umständen abgeriegelt und ausschliesslich einer geschlossenen Benutzergruppe zugänglich gemacht werden. Wenn man wissen will, welcher Benutzer welche Wikiseite bearbeitet hat, reichen leider die schönen Basic-Authentication Features von Apache nicht aus. Damit Mediawiki alle zur Anmeldung zwingt muss die Datei LocalSettings.php folgendermassen ergänzt werden:
############## Handmade ################
# Specify who can edit: true means only logged in users may edit pages
$wgGroupPermissions['*'    ]['createaccount']   = false;
$wgGroupPermissions['*'    ]['edit']            = false;
$wgGroupPermissions['*'    ]['read']            = false;
$wgGroupPermissions['sysop']['createaccount']   = true;
$wgGroupPermissions['user' ]['edit']            = true;
$wgGroupPermissions['user' ]['read']            = true;

# Logo
$wgLogo                         = "/images/bbbq.gif";

# Pages anonymous (not-logged-in) users may see
$wgWhitelistRead = array ("Spezial:Userlogin", "Wikipedia:Help");

Benutzer

Am Einfachsten ist sicher das Kopieren eines bestehenden Users (eventuell in MySQL). Dabei müssen user_id unduser_name eindeutig sein. Normalerweise braucht es keine weiteren Rechtemanipulationen. Sollen die Benutzer trotzdem gewissen Gruppen zugeteilt werden, gibt die Mediawiki-Dokumentation Auskunft über die Rechte und die Zuteilung zu Gruppen.

Passworte

In Mediawiki 1.10 ist die Passwortverschlüsselung in der Funktion includes/GlobalFunctions.php definiert:

function wfEncryptPassword( $userid, $password ) {
        global $wgPasswordSalt;
        $p = md5( $password);

        if($wgPasswordSalt)
                return md5( "{$userid}-{$p}" );
        else
                return $p;
}

$wgPasswordSalt kann in LocalSettings.php umdefiniert werden, aber normalerweise ist es in includes/DefaultSettings.php auf true gesetzt. $userid ist die user_id aus der Tabelle user.

Das Passwort kann mit php ausgegeben werden (angenommen für user mit id 15):

<?php echo md5('15-'.md5('PASSWORT'))."\n"; ?>

Oder direkt in Mysql:

UPDATE bi_user SET user_password=md5(concat(user_id,'-',md5('PASSWORT'))) WHERE user_id=15;
Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Web | Keine Kommentare »

Mediawiki Update/Upgrade unter Debian

Geschrieben von skaldrom am 18. September 2007

Upgrade von 1.7 auf 1.10

Um die installierte Version zu checken kann folgende Spezialseite aufgerufen werden: http://wiki.yourhost.ch/mediawiki/index.php/Spezial:Version.

Zuerst muss man mal upgraden und das Baby installieren:

apt-get update
apt-get install mediawiki mediawiki1.10

Danach sollte man zu folgenden Dateien kommen:

LocalSettings.php
Ist bei Version 1.7 an einem anderen Ort:

cp /var/lib/mediawiki1.7/LocalSettings.php /etc/mediawiki1.10/

Eventuell muss in der Datei das Verzeichnis angepasst werden.

AdminSettings.php
Hat bei mir noch nicht existiert:

cp /usr/share/doc/mediawiki1.10/examples/AdminSettings.sample /etc/mediawiki1.10/AdminSettings.php

Und danach die Datei editieren und Usernamen/Passwort setzen.

Verzeichnisse: extensions und images
Gibt es bei uns nicht… Sie werden sich aber höchstwahrscheinlich im Verzeichnis /var/lib/mediawiki1.7 befinden und müssen unter Umständen in /var/lib/mediawiki1.10 kopiert werden.

apache.conf
/etc/mediawiki1.7/apache.conf und /etc/mediawiki1.10/apache.conf müssen der lokalen Konfiguration angepasst werden.

Nun muss die Datenbank von der Kommandozeile aus geupdated und Apache neu gestartet werden.

cd /var/lib/mediawiki1.10/maintenance
php5 update.php
/etc/init.d/apache2 reload

Ein Aufrufen der Seite provozierte bei mir den Fehler: failed to open stream: Permission denied in /usr/share/mediawiki1.10/includes/WebStart.php on line 86. Dagegen half folgendes:

chown www-data.www-data /etc/mediawiki1.10/*
chmod a+r /etc/mediawiki1.10/*
Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in Web | Keine Kommentare »

ClickHeat: Klick, zeig Dich, Du bist umzingelt!

Geschrieben von skaldrom am 16. September 2007

Heatmaps

Spannende Methode zur Analyse des Benutzerverhaltens von Websites sind sogenannte Heatmaps. Sie speichern die Koordinaten aller Klicks auf eine Website und stellen sie mit “Hitzepunkten” dar:
Beispiel Heatmap

Crazy Egg

CrazyEgg in ActionEine “kommerzielle” Möglichkeit zum Erstellen solcher Heatmaps ist CrazyEgg. Die Basisvariante ist gratis und reicht eigentlich aus für kleine Websites. Viel Web 2.0-Ajax und eine einfache Bedienungsführung machen es zu einem angenehmen Tool. Es ist möglich verschiedene “Tests” zu fahren mit unterschliedlichem Aufbau der Website und diese Durchgänge dann zu vergleichen.
CrazyEgg hat es voll im Griff die Klicks den richtigen Links zuzuordnen. Keine leichte Aufgabe wenn man bedenkt, dass jeder Besucher mit einer anderen Auflösung ankommt. Zur Auswertung stehen folgende Darstellungen zur Verfügung:

Overlay (Siehe Bild)
Zeigt die Attraktivität der Links in absoluten und relativen Zahlen
List
Eine Liste aller Links mit ihrer Popularität
HeatMap
Eine schöne Heatmap halt…
Confetti
Klicks anzeigen an Hand des Referrers (der Website von welcher die Besucher gekommen sind)

ClickHeat

ClickHeat ist eine freie Implementierung für Heatmaps. Sie kann auf dem eigenen Server betrieben werden und ist somit sehr geeignet für Kontrollfanatiker wie ich einer bin. Die Installation ist denkbar einfach:

  1. Downloaden der Applikation.
  2. Alles an einen Ort auf dem Server entpacken
  3. Im Browser dieses Verzeichnis aufrufen (Beispielsweise http://www.yoursite.com/clickheat/index.php)
  4. Alles korrekt einstellem
  5. Den Javascriptcode im Footer der Webseiten einbinden
  6. Abwarten, Tee trinken, Sackhüpfen und danach wieder das ClickHeat Verzeichnis aufrufen
  7. Sich freuen!

Einige Tips noch dazu:

  • Man kann und sollte die eigenen Klicks ausblenden (erster Menüpunkt im Hauptmenü).
  • Beim Generieren vom Javascript kann angegeben werden, wie die Linkdaten unterschieden werden:
    • Mit Keyword. Hier muss aber auf jeder Seite der Javascriptcode angepasst werden! Hben alle Seiten denselben Footer, werden wild alle Klicks gesammelt, auch wenn jede Seite anders aufgebaut ist.
    • Nach Titel oder Pfad: Damit kann schön nach einzelnen Seiten unterschieden werden.
  • Um zu checken, ob die Datensammlung funktioniert, die Seite mit dem Parameter ?debugclickheat aufrufen. Also beispielsweise http://www.yoursite.com/index.php?debugclickheat. Dies zeigt ein nettes Overlay mit vielen Informationen.
  • Unbedingt das Layout der Site konfigurieren (beim Icon Icon zur Layoutangabe), da er ansonsten die Klickpositionen ein Bisschen durcheinander bringt. Dieses Blog beispielsweise ist Fixed left and right menus, liquid content.

Resultate

Was habe ich für dieses Blog für Erkenntnisse gewonnen?

  1. Die Suche wird benutzt und hat somit ihren prominenten Platz oben rechts verdient.
  2. Es wird ziemlich oft auf das “lead-in” Bild geklickt. Hmmm, was dies zu bedeuten hat muss ich mir noch überlegen. Was erwarten die Besucher wenn sie draufklicken?
  3. Es wird auch auf den kleinen Link skaldrom oberhalb der Beiträge geklickt. Ich habe den Link darum weg von der Homepage (was wohl eher verwirrend war) auf die Schreiberling-Seite umgebogen.
  4. Die Ads scheinen in einem guten Bereich mit vielen Clicks rundherum zu sein.

Weiteres

t-error (error terror?) hat auch über ClickHeat geschrieben. Inspirierend war auch wieder einmal der ProBlogger Beitrag.

Teile und geniesse:
  • Technorati
  • del.icio.us
  • MisterWong
  • Digg
  • StumbleUpon
  • blogmarks
  • Furl
  • Simpy
  • Spurl
  • YahooMyWeb

Eingeordnet in