Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- meshcore:allgemeines:regions:definieren [05.02.2026 16:05] – josch0
+++ meshcore:allgemeines:regions:definieren [08.02.2026 14:11] (aktuell) – josch0
@@ Zeile 24: / Zeile 24: @@
   * [[cli|Repeater Konfiguration]]
   * [[scopes-nutzen|Scopes in Companions nutzen]]
+===== Wie benennt man Regions am besten? =====
+Bei der Benennung von Regions muss der Fokus zu 100% auf dem Nutzer ohne MeshCore- und Community-Erfahrung liegen, damit dieser bei der Auswahl des Scopes intuitiv den Richtigen findet und auswählen kann. Wenn der Nutzer die Scopes nicht versteht, oder auf Grund eines schlecht gewählten Scopes eine schlechte Nutzererfahrung macht, wird er zukünftig vermutlich auf die Nutzung von Scopes komplett verzichten, weil "geht ja eh nicht".
+Die Diskussionen die bisher in den Communities zu Regions stattgefunden haben, tendieren eher dazu, Benennungen nach technischen Aspekten (Länge) auszuwählen, was zu mehrdeutigen oder nicht nachvollziehbaren Abkürzungen führt. In der Runde der Entscheider mögen die Namen nachvollziehbar sein, für Außenstehende vermutlich aber nicht. Dies muss vermieden werden, um bei den Nutzern eine breite Akzeptanz für Scopes herzustellen.
+Folgende Punkte sollten bei der Benennung von Regions beachtet werden:
+  * Namen möglichst sprechend wählen, mehrdeutige oder unbekannte Abkürzungen vermeiden (__westerwald__ vs. __ww__, __rhein-main-gebiet__ vs. __rmg__)
+  * Für definierte Gebiete besser den bereits etablierten Namen nutzen, als eigene Namen erfinden (__rhein-main-gebiet__ vs. __frankfurter-umland__)
+  * Keine Hierarchien einbauen, die faktisch nicht existieren (__de-rp-westerwald__ ist falsch, da der Westerwald HE, RP und NW umfasst)
+  * Da regionale Regions eine begrenzte Reichweite und im besten Fall eindeutigen Namen haben, braucht es keinen de-Präfix (__de-westerwald__ ist unnötig, __westerwald__ reicht)
+:!: Grundsätzlich muss der Name der Region nicht hierarchisch aufgebaut sein. Es ist auch kontraproduktiv, die __de-xx-...__ Hierarchie fortzuführen. \\
+Beispiel: __de-by-ofr-er__ statt __erlangen__
+  * Der Informationsgehalt steckt bei der Abkürzung nur in den letzten beiden Buchstaben (er). Die ersten 10 (!!) Buchstaben sind redundant und verschenkter Platz
+  * Die Abkürzung ist LÄNGER, als der ausgeschriebene Namen
+  * Die Hierarchie im Namen braucht es nicht, sie bringt keinerlei Vorteile.
+  * __erlangen__ ist für sich alleine eindeutig und klar verständlich
+\\
+|< 100% 50% 50% >|
+^ Beispiel 1: Abgekürzt ^ Beispiel 2: Sprechend ^
+| {{ :meshcore:allgemeines:regions:folie11.jpg }} | {{ :meshcore:allgemeines:regions:folie12.jpg }} |
+| **:-) VORTEILE:** \\ - Abkürzungen sparen (vermeintlich) Platz in der begrenzten Übertragung (160 Zeichen) der Regions \\ - Abkürzungen folgen der __de__ und __de-bl__ Schematik  | **:-) VORTEILE:** \\ - Namen sind sprechend und nachvollziehbar \\ - Es gibt bei aktuellem Schnitt der Regions nach Empfehlung dieser Seite vermutlich nur eine handvoll Regions pro Repeater, die sich ohne Probleme mit 160 Zeichen übertragen lassen \\ - Keine Verwechslungsgefahr wie bei Abkürzungen \\ - Das Schema __de__ -> __de.bl__ muss nicht fortgesetzt werden, ebenso braucht es keine fixen weiteren Hierarchie-Ebenen unterhalb __de-bl__ |
+| **:-( NACHTEILE:** \\ - Für den Nutzer ist die Bedeutung der Abkürzungen kaum nachvollziehbar \\ - Bei sehr kurze Abkürzungen kann es häufiger Duplikate mit unterschiedlichen Bedeutungen geben \\ - Bei langen Abkürzungsketten steckt der Informationsgehalt nur in den letzten Zeichen, der größte Teil ist redundant und unnötig (Bsp.: __de-by-ofr-er__ -> er für Erlangen) \\ - Lange Abkürzungen sind ggf. länger als ausgeschrieben (Bsp.: __de-by-ofr-er__ vs __erlangen__) | **:-( NACHTEILE:** \\ - Etwas längere Namen |
 ===== Wie schneidet man Regions am besten? =====
@@ Zeile 92: / Zeile 119: @@
 ^ Regions mit festen Grenzen ^ Regions die überlappen ^
 | {{ :meshcore:allgemeines:regions:folie9b.jpg }} | {{ :meshcore:allgemeines:regions:folie10b.jpg }} |
-| Die Landesgrenzen zwischen DE und RP sind klar definiert und sollten nicht aufgeweicht werden. ABER: "Grenzrepeater" mit Reichweite in beide Gebiete, sollten auch beide Regions konfiguriert haben. | Frei definierte Regions können nach belieben überlappen. Das kann sogar von Vorteil sein, weil damit eben eine starre Zuordnung zu einer oder der anderen Region entfällt. Es muss aber deutlich ersichtlich sein, dass solche Überlappungen existieren, um diesen Vorteil sinnvoll auszunutzen. |
+| :-) Die Landesgrenzen zwischen DE und RP sind klar definiert und sollten nicht aufgeweicht werden. \\ ABER: "Grenzrepeater" mit Reichweite in beide Gebiete, sollten auch beide Regions konfiguriert haben. | :-) Frei definierte Regions können nach belieben überlappen. Das kann sogar von Vorteil sein, weil damit eben eine starre Zuordnung zu einer oder der anderen Region entfällt. Es muss aber deutlich ersichtlich sein, dass solche Überlappungen existieren, um diesen Vorteil sinnvoll auszunutzen. |
-===== Wie benennt man Regions am besten? =====
-Bei der Benennung von Regions muss der Fokus zu 100% auf dem Nutzer ohne MeshCore- und Community-Erfahrung liegen, damit dieser bei der Auswahl des Scopes intuitiv den Richtigen findet und auswählen kann. Wenn der Nutzer die Scopes nicht versteht, oder auf Grund eines schlecht gewählten Scopes eine schlechte Nutzererfahrung macht, wird er zukünftig vermutlich auf die Nutzung von Scopes komplett verzichten, weil "geht ja eh nicht".
-Die Diskussionen die bisher in den Communities zu Regions stattgefunden haben, tendieren eher dazu, Benennungen nach technischen Aspekten (Länge) auszuwählen, was zu mehrdeutigen oder nicht nachvollziehbaren Abkürzungen führt. In der Runde der Entscheider mögen die Namen nachvollziehbar sein, für Außenstehende vermutlich aber nicht. Dies muss vermieden werden, um bei den Nutzern eine breite Akzeptanz für Scopes herzustellen.
-Folgende Punkte sollten bei der Benennung von Regions beachtet werden:
-  * Namen möglichst sprechend wählen, mehrdeutige oder unbekannte Abkürzungen vermeiden (__westerwald__ vs. __ww__, __rhein-main-gebiet__ vs. __rmg__)
-  * Für definierte Gebiete besser den bereits etablierten Namen nutzen, als eigene Namen erfinden (__rhein-main-gebiet__ vs. __frankfurter-umland__)
-  * Keine Hierarchien einbauen, die faktisch nicht existieren (__de-rp-westerwald__ ist falsch, da der Westerwald HE, RP und NW umfasst)
-  * Da regionale Regions eine begrenzte Reichweite und im besten Fall eindeutigen Namen haben, braucht es keinen de-Präfix (__de-westerwald__ ist unnötig, __westerwald__ reicht)
-\\
-|< 100% 50% 50% >|
-^ Beispiel 1: Abgekürzt ^ Beispiel 2: Sprechend ^
-| {{ :meshcore:allgemeines:regions:folie11.jpg }} | {{ :meshcore:allgemeines:regions:folie12.jpg }} |
-| **:-) VORTEILE:** \\ - Abkürzungen sparen Platz in der begrenzten Übertragung (160 Zeichen) der Regions \\ - Abkürzungen folgen der __de__ und __de-bl__ Schematik  | **:-) VORTEILE:** \\ - Namen sind sprechend und nachvollziehbar \\ - Es gibt bei aktuellem Schnitt der Regions nach Empfehlung dieser Seite vermutlich nur eine handvoll Regions pro Repeater, die sich ohne Probleme mit 160 Zeichen übertragen lassen \\ - Keine Verwechslungsgefahr wie bei Abkürzungen \\ - Das Schema __de__ -> __de.bl__ muss nicht fortgesetzt werden, ebenso braucht es keine fixen weiteren Hierarchie-Ebenen unterhalb __de-bl__ |
-| **:-( NACHTEILE:** \\ - Für den Nutzer ist die Bedeutung der Abkürzungen kaum nachvollziehbar \\ - Bei sehr kurze Abkürzungen kann es häufiger Duplikate mit unterschiedlichen Bedeutungen geben | **:-( NACHTEILE:** \\ - Etwas längere Namen |
 ===== Was sind private Regions? Was ist die Home-Region? =====

MeshCore Wiki DE

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Unterschiede

Seiten-Werkzeuge