Inclusives Design: Das „current page“-Problem
bearbeitet von
@pl @marctrix @encoder
Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“ anbietet (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen. Ich nutze das jetzt nicht unbedingt häufig, aber ich denke, dass mir das Fehlen dieses Features öfter mal negativ auffallen würde (zum Beispiel in Foren, siehe unten). Konkret verändert man mit einem Entfernen des Selbstlinks die Funktionalität der entsprechenden Schaltfläche. Sie tut dann nicht mehr das, was sie auf anderen Seiten des Angebots tut und was erwartbar ist.[^erwartung]
[^erwartung]: Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt.
Wenn ich bei `HOME | BLOG | CONTACT` (nur Wörter in Großbuchstaben sollen Links sein) auf `BLOG` klicke und dann `HOME | Blog | CONTACT` im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf `Blog` zu klicken – auf `HOME` oder `CONTACT` klicken, um dann dort direkt wieder auf `BLOG` klicken zu können.
Alternativ müsste ich zur Tastatur greifen und `F5` drücken (umständlich und nicht funktional identisch (!)[^funk]) oder den Refresh-Button in der Toolbar des Browsers betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).
[^funk]: Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“.
Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.
Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler.
---
Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein `aria-current` wie [im verlinkten Artikel](http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum) erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.
---
Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.
Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“ anbietet (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen. Ich nutze das jetzt nicht unbedingt häufig, aber ich denke, dass mir das Fehlen dieses Features öfter mal negativ auffallen würde (zum Beispiel in Foren, siehe unten). Konkret verändert man mit einem Entfernen des Selbstlinks die Funktionalität der entsprechenden Schaltfläche. Sie tut dann nicht mehr das, was sie auf anderen Seiten des Angebots tut und was erwartbar ist.[^erwartung]
[^erwartung]: Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt.
Wenn ich bei `HOME | BLOG | CONTACT` (nur Wörter in Großbuchstaben sollen Links sein) auf `BLOG` klicke und dann `HOME | Blog | CONTACT` im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf `Blog` zu klicken – auf `HOME` oder `CONTACT` klicken, um dann dort direkt wieder auf `BLOG` klicken zu können.
Alternativ müsste ich zur Tastatur greifen und `F5` drücken (umständlich und nicht funktional identisch (!)[^funk]) oder den Refresh-Button in der Toolbar des Browsers betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).
[^funk]: Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“.
Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.
Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler.
---
Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein `aria-current` wie [im verlinkten Artikel](http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum) erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.
---
Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.
Inclusives Design: Das „current page“-Problem
bearbeitet von
@pl @marctrix @encoder
Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“ anbietet (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen. Ich nutze das jetzt nicht unbedingt häufig, aber ich denke, dass mir das Fehlen dieses Features öfter mal negativ auffallen würde (zum Beispiel in Foren, siehe unten). Konkret verändert man mit einem Entfernen des Selbstlinks die Funktionalität der entsprechenden Schaltfläche. Sie tut dann nicht mehr das, was sie auf anderen Seiten des Angebots tut und was erwartbar ist.[^erwartung]
[^erwartung]: Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt.
Wenn ich bei `HOME | BLOG | CONTACT` (nur Wörter in Großbuchstaben sollen Links sein) auf `BLOG` klicke und dann `HOME | Blog | CONTACT` im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf `Blog` zu klicken – auf `HOME` oder `CONTACT` klicken, um dann dort direkt wieder auf `BLOG` klicken zu können.
Alternativ müsste ich zur Tastatur greifen und `F5` drücken (umständlich und nicht funktional identisch (!)[^funk]) oder den Refresh-Button in der Toolbar des Browser betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).
[^funk]: Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“.
Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.
Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler.
---
Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein `aria-current` wie [im verlinkten Artikel](http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum) erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.
---
Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.
Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“ anbietet (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen. Ich nutze das jetzt nicht unbedingt häufig, aber ich denke, dass mir das Fehlen dieses Features öfter mal negativ auffallen würde (zum Beispiel in Foren, siehe unten). Konkret verändert man mit einem Entfernen des Selbstlinks die Funktionalität der entsprechenden Schaltfläche. Sie tut dann nicht mehr das, was sie auf anderen Seiten des Angebots tut und was erwartbar ist.[^erwartung]
[^erwartung]: Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt.
Wenn ich bei `HOME | BLOG | CONTACT` (nur Wörter in Großbuchstaben sollen Links sein) auf `BLOG` klicke und dann `HOME | Blog | CONTACT` im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf `Blog` zu klicken – auf `HOME` oder `CONTACT` klicken, um dann dort direkt wieder auf `BLOG` klicken zu können.
Alternativ müsste ich zur Tastatur greifen und `F5` drücken (umständlich und nicht funktional identisch (!)[^funk]) oder den Refresh-Button in der Toolbar des Browser betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).
[^funk]: Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“.
Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.
Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler.
---
Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein `aria-current` wie [im verlinkten Artikel](http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum) erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.
---
Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.
Inclusives Design: Das „current page“-Problem
bearbeitet von
@pl @marctrix @encoder
Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“lanbieftert (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen. Ich nutze das jetzt nicht unbedingt häufig, aber ich denke, dass mir das Fehlen dieses Features öfter mal negativ auffallen würde (zum Beispiel in Foren). Konkret verändert man mit einem Entfernen des Selbstlinks die Funktionalität der entsprechenden Schaltfläche. Sie tut dann nicht mehr das, was sie auf anderen Seiten des Angebots tut und was erwartbar ist.[^erwartung]
[^erwartung]: Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt.
Wenn ich bei `HOME | BLOG | CONTACT` (nur Wörter in Großbuchstaben sollen Links sein) auf `BLOG` klicke und dann `HOME | Blog | CONTACT` im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf `Blog` zu klicken – auf `HOME` oder `CONTACT` klicken, um dann dort direkt wieder auf `BLOG` klicken zu können.
Alternativ müsste ich zur Tastatur greifen und `F5` drücken (umständlich und nicht funktional identisch (!)[^funk]) oder den Refresh-Button in der Toolbar des Browser betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).
[^funk]: Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“.
Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.
Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler.
---
Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein `aria-current` wie [im verlinkten Artikel](http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum) erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.
---
Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.
Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“
[^erwartung]: Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt.
Wenn ich bei `HOME | BLOG | CONTACT` (nur Wörter in Großbuchstaben sollen Links sein) auf `BLOG` klicke und dann `HOME | Blog | CONTACT` im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf `Blog` zu klicken – auf `HOME` oder `CONTACT` klicken, um dann dort direkt wieder auf `BLOG` klicken zu können.
Alternativ müsste ich zur Tastatur greifen und `F5` drücken (umständlich und nicht funktional identisch (!)[^funk]) oder den Refresh-Button in der Toolbar des Browser betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).
[^funk]: Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“.
Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.
Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler.
---
Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein `aria-current` wie [im verlinkten Artikel](http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum) erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.
---
Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.
Inclusives Design: Das „current page“-Problem
bearbeitet von
@pl @marctrix @encoder
Ich habe den „Deppenlink“ nie als großes Problem begriffen, weil er für mich neutral die Funktionalität „Seite abrufen“ liefert (GET-Request). Da sich Seiteninhalte auch schon mal aktualisieren, kann es Sinn ergeben, auch die aktuelle Seite erneut abzurufen. Ich nutze das jetzt nicht unbedingt häufig, aber ich denke, dass mir das Fehlen dieses Features öfter mal negativ auffallen würde (zum Beispiel in Foren). Konkret verändert man mit einem Entfernen des Selbstlinks die Funktionalität der entsprechenden Schaltfläche. Sie tut dann nicht mehr das, was sie auf anderen Seiten des Angebots tut und was erwartbar ist.[^erwartung]
[^erwartung]: Wobei die Erwartbarkeit natürlich auch dadurch entsteht, was der Ist-Zustand ist. Der sieht nun mal so aus, dass so ziemlich jede große Seite den Selbstlink setzt.
Wenn ich bei `HOME | BLOG | CONTACT` (nur Wörter in Großbuchstaben sollen Links sein) auf `BLOG` klicke und dann `HOME | Blog | CONTACT` im Menü habe und die Blog-Seite aktualisieren möchte, würde ich – nach dem vergeblichen Versuch, auf `Blog` zu klicken – auf `HOME` oder `CONTACT` klicken, um dann dort direkt wieder auf `BLOG` klicken zu können.
Alternativ müsste ich zur Tastatur greifen und `F5` drücken (umständlich und nicht funktional identisch (!)[^funk]) oder den Refresh-Button in der Toolbar des Browser betätigen (wie eben, dazu clientspezifisch und bei mir nach Möglichkeit ausgeblendet) oder die entsprechende Funktion anders mit der Maus auslösen (im Firefox etwa über das Kontextmenü, was natürlich auch umständlich und clientspezifisch und auch nicht funktional identisch ist).
[^funk]: Ein Refresh wiederholt den aktuellen Request. Das kann Seiteneffekte haben, wenn der beispielsweise POST war. Es gibt aber auch bei GET Beispiele, in denen unnötig Parameter erhalten bleiben (UTM-Trackingcodes, gesetzte Filter, #-Sprungziele, …), die man oft loswerden möchte/könnte. „Seite abrufen“ ist jedenfalls nicht das Gleiche wie „Refresh“.
Ein Beispiel aus einem Forum, in dem normalerweise der Threadtitel mit dem Thread verlinkt ist – nur nicht in der Detailansicht des Threads:

Das will ich ständig anklicken, um einen sauberen Link zum Thread zu bekommen (für Verlinkung), weil ich über Suchfunktionen und dergleichen eben oft über einen URL in den Thread komme, der direkt zu einem Post linkt oder dergleichen.
Ich habe zum Glück irgendwann gemerkt, dass das Icon daneben diesen Anwendungsfall abdeckt, weil es selbst verlinkt ist, aber dennoch ist das im Grunde meines Erachtens ein UI-Fehler.
---
Was speziell Screenreader oder andere Assistenztechnologien angeht: Wenn es keine Semantik dafür gibt (kein `aria-current` wie [im verlinkten Artikel](http://www.heydonworks.com/article/the-accessible-current-page-link-conundrum) erwähnt), dann sollte man meines Erachtens nicht einfach irgendwas machen, sondern abwarten. Es ist ja auch nicht so, dass die Nutzer nicht wüssten, wie man sonst Seiten bedient.
---
Die Idee, ein #-Sprungziel statt eines reinen Selbstlinks zu setzen, halte ich auch nicht für gut, weil es unerwartet ist und weil es mir die URLs versaut, falls ich die Seite verlinken möchte.