Archicad - Verbesserung der Elementstruktur
Ich arbeite sein einigen Jahren mit ArchiCad und habe auch einen Blick über den Tellerrand bei Konkurenzprodukten wagen können. Nachdem ich nun täglich mit ArchiCAD arbeiten muss, sind mir so die einen und anderen Dinge aufgefallen, die mich schon arg stören.
Ich habe immer das Gefühl den Dingen hinterher zu arbeiten und das sich das Eigentliche was ich machen möchte nicht so schnell erledigt ist wie es sollte – es bleibt immer ein Nachgeschmack der Unzufriedenheit und das schlechte Gewissen, dass ich es irgendwann nacharbeiten muss.
Ich habe einige Zeit mit der Problemanalyse beschäftigt und musste für mich feststellen, dass ArchiCad eine unmögliche Art von Workflow an den Tag legt.
Ich habe den Wunsch, dass ArchiCAD eine richtig typisierte Elementstruktur entwickelt.
Denn eigentlich geht es doch darum Elemente in 2D – oder 3D zu erstellen und ihnen ihre Eigenschaften ihres Daseins mitzugeben. Viele Arbeitsschritte nerven einfach und könnten auch obsolet sein. ArchiCad ist voll von problemorientierten Lösungen die eigentlich die Sackgassenprogrammierung umschiffen sollen und dabei an die Grenzen stoßen oder nicht zu Ende gedacht sind.
Sei es bei den Baustoffen, welche mühsam mit bauphysikalischen Werten versehen werden könnten, jedoch diese Werte bereits bei den mehrschichtigen Bauteilen verloren sind und über IFC so gleich gar nicht exportiert werden.
Über die bauteilspezifischen Eigenschaften, welche ich eigentlich global für ein mehrschichtiges Bauteil definieren müsste – die wiederum dann in den Eigenschaften der jeweiligen Wand definiert werden müssen. Hier ist der eine Gedankenansatz nicht zu Ende Gedacht und ein Anderer angefangen und implementiert worden. Mir fehlt es ganz stark an der Logik des Programmes! An Stelle sich einer konsequenten Struktur zu bedienen, wird hier nur problemorientiert irgendetwas programmiert womit der Endbenutzer dann zurechtkommen muss. Noch schlimmer – es werden Sackgassen konzipiert.
So kann sich ein Programm nicht weiter entwickeln sondern nur auf der Stelle treten und an neuen Lösungen für das Umschiffen von bereits implementierten Fehlern arbeiten. Ich habe es seit Jahren verfolgt. Immer werden neue Workarounds und Tools um bekannte Probleme entwickelt. Anstelle Abläufe zu verbessern oder neu zu überdenken. Eine Datenflut erschlägt den Benutzer bei jeder Eingabe und ein riesiger Aufwand der Dokumentation seitens der Entwickler fällt an. Sei es drum, um die kleinen fehlerhaften und fehlenden Optionen, welche viele Anwender nerven wie etwa ein einfacher „Anwenden“ Button um Änderungen an Objekteinstellungen zu überprüfen ohne dass dich der Einstellungsdialog schließt und man gezwungen ist diesen wieder zu aktivieren und die Einstellung erneut aufzusuchen – hier zeigt sich das Design, welches von Nichtbenutzern implementiert wurde. Oder – mehrere Elemente auf verschiedenen Ebenen markieren und dann eine neuen Ebene zuweisen klappt je nach Auswahl und jeweiliger Aart der Elemente und deren Ebenenzugehörigkeit nur sporadisch – warum? Was ist so schwierig daran? Man könnte hier die Liste an Beispielen weiter führen.
Als einfaches Beispiel der Suchen & aktivieren Dialog:
Bei Auswahl eines Objektes müsste es eigentlich reichen, mit der rechten Maustaste den Befehl: „gleiche Elemente auswählen“ abzusenden. Dann werden z.Bsp. alle Fenster des gleichen Typs gewählt, oder sämtliche Wände des selben Bauteils. Eigentlich die Objekte, wie sie in den Favoriten erstellt abgelegt werden könnten. Es geht hier weniger wo die Elemente liegen oder in welchen Bauteil sie stecken, sondern nur die Elemente selbst. Doch das geht in Archicad nicht so einfach, denn durch die Art wie die Elemente erstellt wurden und dass diese individuell geändert sein könnten, besteht die Möglichkeit nicht alle diese Elemente einfach zu finden ohne besondere Filterung durch den Auswahldialog. Das Programm hat an diesem Punkt bereits die Kontrolle abgegeben. Und schon befinden wir uns in der wüsten Gedankenschleife des ArchiCAD 😉
Am besten ein Tool entwickeln welches auf all die Bedürfnisse der Elemente eingeht. Der Benutzer hat erstellt – der wird wissen was zu tun ist. Benutzer: Tja. was soll der Benutzer nun machen… Aus bestem Gewissen und Wissen die möglichen Kriterien manuell hinzufügen. Ohne Routine nicht zu wissen was er tut. Dabei kann er nun mit der Pipette Elemente wählen, oder eine Auswahl tätigen und viel Zeit in trys & erros investieren um nur mal eben ein paar Elemente des selben syles zu markieren. – Klappt doch toll dieses Auswahlwerkzeug. Es wählt das aus was der Benutzer definiert. Wenn er denn weiß was er definiert.
- Wie ermüdend.
Eigentlich kann man das ganze Dilemma auf den Punkt bringen und Konstatieren, dass sich die Elemente zurück referenzieren lassen müssen um sich über einen Typ konkret zu definieren. Es reicht eben nicht aus zu wissen ob es sich bei dem Objekt um eine Wand oder eine Tür handelt wenn alles andere individuell sein kann. Ein Typ muss neben den individuellen Eigenschaften auch alle arttypischen Daten enthalten. Das Programm muss doch in der Lage sein, seine Elemente zu verwalten. Es kann doch nicht sein, dass es vom Benutzer verlangt wird dies zu tun. Die Software soll doch unterstützen. Eingabedialoge mit vielen Fragen sind doch nur der Software nützlich, nicht dem Benutzer.
Ich würde die Struktur der Typendefinition für sämtliche zu erstellende Elemente begrüßen und es würde auch AC einen großen Schritt voran bringen.
Ich habe einmal eine Grafik erstellt, welche das Schema der Elementenverwaltung nach meinem Empfinden darstellt und wie es effektiver sein könnte. Viele Probleme würden sich zentraler und übergreifender handlen lassen.
Derzeit werden jede Art von Element als ein eigenes Element erstellt. Durchaus mit Schablonen wie Favoriten oder die Bauteile aus dem Werkzeugkasten, jedoch immer mit der Möglichkeit der individuellen und unabhängigen Einstellmöglichkeit wie Dicke, Baustoff, Farbe, Schraffur, Ebene, Höhe etc, tec.. Dieses Element ist doch keinem Schema mehr zuzuweisen oder wieder zu finden. Einzig und alleine das Grundelement Wand, Decke , Sturz , Stütze etc, ist hinterlegt. Das reicht doch nicht aus. Eine typisierte Struktur erlaubt dies alles auch, jedoch basiert die typisierte Struktur auf einem Kontrollelement - dem Typ - welcher ausschlaggebend für die weitere Verwendung innerhalb des Programmes und dem Benutzer eine Schnittstelle bietet. Diese Problematik ist meiner Meinung nach der Auslöser dieser vielen unstrukturierten und individuellen Lösungen mit denen sich die Benutzer über die Runden helfen und nach "Lösungen" und "Tools" schreien, welche dann auch dargeboten werden.
Neben den herkömmlichen „dummen“ 2D Elementen, wäre es sicherlich gut ebenso wie Bauteile auch Linientypen und Schraffurtypen zu erstellen und als eigenständige Elemente zu definieren und denen einen typenbasierten Namen zu geben. Bsp.: Konturlinie, Linie Begrenzung, Parkplatzlinie, Feuerwehrstandfläche, Grünfläche etc. .
Im Grunde eine Art Katalog mit den verschiedenen Typen mit der Art der Darstellung (Farbe, Linienstärke, Linienart usw.) zu erstellen. Der Vorteil wäre eine bessere Verwaltbarkeit („Konsistenz“) im Projekt, ein sicheres auffinden der Objekte bei Mehrfachauswahl und ein leichteres und problemloses ändern der verwendeten Linien im Projekt.
Eine Linie auswählen -> Eigenschaften anpassen –Fertig -> alle diese verwendeten Linien welche auf diesen Typ referenzieren würden geändert dargestellt werden. auch die Dateigröße würde stark reduziert werden, da nicht für jede Linie ein ganzes Eigenschaftenset mitgeführt werden muss, sondern nur eine ReferenzID.
Man könnte sogar einen Schritt weiter gehen und Ebenen hiervon direkt ableiten. Eine individuelle Zuweisung wäre dann obsolet.
Die herkömmlichen 2D Elemente können ja weiterhin zum Einsatz kommen und auf die Ebenen gelegt werden. – Für den der es braucht.
Ich wollte dies als Anregung für Verbesserungen loswerden, niemanden auf die Füße treten und die bisher geleistete Arbeit nicht in den Schmutz ziehen.
Ich denke man muss bestehende Strukturen in Frage stellen-, überdenken,,- und verbessern.
Ich weiß, dass ich hiermit viel Unmut bei einigen eingefleischten AC-usern formuliert habe. Jedoch lasst es sacken und lest es zweimal bevor Ihr kommentiert!
Ich bin in Kenntnis, dass gewisse angesprochene Punkte über diverse AC-Tools in korrekter Benutzung zu vermeiden/ zu beheben sind. - Darum geht es im Beitrag nicht.
Ich bin in Kenntnis dass im Text grammatikalische- und Rechtschreibfehler sind. – Darum geht es im Beitrag nicht.
Ich bin in Kenntnis dass ich außer ArchiCad auch andere Programme verwenden kann. – Darum geht es im Beitrag nicht. 😉
Einen schönen Abend.
Ich arbeite sein einigen Jahren mit ArchiCad und habe auch einen Blick über den Tellerrand bei Konkurenzprodukten wagen können. Nachdem ich nun täglich mit ArchiCAD arbeiten muss, sind mir so die einen und anderen Dinge aufgefallen, die mich schon arg stören.
Ich habe immer das Gefühl den Dingen hinterher zu arbeiten und das sich das Eigentliche was ich machen möchte nicht so schnell erledigt ist wie es sollte – es bleibt immer ein Nachgeschmack der Unzufriedenheit und das schlechte Gewissen, dass ich es irgendwann nacharbeiten muss.
Ich habe einige Zeit mit der Problemanalyse beschäftigt und musste für mich feststellen, dass ArchiCad eine unmögliche Art von Workflow an den Tag legt.
Ich habe den Wunsch, dass ArchiCAD eine richtig typisierte Elementstruktur entwickelt.
Denn eigentlich geht es doch darum Elemente in 2D – oder 3D zu erstellen und ihnen ihre Eigenschaften ihres Daseins mitzugeben. Viele Arbeitsschritte nerven einfach und könnten auch obsolet sein. ArchiCad ist voll von problemorientierten Lösungen die eigentlich die Sackgassenprogrammierung umschiffen sollen und dabei an die Grenzen stoßen oder nicht zu Ende gedacht sind.
Sei es bei den Baustoffen, welche mühsam mit bauphysikalischen Werten versehen werden könnten, jedoch diese Werte bereits bei den mehrschichtigen Bauteilen verloren sind und über IFC so gleich gar nicht exportiert werden.
Über die bauteilspezifischen Eigenschaften, welche ich eigentlich global für ein mehrschichtiges Bauteil definieren müsste – die wiederum dann in den Eigenschaften der jeweiligen Wand definiert werden müssen. Hier ist der eine Gedankenansatz nicht zu Ende Gedacht und ein Anderer angefangen und implementiert worden. Mir fehlt es ganz stark an der Logik des Programmes! An Stelle sich einer konsequenten Struktur zu bedienen, wird hier nur problemorientiert irgendetwas programmiert womit der Endbenutzer dann zurechtkommen muss. Noch schlimmer – es werden Sackgassen konzipiert.
So kann sich ein Programm nicht weiter entwickeln sondern nur auf der Stelle treten und an neuen Lösungen für das Umschiffen von bereits implementierten Fehlern arbeiten. Ich habe es seit Jahren verfolgt. Immer werden neue Workarounds und Tools um bekannte Probleme entwickelt. Anstelle Abläufe zu verbessern oder neu zu überdenken. Eine Datenflut erschlägt den Benutzer bei jeder Eingabe und ein riesiger Aufwand der Dokumentation seitens der Entwickler fällt an. Sei es drum, um die kleinen fehlerhaften und fehlenden Optionen, welche viele Anwender nerven wie etwa ein einfacher „Anwenden“ Button um Änderungen an Objekteinstellungen zu überprüfen ohne dass dich der Einstellungsdialog schließt und man gezwungen ist diesen wieder zu aktivieren und die Einstellung erneut aufzusuchen – hier zeigt sich das Design, welches von Nichtbenutzern implementiert wurde. Oder – mehrere Elemente auf verschiedenen Ebenen markieren und dann eine neuen Ebene zuweisen klappt je nach Auswahl und jeweiliger Aart der Elemente und deren Ebenenzugehörigkeit nur sporadisch – warum? Was ist so schwierig daran? Man könnte hier die Liste an Beispielen weiter führen.
Als einfaches Beispiel der Suchen & aktivieren Dialog:
Bei Auswahl eines Objektes müsste es eigentlich reichen, mit der rechten Maustaste den Befehl: „gleiche Elemente auswählen“ abzusenden. Dann werden z.Bsp. alle Fenster des gleichen Typs gewählt, oder sämtliche Wände des selben Bauteils. Eigentlich die Objekte, wie sie in den Favoriten erstellt abgelegt werden könnten. Es geht hier weniger wo die Elemente liegen oder in welchen Bauteil sie stecken, sondern nur die Elemente selbst. Doch das geht in Archicad nicht so einfach, denn durch die Art wie die Elemente erstellt wurden und dass diese individuell geändert sein könnten, besteht die Möglichkeit nicht alle diese Elemente einfach zu finden ohne besondere Filterung durch den Auswahldialog. Das Programm hat an diesem Punkt bereits die Kontrolle abgegeben. Und schon befinden wir uns in der wüsten Gedankenschleife des ArchiCAD 😉
Am besten ein Tool entwickeln welches auf all die Bedürfnisse der Elemente eingeht. Der Benutzer hat erstellt – der wird wissen was zu tun ist. Benutzer: Tja. was soll der Benutzer nun machen… Aus bestem Gewissen und Wissen die möglichen Kriterien manuell hinzufügen. Ohne Routine nicht zu wissen was er tut. Dabei kann er nun mit der Pipette Elemente wählen, oder eine Auswahl tätigen und viel Zeit in trys & erros investieren um nur mal eben ein paar Elemente des selben syles zu markieren. – Klappt doch toll dieses Auswahlwerkzeug. Es wählt das aus was der Benutzer definiert. Wenn er denn weiß was er definiert.
- Wie ermüdend.
Eigentlich kann man das ganze Dilemma auf den Punkt bringen und Konstatieren, dass sich die Elemente zurück referenzieren lassen müssen um sich über einen Typ konkret zu definieren. Es reicht eben nicht aus zu wissen ob es sich bei dem Objekt um eine Wand oder eine Tür handelt wenn alles andere individuell sein kann. Ein Typ muss neben den individuellen Eigenschaften auch alle arttypischen Daten enthalten. Das Programm muss doch in der Lage sein, seine Elemente zu verwalten. Es kann doch nicht sein, dass es vom Benutzer verlangt wird dies zu tun. Die Software soll doch unterstützen. Eingabedialoge mit vielen Fragen sind doch nur der Software nützlich, nicht dem Benutzer.
Ich würde die Struktur der Typendefinition für sämtliche zu erstellende Elemente begrüßen und es würde auch AC einen großen Schritt voran bringen.
Ich habe einmal eine Grafik erstellt, welche das Schema der Elementenverwaltung nach meinem Empfinden darstellt und wie es effektiver sein könnte. Viele Probleme würden sich zentraler und übergreifender handlen lassen.
Derzeit werden jede Art von Element als ein eigenes Element erstellt. Durchaus mit Schablonen wie Favoriten oder die Bauteile aus dem Werkzeugkasten, jedoch immer mit der Möglichkeit der individuellen und unabhängigen Einstellmöglichkeit wie Dicke, Baustoff, Farbe, Schraffur, Ebene, Höhe etc, tec.. Dieses Element ist doch keinem Schema mehr zuzuweisen oder wieder zu finden. Einzig und alleine das Grundelement Wand, Decke , Sturz , Stütze etc, ist hinterlegt. Das reicht doch nicht aus. Eine typisierte Struktur erlaubt dies alles auch, jedoch basiert die typisierte Struktur auf einem Kontrollelement - dem Typ - welcher ausschlaggebend für die weitere Verwendung innerhalb des Programmes und dem Benutzer eine Schnittstelle bietet. Diese Problematik ist meiner Meinung nach der Auslöser dieser vielen unstrukturierten und individuellen Lösungen mit denen sich die Benutzer über die Runden helfen und nach "Lösungen" und "Tools" schreien, welche dann auch dargeboten werden.
Neben den herkömmlichen „dummen“ 2D Elementen, wäre es sicherlich gut ebenso wie Bauteile auch Linientypen und Schraffurtypen zu erstellen und als eigenständige Elemente zu definieren und denen einen typenbasierten Namen zu geben. Bsp.: Konturlinie, Linie Begrenzung, Parkplatzlinie, Feuerwehrstandfläche, Grünfläche etc. .
Im Grunde eine Art Katalog mit den verschiedenen Typen mit der Art der Darstellung (Farbe, Linienstärke, Linienart usw.) zu erstellen. Der Vorteil wäre eine bessere Verwaltbarkeit („Konsistenz“) im Projekt, ein sicheres auffinden der Objekte bei Mehrfachauswahl und ein leichteres und problemloses ändern der verwendeten Linien im Projekt.
Eine Linie auswählen -> Eigenschaften anpassen –Fertig -> alle diese verwendeten Linien welche auf diesen Typ referenzieren würden geändert dargestellt werden. auch die Dateigröße würde stark reduziert werden, da nicht für jede Linie ein ganzes Eigenschaftenset mitgeführt werden muss, sondern nur eine ReferenzID.
Man könnte sogar einen Schritt weiter gehen und Ebenen hiervon direkt ableiten. Eine individuelle Zuweisung wäre dann obsolet.
Die herkömmlichen 2D Elemente können ja weiterhin zum Einsatz kommen und auf die Ebenen gelegt werden. – Für den der es braucht.
Ich wollte dies als Anregung für Verbesserungen loswerden, niemanden auf die Füße treten und die bisher geleistete Arbeit nicht in den Schmutz ziehen.
Ich denke man muss bestehende Strukturen in Frage stellen-, überdenken,,- und verbessern.
Ich weiß, dass ich hiermit viel Unmut bei einigen eingefleischten AC-usern formuliert habe. Jedoch lasst es sacken und lest es zweimal bevor Ihr kommentiert!
Ich bin in Kenntnis, dass gewisse angesprochene Punkte über diverse AC-Tools in korrekter Benutzung zu vermeiden/ zu beheben sind. - Darum geht es im Beitrag nicht.
Ich bin in Kenntnis dass im Text grammatikalische- und Rechtschreibfehler sind. – Darum geht es im Beitrag nicht.
Ich bin in Kenntnis dass ich außer ArchiCad auch andere Programme verwenden kann. – Darum geht es im Beitrag nicht. 😉
Einen schönen Abend.
Keine Antwort gefunden?
Andere Beiträge
im Board ansehen
Zurück zum Board
Neueste Lösungen durchsuchen
Akzeptierte Lösungen zeigenEine neue Diskussion starten!
Neues Thema erstellen