diff --git a/docs/md/projektkonfig/collections/fields.md b/docs/md/projektkonfig/collections/fields.md
index 2354865..cbc79e3 100644
--- a/docs/md/projektkonfig/collections/fields.md
+++ b/docs/md/projektkonfig/collections/fields.md
@@ -134,3 +134,11 @@ containerProps:
             small: "col-12"
             large: "col-4"
 ```
+
+## inputProps
+
+Wenn man das Input element direkt bearbeiten möchte (Bspw. readonly oder ähnliches), so kann man diese hier als Objekt übergeben:
+
+```yaml
+inputProps: { readonly: true, placeholder: { de: "Wert wird automatisch gesetzt", en: "Value is set automatically" } }
+```
diff --git a/docs/md/projektkonfig/collections/fields/datentypen.md b/docs/md/projektkonfig/collections/fields/datentypen.md
index 5c6ae83..0b41cae 100644
--- a/docs/md/projektkonfig/collections/fields/datentypen.md
+++ b/docs/md/projektkonfig/collections/fields/datentypen.md
@@ -1,6 +1,6 @@
 # Datentypen
 
-Via `type` wird der Datentyp des Feldes definiert. Folgende Datentypen sind möglich:
+Via `type` wird der Datentyp des Feldes definiert. Diese Angaben sind für den Tibi Server relevant. Folgende Datentypen sind möglich:
 
 ## string
 
@@ -41,4 +41,3 @@ Wie `"object"` fasst auch das `"object[]"` Array `subFields` zusammen. Diese all
 ## any
 
 Felder vom Typ `"any"` können beliebige Daten aufnehmen. Die Validierung schlägt auf Basis der Typ-Validierung hier nie fehl.
-
diff --git a/docs/md/projektkonfig/collections/fields/widgets.md b/docs/md/projektkonfig/collections/fields/widgets.md
index 56161e8..be10513 100644
--- a/docs/md/projektkonfig/collections/fields/widgets.md
+++ b/docs/md/projektkonfig/collections/fields/widgets.md
@@ -1,28 +1,22 @@
 # Widgets
 
-Das im *tibi-admin* für die Ein- und Ausgabe von Daten zu verwendente Widget wird über die Feldkonfiguration `meta.widget` festgelegt. Die Angabe erfolgt als String mit dem Widget-Namen.
+Das im _tibi-admin_ für die Ein- und Ausgabe von Daten zu verwendente Widget wird über die Feldkonfiguration `meta.widget` festgelegt. Die Angabe erfolgt als String mit dem Widget-Namen.
 
 Nicht jedes Widget kann mit jedem Datentyp umgehen, die möglichen Datentypen werden aber nachfolgend bei jedem Widget erwähnt. Außerdem wird auf individuelle Konfigurationsmöglichkeiten eingegangen.
 
-## text
+## string / text / input
 
-## number
+## number / int / integer / float / double
 
-## checkbox
+## boolean / bool / check / switch / checkbox
 
-## select
+## select / selectArray
 
-## date
+## date / dateTime
 
-## datetime
+## richtext / html 
 
-## richtext
-
-## file
-
-## image
-
-## selectArray
+## file / image / mediaLibraryFile
 
 ## checkboxArray
 
@@ -30,7 +24,7 @@ Nicht jedes Widget kann mit jedem Datentyp umgehen, die möglichen Datentypen we
 
 ## object
 
-## objectArray
+## objectArray / object[]
 
 ## tabs
 
diff --git a/docs/md/projektkonfig/collections/meta.md b/docs/md/projektkonfig/collections/meta.md
index d9b5487..418fcee 100644
--- a/docs/md/projektkonfig/collections/meta.md
+++ b/docs/md/projektkonfig/collections/meta.md
@@ -1,15 +1,14 @@
 # meta Objekt
 
-Wie bereits an anderer Stelle beschrieben, dient das `meta` Objekt zur Definition von Merkmalen, die im *tibi-admin* finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
+Wie bereits an anderer Stelle beschrieben, dient das `meta` Objekt zur Definition von Merkmalen, die im _tibi-admin_ finden. Zum Anlegen der Struktur in der Datenbank und Definition der API haben diese Angaben keine Relevanz.
 
 Folgende Angaben sind möglich:
 
 !!!include(../api/collections/democol/meta.yml)!!!
 
-
 ## views Liste
 
-`views` werden für die Darstellung der Kollektion-Daten im *tibi-admin* benötigt. Die Auswahl des passenden View erfolgt über CSS Media-Queries.
+`views` werden für die Darstellung der Kollektion-Daten im _tibi-admin_ benötigt. Die Auswahl des passenden View erfolgt über CSS Media-Queries.
 
 Optionale Unternavigationen können eigene `views` haben.
 
@@ -23,6 +22,10 @@ Folgende möglche Einträge für `views` gibt es derzeit:
 
 !!!include(../api/collections/democol/table.yml)!!!
 
+## cardList
+
+TODO
+
 ## tablist
 
 Wird die `tablist` verwendet, ist sicher zu stellen, dass alle Felder in der Definition aufgenommen werden. Werden Felder nicht in die `tablist` aufgenommen, sind diese weiterhin in einer Gesamtliste unterhalb der Tabs und bringen das Layout durcheinander.