Robots Exclusion Standard: Ein Test

Für einen Test muss ich hier mal zwei (Sub-)Domains verlinken. Über diese Links werden die beiden Domains dann von den Search Engine Crawlern gefunden. Da bei beiden Domains die robots.txt unterschiedlich gesetzt ist, sollte nur eine der beiden Domains in den Index aufgenommen werden.

Warum dieser Test? Ein Bekannter hat mal beobachtet, wie seine Site trotz robots.txt im Google Index gelandet ist. Hiermit wollen wir jetzt prüfen, ob dies an Fehlern in der robots.txt lag oder ob sich nicht alle Crawler an den Robots Exclusion Standard halten. Dieser ist nur eine Empfehlung.

• http://robots-allow.smilinginthesun.de/
• http://robots-disallow.smilinginthesun.de/

Ergebnisse

Wie den Screenshots zu entnehmen ist, wurden beide URLs in den Google-Suchindex aufgenommen. Auch wenn bei der Disallow-Variante zwar keine weiteren Informationen ausgewertet wurden, so ist die URL doch im Index. Will man eine Domain also nicht öffentlich sichtbar machen, sollte sie auch nirgendwo verlinkt sein.

Auch eine Suche nach z.B. "robots disallow smiling the sun" liefert dieses Ergebnis - es liegt also nicht daran, dass die genaue URL bekannt ist.


Zu beachten ist, dass dieser Test mit zwei Sub-Domains einer registrierten Domain durchgeführt wurde. Ob dies Einfluss auf die Aufnahme in den Index hat, kann ich nicht sagen.

Usability-Tests mit Kindern durchführen 1: Die Einleitung

Bei Kindern zwischen 3 und 12 Jahren, sind die verschiedenen Fertigkeiten sehr unterschiedlich weit entwickelt. 

Dies betrifft nicht nur die Fähigkeiten beim Umgang mit dem Computer, sondern auch die Aufnahmefähigkeit und das Verständnis dafür, gestellte Aufgaben gezielt umzusetzen. Nicht zuletzt ist beim Auswerten der Ergebnisse zu bedenken, dass die Kritikfähigkeit und -bereitschaft sich von der erwachsener Menschen und auch innerhalb dieser Altersspanne sehr stark unterscheidet. 

Aus diesen und weiteren Gründen ist es daher unbedingt erforderlich, dass man bei Usability-Tests mit Kindern auf diese Eigenschaften und Bedingungen gezielt eingeht. Nur so kann ein erfolgreiches Gelingen und verwertbare Ergebnise sichergestellt werden. 

In den folgenden Beiträgen gehe ich auf diese Feinheiten ein. In diesem Beitrag beschäftigen wir uns zunächst mit der Einleitung der Tests:

Das System wird getestet, nicht das Kind

Wie auch bei Tests mit Erwachsenen ist es besonders wichtig zu verdeutlichen, dass das System getestet wird und nicht das Kind. Das Kind darf gerne Fehler machen - ja es hilft sogar, wenn es Fehler macht, denn die anderen Kinder, die später das Produkt verwenden werden, werden auch Fehler machen. Daher ist es wichtig zu testen, wie sich das Produkt dabei verhält.

Es muss klar gestellt werden, dass die Meinung des Probanden zum Produkt und ihre Mithilfe gefragt sind. Es geht nicht darum die Leistung des Kindes zu messen oder gar zu beurteilen.

Wenn die Kinder nicht weiterkommen, liegt es in der Regel an dem Produkt und nicht an dem Kind.

Sollten die Eltern nach der Einleitung im Testraum bleiben wollen, sollten sie nach Möglichkeit außerhalb des Sichtfeldes platziert werden. Außerdem schon vor der Session instruieren, dass sie keine Hilfestellungen geben dürfen und ihr Kind nicht ablenken sollen.

Hilfestellung

Da Kinder in der Regel mehr Hilfestellung erwarten, als erwachsene Probanden, muss vor dem Test erklärt werden, dass das Kind die Aufgaben selbstständig durchlaufen soll. Gibt es im späteren Verlauf doch viele Fragen, sollte mit Gegenfragen reagiert werden. "Was meinst Du?"

Usability-Tests mit Kindern vorbereiten

Ein Usability-Test sollte gründlich vorbereitet werden. Dies gilt natürlich auch insbesondere für Tests, die man mit Kindern durchführt.


Folgende Punkte empfehlen die Autoren von "Guidelines for Usability Testing with Children":

• Das Testlabor sollte kinderfreundlich eingerichtet werden, um etwas vom "offiziellen Charakter" zu verlieren. ZB. ein paar Poster an der Wand. Eine Spielecke wäre aber zu viel des Guten und würde eher ablenken.
• Vorschulkinder sollten das gleiche Eingabegerät benutzen können, wie es dies von zu Hause gewohnt ist: Maus vs. Trackball, 1 vs. 2 Button. Die Geschwindigkeit des Mauszeigers sollte auf das Minimum reduziert werden.
• Die Laborausrüstung (Kameras, Mikrophone, etc.) müssen zwar effektiv eingesetzt werden (damit man zB. die Mimik des Kindes gut erkennen kann), sollten aber so unauffällig wie möglich platziert werden. Die Kamera sollte nie direkt vor dem Probanden platziert sein.
• Maximale Dauer eines Tests: eine Stunde, Vorschulkinder: eine halbe Stunde (hier zusätzliche Zeit für freies Spielen und Exploration einplanen).
• Die Pausen zwischen zwei Probanden sollten größer eingeplant werden als gewohnt, da die Zusammenarbeit mit Kindern für den Testleiter anstrengender ist als mit Erwachsenen.
• Wie immer gilt, dass die Reihenfolge der Tasks zwischen den Probanden variieren sollte. Dies ist hier besonders wichtig, da Kinder schneller ermüden und unkonzentrierter werden, als Erwachsene.
• Es sollten immer Kinder für Tests ausgewählt werden, die bereits mindesten ein halbes Jahr Erfahrungen im Umgang mit Computern haben...
• ... allerdings sollten Kinder mit überdurchschnittlichen Erfahrungen (Programmieren, Webseiten bauen) vermieden werden (wenn dies nicht explizit die Zielgruppe ist).
• Kinder von Kollegen und die eigenen sollten nicht als Probanden eingeladen werden: Erstens sind ihnen Terminologien aus dem Produkt, der Branche bekannt und zweitens haben sie eine andere Einstellung zu dem Produkt, wenn ein Elternteil es mit entwickelt hat. Diese Faktoren verfälschen das Ergebnis.

Usability Tests mit Kindern: Altersklassen

Hanna, Risden und Alexander unterteilen in Ihrem Artikel "Guidelines for Usability Testing with Children" die Kinder in drei verschiedene Alterklassen ein:

• Vorschule (2 bis 5 Jahre)
• Grundschule (6 bis 10 Jahre)
• 'Mittelschule' (11 bis 14 Jahre)

Kinder unter 2 1/2 Jahren können noch nicht gut genug mit den Eingabegeräten, wie Maus und Trackball umgehen.

Kinder über 14 Jahren können beim Testen wie Erwachsene behandelt werden.

Vorschule (2 bis 5 Jahre)

Für diese Altersklasse sind die aufwendigsten Anpassungen notwendig:

• Aufmerksamkeitsspanne gering
• Motivation, Erwachsene zufrieden zu stellen, nicht gegeben
• Wohlbefinden in fremder Umgebung mit fremden Leuten kann augenblicklich umschlagen
• nur exploratives Testen möglich, keine Aufgabenstellungen
• Problem im Labor: Vorschulkinder können Methode des Lauten Denkens nicht umsetzen. Daher ist es besonders wichtig per Kamera auf die Reaktionen (Gesicht und Körper) des Kindes zu achten. Allerdings sollte die Kamera (in keinem Testfall) direkt vor den Probanden gestellt werden.

Grundschule (6 bis 10 Jahre)

Für diese Altersgruppe ist es schon relativ leicht, altersgerechte Usability-Tests durchzuführen:

• Ruhig sitzen und Bearbeiten von Aufgaben bereits in der Schule erlernt.
• Kinder können Anweisungen von Erwachsenen folgen.
• Probanden sind sich nicht unmittelbar bewusst, dass sie beobachtet werden.
• Je jünger, desto schüchterner; je älter, desto eher bereit, die Software auch zu kritisieren.

Mittelschule (11 bis 14 Jahre)

Diese Altersgruppe ist natürlich am leichtesten zu integrieren:

• i.d.R. geübt in Computerbedienung 
• fremde Erwachsene sind keine Hürde
• in der Lage, Aufgaben zu erledigen und dies auch gerne zu tun (beachten, dass eine erste Phase der freien Exploration gegeben werden sollte)
• Auf der einen Seite funktioniert Lautes Denken bei älteren Kindern
• auf der anderen Seite können sie aber auch gehemmt sein, da ihnen bewusst ist, dass sie sich in einer Testsituation befinden und beobachtet werden.

Welche Konsequenzen sich aus den unterschiedlichen Verhaltensweisen für die Vorbereitung und Umsetzung von Usability Tests ergeben, wird im folgenden Artikel beschrieben.

MSSQL SSAS: MeasureGroups kombinieren

Ich baue zur Zeit ein Data Warehouse mit MSSQL Server 2008 auf.
Dabei bin ich aktuell beim Designen eines Cubes in den SSAS auf folgende Meldung gestoßen:

Warning 1 Cube [MyCube] : The 'M One' and 'M Two' measure groups have the same dimensionality and granularity. Consider unifying them to improve performance.

Best Practices for Data Warehousing with SQL Server 2008 auf MSDN Microsoft sagt hierzu folgendes:

Seriously consider the best practice advice offered by AMO [Analysis Management Objects] warnings

Gesagt, getan:

1. Named Query erstellen: SELECT mOne.key, mOne.value AS value1, mTwo.value AS value2 FROM mOne JOIN mTwo ON mOne.key = mTwo.key (in meinem Fall sind die Keys in beiden Tabellen identisch)
2. In der DataSource-View Schlüssel-Beziehungen bei der Named Query genau so wie bei den Tabellen mONE, bzw. mTWO setzen.
3. Im Cube-Designer unter Measures per Rechtsklick die neue MeasureGroup hinzufügen.
4. Speichern, bauen, Meldung weg, Performance optimiert!