Archicad 28 TP - Globale Bibliotheken - Migration / Individuelle erstellen

[Frank Beister]

Ich mache jetzt mal den Faulen und frage ganz dumm, obwohl ich doch auch etwas recherchiert habe:

Mit AC28 kommen die neuen globalen Bibliotheken. Das Konzept ist schon mal ganz gut, auch wenn ich meine Zweifel habe, dass die Notwendigkeit 20 Bibliotheken zum Projekt zu laden das Verständnis für die Bibliotheken verbessert. Aber darüber will ich gar nicht reden. Einfacher wird es jedenfalls nicht.

Ich habe ein paar Fragen zu Migration und v.a. Neu erstellen:

1. Hat schon jemand seine Vorlage migriert und kann einen Erfahrungsbericht (außer diesem) geben? Und wird es ein Tool geben, das die Migration vereinfacht? Denn bei allen Elementen, platziert oder Favorit, das Pendant zu suchen und mit Pipette und Spritze zu übertragen wird bei guten Vorlagen echt mühsam.
2. Zum Aufbau einer eigenen Bibliothek mit eigenen Objekten kann man diese ja nun nicht nur internationalisieren sondern auch einzelne Objekte in die Standard-Ordner-Struktur einfädeln. Also eine neue Tür liegt dann auch im Türenordner und nicht in der bim-all-doors Bibliothek. Das alles geht per JSON und Textdateien. Auch für die Übersetzung von Ordner-, Datei- und Objektnamen bis zu Parameternamen. Sehr gut für die Analyse, aber für die Eingabe sehr umständlich und fehlerträchtig. Wird es dazu ein Tool geben? Und/oder eine genauere Beschreibung des Formates bzw. der Bedeutung der Tags? Ist dann z.B. eine eigene Bürobibliothek eine "essential library"?
3. Die Bibliothekselement-Palette hat ja eine Reihe neuer Funktionen. Gibt es eine Anleitung zu den Funktionen?
4. Wenn ich das richtig gelesen habe kann man die Parameter-Einstellungen eines Objektes als JSON exportieren, extern bearbeiten und wieder einlesen. Ich habe diese Funktion allerdings noch nicht gefunden. Hinweise?

Ich weiß, dass die Entwickler hier nicht mitlesen, aber ein paar GDLer sind ja doch an Bord, vielleicht kämpfen ja noch mehr an der Aufgabe.

[torben_wadlinger]

Ich lehne mich jetzt mal aus dem Fenster: ohne mich bisher um das Thema der globalen Bibliothek gekümmert zu haben, vermute ich, dass wir auch bei diesem Thema wieder Zeuge der fatalen Entscheidung von GS sind, die existierende Software im laufenden Betrieb zu modernisieren. Nur dass wir eben jetzt bei den Bibliotheken angekommen sind. 

Ich hatte schon vor Jahren, ich glaube es war kurz nach Huw's Einritt in die Firma, in einem Beitrag geschrieben, dass dieses Unterfangen scheitern muss und dass es technisch und unternehmerisch besser wäre einen klaren Schlussstrich zu ziehen und das Produkt von Grund auf neu zu entwickeln. Wir wäre alle glücklich gewesen, wenn es Bugfixes für das laufende Produkt gegeben hätte und gleichzeitig ein neues Produkt auf neuer Codebasis entstanden wäre. Es wären uns viele Dinge erspart geblieben (das Maßketten-Desaster, das Textboxen-Desaster, das Geschwindigkeits-Desaster), und jetzt, 5 Jahre später, hätten wir eine neue, moderne Software. Vielleicht hätten wir sogar ein halbes Jahr nach der Einführung der M-Prozessoren auch eine angepasste Version gehabt - statt zwei Jahre später und als Vorletzte (vor AutoCAD für Mac).

Und ich fürchte es wird so sein wie Frank es schreibt: die letzten 20% werden nicht erreicht werden und wir werden mit unfertiger Software arbeiten müssen. Wie immer.

Ich hoffe inständig, dass GS aus der Vergangenheit etwas gelernt hat und anfängt Archicad auf ARM für Windows zu portieren. Die X86-Architektur ist technologisch am Ende. Intel bekommt weder die Strukturbreiten in den Griff noch die Temperaturen und den Stromverbrauch. 

Und die KI-Bausteine in den Prozessoren von Apple und Qualcomm sind wie dafür gemacht Routineaufgaben zu übernehmen. Übrigens wäre das etwas worin man Revit voraus wäre, wenn man denn endlich mal Plattform-gerecht entwickeln würde und nicht über ein plattformübergreifendes Framework.

Ich bin an dieser Stelle vom Produktmanagement wirklich enttäuscht. Es fehlt im Unternehmen die visionäre Kraft und der Mut Archicad neu zu denken, neue Ansätze zu entwickeln. Denn am Geld kann es ja nicht liegen …

[Frank Beister]

Uiui. Den Sturm wollte ich gar nicht auslösen und schon wieder einen Pranger aufstellen, sondern Defizite und Lösungen diskutieren. Erstmal: Ich kann euch sehr gut verstehen, dass die letzten Jahre Spuren hinterlassen haben. Ich hatte "das Glück" schon länger nicht mehr operativ 40/5 mit Archicad zu arbeiten. daher kann ich etwas gelassener sein. Ich versuche das in jedem Fall nicht persönlich zu nehmen, sondern den Verantwortlichen, und zu einigen haben wir ja Kontakt, stetig zu spiegeln, was schief läuft.

Allgemein: Wir wollten dieses ewige "im Juli müssen tolle neue Funktionen fertig sein und müssen gnadenlos veröffentlicht werden" geändert haben, damit es besser ein gleitender Prozess mit kontinuierlichen Updates wird. Das gibt das Konzept zumindest her. Auch die Intransparenz hat sich drastisch geändert und ich sehe Bemühungen den Kundenkontakt besser zu machen.

Die GL haben das Zeug eine Reihe von Problemen anzupacken. Sie sind schon ein gewisser cut, aber nicht so radikal, dass alte Objekte prinzipiell nicht mehr funktionieren. Das finde ich prinzipiell gut. Dass Neues, wie seit 10 (?) Jahren üblich, noch verbesserungswürdig ist, ist bedauerlich, aber die Funktion hätte ich jetzt nicht als experimentell eingestuft und das alte System funktioniert ja auch noch. Auf der anderen Seite sehe ich eine Reihe von wirklich guten Ansätzen. Schon alleine die Versionskompatibilität und die Mehrsprachigkeit. Auch das über JSON und XML zu lösen und nicht wie z.B. in Smartparts alles in geschlossenem Code, wo man nicht mal selbst Hand anlegen kann.

Lukas, wo siehst du denn diese metrische Tonne an Problemen?  Ich muss gestehen, dass ich Beta und TP nur reduziert verfolgt habe. Ist mir da noch mehr durchgegangen? Soll denn keine Verbindung zu LibraryGlobals mehr hergestellt werden können? Eine Steuerung der Detaillierung ist sinnvoll nur durch die Skripte möglich, wieso sollte das GS nicht nachrüsten, da es eine essentielle Schraube im BIM Prozess ist?

M.E. teile ich die Meinung von GS, dass das Erstellen ganzer Bibliotheken eine 1 von 1000 Anwendung ist und v.a. Spezialwissen erforderert. Dazu brauche ich dann auch kein durchdesigntes UI, weil ich von einem (Objekt-)Programmierer schon mal die eine oder andere Abstraktion erwarten kann. Ich behaupte jetzt mal, dass in DACH das auch maximal 20 Leute für die Bibliothekenerstellung nutzen werden.  Der Rest muss es "nur" smart anwenden können. 

Vielleicht sollten wir ganz konkret und nicht diffus ("das wird nix", "das zerfranst") zusammenstellen, was die Probleme sind.

Und Torben ja, so ein Neuanfang oder Konsolidierung wie mit Archicad 10 wird immer deutlicher nötig. Das muss aber auch damit kein ganz neues Produkt werden. GS hatte ja vorgestellt, dass sie sehr viel Resourcen in einen flexibleren Unterbau gesteckt haben, und ja, die Früchte sollten wir langsam ernten, dass es am Frontend wieder mehr rockt.

[Frank Beister]

Danke für den Hinweis mit dem Subtyp. Das kenne ich natürlich und das hat auch seinen Sinn. Das mit der Vorauswahl der Klassifizierung kannte ich allerdings nicht. Dafür ist die Zuordnung aber unterirdisch gepflegt. Ein Großteil ist völlig unzureichend zugeordnet, auch bei OOTB Projekten. Außerdem kann ich die generelle Zuordnung auch zu einem anderen Klassifizierungssystem ändern. Wäre gut wenn das dann gleich zu mehreren möglich wäre.

[EDIT] Es IST möglich alle Klassifizierung voreinzustellen! Cool. So kann man Gruppen von Objekten einen Vorschlag für die Klassifizierung mitgeben. Warum nutzt das keiner (auch nicht GS)?  DAS wäre ein Punkt für GS, dass, wenn schon die Bibliotheken neu angelegt werden, die Subtypen detaillierter werden und eine vernünftige Zordnung erfolgt.

[runxel]

Mit dem "Zerfransen" der Nutzerlandschaft meinte ich folgendes (und das ist gar nicht mal so diffus):
Es wird jetzt folgendes passieren: Die einen werden so weitermachen, wie bisher. Das Bestandstemplate wird in die 28 übernommen und man arbeitet mit der – nun für immer eingefrorenen – 27er Bib weiter. Andere Büros werden auf einige Objekte, wie Hebeschiebetüren etc., nicht verzichten wollen, und ein neues Template aufbauen, mit der GL. Das wird erstmal ziemlich bitter und viel Zeit fressen, aber klar, in the long run ist das schöner.
Das bedeutet jedenfalls, dass auch die Erfahrungen innerhalb eines Sprachraums, was die Bibliotheken angeht, ganz grundsätzlich sich unterscheiden werden, und über einen mittelfristigen Zeitraum auch weiter abdriften. Das war bislang nicht so. Unterschiede zu anderen Ländern, ja, das war klar, das kannte man, aber jetzt wird man im Forum hier oder beim Support auch immer mit dazu schreiben müssen, welche Bibliotheksart man denn verwendet. Das erhöht den kognitiven Aufwand, aber dazu gleich noch mehr.
Hätte man das verhindern können? Ich weiß es nicht, aber unglücklich darf ich es trotzdem finden.
 
Ein ungeklärtes Biest ist, was passiert denn, wenn doch mal eine Änderung im GDL selbst erfolgt. Bislang war GDL bis zum 20er Bruch als jüngstes Beispiel immer aufwärtskompatibel (und mit dem runterspeichern auch bedingt abwärtskompatibel). Trotz der engen Verbindung von Objekt/GDL zu AC Version war das nicht dramatisch. Man hat migriert und dann war es in 95% der Fälle auch in Ordnung. Mit einer versionslosen Bibliothek – die auch ihre Vorzüge hat bzw. später haben wird, gar keine Frage! – ist das nicht mehr so trivial, was in dem Fall passiert. Ich bin extrem gespannt, wie sie das lösen wollen, denn das ist letztlich eine Versionierung durch die Hintertür.
Die Grundaussage, die ich zwischen den Zeilen gelesen habe, ist allerdings, dass man erstmal sagt "habe fertig". Einige neue Befehle oder Verbesserungen, die wir uns als Coder wünschen würden, rücken damit traurigerweise in weite Ferne. Das ist für das Ökosystem "GDL" aus meiner Sicht schade. Da hätte ich mir den Mut zu mehr Erneuerung gewünscht. Das wäre ja zu dieser Version 28 passend gewesen und da hätte ich mehr Verständnis für aufgebracht.

Noch mal zum kognitiven Overload:
Sich da 60+ Bibliotheken reinzuladen kann nur zur Katastrophe führen. Man sieht doch überhaupt nicht mehr durch. Komplexität muss man manchmal abbilden, aber Einfach ist immer besser. Wir wollen unser Leben doch nicht noch schwieriger machen, als nötig.
Angetreten ist die GL ja auch mit dem Werbespruch, dass unterschiedliche Nutzer ja nicht mehr alles laden müssen. Das halte ich aber für sehr merkwürdig, denn so funktioniert Archicad ja nunmal nicht. Die Bibliotheken sind in der Datei verlinkt – und nicht beim User. Also wird sich doch keiner hinstellen, die Dateien laden, mit allem drum und dran, und dann sagen, naja ich bin ja Ingenieur, oder welche Sau auch immer durchs Dorf getrieben wird, ich muss mir ja die Stühle nicht anzeigen lassen. Dann löscht der Kandidat die Bib raus, hat viele schwarze Punkte durchs Modell fliegen, gut egal, zack gespeichert, und der BIM Koordinator flucht. Da ergibt sich für mich überhaupt keine Logik.
Andersrum: Gut, ist gekauft. Wenn man die elende Elchtest-A-Klasse nicht mehr sehen will, dann kann man die jetzt einfacher loswerden. Durch die teilweise Abhängigkeit der Pakete von einander wird aber auch das wieder aufgeweicht. In jedem Fall hätte ich mir da eine bessere Organisation gewünscht. Vielleicht so einen kleinen Dialog mit Checkboxen „yo, was willste denn haben, Chefe?“. Das muss man sich jetzt stattdesen selbst zusammen klicken – und da sage ich nur „Viel Spaß oder Glück“ beim Übersichtbehalten.

Es gibt noch andere Probleme. Einige haben sich schon verbessert. In der Beta war das Laden der GL schnarchlangsam. Ein leeres (!) Projekt brauchte bis zu 10 Minuten zum Laden, gut gefüllte .... naja, noch viel länger. Das hat sich stark verbessert, und da bin ich froh drüber. Aber die Ladezeit ist dennoch immer noch etwa doppelt so lang (ca. 20 statt 10 sec bei kleinen/leeren Projekten), wie mit der Monolithischen. Das ergibt sich zumindest aus meinen eigenen Tests. Darauf werde ich mal ein Auge haben, wie sich das langfristig entwickelt. Aber trotzdem mal wieder ein Schritt in die falsche Richtung. Wenn, dann wollen wir ja mehr Performance, nicht weniger…

Ganz prinzipiell nicht nutzbar ist für mich die GL aber allein durch die Kastrierung von Funktion. Das separate Einstellen der Detailtiefe ist für mich beim Bauen im Bestand essentiell.
Ich bin sehr unzufrieden damit, weil dazu hahnebüchene Aussagen getroffen worden sind (sehr witzig, dass du ausgerechnet mit BIM argumentierst; GS argumentierte genau umgekehrt, aber aus dem selben Grund....).
Also kurzum, um dir den Zahn zu ziehen: Diese Funktion wird in dieser Form definitiv nicht zurück kommen, das wurde leider sehr klar kommuniziert, trotz allem Geschimpfe. Vielleicht kommt es in anderer Art. Vielleicht. Aber irgendwann, keinesfalls zeitnah oder gar in einem Update.
 
Zum Thema der Vor-Zuordnung: Warum das so unbekannt ist und nicht weiter verfolgt wird, frage ich mich auch....
Man ist aber durch die Kopplung an den Objekt-Subtype ja durchaus etwas beschränkt. Um das Potential voll auszuschöpfen, muss man wohl seine eigene Bibliothek mit eigenen Subtypen ausstatten, auch weil die Zuordnungen zu den Objekt-Subtypen von GS selbst in der OOTB Bib nicht immer konsequent oder intuitiv sind. Viele Objekte sind z.B. auch einfach nur „Modellelement“. Mit dieser „Catch-All“-Kategorie kann man hier wenig(er) anfangen. Welche Vor-Zuordnung würde man da wählen?
Insofern ist das eine Funktion, die wirklich beim Template-Ersteller liegt – aber eben im Zusammenspiel mit dem, der die Bürobibliothek schreibt. Muss ja nicht immer die gleiche Person sein.
Da würde mich in dem Zusammenhang auch mal interessieren, wie so die Verteilung aussieht, wie viele Büros (ausschließlich) mit eigener Klassifizierung arbeiten, und wie viele tatsächlich einfach die AC OOTB Klassifizierung OHNE jegliche Änderung verwenden (die ja auch nicht migrierbar ist! – also zumindest nicht ohne eigenes Zutun.)

[Frank Beister]

Kognitive Fähigkeiten
Ich denke Support und Forum können sich darauf gut einstellen. Wer schon mit den bisherigen Bibs nicht klar kommt, und das sind nicht wenige, kommt auch mit den neuen nicht klar. Dann muss er halt mal nachlesen oder sich helfen lassen. Wir machen ja schließlich Architektur und CAD sogar mit BIM und fegen nicht den Hof. Wir rufen nach mehr Freiheit und kommen dann nicht damit klar, wenn es komplexer wird.

Versionierung
Ich sehe da keinerlei Nachteil. Wenn eine grundlegende Änderung kommt, dann funktionieren die Objekte halt nur ab einer bestimmten Version. Öffnest du eine neue Bib mit einer alten AC Version werden die neuen, inkompatiblen Objekte nicht angezeigt. Auch beim Support sehe ich da kein Problem. Ich habe früher immer die alte Bibliothek mit der neuen Version abgeglichen, um zu sehen, was sich geändert hat. Das war meist so wenig, dass es logisch ist nicht bei jeder neuen AC Version die alten Objekte inkompatibel zu schalten. Hilfreich wäre es, wenn die Fehlermeldungen, die beim Ladeneiner Bib entstehen können so einzudämmen, dass man sich die auch ansieht. Da würde man auch hinschauen, wenn eine Projekt-AC-Bib-Version - Inkompatibilität besteht.
Und es wird GS Aufgabe sein dann den Makro-Kosmos von den hoch verschachtelten Objekten am Laufen zu halten oder eben einen Fork aufzubauen. IMHO ist das unter der Haube und für den reinen Anwender und beherrschbar.

Übersicht behalten
Das Szenario, vor dem du Sorge hast, sehe ich nicht. Es geht doch darum, wie ich ein Projekt starte. Wenn ich keine Haustechnik mache, lasse ich diese Bibs einfach komplett raus, wenn ich es performanter möchte. Es ist doch nicht so gedacht, dass man im laufenden Projekt einfach mal Bibliotheken raus lässt. Das wird zumindest nicht schlimmer.
Das UI zur GL-Auswahl "unglücklich" zu bezeichnen wäre ein Euphemismus. Da wird niemand was raus lassen, so lange der Dialog so ist. Denn da behält keiner die Übersicht. Die Standardbibliotheken müssen in einen lokalisierten, übersichtlichen Dialog.

Die Performance sollte doch eigentlich besser werden. bei der ersten Beta wurde ja auch erklärt, dass das mit dem Entwicklungsstadium zusammen hing. Und wenn die Bibliothek immer größer und komplexer wird ist ein möglicher Schritt sie modular aufzubauen, sodass nicht alles geladen sein muss. Ist die Funktion Objekte auf Eignung zur Hintergrundaktualisierung zu testen eigentlich neu?

Funktionsumfang
Ich hoffe, dass die Einstellung der Detailtiefe nicht dauerhaft beschnitten wird. Da sehe ich v.a. Holger in der Pflicht, das wieder zu integrieren. Gibt es noch weitere Abweichungen funktioneller Art oder im UI/Handling? Was gar nicht geht, ist dass die GL weniger leistet als die monolithische. Dann würdest du mit deinem skizzierten Szenario recht behalten.

Klassifizierung von Subtypen
Da ist GS DE in der Pflicht das für die OOTB Templates korrekt einzustellen. Ich hatte auch mal begonnen eigene Subtypen zu erstellen, das lohnt sich aber nur, wenn man wirklich eigene Objektgruppen hat. Dann hat man nämlich auch immer den gleichen Grund-Parametersatz dabei. Ansonsten ist es sinnvoll die eigenen Objekte auch korrekt zuzuordnen. Da war ich meist etwas nachlässig. Da man aber ohnehin mehr mit Favoriten arbeiten sollte, muss man das auch nicht zu hoch bewerten.

Bürostandards
Viel spannender sehe ich die Option nun endlich Bürostandards der Attribute in eine Bib einpflegen zu können. Und dass das nicht mit jeder neuen Version verloren geht wäre ein riesen Schritt voran.

Aber nochmal:
Gibt es weitere konkrete Punkte, die geändert werden müssen. Und vielleicht kann Bence nochmal was zu der Entscheidung von GS-DE dazu sagen. Ist ja nicht so toll, wenn die GL als tolles neues Feature vermarktet wird und die Empfehlung ist es nicht zu nutzen. (Das ist wie autonomes Auto fahren, das man eigentlich nicht nutzen soll.)

[Bernhard Binder]

Eine wichtige Frage: gibt es außer den beiden hier erwähnten Einschränkungen bei den Objekten (keine Möglichkeit im Objekt die Modelldarstellung zu überschreiben, keine Möglichkeit Objekte einzeln in 3D nicht darzustellen) noch weitere Probleme, die bei der Verwendung der GL zu erwarten sind?

Ich meine jetzt, wenn man ein neues Template mit AC28 beginnt und das Thema Migration und unpraktischer Verwaltung der Bibliotheken mal ausnimmt.

[runxel]

Naja... ist ja wohl gravierend genug, oder?

Das klingt so lapidar, Bernhard. 😄

[runxel]

Ich glaube, wir reden vielleicht ein bisschen aneinander vorbei.

Bei einigem stimme ich dir ja zu.

Nur, was glaube ich nicht ganz rüberkam, ist mein Frust, dass teilweise bei GS das eigene Produkt nicht verstanden wird.

Es ist doch nicht so gedacht, dass man im laufenden Projekt einfach mal Bibliotheken raus lässt

Doch doch... ich zitierte! Ich finde das, wie du, so derartig abwegig, dass ich niemals selbst darauf gekommen wäre. Das ist ja ein direktes Zitat, ein erklärtes Ziel.

Ist die Funktion Objekte auf Eignung zur Hintergrundaktualisierung zu testen eigentlich neu?

Nein, gibts auch schon länger.

Also abschließend: Es gibt noch viel zu tun und etlichen Verbesserungsbedarf. Ich habe eben nur die Angst, dass, wie in den letzten 10 Jahren immer, Projekte angefasst und dann in so einem semi-kaputten Zustand gelassen werden. Ich will ja auch nicht immer nur maulen 😉 – die Hintergedanken sind gut, die Ausführung noch holprig. Der Grundbaustein ist gelegt, aber nun muss geliefert werden. Solange die beschriebenen Einschränkungen bestehen, werde ich die GL bei mir nicht nutzen.

[Bernhard Binder]

Nein, bitte nicht falsch verstehen, das sind natürlich ernst zu nehmende Einschränkungen. Ich wollte nur wissen, ob euch bereits irgendetwas anderes zusätzlich untergekommen ist.

[Bence Zobor]

Hi @Bernhard Binder,  die Grundeinstellungen der Objekte sind großteils nur aus der INT Einstellungen übernommen. Diese sind dadurch anders als sie vorher in der deutsche/österreichische Bibliothek waren. Teilweise neue Funktionen sind eingeschaltet, die aus der Schweizer Bibliothek kommen, die wir nicht als Standard einstellen würden. Diese Punkte fallen mir jetzt zusätzlich zu den vor Dir auch schon erwähnten Einschränkungen ein.