Wie du ja weißt, bin ich sehr interessiert an kleine Anwendungen mit dem UniPro-Baukasten-Einzelteilen.
Hierzu bin ich gerade dabei, einen Katalog zu erstellen, welcher mal alle Einzelteile beinhalten soll, so dass die Homefaber möglich schnell und übersichtlich ihre Bauteile zusammensuchen können.
Einen ersten kleinen Entwurf mit wenigen Teilen habe ich schon mal gemacht.
Was ich nun noch tun möchte ist es, eine Systematik zu finden, welche es auch für dich erlaubt, neue Teile hinzufügen zu können, ohne dir nennenswert größeren Aufwand zu erzeugen.
Des Weiteren möchte ich zu den Teilen auch noch den Direktlink zu den CAD-Dateien der Einzelteile einfügen, so dass sich der Nutzer die CAD-Datei runterladen und sofort loslegen kann.
Dann soll es natürlich auch noch einen Katalog aus Kontruktionen wie einem Regal oder (m)einem Handtuchhalter geben, auch da wieder mit Direktlink zur CAD-Datei sowie einer semantischen Bau Anleitung bei einfachen Kontrukten und einer ausführlicheren Anleitung mit Bild und Video bei komplexeren Konstrukten sowie einer Teileliste der dafür benötigten Teile und nach Möglichkeit noch mögliche Bezugsquellen evt. aufgeschlüsselt nach Regionen.
Perspektifisch würde ich noch etwas einbauen, bei dem Nutzer auch ihre Konstrukte hochladen und Anleitungen erstellen oder vielleicht einfach nur eine regionale Handelsstelle für UniPro-Bauteile sein und sich in die Liste eintragen lassen wollen.
Wenn ich einen entsprechenden Entwurf erstellt habe, würde ich dies dann gern bei kokonsum.org mal vorstellen wollen, denn ich denke, dass gerade sowas zu einer Shareconomy sehr gut passt.
zony ist aktuell dabei mal ein Regal und Handtuchhalter im FreeCAD zu konstruieren.
Genau über sowas in der Art, sprich, einen „browse-ablen“ Katalog der die Bauteile auch visualisiert, hatte ich mir seinerzeit schon den Kopf zerbrochen, aber dann die Sache nicht mehr weiter verfolgt weil ich gemerkt hab, das das Ganze nicht so trivial ist und es mir zu dem Zeitpunkt wichtiger war überhaupt endlich mal mit ein paar Bauteilen aus dem Quark zu kommen. Aber eigentlich ist das (also eine Art visueller Navigationsmöglichkeit) schon wichtig, insbesondere später, wenns mal mehr Teile werden und - das ist ja die Idee der Systematik - auch von anderen Usern Sets und Teile definiert werden damit ein großer Pool entsteht, weil Namensgebung und Einordnung nicht immer eindeutig sein können und man so eine visuelle Hilfe hat um schnell rauszufinden ob das benötigte Teil bereits im Pool vorhanden ist.
Was ich nun noch tun möchte ist es, eine Systematik zu finden, welche es auch für dich erlaubt, neue Teile hinzufügen zu können, ohne dir nennenswert größeren Aufwand zu erzeugen.
Auch das ist sehr willkommen und wird dringend benötigt, nämlich spätestens dann, wenn die ersten Konstruktionsbeispiele erstellt werden, damit man im Zuge der jeweiligen Bauanleitung mindestens eine Stückliste mit angeben kann.
Ich halte diesen Entwurf für einigermaßen brauchbar, insbesondere, weil er einen ausreichend großen und flexiblen Adressierungs-Raum beinhaltet um später eine große Anzahl an Bauteilen und Bauteile-Gruppen mit Unterkategorien möglichst sinnvoll und gut navigierbar darin unterbringen zu können.
Das einzige was daran nicht so schön ist, das ist, das die Nummernrelativ lang sind, aber kürzere Nummern sind m.E. nicht ohne deutliche Verluste an Flexibilität und Leistungsfähigkeit des Systems möglich.
Die Debatte zeigt glaub ich, das das Thema nicht ganz trivial ist, aber ich bin inzwischen soweit, das mir alles recht ist was irgendwie einigermaßen praktikabel ist.
Des Weiteren möchte ich zu den Teilen auch noch den Direktlink zu den CAD-Dateien der Einzelteile einfügen, so dass sich der Nutzer die CAD-Datei runterladen und sofort loslegen kann.
Jau, macht Sinn. Ich glaube ich hab auch noch nicht die Sketchup-Dateien zum Basis-Set hochgeladen, die müssten da noh mit rein, hab ich aber hier bei mir aufm Rechner liegen.
Dann soll es natürlich auch noch einen Katalog aus Kontruktionen wie einem Regal oder (m)einem Handtuchhalter geben, auch da wieder mit Direktlink zur CAD-Datei sowie einer semantischen Bau Anleitung bei einfachen Kontrukten und einer ausführlicheren Anleitung mit Bild und Video bei komplexeren Konstrukten sowie einer Teileliste der dafür benötigten Teile und nach Möglichkeit noch mögliche Bezugsquellen evt. aufgeschlüsselt nach Regionen.
Dieses, d.h. vollständige Bauanleitungen von Konstrukten mit Stückliste, etwas Text, Bildern und ev. noch Video, ist m.E. das Wichtigste überhaupt, was dem System schliesslich zum Durchbruch verhelfen könnte. Die meisten Leute können sich unter dem Baukasten selbst irgendwie nix vorstellen bzw. nicht die Tragweite der Möglichkeiten darin erkennen, aber sobald etwa Konkretes da ist, was jemand ev. gerne haben oder nachbauen wollen würde, da ist die Sache dann klar.
Und vermutlich geht den Leuten dann auch auf, das sie selbst damit ganz wundervolle Dinge der verschiedensten Art erstellen können.
Perspektifisch würde ich noch etwas einbauen, bei dem Nutzer auch ihre Konstrukte hochladen und Anleitungen erstellen
Ja, sehr gut! Sowas kann man vielleicht mit Templates oder besser noch Eingabemasken für Kurzbeschreibung, Langbeschreibung, Bilder usw. in eine gleichmässig strukturierte Form bringen, das wäre mittelfristig schon sinnvoll.
oder vielleicht einfach nur eine regionale Handelsstelle für UniPro-Bauteile sein und sich in die Liste eintragen lassen wollen.
Ich finde vor allem wichtig, das Leute sich als Hersteller und Anbieter eines oder mehrer bestimmter Bauteile positionieren und nicht nur als reine Händler, sonst hast Du womöglich am Ende 25 Leute, die damit handeln und Kohle machen wollen, aber nur 3, die auch tatsächlich Teile herstellen. Aber abgesehen davon sollte als fester Bestandteil der Daten zu jedem Bauteil natürlich eine Liste mit Links auf Bezgsquellen vorhanden sein und ob sich hinter so einem Link nun ein Hesteller oder ein „reiner“ Händler (oder beides) befindet ist aus Sicht des Nutzers vermutlich eh egal.
Wenn ich einen entsprechenden Entwurf erstellt habe, würde ich dies dann gern bei kokonsum.org mal vorstellen wollen, denn ich denke, dass gerade sowas zu einer Shareconomy sehr gut passt.
Ja, das finde ich auch. Und gerade in diesem speziellen Fall macht es m.E. besonders viel Sinn, da es halt mit einem gewissen Aufwand verbunden ist, auch nur ein einziges Teil in größeren Mengen und guter Qualität herzustellen, also z.B. Erstellung eines dafür geeigneten speziellen Bohrautomaten, da ist es doch gut, wenn sich ein einzelner oder eine Gruppe auf ein oder ein paar bestimmte Bauteile spezialisiert und eine andere Gruppe wieder auf andere Bauteile und man sich untereinander austauschen kann. Sowas, also verteilte, dezentrale Strukturen sind m.E. ein wichtiges Merkmal von OpenSource/Hardware und auch OpenSourceEconomy.
zony ist aktuell dabei mal ein Regal und Handtuchhalter im FreeCAD zu konstruieren.
Ah, sehr gut, es geht voran !
Ich hab gestern auch mal angefangen mich etwas ausführlicher mit FreeCAD auseinanderzusetzen, aber hab mir dabei noch ziemlich einen abgebrochen, das ist halt nicht so ganz easy fürn Quereinsteiger. Aber ich denke, der Aufwand lohnt sich und langfristig wird FreeCAD m.E. das Mittel der Wahl sein um Konstruktionspläne in halbwegs professioneller Qualität erstellen zu können. Sketchup ist halt gut für nen Schnellschuss, um insbesondere am Anfang überhaupt erst mal was aufs Papier zu bringen. Ich denke mal, im Endeffekt muss man zweigleisig fahren, da die Verwendung des einen oder des anderen Tools letztlich von den derzeitigen Fähigkeiten des jeweiligen Anwenders abhängt. Jedenfalls hoffe ich meine FreeCAD-Fähigkeiten im Laufe der Zeit noch etwas verbessern zu können
Was mir nämlich noch zu den Bauteilen dringend fehlt bzw. wichtig erscheint, das sind einigermaßen brauchbare und professionelle (d.h., normgerechte) Konstruktionszeichnungen, welche mindestens eine 2D-Darstellung in 3 Ansichten samt Bemaßung enthalten, wie etwa dieses von Bastelmike erstellte Beispiel:
oder optional auch noch ein 3D-Darstellung mit beinhalten können, wie etwa dieses Beispiel aus der FreeCAD-Gallerie (ok, da fehlen noch die Bemaßungen und es ist ein Sreenshot):
Aber das bezieht sich vor allem auf die Bauteile selbst, wobei aber natürlich nichts dagegen spricht, bei Konstrukten ein ähnliches Niveau anzustreben, aber da sehe ichs eher als „kann“ denn als „muss“ (wie bei den Bauteilen selbst).
Was hältst du davon?
Alles sehr gut, Thumbs up !!!
Gruss, Oliver
PS: Bezügl. Regal, ich habe jetzt eben schnell noch im Basis-Set Holz eine Ergänzung eingefügt die mir schon seit längerem vorschwebt und zwar ein Kantholz mit 32x32mm Querschnitt und Lochreihen, sowas ist m.E. ideal für Regale. (Oder übrigens auch ein geeignetes Teil für Nikolays Kniestuhl.) Ist aber bislang erstmal nur eine reine Definition ich hab noch keine Zeichnungen dazu. Aber damit könnte sich Zony zumindest schonmal an den Abmessungen orientieren.
hab mal die Systematik noch ein wenig einfacher gestaltet, damit Hanschen Müller dies auch kapiert. Sollte sich später herausstellen, dass dies nicht ausreichend sein sollte, dann kann man es ja wieder weiter aufbohren.
Ich denke damit sollten wir es versuchen und der Adressraum bietet mit 26 x 26 x 999 = 675324 möglichen Bauteil-Kategorien, die wiederum in 9999 Parametervariationen unterteilt werden können m.E. auch eine ordentliche Größe und Flexibilität.
Nur eine Kleinigkeit würde ich ev. ändern:
Du scheinst bei der Nummernvergabe einem Ansatz zu folgen, den ich auch ursprünglich mal angestrebt hatte, nämlich dem von „sprechenden“ Artikelnummern.
D.h., die 20, 40 und 60er Länge wird in der Endnummer mit abgebildet. Das hat zwar einen gewissen Reiz und theoretisch könnte man zumindest solange noch reichlich Platz im Nummernspace ist auch erst mal versuchen solche sprechenden Nummern zu bilden, aber ich vermute mal, das sobald die Sache komplexer wird, etwa weil ein Bauteil mehrere variable Parameter aufweist, wird sich das nicht mehr durchhalten lassen.
Daher würde ich empfehlen, die Bauteile einfach stumpf laufend durchznummerieren, so wie sie halt gerade reinkommen bzw. sich das aus der chronologischen Entwicklungsgeschichte einfach ergibt. D.h., im vorliegenden Beispiel, einfach als Endnummern 0001, 0002 und 0003. Damit hätten zumindest Teile, die zur selben Zeit definiert wurden, einen zusammenhängenden Nummernbereich. Würde später noch was ergänzt gibts natürlich Brüche, aber das ist dann eben so.
Auch vermute ich, das eine chronologische Nummernvergabe sich später einfacher realisieren lässt, wenn man aufgrund steigernder Bauteileanzahlen die Nummern nicht mehr manuell generieren kann, sondern darauf angewiesen sein wird, durch ein kleines Progrämmchen dafür zu sorgen, dass nur eindeutige Nummern (die noch nicht vorhanden sind) vergeben werden.
Normalerweise geschieht das durch eine Datenbankfunktion bei Erstellung eines neuen Datensatzes mehr oder weniger automatisch. Was mich zu der Frage bringt: Hattest Du in Richtung Datenbank schon etwas angedacht ?
Eine Datenbank habe ich noch nicht im Blick.
Eigentlich dachte ich mir, dies übers Wiki zu machen und eine Teileliste aufzubauen.
Je nach Anzahl der Teile kann man dies dann ja auch in verschiedenen Unterseiten organisieren.
Zudem würde ich ein Script so schreiben, dass es alle Teile aus den Wikiseiten zieht und eine Gültigkeitsprüfung macht, dann die Liste als API über JSON oder .csv zur Verfügung stellt, falls jemand einen solchen Teilekatalog für seine Seite braucht.
Teilenummern, welche ungültig sind, werden dann vom Script als Fehlermeldung gemeldet und die nächst gültige Nummer angegeben.
Des Weiteren sollten wir auf jeden Fall schauen, dass wir keinesfalls abertausende an verschiedenen Teilen erst haben und die Stückliste möglichst klein halten, denn sonst verpuffen die vorteiligen Effekte.
Sollte Jemand dennoch zwischenmaße benötigen bzw. die Absrufungen an Längen usw. nicht ausreichend sein, so müsste man evt. darüber nachdenken, dass man den Katalog in Standardteile und Spezialteile unterteilt und den Anwender bzw. Konstrukteur darauf hinweist, dass er nur in Ausnahmefällen Spezialteile verwenden sollte.
Was mir gerade eingefallen ist, wäre z.B. ein Scoring einzuführen, anhand dessen man erkennen kann, wie hoch der „Standardisierungsfaktor“ ist. D.h. wenn Jemand ein Regal aus T-Slot-Profilen konstruiert, erhält jedes darin verwendete Teil einen Punkt.
Verwendet man in einem Regal eine T-Slot-Länge 640mm z.B. 8x so erhält dieses Teil 8 Punkte.
Nun konstruiert Jemand einen Handtuchhalter und er verwendet ebenfalls T-Slot-Länge 640mm, so erhält dieses Teil einen weiteren Punkt je Verwendung.
Dies führt dann dazu, dass jedes Teil eine Score in Höhe der Verwendung erhält und jedes Konstrukt ebenfalls eine Gesamtsumme aller Einzelteilscores erhält, welche dann durch die Anzahl der Teile geteilt wird und dann eine durchschnittliche Score ergibt.
Dadurch würden sich vermutlich von selbst Spezialteile herauskristalisieren und Standardteile bevorzugt, u.a. weil dann der Anwender die Vorteile des unkomplizierten Tauschens und Weiterverwendung auskosten kann.
Gleichzeitig würde es auch eine gewisse Wertigkeit eines Einzelteils ergeben und möglichen Herstellern privat wie gewerblich einen gewissen Anhaltspunkt geben, welche Teile man mehr oder weniger herstellen oder auf Lager halten könnte.
Zu den Teilenummern bzw. der Durchnummerierung, hier gebe ich dir recht, dies könnte später problematisch werden.
Andererseits bin ich ein Freund von aussagekräftigen Nummern.
Denkbare wäre, dass man einfach eine weitere 4er-Reihe getrennt mit Bindestrich hinten dran hängt (optional) und zu jeder Reihe eine Parmeterinfo angibt (d.h. Länge, Breite, Höhe, Radius, Windungen, uvm.)
Denkbar wäre auch, dass man l für length oder w für width, h für height, usw. vorn vor die Zahlenreihe anstellt, wenn dies einen Parameter direkt abbildet.
Ferner sei noch zu bedenken, dass es später vielleicht auch Maßerungen unterhalb eines Milimeters gibt, hier könnte man dann eben ml oder mw oder mh oder µh voranstellen.
Also mir wäre es wichtig, dass man es lesen kann, weil ich denke, dass dies vor allem auch beim Zusammenbau von Konstrukten wichtig werden könnte, man so die Teile besser und schneller zuordnen könnte. Andernfalls müsste man dann stets in Listen blättern um zu wissen, welches Teil dies ist.
OK, denn mach das man so bzw. mit der Technologie, die Dir am angenehmsten ist. Ich halte eine DB langfristig für die beste Lösung, aber im Moment brauchen wir die noch nicht zwingend.
Je nach Anzahl der Teile kann man dies dann ja auch in verschiedenen Unterseiten organisieren.
Ja, seh ich auch so.
Zudem würde ich ein Script so schreiben, dass es alle Teile aus den Wikiseiten zieht und eine Gültigkeitsprüfung macht, dann die Liste als API über JSON oder .csv zur Verfügung stellt, falls jemand einen solchen Teilekatalog für seine Seite braucht.
Teilenummern, welche ungültig sind, werden dann vom Script als Fehlermeldung gemeldet und die nächst gültige Nummer angegeben.
D.h., wenn ich ein neues Teil reinsetze wird die Teilenummer nicht automatisch generiert, sondern ich muss sie sozusagen von Hand definien und das Script checkt dann, ob es sie schon gibt, so in der Art ?
Des Weiteren sollten wir auf jeden Fall schauen, dass wir keinesfalls abertausende an verschiedenen Teilen erst haben und die Stückliste möglichst klein halten, denn sonst verpuffen die vorteiligen Effekte.
Ähm, wenn ich Dich richtig verstehe, dann beziehst Du Dich damit auf die typische Eigenschaft jedes Baukastens, dass da ein Satz von möglichst häufig gebrauchten Längen definiert sind die den gesamten Bereich einigermaßen gut bzw. grob abdecken so dass sich für die meisten Anwendungsfälle ein geeignetes kurzes, mittleres oder langes Stück findet, man sich dadurch aber gleichzeitig auch auf eine kleine Anzahl von Längen (z.B. bei der Herstellung) beschränken kann, anstatt 1- oder 2-centimeterweise den gesamten Bereich abzubilden - was ja zu zig verschiedenen Längen führen würde. Das hab ich auch deutlich gemerkt, als ich mir die jeweiligen Längenmaße überlegt hab - einerseits hast Du die Freiheit zu definieren was Du willst, andererseits sollen es aber möglichst wenige Teile sein, und die Längen recht universell verwendbar.
Sollte Jemand dennoch zwischenmaße benötigen bzw. die Absrufungen an Längen usw. nicht ausreichend sein, so müsste man evt. darüber nachdenken, dass man den Katalog in Standardteile und Spezialteile unterteilt und den Anwender bzw. Konstrukteur darauf hinweist, dass er nur in Ausnahmefällen Spezialteile verwenden sollte.
Ich verstehe was Du meinst, aber hierbei wäre es mir wirklich wichtig, das anders zu handhaben.
Und zwar sollte nach meinem Verständniss die Unterscheidung zwischen speziell und standard nicht auf der (Katalog-)Ebene der Bauteile stattfinden, sondern auf der Ebene der Sets, indem unterschieden wird zwischen Basis-Sets und Ergänzungs-Set. Und noch ganz besonders speziellen Sets, die ich vielleicht am ehesten als Themen-Sets bezeichnen würde. Diese Unterteilung hat sich bei allen Baukästen, von Märklin bis Fischertechnik etc. in der Historie der Baukästen stets bestens bewährt und funktioniert halt so, dass ein Basis-Set naturgemäß die universelleren Teile enthält, das Ergänzungs-Set dann einerseits die Stückzahlen bestimmter universeller Teile vergrößert, aber andererseits auch schon einige speziellere Teile einführt und die Themen-Sets eben die ganz speziellen Teile enthalten die eigentlich nur oder hauptsächlich in den speziellen Themen-Anwendungen Sinn machen.
Dieses Prinzip hat u.a. zwei wichtige Vorteile:
Die Ebene der Sets bietet Vorteile für die nächsthöhere Ebene, nämlich den Konstruktionsbeispielen bzw. den Konstruktionen/Anwendungen. Du kannst dann nämlich Konstruktionsbeispiele nach Sets gestaffelt aufteilen und sagen, ok, alle diese Dinge kannst Du pauschal bauen, wenn Du das Basis-Set hast. Und alle jene Dinge kannst Du bauen, wenn Du das Basis-Set plus demunddem Ergänzungs-Set hast. In einzelnen Fällen kannst Du auch sagen das ein bestimmtes Ding gebaut werden kann, wenn man das Basis-Set und das Ergänzungs-Set hat plus diesem oder jenen proprietären Teil. Letzteres wird glaubich später insbesondere für die Anwendung in OSE- oder anderen Projekten eine wichtige Rolle spielen, weile s sich hier eben nicht um Kinderspielzeug handelt, wo z.B. das Modell eines Schaufelradbaggers nachgebaut werden soll, sondern um richtige Anwendungen, bei denen der Sinn und Zweck jener Anwendung im Vordergrund steht. Das man dabei möglichst viele Teile aus dem Baukasten verwenden kann ist erstrebenswert und nice-to-have, aber wenns nicht anders geht muss man halt auch ein proprietäres Teil ergänzen und man wird deswegen nicht die ganze Anwendung von Grund auf anders gestalten oder gar ganz darauf verzichten wollen.
Ob ein Bauteil standard oder speziell ist, lässt sich in vielen Fällen nicht anhand des Bauteils allein bestimmen, vermutlich noch nicht einmal durch eine nachgeschaltete statistische Analyse wie dem von Dir weiter unten vorgeschlagenen Scoring, sondern ist allein Kontext-abhängig, d.h., ein Bauteil kann theoretisch sowohl Bestandteil eines Basis-Sets und damit universell sein, als auch Bestandteil eines Themen-Sets und damit speziell. Auf Ebene der Sets und bei der Definition derselben hat man aber noch am ehesten die Möglichkeit, dies schon vorab sinnvoll festzulegen, weil man eben ausser dem Bauteil dabei auch das Set und dessen Anwendungsbereich mit im Blickfeld hat.
Klingt vielleicht etwas theoretisch, aber ich kanns anhand eines Praxisbeispiels belegen: Bei der Definition eines speziellen Themensets XY stehe ich vor der Frage, ob ich bestimmte Bauteile, welche z.B. auch im Basis-Set vorkommen, mit reinnehmen soll oder nicht. In den meisten Fällen werde ich das nicht tun, weil ich sage es kommt ja auch im Basis-Set vor und ich möchte natürlich das Themenset so schmal wie möglich halten und möglichst auf die speziellen Bauteile beschränken. Wenn ich aber erwarten würde, das dieses Themenset seiner Art und seinem Charakter nach auch oft und gern von Leuten nachgefragt oder verlangt werden wird, die sich aber für den Rest des Baukasten-Systems gar nicht weiter interessieren (also sagen wir mal, dieses Themenset wäre eine spezielle Solaranwendung, die gut für sich allein stehen kann) und es zusätzlich nur eine greinge Anzahl, also einige wenige der universellen Bauteile sind, die da noch fehlen um das Themenset „rund“ zu machen, im Sinne von stand-alone, dann könnte dies ein guter Grund sein, die paar universellen Bauteile auch in das Themenset mit aufzunehmen. Ists jedoch eine größere Menge an universellen Bauteilen, die sagen wir mal die Hälfte oder mehr der Bestandteile des Basis-Sets abdecken, dann wäre es natürlich irrwitzig die alle mit aufzunehmen und ich würde stattdessen in die Bauanleitung der Konstruktion schreiben: Dieses Ding kann man bauen, wenn man das Basis-Set sowie das Themenset hat.
Was mir gerade eingefallen ist, wäre z.B. ein Scoring einzuführen, anhand dessen man erkennen kann, wie hoch der „Standardisierungsfaktor“ ist. D.h. wenn Jemand ein Regal aus T-Slot-Profilen konstruiert, erhält jedes darin verwendete Teil einen Punkt.
Verwendet man in einem Regal eine T-Slot-Länge 640mm z.B. 8x so erhält dieses Teil 8 Punkte.
Nun konstruiert Jemand einen Handtuchhalter und er verwendet ebenfalls T-Slot-Länge 640mm, so erhält dieses Teil einen weiteren Punkt je Verwendung.
Dies führt dann dazu, dass jedes Teil eine Score in Höhe der Verwendung erhält und jedes Konstrukt ebenfalls eine Gesamtsumme aller Einzelteilscores erhält, welche dann durch die Anzahl der Teile geteilt wird und dann eine durchschnittliche Score ergibt.
Dadurch würden sich vermutlich von selbst Spezialteile herauskristalisieren und Standardteile bevorzugt, u.a. weil dann der Anwender die Vorteile des unkomplizierten Tauschens und Weiterverwendung auskosten kann.
Das würde m.E. auf der Ebene der Konstruktionen vermutlich funktionieren, aber auf der Ebene der Bauteile aus den vorgenannten Gründen wäre es aus den vorgenannten Gründen aus meiner Sicht nicht wünschenswert. Ausserdem sehe ich etwas das Problem, dass Du damit zwar generell die Universalität eines Konstrukts oder Bauteils sozusagen evolutionär unterstützen würdest. Aber obwohl die Universalität sowohl aus Sicht des Anwenders als auch des Herstellers sicherlich ein wichtiger Aspekt und ein mächtiges Feature eines Baukastens-Systems darstellt und von daher auch gerne so oft wie möglich zum Zuge kommen sollte, so sagt sie doch nichts über die Wertigkeit einer Anwendung bzw. eines Konstrukts aus. Es kann sein, das eine Anwendung aus einem Themenset viel höherwertiger ist als eine aus einem Basis-Set, obwohl letzteres mich in die Lage versetzt damit auch eine Vielzahl von anderen Anwendungen realisieren zu können. Aber ich kann deren Wertigkeit nicht einfach aufsummieren und der Themenset-Anwendung gegenüberstellen.
Gleichzeitig würde es auch eine gewisse Wertigkeit eines Einzelteils ergeben und möglichen Herstellern privat wie gewerblich einen gewissen Anhaltspunkt geben, welche Teile man mehr oder weniger herstellen oder auf Lager halten könnte.
Das ist unter einem auf reine Wirtschaftlichkeit und Effiziens ausgerichteten Blickwinkel durchaus zutreffend, aber denoch das genaue Gegenteil von dem, was ich als wünschenswert ansehe. Du würdest damit bestenfalls fördern, das die speziellen Teile besonders teuer würden und schlimmstenfalls, das sie gar nicht verfügbar sind, weil keiner sie herstellt.
Ein schönes Beispiel, was mir gerade in den Sinn kommt und eigentlich gar nichts mit Baukasten, dafür aber mit Universalität und einer Überbetonung derselben zu tun hat, das ist die berühmte EU-Tomate.
Durch die Praktiken des Bundessortenamtes und die Saatgutverordnung ensteht der Effekt, das einige wenige Tomatensorten, mit bestimmten universellen und zum Teil auch durchaus positiven Eigenschaften auf Deubel komm raus angebaut und weitervermehrt werden, dafür aber dafür auf der anderen Seite mehrere zehntausend Tomatensorten zum aussterben verdonnert sind. Die EU-Tomate ist zwar optimiert auf einen bestimmten durchschnittlichen Geschmacksbedarf einer breiten Mehrheit der Bevölkerung, aber die alten Sorten haben dafür besondere, eben spezielle Eigenschaften, wie zB. die Fähigkeit in bestimmten lokalen Regionen besonders gut zu wachsen, weil sie daran besonders gut angepasst sind. Was aber unter wirtschaftlichen Aspekten niemanden interessiert. Das die alten Sorten nun aussterben stellt aber in Wahrheit einen schlimmen und unwiederbringlichen Verlust dar (und ich halte die verantwortlichen Politiker und Lobbygruppen für Verbrecher, aber das ist jetzt ein anderes Thema ). Aber ich denke mal Du siehst worauf ich hinauswill, eine gewisse Vielfalt in der Landschaft anstatt Monokultur ist aus unserer und aus Sicht des Baukasten-Systems durchaus wünschenswert.
Zu den Teilenummern bzw. der Durchnummerierung, hier gebe ich dir recht, dies könnte später problematisch werden.
Andererseits bin ich ein Freund von aussagekräftigen Nummern.
Denkbare wäre, dass man einfach eine weitere 4er-Reihe getrennt mit Bindestrich hinten dran hängt (optional) und zu jeder Reihe eine Parmeterinfo angibt (d.h. Länge, Breite, Höhe, Radius, Windungen, uvm.)
Denkbar wäre auch, dass man l für length oder w für width, h für height, usw. vorn vor die Zahlenreihe anstellt, wenn dies einen Parameter direkt abbildet.
Ferner sei noch zu bedenken, dass es später vielleicht auch Maßerungen unterhalb eines Milimeters gibt, hier könnte man dann eben ml oder mw oder mh oder µh voranstellen.
Du kannst es gerne versuchen, aber ich glaube es wird nicht so gehen. Ich hab mir ja ebenfalls lange den Kopf darüber zerbrochen, weil ich es gerne so gehabt hätte. Selbst bei einem einfachen Winkelprofil mit zwei ungleichlangen Schenkeln wirds schon kompliziert und dan kommt da noch die Materialdicke hinzu, usw.
Selbst wenn Du da noch mehrere Ziffern dranhängen würdest, am Ende hast Du eine völlig unleserliche Nummer mit einer Zuordnungsvorschrift die niemand mehr durchschaut.
Also mir wäre es wichtig, dass man es lesen kann, weil ich denke, dass dies vor allem auch beim Zusammenbau von Konstrukten wichtig werden könnte, man so die Teile besser und schneller zuordnen könnte. Andernfalls müsste man dann stets in Listen blättern um zu wissen, welches Teil dies ist.
Ja, aber in der Praxis wird so eine Nummer selten für sich alleine stehen, normalerweise ist da auch noch eine Bauteilbezeichnung mit dabei und anhand derer kannst Du das Teil schnell zuordnen und darin auch die übrigen Kenn-Parameter problemlos unterbringen.
Ausserdem haben wir ja schon in den vorangehenden Ziffern eine ganze Hierarchie von Kategorien und Unterkategorien abgebildet, anhand derer man gut navigieren kann, es geht doch jetzt nur noch um den letzten Nummernteil und solange wir da noch nicht zigtausende Teile in einer End-Kategorie haben braucht man auch nicht viel blättern.
Und es wäre schade, die jetzt einigermaßen kurze Nummer, die ja auch an sich einen Vorteil darstellt, wieder aufzubohren und den Ergonomiegewinn wieder zu verschenken.
Wenn wir auf die sprechenden Nummern verzichten dann wäre das System jetzt einsatzbereit, wir ersparen uns weiteren Heckmeck, die Generierung neuer Nummern wäre einfacher, sprich automatisierbar und die Nummern wären einigermaßen kurz und griffig und dennoch anhand des ersten Teils gut navigierbar.
Was will man mehr ?
Gruss, Oliver
PS: Ich hab noch was vergessen, bzw, bin weiter oben vom Weg abgekommen, ich wollte noch was sagen zu
Sollte Jemand dennoch zwischenmaße benötigen bzw. die Absrufungen an Längen usw. nicht ausreichend sein, so müsste man evt. darüber nachdenken, dass man den Katalog in Standardteile und Spezialteile unterteilt und den Anwender bzw. Konstrukteur darauf hinweist, dass er nur in Ausnahmefällen Spezialteile verwenden sollte.
Also, ich sehe den Katalog,d.h., die Liste sämtlicher Bauteile als eine Art Pool, in den man im Grunde hineingeben kann, was und soviel man will. Später sollen auch andere Leute das tun können. Die Inhaltliche Bedeutung der einzelnen Bauteile und Dinge wie universell oder speziell sollte,w ie weiter oben schon ausgeführt nicht auf dieser Ebene, sondern auf Ebene der Sets stattfinden.
Auf dieser Ebene sind aus meiner Sicht nur zwei Dinge wichtig:
Die Navigierbarkeit und eindeutige Einordnung eines Bauteils in die Hierarchie (der Kategorien), welche sich aus der Teilenummer ergibt bzw. für die Generierung einer neuen Teilenummer maßgeblich ist.
Die formale Vollständigkeit der Definition eines Bauteils. D.h., ein Bauteil ist erst dann vollständig definiert, wenn ausser TeileNr. und Bezeichnung auch eine (Fertigungs-)Zeichnung mit Maßangaben, eine 3D-Library und vielleicht noch eine Bezugsquelle und/oder eine Selbst-Herstellungsanleitung dazu gegeben sind.
Erst dann ist es sozusagen offizieller Bestandteil des Pools/Katalogs bzw. des UniPro-Kits. Vorher hat es den Status einer Anwärterschaft, d.h., es ist noch Baustelle.
Was das nun in der Praxis bedeutet muss man sehen, vermutlich erst mal nicht viel, ausser das man halt eine Art Status-Tag definieren muss welches Verschiedene Zwischen-Zustände auf dem Weg zur vollständigen Definition beschreibt. Und das ein Nutzer die Möglichkeit hat, sich anhand dieses Tags gezielt und selektiv nur diejenigen Teile anzeigen zu lassen, die schon vollständig sind. Oder aber auch diejenigen, zu denen es zwar noch keine Bezugsquelle, aber immerhin schon eine Maß-Zeichnung gibt. Oder diejenigen mit 3D-Lib, weil er damit ja schon was am Computer konstruieren kann.
Ich sehe das halt im Hinblick auf die Möglichkeit, das auch andere Leute Bauteile definieren möchten, was ja sehr willkommen ist. Andererseits möchte ich aber irgendwie auch gerne das vermeiden, was ich selbst im Moment gerade (notgedrungernermaßen) praktiziere nämlich etliche angefangene Bauteile, die gerade mal eine Beschreibung enthalten, aber zu denen noch nicht mal eine Zeichnung existiert.
Ich weiss aus der Erfahrung, das sich das an sich nicht ganz vermeiden lässt, denn es war mir bislang wichtiger, eine Idee erst mal festzuhalten, auch wenn vorherige Bauteile noch nicht komplett fertig sind. Aber wenn dem schon so ist, dann muss man wenigstens dazwischen unterscheiden oder selektieren können oder es als Minimum (insbesondere in der Katalogauflistung) irgendwie kenntlich machen können.
Ähm… dies würde nicht passieren, weil der Markt automatisch für einen Ausgleich sorgen würde. D.h. wenn die Preise steigen, lohnt es sich die Teile auch herzustellen. Sind die Preise niedrig, dann eben nicht.
Der Bezug zu den Baukästen ist mir einleuchtend, könnte bzw. sollte man wohl mit erwähnen um eine Verbindung herzustellen.
Wiederum muss man bedenken, dass viele Leute vermutlich keine ganzen Baukästen kaufen werden wollen, weil sie eben nur ein paar Teile davon benötigen.
Die Baukästen sehe ich daher eher was für Bastler und Entwickler, weniger aber für den normalen Konsumenten und Anwender, welche jedoch die Masse darstellen werden. Ich mein als Anwender sucht man z.B. nach einem Regal und will dann auch nur die Teile für das Regal erwerben und keine weiteren Teile irgendwo auf dem Dachboden vor sich hin vegetieren lassen.
Und selbst wenn man den Baukasten kauft, das Regal daraus baut, so müsste man den Baukasten mit Einzelteilen wieder auffüllen, weil das Regal ja nicht nur temporär, sondern vielleicht für mehrere Jahre benutzt werden will, andernfalls hätte man dan einen unvollständigen Baukasten, dessen Verwendungsmöglichkeiten damit eingeschränkt werden würden.
Zudem darf man nicht vergessen, dass es sich hier nicht um Miniaturen sondern um echt große Teile handelt, d.h. das Prinzip des Baukastens was in Miniatur noch funktioniert, wird mit großen Baukästen eine logistische und lagertechnische Herausforderung.
Ferner wäre es meiner Meinung nach auch nicht erstrebenswert, dass jede Menge an Bauteilen unbenutzt lagern, denn gerade mit diesem universellen Prinzip wollen wir doch Ressourcen möglichst effektiv und sparsam einsetzen.
Daher wäre mein Vorschlag, die Teile im Teilekatalog aufgelöst / sortiert nach Baukästen zu listen, welche man dann durchblättern kann und jene Baukästen den Entwicklern schmackhaft machen und als Gesamtes, gleichzeitig aber auch Einzelteile gezielt nach Anwendung für den Normaloanwender anzubieten. Ein Scoring könnte hierbei statistische Randinformationen liefern, denn ich finde es durchaus interessant zu erkennen, wie oft ein Teil verwendet wurde oder auch wie oft eine Konstruktionsanleitung und Bauplan heruntergeladen wurde, denn dies bietet auch den Entwicklern und Herstellern nützliche Informationen, denn auch hier ist es meiner Meinung nach durchaus erstrebenswert dass sich gewisse Maße in Masse durchsetzen und man nicht wie Heute an vielen Stellen die Teile der Konstruktion anpasst, sondern man auch mal weiter denkt und die Konstruktion so gestaltet, dass darin viel verwendete Teile integrierbar sind.
Denn aus Sicht eines Herstellers (gewerblich aber auch privat) ist es schon entscheidend ob er 1000 T-Slot mit Maß 640mm oder er 100 mit 600, 100 mit 620, 50 mit 540, … herstellen muss.
U.a. kenne ich diese Entwicklungen durch meinen Vater, der seit 30 Jahren in der Metallverarbeitung arbeitet und die Ineffektivitäten durch ständiges Umspannen und neu einrichten kennt. Dies ist teils mittlerweile so krass, dass die Zeit der Einrichtung die Zeit der Produktion nicht selten übersteigt.
Ferner kommt noch hinzu, dass man hierzu wieder mehr verschiedene Werkzeuge oder Jigs benötigt.
Daher finde ich diese statistischen Informationen wie eine Art Scoring interessant.
Aber gut, ich denke dies wird Anfangs eher sekundär sein und daran soll eine solche Sache nicht scheitern oder aufgehalten werden, sowas ist was für spätere Zeiten.
Bezüglich der Teilenummerierung, hierbei hätte ich einen weiteren Gegenvorschlag.
Sollten wir schon durchnummerieren, so würde ich nach Sets aufschlüsseln.
D.h.
erste Buchstabe könnte das Material grob klassifizieren (W für wooden, M für metal, P für plastic, …)
zweite Buchstabe könnte man für „Basis (Standardmaße), Erweiterungs (weitere Abmaßungen, Zubehörteile), Spezial (z.B. Motoren, Platinen, usw.), Custom (Sonderteile, welche weder in Basis- noch Erweiterungsset platz finden, z.B. T-Slotprofil mit einem gebohrten Loch drin oder so)“
die dritte und vierte Nummer würde dann für das entsprechende Set stehen, welches man dann durchnummeriert.
dann Bindestrich und die Teile mit Buchstaben gruppieren, evt. A für angle, P für profile, S für screw, usw.
dann eine zweistellige Nummer zur Durchnummerierung der Längen vom kleinsten bis größten Teil.
So ist die lesbarkeit durch die Verknüpfung zu den Sets halbwegs gegeben und zudem fördert es die Set-„Mentalität“
Als Teilegruppierung hab ich die Form des Buchstaben als Gruppierungsgrundlage genommen, z.B. L für Winkel, O für Kugellager, O-Ringe, Räder, usw. …
Zwar findet man dann in einer Gruppierung mehrere verschiedene Teilegruppen, jedoch würde ich dies dann eher über Teilebeschreibung oder/und Tags regeln, d.h. man tagt Detailinformationen an, so wie es http://ouishare.net/ aktiv verwendet.
Ebenfalls könnte ich mir gut vorstellen, dass wenn Anwendungen entstehen, man jene Anwendungen an die Teile tagt, so dass man sofort erfahren kann, wozu man dieses Teil verwenden kann. Im Grunde eigentlich schon das Scoringsystem, welches ich haben möchte
OK, lass ich mal so stehen. Mir wäre es halt wichtig, das die speziellen Teile auch hergestellt und Angeboten werden würden.
Der Bezug zu den Baukästen ist mir einleuchtend, könnte bzw. sollte man wohl mit erwähnen um eine Verbindung herzustellen.
Wiederum muss man bedenken, dass viele Leute vermutlich keine ganzen Baukästen kaufen werden wollen, weil sie eben nur ein paar Teile davon benötigen.
Die Baukästen sehe ich daher eher was für Bastler und Entwickler, weniger aber für den normalen Konsumenten und Anwender, welche jedoch die Masse darstellen werden. Ich mein als Anwender sucht man z.B. nach einem Regal und will dann auch nur die Teile für das Regal erwerben und keine weiteren Teile irgendwo auf dem Dachboden vor sich hin vegetieren lassen.
Und selbst wenn man den Baukasten kauft, das Regal daraus baut, so müsste man den Baukasten mit Einzelteilen wieder auffüllen, weil das Regal ja nicht nur temporär, sondern vielleicht für mehrere Jahre benutzt werden will, andernfalls hätte man dan einen unvollständigen Baukasten, dessen Verwendungsmöglichkeiten damit eingeschränkt werden würden.
Zudem darf man nicht vergessen, dass es sich hier nicht um Miniaturen sondern um echt große Teile handelt, d.h. das Prinzip des Baukastens was in Miniatur noch funktioniert, wird mit großen Baukästen eine logistische und lagertechnische Herausforderung.
Ferner wäre es meiner Meinung nach auch nicht erstrebenswert, dass jede Menge an Bauteilen unbenutzt lagern, denn gerade mit diesem universellen Prinzip wollen wir doch Ressourcen möglichst effektiv und sparsam einsetzen.
Darin stimme ich 100%ig mit Dir überein. Ich will auch niemandem den Baukasten mit Gewalt aufs Auge drücken, sondern hatte ja kürzlich schon konstatiert, dass die Teile selbstverständlich auch einzeln beziehbar sein müssen.
Ich gebe aber gern zu, dass ich ursprünglich tatsächlich primär die Entwickler als Zielgruppe im Auge hatte, die daraus Maschinen oder Geräte entwickeln, die Zielgruppe der Endanwender und Konsumenten, die sich daraus Endprodukte erstellen, das ist sozusagen eine neue Strömung, die durch Dich hinzugekommen ist und die ich genauso unterstütze.
Ich möchte aber das gerade von Dir gesagte nochmal explizit betonen und als Definiton so formulieren, das Baukästen und Sets sich vornehmlich an Entwickler richten und einzeln beziehbare Bauteile und Stücklisten zu Konstrukten als Endprodukte an den Endanwender/Konsumenten.
Daher wäre mein Vorschlag, die Teile im Teilekatalog aufgelöst / sortiert nach Baukästen zu listen, welche man dann durchblättern kann und jene Baukästen den Entwicklern schmackhaft machen und als Gesamtes, gleichzeitig aber auch Einzelteile gezielt nach Anwendung für den Normaloanwender anzubieten.
Damit bin ich im Prinzip auch einer Meinung, es darf aber meines Erachtens nicht technisch auf Ebene der TeileNummern realisiert werden, aber dazu gleich mehr.
Ein Scoring könnte hierbei statistische Randinformationen liefern, denn ich finde es durchaus interessant zu erkennen, wie oft ein Teil verwendet wurde oder auch wie oft eine Konstruktionsanleitung und Bauplan heruntergeladen wurde, denn dies bietet auch den Entwicklern und Herstellern nützliche Informationen, denn auch hier ist es meiner Meinung nach durchaus erstrebenswert dass sich gewisse Maße in Masse durchsetzen und man nicht wie Heute an vielen Stellen die Teile der Konstruktion anpasst, sondern man auch mal weiter denkt und die Konstruktion so gestaltet, dass darin viel verwendete Teile integrierbar sind.
Denn aus Sicht eines Herstellers (gewerblich aber auch privat) ist es schon entscheidend ob er 1000 T-Slot mit Maß 640mm oder er 100 mit 600, 100 mit 620, 50 mit 540, … herstellen muss.
U.a. kenne ich diese Entwicklungen durch meinen Vater, der seit 30 Jahren in der Metallverarbeitung arbeitet und die Ineffektivitäten durch ständiges Umspannen und neu einrichten kennt. Dies ist teils mittlerweile so krass, dass die Zeit der Einrichtung die Zeit der Produktion nicht selten übersteigt.
Ferner kommt noch hinzu, dass man hierzu wieder mehr verschiedene Werkzeuge oder Jigs benötigt.
Daher finde ich diese statistischen Informationen wie eine Art Scoring interessant.
Aber gut, ich denke dies wird Anfangs eher sekundär sein und daran soll eine solche Sache nicht scheitern oder aufgehalten werden, sowas ist was für spätere Zeiten.
Also, Scoring oder nicht, das ist mir nicht so wichtig, aber was die Grundaussage hinsichtlich der Rüstzeiten und die Effizienz einiger weniger universeller Maße betrifft bin ich ebenfalls absolut Deiner Meinung, Mit meinen vorherigen Einlassungen bezügl. universeller versus spezieller Teile hab ich mich eher auf die „marktwirtschaftliche“ Seite bzw. deren Auswirkungen des Scorings bezogen, aber die Universalität als Prinzip ist für mich mit das Wichtigste am Baukastensystem.
Ev. gibts auch noch ein kleines begriffliches Missverständniss zwischen uns mit den Spezialteilen: Damit meinte ich eher sowas wie ein spezielles Solarbauteil, aber nicht sowas wie die von Dir genannten Zwischengrößen, letztere möchte ich im Rahmen eben genau der Universalität auch nicht haben. Nach meiner Vorstellung werden sie deshalb auf der Ebene der Sets einfach ausgeblendet bzw. tauchen dort gar nicht auf. Wenn einer aber meint sowas unbedingt zu brauchen, dann kann er das gerne als eine Art Stand-alone-Bauteil innerhalb des Gesamtpools definieren und in der Stückliste eines Konstrukts oder Projekts auch referenzieren, es verschwindet bildlich gesprochen anonym in der Masse der Bauteile und tut dort niemandem weh bzw. stört nicht, gleichzeitig erhält man sich aber die Freiheit, nach allen Seiten hin offen zu sein und damit maximale Flexibilität. D.h., bei sowas wäre es mir relativ egal ob irgendjemand das produziert und anbietet (solange ich es nicht selbst brauche ;P) im Gegensatz zu den Spezialbauteilen aus einem Themenset, da wäre es mir wichtig. Ich weiss nicht ob ich mich hier verständlich ausdrücke, aber ich kanns grad nicht besser illustrieren.
Bezüglich der Teilenummerierung, hierbei hätte ich einen weiteren Gegenvorschlag.
Sollten wir schon durchnummerieren, so würde ich nach Sets aufschlüsseln.
D.h.
erste Buchstabe könnte das Material grob klassifizieren (W für wooden, M für metal, P für plastic, …)
zweite Buchstabe könnte man für „Basis (Standardmaße), Erweiterungs (weitere Abmaßungen, Zubehörteile), Spezial (z.B. Motoren, Platinen, usw.), Custom (Sonderteile, welche weder in Basis- noch Erweiterungsset platz finden, z.B. T-Slotprofil mit einem gebohrten Loch drin oder so)“
die dritte und vierte Nummer würde dann für das entsprechende Set stehen, welches man dann durchnummeriert.
dann Bindestrich und die Teile mit Buchstaben gruppieren, evt. A für angle, P für profile, S für screw, usw.
dann eine zweistellige Nummer zur Durchnummerierung der Längen vom kleinsten bis größten Teil.
So ist die lesbarkeit durch die Verknüpfung zu den Sets halbwegs gegeben und zudem fördert es die Set-„Mentalität“
Das geht aus einer Vielzahl von Gründen nicht, d.h., zumindest nicht auf Ebene der Teilenummern.
Der erste Grund ist, weil es sein kann, das ein Bauteil Bestandteil von mehreren Sets sein kann. Und mehr noch, Du weisst im Vorfeld nicht, welche Sets noch zukünftig definiert werden könnten.
Ein zweiter Grund ist für mich schwer zu erläutern, aber ich versuchs mal: Damit würde man eine an sich absolut klare und eindeutige zugrundeliegende Struktur, die nach dem Top-Down-Prinzip funktioniert, ohne große Not zerstören und damit wäre auch gleichzeitig der Sinn einer Trennung bzw. Verschiebung der Sets (als wichtiges Instrument) auf eine separate, eins höher gelegene Ebene, hinfällig.
Ich möchte dabei noch vorausschicken, dass ich inhaltlich kein Problem mit einer solchen , ich nenne es mal „Rückbezüglichkeit“ habe, nur darf sie m.E. nicht auf Ebene bzw. anhand der Teilenummern technisch realisiert werden, sondern wenn, dann muss dies auf andere Weise geschehen.
Ich hab zu diesen beiden Punkten mal versucht, das, was ich mit klarer und eindeutiger Struktur meine, grafisch zu visualisieren, vielleicht wird es dann etwas deutlicher.
Klar und eindeutig meint hier, dass die Pfeile immer nur in eine Richtung gehen, d.h., ein Element einer höhergelegenen Ebene referenziert stets nur Elemente der tiefer liegenden Ebenen. (zu etwaigen möglichen Rückbezüglichkeiten gleich mehr), d.h., alle Pfeile gehen nur in Richtung von oben nach unten (top-down).
Ein beliebiges Konstrukt A kann auf zwei mögliche Arten Bauteile referenzieren, entweder direkt, in Form einer Stückliste, oder indirekt in Form eines Verweises auf ein Set, welches dann seinerseits direkt auf Bauteile verweist. Daher ist ein Set und eine Stückliste vom Charakter her fast dasselbe, der einzige Unterschied besteht darin, das das Set universell ist und ev. auch noch weitere Bauteile referenziert die für Konstrukt A nicht benötigt werden, während die Stückliste A eng im Kontext mit Konstrukt A steht bzw. dazugehört und nur die Bauteile referenziert die auch wirklich dafür benötigt werden.
OK, soweit nix neues
Jetzt zum Pool. Wenn ich hier immer von Ebenen rede, dann meint das im Grunde Abstraktionsebenen und die Eindeutigkeit der in nur eine Richtung gehenden Pfeile bedeutet, das der Pool als unterste Abstraktionsebene völlig losgelöst ist (bzw. betrachtet werden kann) von den darüberliegenden Ebenen. Etwaige Abhängigkeiten gehen immer nur in Richtung von oben nach unten, was den unschlagbaren Vorteil bietet, das ich mich auf der untersten Ebene mit einem Minimum an Komplexität und Definitionen etc. begnügen kann, d.h., die Sache möglichst klar, einfach und effizient gestalten kann, ohne mir sozusagen über die höheren Funktionen der anderen Ebenen an dieser Stelle den Kopf zerbrechen zu müssen und ich kann mich stattdessen hierbei auf das Wesentliche konzentrieren.
Das bedeutet in der Praxis, eine möglichst einfache Zuordnungsvorschrift oder auch Verfahrensweise bei der Integration neuer Bauteile in den Pool, dieses auch gerade im Hinblick auf weitere Entwickler von Bauteilen (aber auch mir selbst), denen ich sozusagen die Motivation, den Pool zu erweitern, nicht unnötig durch zu komplexe Verfahrensweisen erschweren möchte - es ist eh schon genug Arbeit, ein Bauteil wirklich bis zur „vollständigen Definiertheit“ auszuarbeiten.
Alle Fragen des Zugriffs auf einzelne Bauteile sind auf dieser Ebene nicht Gegenstand sondern explizit in die höheren Ebenen ausgelagert, es gibt also klar getrennte Zuständigkeiten.
Was der Bauteile-Entwickler, der soeben Masszeichnung und sonstiges Pipapo eines neuen Bauteils fertiggestellt hat und dieses nun in den Pool integrieren möchte, an dieser Stelle ganz klar und eindeutig braucht das ist Folgendes:
Er wählt nacheinander aus drei Selektoren die Kategoriengruppe, die Kategorie und die Unterkategorie und drückt auf den „Go“-Button. Eine Sekunde später spuckt ihm das System (oder ein Progrämmchen) eine neu generierte Teile-Nr. aus, die systemweit eindeutig ist.
Thats it. Nicht mehr und nicht weniger.
Aus diesem Grunde ist es m.E. unbedingt erforderlich, dass die Teile Nr. selbst so klar und eindeutig ist, wie im ursprünglichen Entwurf von Dir skizziert aber incl. fortlaufend generierter Endnummer.
Alle interpretatorischen Dinge, die Hinweise auf Art und Rang eines Bauteils geben, haben an dieser Stelle nix verloren und würden die Sache ganz gewaltig verkomplizieren.
Soweit die „reine“ Theorie.
In der Praxis habe ich jedoch, wie oben schon angedeutet, überhaupt nichts gegen etwaige Rückbezüge, also Pfeile die von unten nach oben gehen, einzuwenden ich würde es in der Tat sogar genauso wie Du als nice to have oder gar als höchst sinnvoll ansehen, wenn man zu einem Bauteil auch die Information bekommen könnte, in welchen Konstrukten es bislang Verwendung findet und meinetwegen auch, in welchen Sets es definiert wurde.
Es darf nur meiner Meinung nach eben gerade nicht mittels der Teilenummer realisiert werden, sondern muss auf andere Weise technisch umgesetzt werden.
Der natürlichste, simpelste und beste Weg sowas technisch umzusetzen besteht in meinen Augen darin, im Rahmen einer Datenbankanwendung (u.a. darum hatte ich diese auch im vorigen Posting als eine Art „Königsweg“ empfohlen) innerhalb der Bauteile-Tabellenstruktur ein Feld zu definieren, welches vom Typ eines unlimitierten Arrays ist (d.h. man kann da beliebig viele Einträge dranhängen) und in welchem die Rückbezüge (, d.h. die Referenzen auf etwaige Konstrukte und Sets welche dieses Bauteil verwenden) eingetragen und vor allem auch nachträglich (wenn neue Sets und Konstrukte erstellt werden) ergänzt und aktualisiert werden können.
Eine andere technische Umsetzung ohne Datenbank wäre auch möglich, diese müsste halt eine wieauchimmer geartete parallele Struktur (also Parallel zum Bauteile-Datensatz bzw. dessen Teilenummer) verwalten, und imstande sein, auch hier nachträglich Referenzen auf neue Sets und Konstrukte zu ergänzen.
Vielleicht könnte diese Struktur das sein, was Du als „Katalogseite“ bezeichnet hattest, wobei es mir an dieser Stelle angebracht erscheint, davon begrifflich zu unterscheiden, was ich in der obigen Grafik (leichtfertigerweise auch) „Katalog“ genannt hatte und das aber synonym zu „Pool“ meinte. Ich glaube wir meinten beide trotz des ähnlichen Wortes nicht genau das Gleiche damit und schlage der Einfachheit halber vor wir behalten diese beiden Worte „Katalogseite“ und „Katalog“ bei und sind uns im Klaren dass da ein kleiner Unterschied besteht, ich meine halt den Pool und Du glaube ich eine Art Katalog-Webseite die in der von Dir beschriebenen Weise strukturiert ist incl. bestimmter Navigationsmöglichkeiten. Korrigier mich wenn ich damit falsch liege.
Eine andere, vielleicht noch einfachere Form dieser genannten „parallelen Struktur“ könnte vielleicht auch sein, eine zweite Nummer einzuführen, das könnte so eine Art interne Nummer sein, die in Deinem Sinne „sprechend“ ist und für Navigationszwecke dient, etwa so wie von Dir beschrieben. Vielleicht könnte man die sogar als „extended“-TeileNummer bezeichnen, also eine Art Erweiterung zu der normalen, simplen Nummer. Sie bräuchte nur irgendwie damit verknüpft zu sein oder Bestandteil des Datensatzes (aber eben nicht Bestandteil der Teilenr. selbst) und Du könntest damit alle die von Dir beschriebenen Varianten umsetzen bzw. wir könnten ausprobieren ob und inwieweit uns das nützt. Ich bezweifle übrigens auch gar nicht das diese zur Realisierung einer Navigation innerhalb der Katalogseite nützlich wäre, ich glaube nur, das früher oder später Teile auftauchen könnten, deren paramterische Komplexität den Rahmen dieser Nummer sprengen werden. Ausserdem ist mir nicht klar, wie eine solche Nummer überhaupt generiert werden kann, zumindest nicht, ohne dem Entwickler ein größeres Maß an „Handarbeit“ beim erstellen dieser Nummer und „Kopfarbeit“, nämlich das Verstehen der formalen Vorschriften zur ihrer Erstellung, abzuverlangen.
Puuh, ok, soweit erstmal. Ich weiss nicht ob ich mein Anliegen auch nur halbwegs verständlich vermitteln konnte, aber ich habs wirklich nach bestem Wisen und Gewissen versucht
Hierzu würde ich einfach einen Nummerngenerator erstellen und zudem die Katalogseiten im Wiki später schützen und eine Art Seite „Request“ erstelle, wo Nutzer neue Teile auflisten können, welche dann von dir, mir oder einem anderen Administrator in den Katalog bzw. Teileliste eingepflegt werden.
So ist zum Einen sichergestellt, dass die Nummernvergabe und Eingruppierung richtig erfolgt und zum Anderen mögliche Doppelungen erkannt werden, denn es kann bei einer zunehmend großen Zahl an Teilen vorkommen, dass Jemand ein baugleiches Teil nochmal neu erstellt.
Bezüglich Datenbank, im Grunde liegen die Daten ja in der Wiki-Datenbank in Form von Seiten und Tabellen. Jene Tabellen wandle ich dann per Script z.B. in ein export/importfähiges Format JSON um und kann es dann weiter verarbeiten.
Dies hat zwar den Nachteil, dass das Datenhandling nicht ganz so einfach per SQL-Befehl erfolgen kann und zudem auch die Daten offen herumliegen und leichter „vrhunzt“ werden können, doch möchte ich damit bezwecken, dass die Daten öffentlich und unkompliziert einsehbar, strukturierbar (Aufteilung in verschiedenen Seiten) sowie bearbeitbar sind.
Zudem hab ich hier den großen Vorteil, dass wenn Jemand Daten „verhunzt“ ich kein BackUp einspielen, sondern den Teil der Daten bzw. die Änderungen der Wikiseite einfach rückgängig mache.
Meiner Meinung nach ist ein Wiki einfach ein geniales Instrument um diverse Dinge offen und transparent gestalten und anschließend in Quellcode oder Datensätzen umzusetzen.
Man muss dann nur noch eine einzige Wiki-Datenbank und keinerlei Webdateien (HTML, PHP, usw.) sichern.
Zu diesem Thema werde ich denke ich in einigen Wochen anfangen eine Bachelorarbeit zu schreiben, d.h. der Entwicklung von Webseiten und Datenstrukturen mittels Wiki. Meiner Meinung nach eine neue sehr günstige Art der Webentwicklung, welche es bisher nicht gibt, aber sehr viele Vorteile bietet, vor allem im Hinblick Ergonomie, Transparenz, Dezentralität, Sicherheit und OpenSource(optional), was Plattformen wie GitHub nicht bieten (können).
Daher halte ich die Katalogisierung über Wiki für attraktiv, ggf. wird es bei größeren Datenmengen dann halt regelmäßig in eine oder mehrere Datentabellen portiert und kann dann per SQL-Befehl leichter und effektiver verarbeitet werden.
Um die Suche später zu erleichtern, halte ich Tags für die beste Lösung, d.h. im Grunde das Array-Feld, welches du vorgeschlagen hast. Dies wird für den Anfang erstmal sekundär sein, weil die Zahl der Teile und Sets überschaubar ist. Später wird es dann aber eine Möglichkeit geben, den Teilen Tags anhängen zu können.
Auch hier denke ich wäre ein Request-System denkbar, d.h. Nutzer können Teilen Tags vergeben, jene Tags tauchen dann in einer Liste auf und können von den Admins bestätigt, editiert oder abgelehnt werden. Dies ist aber erstmal sekundäre.
Super, na da fällt mir aber ein Stein vom Herzen !
Hierzu würde ich einfach einen Nummerngenerator erstellen und zudem die Katalogseiten im Wiki später schützen und eine Art Seite „Request“ erstelle, wo Nutzer neue Teile auflisten können, welche dann von dir, mir oder einem anderen Administrator in den Katalog bzw. Teileliste eingepflegt werden.
So ist zum Einen sichergestellt, dass die Nummernvergabe und Eingruppierung richtig erfolgt und zum Anderen mögliche Doppelungen erkannt werden, denn es kann bei einer zunehmend großen Zahl an Teilen vorkommen, dass Jemand ein baugleiches Teil nochmal neu erstellt.
Sehr gut! Ich war in meinen früheren Diskussionen zur Systematik auch am Ende zu dem Schluss gelangt das eine Art peer-review System die beste und einfachste Lösung ist und es trägt auch dazu bei, dass das Baukastensystem tatsächlich so eine Art Standard werden kann, d.h., mit gewissen Qualitätsansprüchen. Ähnlich wie beim Linux-Kernel.
Bezüglich Datenbank, im Grunde liegen die Daten ja in der Wiki-Datenbank in Form von Seiten und Tabellen. Jene Tabellen wandle ich dann per Script z.B. in ein export/importfähiges Format JSON um und kann es dann weiter verarbeiten.
Dies hat zwar den Nachteil, dass das Datenhandling nicht ganz so einfach per SQL-Befehl erfolgen kann und zudem auch die Daten offen herumliegen und leichter „vrhunzt“ werden können, doch möchte ich damit bezwecken, dass die Daten öffentlich und unkompliziert einsehbar, strukturierbar (Aufteilung in verschiedenen Seiten) sowie bearbeitbar sind.
Zudem hab ich hier den großen Vorteil, dass wenn Jemand Daten „verhunzt“ ich kein BackUp einspielen, sondern den Teil der Daten bzw. die Änderungen der Wikiseite einfach rückgängig mache.
Meiner Meinung nach ist ein Wiki einfach ein geniales Instrument um diverse Dinge offen und transparent gestalten und anschließend in Quellcode oder Datensätzen umzusetzen.
Ja, volle Zustimmung. Ich hatte mir auch damals gedacht, ehe ich anfange aufwändig eine DB-Anwendung zu schreiben, sollte man lieber erstmal die Vorteile des Wiki voll ausnutzen. Datenhandling per SQL-Befehl hat zwar den Vorteil, das man sich vermutlich etwas an Parser-Arbeit sparen kann, aber auf der anderen Seite einen nicht zu unterschätzenden Aufwand für Eingabe- , Update-, Änderungs- und Lösch-Routinen hat, was beim Wiki ingewisser Weise implizit ist. Ausserdem erspart man sich das DB-Setup, was mitunter auch recht aufwendig sein kann.
Man muss dann nur noch eine einzige Wiki-Datenbank und keinerlei Webdateien (HTML, PHP, usw.) sichern.
Und bei den meisten Web-Hostern kostet jede weitere DB auch extra, während eine oft im Grundtarif inbegriffen ist.
Diesbezüglich, und damit auch was das DB-Backup angeht, hab ich aber noch nen kleinen Tip:
Es ist normalerweise kein Problem in der DB vom Wiki (meist sowas wie MySQL) einfach noch zusätzliche Tabellen zu ergänzen. Die würden dann automatisch mit dem Wiki zuammen gebackupt und kosten auch nix extra Das mal nur so am Rande, also wenn Du mal das Problem hast, im Rahmen einer Script-basierten Anwendung Daten persistent zwischenspeichern zu wollen, einfach eine kleine Tabelle in der Wiki-DB ergänzen. Solange das nur Script-intern genutzt wird hast Du auch keinen weiteren Heckmeck mit irgendwelchen aufwendigen (im Sinne von User-sicheren) Input-/Output-Routinen.
Zu diesem Thema werde ich denke ich in einigen Wochen anfangen eine Bachelorarbeit zu schreiben,
Oh, wusste gar nicht das Du studierst. Na, ich drück die Daumen für gutes Gelingen!
d.h. der Entwicklung von Webseiten und Datenstrukturen mittels Wiki. Meiner Meinung nach eine neue sehr günstige Art der Webentwicklung, welche es bisher nicht gibt, aber sehr viele Vorteile bietet, vor allem im Hinblick Ergonomie, Transparenz, Dezentralität, Sicherheit und OpenSource(optional), was Plattformen wie GitHub nicht bieten (können).
GitHub seh ich mit nem etwas anderen Focus, das ist für mich einfach nur ne moderne und webbasierte Variante eines CVS (Concurrent Versioning System) aber ich stimme voll zu, das man, bevor man sowas wirklich braucht, lange erst mal die gegebenen Möglichkeiten des Wiki nutzen kann. Solange nur ein oder zwei Männekes an einem Projekt arbeiten kommt man damit prima zurecht und muss sich nicht erst aufwendig in die GitHub-Bedienung einarbeiten, das ist erst bei größeren Projekten sinnvoll, wenn zig Leute an einer Sache rumentwickeln, also sowas wie der Linux-Kernel etwa. Na, ich hoffe dennoch das wir auch noch mal irgendwann in den Genuss dieser „Problematik“ kommen werden, sprich, dass jeweils mehrere Leute an den einzelnen Projekten mitarbeiten, dafür würde ich auch gerne GitHub in Kauf nehmen Aber bis dahin sollte man erst mal das Wiki voll ausnutzen.
Daher halte ich die Katalogisierung über Wiki für attraktiv, ggf. wird es bei größeren Datenmengen dann halt regelmäßig in eine oder mehrere Datentabellen portiert und kann dann per SQL-Befehl leichter und effektiver verarbeitet werden.
Kann man später bei Bedarf oder wenn man Zeit dafür hat machen, wichtig ist für mich nur dass diese grundlegende Möglichkeit besteht und solange man Daten per Script aus den Wikiseiten parsen und extrahieren kann, kann man sie wenn benötigt auch jederzeit woandershin exportieren. Aber das ist im Grunde genau das, was ich etwas weiter oben mit der Ergänzung von Tabellen in der WIki-DB meinte.
Um die Suche später zu erleichtern, halte ich Tags für die beste Lösung, d.h. im Grunde das Array-Feld, welches du vorgeschlagen hast. Dies wird für den Anfang erstmal sekundär sein, weil die Zahl der Teile und Sets überschaubar ist. Später wird es dann aber eine Möglichkeit geben, den Teilen Tags anhängen zu können.
Auch hier denke ich wäre ein Request-System denkbar, d.h. Nutzer können Teilen Tags vergeben, jene Tags tauchen dann in einer Liste auf und können von den Admins bestätigt, editiert oder abgelehnt werden. Dies ist aber erstmal sekundäre.
Wenn ich das richtig verstehe, dann brauchen die Tags gar nicht unbedingt reviewed zu werden, sondern man muss einfach nur ein paar allgemeingültige Tags definieren und der Entwickler kann sie selbst eintragen, so er das Interesse hat, das sein BauTeil besser gefunden wird oder andere sehen, wo es überall schon zum Einsatz kommt. Später kann man das mal automatisieren, indem Konstrukte-Stücklisten und Sets per Script gescannt werden und dann das Resultat bei den jeweiligen Bauteilen ergänzt wird. Ev. könnte diese Aufgabe von dem von Dir angedachten Scoring-System miterledigt werden.
Ausserdem kannst Du solche Tags wahrscheinlich auch bei den Konstrukten sinnvoll zum Einsatz bringen, wenn es mal mehr bzw. viele davon gibt und man die nach Themengebieten sortiert präsentieren möchte.
Naja, bis wir soviele Konstrukte haben, dahin müssen wir erst mal kommen, aber eine gute Infrastruktur ist der Sache gewiss förderlich. Und wenns denn mal soweit ist, ist man wenigstens gut vorbereitet.
Im Wiki habe ich es nun mit den verschiedenen Größen so gehandhabt, dass man die Nummer vor der Parameterangabe setzt, so dass auf der Katalogseite das Teil durchummeriert erscheint, gleichzeitig aber die Parameterangabe folgt und als Information mit ausgegeben wird.
Hierbei setzt man für den Parameter „Länge“ ein kleines L vor die Zahl und so wird es dann als Längenparameter ausgegeben.
Weitere Parameter werden in Kürze folgen, eine Wikiauflistung werde ich noch anlegen.
So könnte man auch mehrere Parameter z.B. lw20_40 (length, width) d.h. Länge 20mm und Breite 40mm
Ein weiterer Vorteil ist, dass man nicht für jede Länge einen neuen Datensatz braucht.
Als Nächstes werde ich eine Legitimationsprüfung erstellen und auch das Tagsystem mit einer Funktion belegen. Ziel eines Tagsystems ist es ja, Objekte nach Tags durchsuchen zu können.
D.h. um zu Konstrukten zu kommen, braucht man eigentlich nur an alle notwendigen Teile ein Tag hängen und schon erhält man die Stückliste und Teileliste automatisch.
Jau, sieht sehr gut aus ! Auch gut das man die CAD-Dateien einzeln runterladen kann.
Nur das mit dem „click save as in your browser“ kann man glaubich ruhig weglassen, das dürfte den meisten Leuten klar sein wenn download davor steht.
Und vielleicht auch die Worte Kategoriengruppe, Kategorie und Unterkategorie. Vielleicht könnte man sogar die dahinter befindlichen Infos zusammen einblenden ? Nur mal soone Überlegung, und nur bezogen auf die drei. Das Du bei dem hinteren Teil der Teile Nummer die Parameter wie Länge=60mm einblendest sollte ruhig separat stehenbleiben. Und hier bietet sich denn auch eine gute Möglichkeit, bei komplexeren und andersartigen teilen beliebige andere Parameter und davon bei Bedarf auch mehrere einzublenden, das ist definitiv eine wertvolle Hilfe beim browsen des Katalogs!
Im Wiki habe ich es nun mit den verschiedenen Größen so gehandhabt, dass man die Nummer vor der Parameterangabe setzt, so dass auf der Katalogseite das Teil durchummeriert erscheint, gleichzeitig aber die Parameterangabe folgt und als Information mit ausgegeben wird.
Hierbei setzt man für den Parameter „Länge“ ein kleines L vor die Zahl und so wird es dann als Längenparameter ausgegeben.
Weitere Parameter werden in Kürze folgen, eine Wikiauflistung werde ich noch anlegen.
So könnte man auch mehrere Parameter z.B. lw20_40 (length, width) d.h. Länge 20mm und Breite 40mm
Das sieht auch sehr gut aus, vor allem mit dem Tabellenrahmen und dem eingeblendeten Thumbnail-Bild, das hilft einem ebenfalls sich schnell und sicher zu orientieren bzw. das Gewünschte aufzufinden. Wird in manchen Katalogen kommerzieller Anbieter auch oft so gehandhabt.
Zu der Sache mit dem L-Parameter hätte ich noch nen Alternativorschlag:
Du setzt die laufende Nummer (für die verfügbaren Größen) gleich hinter die „SubKat“-Spalte, aber nicht unbedingt einzeln aufgeführt, sondern vielleicht als von-bis-Angabe, also in der Form „0001 - 0009“ oder vielleicht noch besser „0001 … 0009“ und schreibst dann unter „Verfügbare Größen“ einfach den Namen des variablen Parameters voll aus und setzt die einzelnen Größen dahinter, also etwa „Länge: 40, 60, 80, 120, 160, 240, 320, 400, 640 mm“. Ich weiss nicht ob Dir das praktikabel erscheint aber es hätte zumindest den Vorteil, dass Du kein Kürzelsystem für die Parameter brauchst und der Nutzer demzufolge auch keines zu lernen braucht oder immer wieder auf die Legende schielen muss. Und Du brauchst dieses Kürzelsystem dann auch nicht zu pflegen und immer wieder upzudaten wenn mal völlig neue Arten von Parametern auftauchen.
Ein weiterer Vorteil ist, dass man nicht für jede Länge einen neuen Datensatz braucht.
Genau, die Bauteile sind ja ansich gleich, bis auf einen einzigen variablen Parameter, wie in diesem Fall die Länge. Ich finde es auch von der Optik her übersichtlicher wenn die allein in einer Tabellenzeile zusammengefasst sind.
Als Nächstes werde ich eine Legitimationsprüfung erstellen und auch das Tagsystem mit einer Funktion belegen. Ziel eines Tagsystems ist es ja, Objekte nach Tags durchsuchen zu können.
D.h. um zu Konstrukten zu kommen, braucht man eigentlich nur an alle notwendigen Teile ein Tag hängen und schon erhält man die Stückliste und Teileliste automatisch. >
Genau, das wären die Rückbezüge, die ich an dieser Stelle völlig ok und angemessen finde. Übrigens glaube ich das es reichen würde, wenn man sich dabei auf Referenzen zu den Konstrukten beschränkt, d.h., ich kann dem entnehmen, in welchen Konstrukten das Bauteil verwendet wurde. Für die Sets ist das glaubich nicht nötig, wer wissen will aus was ein Set besteht kann dort auch direkt nachschauen.
So ähnlich hatte ich es mir anfangs auch überlegt. Das Problem aber würde dann entstehen, wenn du nachträglich neue Größen hinzufügen willst, was dazu führen würde, dass dann eben die -0004 eben nicht mehr 120mm sondern dann vielleicht 100mm entspricht und man die 120mm unter der -0005 findet.
Dies wiederum führt zu dem Konflikt bei den Konstrukteuren, welche ja eine Stückliste angeben und pflegen, welche dann durcheinander kommen.
Daher muss man jeder Größe direkt eine Nummer zuordnen.
Und bezüglich der Kürzel, dies ist nur für Jene, welche die Listen im Wiki einpflegen von Interesse. Im Katalog selbst tauchen die Kürzel nicht auf bzw. werden als Info per Tooltip eingeblendet.
Die Listen im Wiki jedoch werden zukünftig nur auserwählte Leute pflegen dürfen, welche sich mit den Kürzeln auskennen und wissen wo sie diese finden oder auch erweitern können.
Damit jeder Nutzer jedoch die Chance hat, neue Teile einpflegen zu können, wird es eine Seite „Request“ geben, in der er seine Teile samt Bild und CAD-Dateien angeben kann. Die verantwortlichen Admins werden dann jene Daten in die Liste passend eintragen oder den Request ablehnen, z.B. wenn ein solches Teil bereits existiert.
Pss: vielleicht schon gemerkt, ich hab die baukasten.php aus dem Testordner in einen nun festen Ordner verschoben. Die alten Links funktionieren demzufolge nicht mehr. Im Eingangposting habe ich den Link geändert.
Mein Vorschlag wäre die ersten beiden Ziffern als Buchstabenkürzel beizubehalten wie gehabt. Und die letzte Stelle wird mit einer Zahl von 1 bis 9 belegt, die wir mit den häufigsten Alu-Sorten (oder denen, die als erstes reinkommen) belegen, und die 0 steht dann für „alle übrigen“ oder „alles Mögliche“ bzw. "nicht näher spezifiziert.
Auf der Materialienseite stünde dann entsprechend :
Zu jedem Bauteil (bzw. jederer Gruppe gleichartiger Bauteile mit einem variablen Parameter) gehört auch noch ein Datenblatt, was ausser den Teilenummern und Kurzbescheibung auch noch die Langebschreibung, und die (2D-)Fertigungszeichnung, ev. eine 3D-Zeichnung und Verweise auf Bezugsquellen oder Selbstbauanleitungen etc. enthält. Sowie alle sonstigen Infos zu diesem Bauteil, die irgendwie anfallen. Dieses Datenblatt ist die letztendlich relevante Instanz.
Bislang wurde das noch nicht so richtig realisiert, d.h., ich habe das andeutungsweise in die Setbeschreibungen mit reingebastelt, aber das war erstmal nur ein Provisorium.
Aber wieauchimmer, ich habe lange überlegt, in welcher Form dieses Datenbatt realisiert sein sollte, z.B. als downloadbare pdf-Datei, oder als Wiki-Seite oder gar beides. Ich denke, im Einklang mit dem weiter oben im Thread gesagten ist Wiki-Seite das Mittel der Wahl. Denn eine .pdf-datei ist nicht browsable und wir brauchen auch die Möglichkeiten Links, etwa auf eine Herstellungsanleitung oder Jigs setzen zu können, auch bei Bezugsquellen ists netter wenn man gleich auf den Anbieter klicken kann, usw. Das ganze zusammengefasst als .pdf-Datei wäre ja immer noch als Option möglich, wenn jemand das wichtig findet und genug Zeit und Lust hätte das zu machen, aber uns ist erstmal mit ner Wiki-Seite besser gedient.
Warum ich das erwähne: Es wäre gut, wenn in der Katalogseite im Wiki eine Spalte für den Link auf das Datenblatt vorgesehen wäre. Da ist z.B. so eine Spalte „Bildlink (direkte URL)“ in der ein Vermerk „in Sammelordner verschoben“ steht, vielleicht könnte man die rausschmeissen und stattdessen umbenennen in „Datenblatt“ und dann (später) die jeweiligen Links auf die Datenblattseite da reinsetzen .
Und, wo wir gerade dabei sind, wäre es möglich die Spalte „verfügbare Größen“ weiter nach links, also direkt hinter „SubKat“ und noch vor „Kurzbeschreibung“ zu setzen ? Irgendwie gehört das ja noch zur Teilenummer und es macht mich etwas nervös wenns weiter hinten frei im Raum floatet
Ja, unbedingt, die Teilenummer MUSS eindeutig sein und bleiben, da ist nicht dran zu rütteln !!!
Wobei aber, und das ist mir noch nicht so recht klar, das ja ein inhaltliches Problem ist und hier gehts erstmal nur um die Frage der Darstellung. Aber dazu gleich noch was und erstmal zu dem inhaltlichen Problem: Du hast auf jedenfall recht damit, dass es ein könnte, das auf Pool-Ebene später noch Zwischengrößen eingeführt werden könnten. In dem Fall würde man die nächste noch freie fortlaufende Nummer vergeben und nicht etwa anfangen, alle Teilenummern zu shiften, aus den von Dir genannten Gründen. Dh, die fortlaufende Nummerierung wird im Hinblick auf die aufsteigenden Größen fragmentiert, bzw. umgekehrt: die aufsteigenden Größen im Hinblick auf die fortlaufende Nummerierung. Das liegt aber in der Natur der Sache und ist eigentlich auch nicht weiter schlimm, da man es durch eine geeignete Darstellung im Katalog kompensieren kann.
Und was das betrifft hast Du natürlich auch damit recht, dass eine Schreibweise wie „0001 … 0009“ dann nicht mehr funktionieren würde. m.E. wäre hier die sauberste Lösung, die Numern tatsächlich voll auszuschreiben, dann kann man später problemlos was zwischenfügen.
D.h., vor der Ergänzung steht in einer Spalte
„0001, 0002, 0003,…“ und in der anderen Spalte „Länge: 40, 60, 80,…“.
Wenn dann später etwa eine Länge „45“ ergänzt würde, dann würde man das in beiden Spalten ergänzen, also
"„0001, 0010, 0002, 0003,…“ und in der anderen Spalte „Länge: 40, 45, 60, 80,…“.
Für den Benutzer ist die Nummerierungs-Spalte erst mal egal, er wird seine Aufmerksamkeit vor allem auf die zweite Spalte mit den Längenangaben richten, um rauszufinden, ob die von ihm benötigte Länge enthalten ist oder was es an alternativen Längen so gibt.
Wenn mans ganz edel machen wollte könnte man ev.noch die Einträge in beiden Spalten durch Zeilenumbrüche formatieren so das sich korrespondierende Paare auf gleicher Höhe gegenüberliegen, aber ich weiss nicht ob es sich wirklich lohnen würde diesen Aufwand zu treiben, da ich tendenziell davon ausgehe, dass der Fall von nachträglich einzufügenden Zwischengrößen eher selten auftreten wird, wenngleich man es natürlich prinzipiell schon mit einkalkulieren und berücksichtigen bzw. ermöglichen muss.
Und bezüglich der Kürzel, dies ist nur für Jene, welche die Listen im Wiki einpflegen von Interesse. Im Katalog selbst tauchen die Kürzel nicht auf bzw. werden als Info per Tooltip eingeblendet.
Die Listen im Wiki jedoch werden zukünftig nur auserwählte Leute pflegen dürfen, welche sich mit den Kürzeln auskennen und wissen wo sie diese finden oder auch erweitern können.
Damit jeder Nutzer jedoch die Chance hat, neue Teile einpflegen zu können, wird es eine Seite „Request“ geben, in der er seine Teile samt Bild und CAD-Dateien angeben kann. Die verantwortlichen Admins werden dann jene Daten in die Liste passend eintragen oder den Request ablehnen, z.B. wenn ein solches Teil bereits existiert.
