Ich habe ein bisschen Einrad-Theorie zusammen geschrieben. Es dreht sich um das Thema Structuring Unicycling Skills. Lasst euch nicht von der Länge abschrecken, der Artikel ist dennoch in 10-20 Minuten lesbar.
Gebt mir bitte Feedback zu meinem neuen Vorschlag oder wie ihr die Sache beurteilt. Siehe auch hier.
Vielen Dank.
Also gleich vorneweg, da ich von Freestyle keine Ahnung habe verstehe ich auch das mit den Transitions nicht so wirklich 
Ansonsten gefällt mir als Softwareentwickler der objektorientierte Ansatz schon recht gut. Der große Vorteil den ich da auch sehe ist, dass neue Tricks ohne Probleme eingefügt werden können. Außerdem geht das Einfügen der viel schneller und einfacher, weil man die Grundlagenbeschreibungen ja schon in den “geerbten” Elementen hat. Somit muss man für neue Tricks nur mehr eine spezialisierte Beschreibung verfassen. Gerade aber auch wenn Tricks aus möglichst vielen unterschiedlichen Gruppen gezeigt werden sollen macht so eine Einteilung schon auch Sinn, wegen den Beschreibungen die du ja auch angeführt hast, dass manche Tricks einer Gruppe zugeordnet sind obwohl sie eindeutig in mehrere Gruppen passen.
Anstelle von “structs” würde ich vorschlagen die übliche Bezeichnung “tags” zu verwenden (z.B. bekannt von Google Mail :)). Hier sind die tags halt noch hierarchisch organisiert.
Über die Vorteile von Tags vs. eine Ordnerstruktur kann man lange diskutieren, das hat aber nichts speziell mit Einradfahren zu tun. 
Wenn Du z.B. eine geordnete Liste von Tricks ausdrucken möchtest dann kannst Du das nicht einfach anhand der Tags machen (siehe z.B. die standard skills Liste). Für eine Webpage machen tags dagegen viel Sinn.
Zum 20-seitigen Text würde ich anmerken: In der Kürze liegt die Würze.
Na ich weiß ja nicht, ob das an meinen mangelnden Englischkenntnissen liegt, aber
1.) ich fand’s ganz schön lang für das bisschen Aussage, das bei mir hängen geblieben ist: Es gibt keine Systematisierung über Einradtricks, die allen Disziplinen gerecht wird und alle vernachlässigen die Trickübergänge. Außerdem ist die Einordnung gewisser Tricks in all dieses Listen problematisch.
Wenn das die wirklich die ganze Aussage ist, kann man das wie grade gezeigt deutlich verkürzen.
2.) ich hab den Sinn dieser Arbeit nicht ganz verstanden.
Wenn’s als Orientierung für Trainer und Trainierende ist, reicht`s doch, wenn man diesen mitteilt, welche Übersichten es bisher alle schon gibt und man ggf. bei den bestehenden noch ein paar Tricks und Übergänge ergänzt.
Das Problem, dass man gewisse Tricks nicht genau einordnen kann, find ich auch nicht so verherend. Wenn einer einbeinig mit Sattel vorn fahren lernen will, kommt er doch bestimmt auf die Idee, wenn er ihn bei Sattel-vorn-Tricks nicht findet auch noch bei Einbeinig-Tricks nach zu sehen.
Ich hoffe, das war jetzt nicht zu harte Kritik… :o
Erstmal vielen Dank für eure Antworten, ich werde darauf nun Bezug nehmen:
@Nico: Definitiv waren Tags mein Vorbild 
Allerdings sind Tags wie du selbst sagst im Internet zu Hause und haben im Sport nichts zu suchen, dort bennent man es anders. Im Turnen nennt man es z.B. Strukturgruppen (ein furchtbar langes Wort und so überhaupt nicht schön), woran sich auch mein Name ‘Structs’ orientiert, ähnlich kurz, genauso sexy und prägnant, lässt sich also gut vermarkten und ist somit gut für jeden Einprägsam. Ich habe den Structs auch eine Hierarchie verpasst und darüber hinaus sogar noch einen abstract Fall verordnet.
Eine verschlagwortete Struktur ist einfach gut effizient. Mag auf den ersten Blick chaotisch Aussehen, ist aber genau das Gegenteil. Ich sortiere damit meine Bookmarks, siehe hier: http://delicious.com/gossi 106 Bookmarks, die ich mit 1-2 Klicks eingrenzen kann. Bei einer Ordnerstruktur müsste ich jedesmal noch Überlegen, welches denn der Topordner dazu wäre, hält also auf. Dadurch ist es auch möglich sich gezielt Listen (anhand eines oder mehrere Structs) anzeigen. Die Standard-Skill List ist hier definitiv ein Spezialfall, deren Ordnung auf eine manuell gepflegte Liste zurück geht, die wird mit keinem anderen Ordnungssystem automatisiert anzeigbar gemacht werden können.
Ich behaupte: Vielleicht ein bisschen. Und dennoch, hätte ich irgendwo etwas ausgelassen, würden hier viel mehr andere Fragen stehen, als dass ihr hier wirklich nur auf das System antwortet. Z.B. welche Items gilt es zu ordnen, welche anderen Systeme gibt es? Wie kommst du zu der Aussage? All diese konnte ich eliminieren und noch einige weitere (Die Länge kommt eigtl. nur durch die elends lange Auflistung der Skills in den Systemen und das “drumrum” (Inhaltsverzeichnis, Quellen, etc.), sonst wäre das ganze nur halb so lang.) Im übrigen bemühe ich mich darum, mit meinen Aussagen mehr wissenschaftlichen Charakter in den Sport zu bekommen, ob ihr das wollt oder nicht - ätsch!
Die Übersichten habe ich ja dargestellt und keine davon für optimal empfunden
Warum es dennoch wichtig ist für Einradfahrer (und dadurch abgeleitet für Trainer, denn die sind ja für die Ausbildung die Leitfigur) hat einen sportlichen Hintergrund: Einradfahrer sollten während des Trainings (über mehrere Jahre hinweg) eine große Range an Bewegungen kennen lernen um Ihre Bewegungserfahrung zu steigern. Je größer diese ist, umso einfach kann man die Differenzierungsfähigkeit (eine Koordinative Fähigkeit) einsetzen um neue Tricks zu lernen, das geht dann wesentlich schneller. Um also die Range zu kennen, gibt es eben diese Systeme, die die verschiedenen Bewegungen beschreiben und die entsprechenden Skills darin sortieren.
Aaaaah, nein du musst verstehen ich hüpf bei dieser Aussage gerade im Dreieck! Das ist einfach unnötig umständlich, ich erklärs warum, hier die Schritte um dahinzukommen:
Der zweite Punkt: Erklär das mal nem Kind, was vollkommen recht hat, wenn es sagt, das gehört in beide Structs. Jüngere Kinder verfügen noch nicht über die nötigen kognitiven Verbindungen zu verstehen, warum manche Erwachsene das in nur eine Kategorie gepackt haben.
Ich muss die aber für deine Aussage danken, es ist genau der Grund, warum ich mich mit dem Thema beschäftigt habe
Keinesfalls, liebend gerne angenommen
@From the Woods: Danke für deine Aussage, bestätigt mich, dass ich auf dem richtigen Weg bin
Im Moment frage ich mich noch, wo im System Lücken sind. Angenommen ihr habt einen neuen Trick entwickelt. Wie fügt ihr den hinzu? Euer Trick passt in keine der vorhanden Structs, wie dann? Macht doch bitte mal ein paar Vorschläge.
Vielen Dank
gossi
Ein schönes Beispiel nach dem auch immer wieder mal gefragt wird sind Unispins, also besser gesagt Tutorials dafür. Dadurch, dass ein Trick mehrere Vorgänger hat, wird sofort ersichtlich was man üben kann/soll/muss damit man den eigentlichen Trick schneller lernt. So könnten in besagtem Fall des Unispins als zugeordnete Structs der No-Footer und 180° Jumpount (also drehen des Unis um 180° während man drauf springt) schon viele Fragen im voraus klären. Wenn ich jetzt nicht weiß was der 180° Jumpmount ist gehe ich einfach eine Stufe hinauf. Dann merke ich vielleicht ich kann die Voraussetzung dafür, den normalen Jumpmount, noch nicht usw. usw.
So ein System gibt also relativ schnell und einfach Auskunft darüber was ich tun kann, um das Erlernen eines Tricks einfacher zu gestalten, indem ich zuerst einzeln die Voraussetzungen lerne.
Auch da muss ich gossi zustimmen. Im worst-case muss man nämlich ganz schön viel Kategorien unnötig durchsuchen bis man zum gewünschten Ergebnis kommt. Ich persönlich bin bei solchen Sachen auch immer etwas perfektionistisch und es stört mich einfach einen Trick fix irgendwo zuzuordnen wo er doch genausogut woanders hingehören kann.
EDIT:
Jetzt habe ich doch glatt noch was vergessen. Ich kenne jetzt die aktuellen Regeln für Flat und Street zwar nicht wirklich, aber eine Einteilung mittels der structs könnte auch da bei Bewerben mehr Vielfalt an Tricks bringen. Wenn man da nämlich einige Tricks als Basis definiert zB. Rolls, Unispins, Crankflips, Unispin+Crankflip Kombination, dann könnte man auch sagen, dass es mehr Punkte gibt wenn man aus möglichst vielen Kategorien Tricks zeigt. Kommt eine Kategorie extrem oft vor gibt es weniger Punkte. Das ist jetzt nur mal eine Grundidee die ich mal so in den Raum werfe - mir ist sehrwohl klar, dass dadurch das Judging komplizierter werden würde, aber eben auch womöglich einheitlicher. Eine Aufteilung mit den structs macht da dann eben diese Zuordnung leichter und logisch nachvollziehbar.
Das hat weniger etwas mit den Structs zu tun. Ein Trick ist an mehrere Structs gebunden. Wenn ich den Trick Hickflip habe, ist er an Unispin und Crankflip gebunden. Über die Structs kann ich die Abhängigkeiten nicht herstellen. Das Trixionary kann das schon: Siehe unispin dort: einradfahren.de (Deine genannten Abhängigkeiten sind nicht eingepflegt, solltest du mal nachholen ;-).
Dein Problem sind die Ebenen: Wir haben structs > trick. Das sind zwei paar Schuhe. Durch das Binden von Tricks an Structs wird aber eine Verknüpfung hergestellt. Die Abhängigkeiten laufen zwischen Tricks, das heißt dort sind die Structs ohne Bedeutung. (Da du ja Software Entwickler bist: Stells dir mal als relationale Datenbank vor, dann wirds dir glaube ich schnell klar :-)).
Was deine Bemerkungen zum Judging System angeht: Goldrichtig! Auf Basis der Neuformulierungen durch die Structs kann man hier klarere Aussagen treffen.
Nur damit meine Fragen nicht vergessen bleiben, hänge ich sie jetzt an jeden Post an, bis ich Antwort bekomme (:p):
Im Moment frage ich mich noch, wo im System Lücken sind. Angenommen ihr habt einen neuen Trick entwickelt. Wie fügt ihr den hinzu? Euer Trick passt in keine der vorhanden Structs, wie dann? Macht doch bitte mal ein paar Vorschläge.
Wie ich dir schon vor ca. 2 Wochen per Mail geschrieben hatte (und wo du mir widersprochen hast), sehe ich die Structs als Attributierung von Skills, was von der Sache her durchaus Sinn macht.
Ich persönlich würde zusätzlich einen gerichteten Graphen daraus machen im Sinne, von Trick x hängt von Trick y und Trick z ab. Man muß sich nun überlegen, ob man Ringschlüsse zulassen will oder nicht. Es ist durchaus denkbar, daß es zwei Tricks x und y gibt, die man beide lernen kann, ohne den jeweils anderen vorher zu können, daß es aber beim Erlernen von Trick x hilft, wenn man bereits Trick y kann, und umgekehrt hilft es zum Lernen von y, wenn man x kann.
Er sollte - ausgestattet mit den entsprechenden Attributen und Verknüpfungen zu anderen Tricks - einfach eingefügt werden. Um hier individuelle Fehlinterpretationen einzelner Personen zu vermeiden sollte das Attributieren und Verknüpfen ein Prozeß sein, der einen Validierungsprozeß durchläuft, entweder über die gesamte Community, oder über ein Kommitee.
Dann kreiert man eben einen neuen Tag. Auch das sollte eine Validierung durchlaufen und ggf. einen Review nach einer gewissen Zeit (z.B. wenn weitere ähnliche Tricks auftauchen).
So, jetzt steh ich auf der Leitung. Ich habe mir jetzt noch einmal das PDF durchgelesen und bin draufgekommen, dass ich da vermutlich was nicht genau gelesen und es deshalb anders interpretiert habe (oder irgendwer von uns hat einen Denkfehler 
). Mit der Datenbank kann ich es deshalb auch weniger in Verbindung bringen, weil das ganze für mich mehr nach Klassen ausschaut
Ich habe es so verstanden, dass die structs schon “Tricks” an sich sind, wobei als Trick einfach nur eine Technik verstanden werden darf (nach dieser Auslegung bräuchte man auch keine abstrakten structs mehr).
So wäre zB “Riding” schon eine eigene Technik mit Beschreibung. Dann gibt es den “Circle”, dem dann “Riding” zugeordnet wird. Dann gibt es irgendwo einen “1ft Circle” dem dann eben “1ft riding” und “Circle” zugeordnet wird. Bin ich da schon irgendwie auf dem falschen Weg bzw. auf einem anderen als von dir gedachten Weg?
Im folgenden gehe ich also von meiner Auffassung aus weiter:
Wenn ich in dieses System dann einen neuen Trick einfügen möchte, dann schaue ich zuerst ob es schon einen Trick/eine Technik gibt, die eine Grundvoraussetzung darstellt. Will ich zB “1ft riding” einfügen ist “Riding” eindeutig eine Vorbedingung.
Wenn ich mir das aber so durchdenke fällt mir aber auf, dass es sehr komplex wird und doch auch nicht so einfach ist neue Tricks einzufügen, weil der neu eingefügte Trick ja auch noch als Vorgänger für andere Tricks fungieren kann. Man müsste also beim Einfügen eines neuen Tricks bei allen schon vorhandenen überprüfen, ob er ein Vorgäner ist.
Was mir auch noch auffällt ist, dass eine klare Trennung zwischen Transition und zugeordnetem struct notwendig ist. Für “Circle” ist zum Beispiel “Riding” und “Mount” zwingend notwendig, für “Wheel Walk” ist “Riding” aber nicht notwendig, weil man direkt mit “Wheel Walk” mounten kann.
Nein, Structs sind Kategorien von Tricks, also z.B. alles was mit 1ft zu tun hat. Da fällt dann z.B. einbeinig fahren rein, aber auch einbeinig pendeln oder einbeinig Wheelwalking. Natürlich gibt es für einige dieser Kategorien so eine Art “Mutter aller Tricks”. Z.B. Wheelwalken vorwärts fahren ist sicherlich der Urvater (man beachte die spontane Geschlechtsumwandlung in der Terminologie) für alle Tricks, die das Attribut Riding haben. Trotzdem ist Vorwärts fahren “nur” ein Trick innerhalb der Kategorie Riding und nicht der Übergeordnete Trick für alle anderen Tricks bei denen man sich vorwärtsbewegt.
Das kommt jetzt drauf an. Muß man für Vorwärtsfahren wirklich vorher aufsteigen? Oder darf ich mich auch an einem Laternenmast festhalten und von da aus losfahren?
Wenn man die Transitions als Bestandteil des Tricks definiert, kommt es auch wieder darauf an, was die Ausgangslage ist. Mit den Füßen auf dem Boden stehen und das Einrad in der Hand halten, oder vorwärtsfahren, oder etwas ganz anderes?
Ah, gut jetzt versteh’ ich es richtig, denke ich.
Gut, dann ist halt der “Mount” für “Circle” auch eher als Transition zu sehen, aber “Riding” ist zwingend eine Vorbedinung, weil kann ich nicht fahren kann ich auch nicht im Kreis fahren 
. Das ändert aber grundsätzlich nichts an der Problematik. Offensichtlicher wird das Problem vielleicht beim Fall Wheel Walk als Vorbedinung zum Gliding. Die meisten werden sagen, man soll Wheel Walk vor dem gliden lernen, aber in Wahrheit ist es ja auch nur eine Transition, weil ich muss nicht zwingend Wheel walken können um aus der Geschwindigkeit heraus einen Fuß auf die Gabel und den anderen auf das Rad zu stellen.
Streicht einfach das Wort “Wheelwalken”. Das war einTipfehler. Ich wollte zuerst ein ww-Beispiel nehmen, habs mir dann aber doch anders überlegt und offenbar vergessen, dieses eine Wort zu löschen.
[B]Seh ich genauso! Man müsste dann noch unterscheiden zwischen “muss man vorher können” und “ist hilfreich zum erlernen dieses Tricks”.
Aber da haben wir auch schon wieder das nächste Problem!
Gibt es wirklich Tricks, die man zwigend vor anderen können muss?[/B]
Intuitiv würde man sicher sagen, bevor man anfängt mit Sattel vor dem Körper zu fahren, muss man erstmal fahren können.
Ich erinnere mich aber zum Beispiel an eine Situation in der ein kleines Mädchen (mit gutem Gleichgewicht und total übermotiviert) Einradfahren lernen wollte, aber auf die zur Verfügung stehenden 20"-Einräder partout nicht drauf passte. Nachdem in sie ein paar Tage lang immer wieder auf die Einräder hab schielen sehen, hab ich sie irgendwann gefragt, ob sie lieber mit Sattel vorne raus fahren oder wheel walk lernen möchte. Leider waren die Ferien zuende bevor sie es konnte, aber ich bin mir sicher, sie hätte es mit etwas mehr Zeit noch gelernt!
Und auf der anderen Seite: "Ist es nicht in jedem Fall von Vorteil, möglichst viele verschiedene Tricks vorher zu können?"
Wäre es nicht auch günstig vor wheel walk einbeinig wheel walk oder stand up zu können? Mit Sicherheit lernt man unter diesen Vorraussetzungen ganz schnell wheel walk, wenn man ihn noch nicht kann!
Also die Idee mit den Vorbedinungen als Lerntipps kann man sozusagen eigentlich schon wieder vergessen, weil es viel zu komplex werden würde und trotzdem nicht eindeutig ist.
Also bleibt übrig, dass man die structs definiert und diese dann einzelnen Tricks zuweist. Eine Aussage darüber was man wie, wann lernen sollte kann man somit nicht mehr treffen. Ich weiß jetzt auch gar nicht ob gossi sich das überhaupt so gedacht hat, oder ob das ohnehin nur ich hineininterpretiert habe
Die Schwierigkeit, die ich jetzt dabei aber noch sehe ist, was man überhaupt als structs definieren sollte. Es hat auch irgendwie keinen Sinn structs anderen structs zuzuweisen, weil man damit wieder das Problem bekommt, dass Vorbedingungen ja nicht uneingeschränkt und einfach zugewiesen werden können.
Structs müssten also die oberste Ebene bilden, möglichst allgemein sein und dürfen nicht mehr abstrakt sein. Direkt darunter liegen dann schon die Tricks, die einfach mehrere structs zugewiesen bekommen können. Die Aussage lasse ich jetzt einfach einmal so stehen.
EDIT: Ich hab’ mir das jetzt gerade kurz überlegt und mir fällt eine Unterscheidung zwischen Trick und struct ordentlich schwer, weil ein struct ja eigentlich immer schon ein Trick ist.
Nein, niemals 
Trickabhängigkeiten sind ein anderes Thema, zwar sehr spannend, aber gehört hier nicht rein, stellt die Diskussion darüber bitte ein, wir können aber gerne einen zweiten Thread hierzu aufmachen
Hmm, im Moment kann man dazu noch vieles sagen, du sagst attribuieren, ich habe das englische assign benutzt. Ich bin mit keinem der Wörter zufrieden, nicht für die Finale Version. Beim Tag-Beispiel oben, sagt man ich habe getaggt. Aber ich habe gestructed klingt beömmelt. Nein, hier muss noch ein Wort erfunden werden, was auch jeder gerne benutzen mag.
Ihr müsst die ganze Sache etwas atomarer sehen. Drag Seat fahren ist eine Einheit. Sattel fallen lassen, ist eine Einheit. Sattel aufheben, ist eine Einheit. Mounts sind spezielle Transitions, von Non-Unicyclists nach Unicyclists (siehe Glossar). Natürlich kannst du ein Wheel-Walk Struct dem 1ft Wheel Walk zuordnen, ohne dass du darin irgendwie mountest. Das wäre ja wieder ein eigener Trick. Wheel-Walk Mount, hätte also auch zwei Structs zugeordnet (Wheel Walk + Mount).
Nein, Kategorien sind es nicht 
Denn die haben eine vorbelastete Definition und haben sich nach meiner Analyse als nichtig dargestellt. Ich würde eher den Terminus Organisationseinheit (sowohl für Struct als auch Kategorie) verwenden. Ja, ein Struct besagt, dass alle zugeordneten Tricks ein bestimmtes Schema aufweisen. Z.B. Der Struct “1ft” hat als Definition, dass Einrad wird mit dem Fuß nur auf einer Pedale angetrieben. Beim WW-Struct: Das Einrad wird mit den Füßen auf dem Einrad angetrieben, usw.
Das Klassen Beispiel, was ich noch loswerden wollte:
<?php
// structs
$unispins = new Struct('Unispins');
$crankflips = new Struct('Crankflips');
...
// tricks
$180u = new Trick('180 Unispin');
$hickflip = new Trick('Hickflip');
$backflip = new Trick('Backflip');
...
$180u->assign($unispins);
$hickflip->assign($unispins);
$hickflip->assign($crankflips);
$backflip->assign($crankflips);
$unispins->getTricks(); // 180 Unispin, Hickflip
$crankflips->getTricks(); // Hickflip, Backflip
?>
Erster Absatz: Ja, wie ich im Dokument schon erwähnt habe, steht das an, nachdem genau gesagt ist, wie dieses System funktioniert. Wenn das System nen Namen hat, dann ist das damit abgeschlossen und wir können erste Structs sammeln und definieren. Die im englischen Forum interessieren sich nicht so sehr dafür, wie die Deutschen, dazu wirds dann einen weiteren Thread geben.
Zweiter Absatz: Ja, das kann sein, dass die abgebildete Hierarchie in den Structs und auch die abstrakten Structs den Umstand zu Komplex machen, geht es nun hier zu diskutieren, aber erstmal musst du den Unterschied zwischen Struct und Trick kapieren
Das ist in beiden Ansätzen sehr viel Bürokratie drinne, mir eindeutig zu viel, als Endlösung könnte ich mir das vorstellen, wenn wir hier nichts besseres finden. Da muss es doch etwas einfacheres geben!
Nein, ein Struct ist kein Trick, siehe oben.
Ich weiß jetzt aber auch, wieso ich immer struct und Trick vermische. Bei den Beispielen hast du ja schon 1ft und WheelWalk als struct genannt. Das sind aber schon Tricks. Oder willst du unterm Wheel Walk struct noch einen Wheel Walk Trick machen? Das betrifft nämlich so ziemlich alle Beispiel die du angeführt hast. In meinen Augen muss ein struct gleichzeitig auch ein Trick sein, nur eben ein Basistrick.
Nein, siehe das Code Beispiel. Obwohl ich dir beipflichte, dass das verwirrend ist, wenn Struct und Trick den gleichen Namen haben. Ist bisher aber auch schon so auf dem Freestyle Judging Sheet und ich habe mich daran schon gewöhnt, auch viele Judges und Trainer haben das. Wenn hier eine Änderung gewollt ist, muss das dabei beachtet werden. Evtl. einfach ein s anhängen (englischer Plural).
Sehr gut, endlich verstanden… dann kann ich ja jetzt wieder zu meiner Ursprungsaussage zurückkehren, dass ich die Idee gut finde
Beim Einfügen eines neuen Tricks müssen also nur die entsprechenden structs zugeordnet werden. Allerdings muss auch bei jedem Trick überlegt werden, ob er nicht zusätzliche neue structs rechtfertigt.
Was die Transitions betrifft, wird aber vermutlich so ziemlich jedem Trick dieses struct zugewiesen werden können. Kann man’s da nicht gleich weglassen? Man kann ja auch nicht erkennen zwischen welchen Tricks diese Transition praktikabel ist (man kann es sich natürlich meistens denken, aber schöner ist es halt wenn man es direkt ablesen kann).
Bevor man so ein System detailliert, sollte man sich auch darüber Gedanken machen, wofür genau es denn verwendet werden soll:
Ja, aber einen Versuch ist es doch Wert?! Es gleich zu lassen, weil es wahrscheinlich scheitert ist bei einem Unternehmen vermutlich besser aber bei so etwas ist es mMn der falsche Weg.