Checkliste zur Prüfung des Inhaltsmodells #

Diese Seite richtet sich an Entwickler, die ein Inhaltsmodell prüfen, ihr eigenes oder das eines Kollegen. Ein Modell lässt sich auf dem Papier billig ändern und teuer, sobald Inhalte existieren; prüfen Sie es also zweimal: vor dem Bau, mit einem Redakteur und einem Designer im Raum, und vor dem Start. Jeder Punkt hat die Frage, die Sie stellen; die verlinkten Seiten erklären die Antworten.

Inhalt #

1. Wie Sie die Prüfung durchführen
2. Klassen
3. Bezeichner und Namen
4. Datentypen
5. Relationen und Wiederverwendung
6. Der Baum
7. Zugriff
8. Sprachen
9. Redaktioneller Ablauf
10. Darstellung
11. Übertragbarkeit
12. Das Ergebnis festhalten

Wie Sie die Prüfung durchführen #

1. Bringen Sie das Modell so mit, wie es aufgeschrieben ist (Ein Inhaltsmodell entwerfen, Schritt 8): eine Tabelle je Klasse, eine Skizze des Baums, die Rollen.
2. Bringen Sie echte Inhalte mit: drei echte Elemente je Klasse, kein Lorem ipsum.
3. Bitten Sie einen Redakteur, jedes Element mit den vorgegebenen Feldern auf dem Papier "anzulegen", und einen Designer, zu zeigen, wo jedes Feld auf der Seite erscheint.
4. Gehen Sie die Listen unten durch; jedes "Nein" wird entweder behoben oder als akzeptiertes Risiko notiert.

Klassen #

• To do: Steht jede Klasse für eine echte Art von Inhalt? (Keine Klasse, deren Feld "Typ" alles ändert.)
• To do: Sind zwei Klassen, die alle Felder teilen, wirklich verschieden? (Unterscheidet sich nur ihr Ort, legen Sie sie zusammen.)
• To do: Ist jeder Behälter ein Behälter und jedes Blatt keiner?
• To do: Ist das Muster für den Objektnamen aussagekräftig, sodass Namen in Listen und URLs erkennbar sind? (Inhaltsklassen und Attribute)

Bezeichner und Namen #

• To do: Sind Bezeichner kleingeschrieben, englisch und für dieselbe Bedeutung in jeder Klasse gleich (title, intro, image)?
• To do: Haben Projektklassen ein Präfix, wo sie mit den Klassen eines Seitenpakets kollidieren könnten?
• To do: Sind die Anzeigenamen und Beschreibungen für Redakteure geschrieben und übersetzt, wo Redakteure es brauchen?

Datentypen #

• To do: Verwendet jedes Feld den Datentyp, der zu seiner Bedeutung passt (Datumsangaben als Datum, Auswahlen als Auswahllisten oder Tags)?
• To do: Ist langer Text Rich Text und kurzer Text reiner Text?
• To do: Sind erforderlich, durchsuchbar und übersetzbar bei jedem Feld bewusst gesetzt?
• To do: Stammt jeder Erweiterungs-Datentyp aus einer Erweiterung, die auf allen Siteaccesses aktiv ist, die ihn brauchen? (Datentypen wählen)

Relationen und Wiederverwendung #

• To do: Ist alles, was an mehr als einer Stelle verwendet wird, ein eigenes Objekt, auf das eine Relation verweist?
• To do: Ist jeder Verweis nur auf einer Seite gespeichert, wobei die Gegenrichtung über einen Fetch gefunden wird?
• To do: Sind Relationsattribute auf die Klassen eingeschränkt, auf die sie zeigen dürfen, mit einem sinnvollen Standardort?
• To do: Liegen gemeinsam genutzte Bilder in der Medienbibliothek statt kopiert in vielen Feldern? (Relationen und Einbettungen, Bilder und Bildvarianten)

Der Baum #

• To do: Spiegelt der Baum unter der Wurzel die Navigation wider, die Redakteure und Besucher erwarten?
• To do: Ist die Sortierung jedes Behälters festgelegt (Priorität für eine Reihenfolge von Hand, Datum für News)?
• To do: Bleiben große Sammlungen bei der in drei Jahren erwarteten Menge benutzbar (Blättern, Datumsangaben)?
• To do: Werden zweite Platzierungen nur dort verwendet, wo Inhalte wirklich an zwei Stellen hingehören? (Objekte, Knoten und Platzierungen)

Zugriff #

• To do: Ist jede Regel "nur X darf Y sehen oder bearbeiten" als Sektion oder Teilbaum plus Rolle ausgedrückt?
• To do: Ist die Rolle Anonymous noch minimal?
• To do: Sind Stufen jenseits von Entwurf und veröffentlicht als Objektzustände modelliert, nicht als Ordner? (Sektionen, Rollen und Richtlinien)

Sprachen #

• To do: Sind die Sprachen und die Reihenfolge der Ausweichsprachen je Siteaccess entschieden?
• To do: Sind Felder, die sich je Sprache nicht unterscheiden dürfen, nicht übersetzbar?
• To do: Sind gemeinsam genutzte Objekte (Ordner, Medien, Personen) immer verfügbar? (Übersetzungen und Sprachen)

Redaktioneller Ablauf #

• To do: Ist klar, wer jede Klasse anlegt, freigibt und veröffentlicht, und ist das ein Workflow oder eine Gewohnheit?
• To do: Sind datiertes Verbergen und Entfernen dort konfiguriert, wo Inhalte ablaufen?
• To do: Sind die Versionsgrenzen für sehr häufig bearbeitete Klassen richtig? (Workflows und Auslöser, Versionen, Entwürfe und Veröffentlichen)

Darstellung #

• To do: Sind für jede Klasse ihre Ansichtsmodi aufgeführt (full, line, eine Karte, embed)?
• To do: Sind Seiten, die Redakteure aus Blöcken zusammenstellen, benannt, und verwenden sie Layouts statt vieler optionaler Felder?
• To do: Sind Bildvarianten für jede Größe festgelegt, die das Design zeigt? (Ansichtsmodi, Layouts für CMS-Entwickler)

Übertragbarkeit #

• To do: Liegen die Klassen in Paketen im Repository?
• To do: Verweisen Code und Einstellungen auf Bezeichner und Remote-IDs, nicht auf Knoten- oder Objektnummern?
• To do: Tragen importierte Objekte Remote-IDs aus ihrer Quelle? (Inhaltsklassen und Attribute)

Das Ergebnis festhalten #

Schreiben Sie Datum, Prüfer, die vereinbarten Änderungen und die akzeptierten Risiken in das Modelldokument in Ihrem Repository. Prüfen Sie vor dem Start erneut mit der Checkliste für den Projektstart und immer dann, wenn nach dem Start eine neue Klasse hinzukommt.

Verwandte Seiten #

• Das Inhaltsmodell
• Inhalte auf Exponential abbilden
• Inhaltsklassen für Website-Bauer
• Freie Dokumentation: Diese Seite darf unter der GNU FDL 1.3 frei kopiert, übersetzt und verbessert werden.