---

Alle Computerprogramme, CAD Systeme natürlich auch, werden von Software-Entwicklern erstellt. Nun ist aber nicht jeder Software-Entwickler auch gleichzeitig Konstrukteur. Software-Entwicklung ist wie die Konstruktion ein kreativer Prozess an dem man Freude haben muss. Ansonsten sollte man es, sowohl das Konstruieren wie auch das Programmieren, besser lassen.
Aber sollte es nicht jedem selbst überlassen sein, woran er meint Freude zu haben?
Leider haben Konstrukteure nicht die Möglichkeit den Software-Entwickler zum Konstruieren zu zwingen. Umgedreht aber offensichtlich schon.
Finden Sie nicht auch, dass die Konstrukteure regelrecht zum Programmieren gezwungen werden?
Immer dann wenn etwas während der Konstruktion nicht klappt, liegt es dann nicht an einer Systemvariable, einem Flag oder sonstigen Dingen?

An alle Programmierer:
Lasst den Konstruktueren die Freude an der Konstruktion!
Nicht jeder Konstrukteur ist auch Software-Entwickler und liebt das Programmieren so wie ihr!

Sieht das irgendjemand anders?

[Diese Nachricht wurde von AndreasK am 12. Mai 2000 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Andreas,
du hast vollkommen recht ;-)
Beim "nichtklappen" beim Konstruieren hast du aber einen Punkt vergessen:
- wir Konstrukteure sind schlichtweg zu dumm zum Bedienen der Software
- ausserdem wurde _viel_ zu wenig Schulung gekauft

ciao
Thomas

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen

Naja... ich würde es mir sehr wünsche, dass z.B. eine Outsourcing-Firma, die ein CAD-Produkt vertreibt, direkte Verbindungen zu den Software-Entwickler zusteht. Wir hatte vor kurzer Zeit noch von UG das sogenannte QTac (wir waren ausser GM die einzigen die einen solchen Service nutzen konnten). Wir sind unserem Kunden verpflichtet, Ihn immer auf einem technologischem neusten Stand zu bringen. Jetzt erhält man eine Beta-Version von einem z.B. UG v17 *grins* so könnten direkt mit den Betatestern die Bugs und andere Anregungen direkt beim Hersteller platzieren. Mit diesem QTac hatten wir die möglichkeit bei den Entwicklern grösseren druck, zur Behebung von Bugs zu erreichen.
Wir arbeiten in sehr engem Verhältnis mit dem Kunden und erfahren sehr viel, was der Kunde noch zu Konstruktion verwenden könnte und von anderen Kunden die ein solches Tool auch einen Verwendung sehen. Wir sind dann angewiesen Costumizing zu machen um das Produkt dem Kunden anzupassen. Wir sind uns wahrscheinlich einig, dass das Anpassen an die Kundenbedürfnisse eine sehr grosse Rolle spielen kann, bei evaluieren einer Software.

Durch die Mögichkeit bei UG/iMAN eine sehr tiefe, intergrierte Anpassung zu machen, sind unsere Anwendern sehr zu Frieden mit dem Produkt UG/iMAN. Dies ist ein Thema, das ich bei einigen CAD-Systen sehr vermisse oder man muss einen riesigen Aufwand treiben, die Kundenbedürfnisse zu decken.

Und das mit der Schulung. Es ist doch so, dass man die Software erst bei der Konstruktion richtig kennen lernt (als bei mir war es immer so). In einer Schulung werden nur bekannte Problematiken behandelt und wenn man nach der Schulung, produktiv arbeitet, stöst man immer auf Probleme, die man nicht geschult hat.

Hoffe auf weiter diskussionen, denn ich habe noch einige Punkte die man sicherlich noch in der CAD-Systementwicklung verschäft disskutieren sollte unter den Anwendern und Softwareentwickler.

MfG
DanyB

MfG

Zitat:

---

Original erstellt von AndreasK:
Alle Computerprogramme, CAD Systeme natürlich auch, werden von Software-Entwicklern erstellt. Nun ist aber nicht jeder Software-Entwickler auch gleichzeitig Konstrukteur. Software-Entwicklung ist wie die Konstruktion ein kreativer Prozess an dem man Freude haben muss. Ansonsten sollte man es, sowohl das Konstruieren wie auch das Programmieren, besser lassen.
Aber sollte es nicht jedem selbst überlassen sein, woran er meint Freude zu haben?
Leider haben Konstrukteure nicht die Möglichkeit den Software-Entwickler zum Konstruieren zu zwingen. Umgedreht aber offensichtlich schon.
Finden Sie nicht auch, dass die Konstrukteure regelrecht zum Programmieren gezwungen werden?
Immer dann wenn etwas während der Konstruktion nicht klappt, liegt es dann nicht an einer Systemvariable, einem Flag oder sonstigen Dingen?

An alle Programmierer:
Lasst den Konstruktueren die Freude an der Konstruktion!
Nicht jeder Konstrukteur ist auch Software-Entwickler und liebt das Programmieren so wie ihr!

Sieht das irgendjemand anders?

[Diese Nachricht wurde von AndreasK am 12. Mai 2000 editiert.]

---

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Als ehemaliger Ingenieur, jetzt Admin und Hobbyprogrammierer muss ich mich nun doch zu Wort melden (ist teilweise sarkastisch gemeint, also nicht gleich steinigen):

Zitat:

---

Original erstellt von AndreasK:
Finden Sie nicht auch, dass die Konstrukteure regelrecht zum Programmieren gezwungen werden?
Immer dann wenn etwas während der Konstruktion nicht klappt, liegt es dann nicht an einer Systemvariable, einem Flag oder sonstigen Dingen?

---

Ja, aber wer will denn diese ganzen Flags, Variablen und sowas alles haben? Der Programmierer weiss doch, was er tut (deswegen mach ich meine Betatests auch am liebsten mit meiner Frau, wo die alles draufdrückt ...), aber es kommen immer irgendwelche InGENIEure und wollen noch hier eine Option oder das mal zum ein- und ausschalten usw.

Und ganz ehrlich: der Vergleich mit dem Telefon ist doch ganz gut: an das gute alte Wahlscheibending konnte sich jeder ransetzen und sofort telefonieren.
Als wir dann die neuen digitalen Dinger mit Zusatzmodulen, digitaler Sprachbox und optionaler Steuerung vom PC aus bekommen haben konnte immer noch jeder telefonieren, aber die sich die Mühe gemacht haben die Anleitung zu studieren und mal die ganzen Schalter zu "probieren" haben jetzt eine echte Kommunikationszentrale. Und die, die das voller Neid sehen sind auch genau die, die über die vielen Knöpfe und verschachtelten Menus motzen und "das-muss-doch-alles-viel-einfacher-klappen" herunterbeten, statt sich damit auseinander zu setzen.

ich habe noch keinen ernstzunehmenden Programmierer kennengelernt, der nicht gerne die Kritik von seinen Usern entgegen nimmt und versucht das Beste daraus zu machen. Aber die Gelegenheit durch konstruktive Kritik muss man ihm schon geben.

Zitat:

---

An alle Programmierer:
Lasst den Konstruktueren die Freude an der Konstruktion!
Nicht jeder Konstrukteur ist auch Software-Entwickler und liebt das Programmieren so wie ihr!

Sieht das irgendjemand anders?

---

Aber ja, sogar ganz entschieden. Ein Konstrukteur ist genau wie ein Programmierer der Geist hinter einem kreativen Prozess. Klar hat jeder seine eigenen Vorstellungen dabei. Aber hat sich bisher auch nur einer der Konstrukteure der "das-muss-doch-auch-einfacher-gehen"-Kategorie mal hingesetzt und einem der Programmierer einen Vorschlag für ein wirklich intuitives Userinterface gemacht? Statt "so kann das doch nie funktionieren" mal einen Vorschlag eingereicht, wie es gehen könnte? Statt "wozu die vielen Optionen" mal sich selbst darauf beschränkt mit den vorhandenen Möglichkeiten einen Weg zu finden?

Letztendlich ist es doch mit Konstrukteur und Programmierer wie im richtigen Leben: jeder sollte etwas über seinen Tellerrand schauen und versuchen den anderen zu verstehen und dabei zu helfen ein brauchbares Werkzeug zu schaffen. Und ich meine nicht den Hammer, um den Monitor einzuschlagen ...

CU

Stefan

------------------
--
Inoffizielle Solidworks Hilfeseite
http://home.wtal.de/berlitz/solidworks
EMail: Stefan.Berlitz@gmx.de

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Stefan.
Eigentlich hast Du völlig Recht, aber auch wieder nicht. Ich glaube nicht das ein Anwender ein Flag oder eine Option tatsächlich haben möchte. OK, Flags wie 'Diese Software arbeitet in einer Mehrbenutzerumgebung' oder 'Wenn die Zeichnung auf einer Station geladen ist, dann anderen Anwendern nur Leserecht geben' sind sicherlich notwendig. Auch sind Optionen und Grundeinstellungen wie die Sprache der Benutzerführung oder die Einstellung der Unterkataloge für die Zeichnungsablage und solche Sachen ebenfalls notwendig. Aber um diese Dinge geht es doch nicht! Es geht doch um die kleinen Alltäglichkeiten die das Leben einfach machen. Beispiel: Muss ein nicht-massstäbliches Mass nicht immer unterstrichen werden, auch wenn der Anwender dies nicht ausdrücklich über eine Option ge-'enabled' hat (mag er den Unterstrich auch später wegnehmen wollen). Diese Art der Optionen und Einstellung sind sicherlich keine Anwenderwünsche. Anwender wollen sowas nicht, kriegen es aber als einzige (weil einfache und schnelle) Lösung 'aufs Auge gedrückt'.

Und die Anwender die über verschachtelte Menüs und viele Knöpfe motzen und behaupten 'Das muss doch alles viel einfacher klappen' haben doch völlig Recht!

Wenn sich wirklich mal Anwender und Programmierer zusammensetzen, nicht auf Seminaren oder ähnlichen Veranstaltungen, sondern der Programmierer geht vor Ort und setzt sich neben einen Anwedner, dann geht das am Ende auch alles viel einfacher. Jeder Programmierer lebt von der Zustimmung seiner Anwender, nur kriegt er das auch mit. Die meisten Programmierer bekommen doch nur die Bug-Liste zu sehen und denen sind die Anwedner der eigenen Software dadurch doch letzlich nur ein notwendiges Übel. Dafür kann der Programmierer aber nichts. Ich bin davon überzeugt (aus eigener Erfahrung), dass Software nur dann Gut wird, wenn sie in Zusammenarbeit mit den Anwendern entwickelt wird. Oder, der Programmierer versucht mal ein Teil zu konstruieren, dann entstehen auch sinnvolle Verbesserungen und Erleichterungen.
Ob sich schon mal Konstrukteure gedanken über ein intuitives Userinterface gemacht haben? Ja, natürlich. Jedesmal wenn ein Anwender sagt: 'Was macht das Programm den jetzt schon wieder? Sieht der Rechner das denn nicht was ich hier will?', hat er sich darüber Gedanken gemacht! Leider haben Konstrukteure nicht die Zeit, sich ein oder zwei Wochen von der Konstruktion zurückzuziehen und ein Interface zu entwerfen. Das geht, wenn überhaupt, auch nur zusammen mit den Programmierern, die die Ideen des Anwenders (bitte nicht mit zwei Anwendern versuchen, dann gibt ewige Diskussionen!) direkt umsetzen und so durch ständige Vorschläge das beste Resultat gemeinsam erzielen.
Einen Vorschlag einzureichen ist also unmöglich. Kein Anwender ist dazu in der Lage (zumindest nicht so konkret, dass ein Programmierer damit etwas anfangen könnte).

Über den Tellerrand schauen?
Ja bitte gerne! Mit Nachdruck!
Nur ist nicht der Blick aus der 'Küche' in das 'Restaurant' viel hilfreicher als der Blick zum 'Herd' wo alles gekocht wird?

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Also jetzt kann ich mir als Vertreter der softwareherstellenden Fraktion
nicht mehr verkneifen, ein Wörtchen mitzureden.

Zitat:

---

Original erstellt von AndreasK:
Ich glaube nicht das ein Anwender ein Flag oder eine Option tatsächlich haben möchte.

---

Klar, kein Anwender will gezwungen werden, Optionen einstellen zu müssen. Aber wenn der eine Anwender ein bestimmtes Feature der Software genau so haben möchte, wie's gerade funktioniert, will der nächste Anwender es gerade so eben nicht, oder einfach anders.

Genausowenig will aber ein Softwareentwickler gezwungen sein, für jeden Anwender eine eigene
individuelle Programmversion schaffen zu müssen. Jedenfalls nicht für den Preis von Standardsoftware. Also werden beide oder mehrere Versionen des betreffenden Features in dasselbe Programm gestrickt und per Option umschaltbar gemacht - dann hat jeder was davon. Auch die Anwender, die nicht "programmieren" wollen. Die bekommen nämlich ein durch Optionen, Konfigurationen und Parametereinstellungen für verschiedene Anwenderbedürfnisse adaptierbares und daher mehrfach verwendbares (verkaufbares) Programm wesentlich günstiger als eine perfekt auf die eigenen Bedürfnisse zugeschnittene Individualsoftware - die sie sich garnicht mehr leisten könnten oder wollten.

Zitat:

---

Original erstellt von AndreasK:
Muss ein nicht-massstäbliches Mass nicht immer unterstrichen werden, auch wenn der Anwender
dies nicht ausdrücklich über eine Option ge-'enabled' hat. Diese Art der Optionen und Einstellung sind sicherlich keine Anwenderwünsche. Anwender wollen sowas nicht, kriegen es aber als einzige (weil einfache und schnelle) Lösung 'aufs Auge gedrückt'.

---

Garantiert finden sich für jede zwangsweise Normgerechtigkeit der Software auch Anwender,
denen genau das nicht passt und wenn es nur für einen einmaligen Sonderfall nicht passt.
Selbstverständlich muss ein Programm für alle Optionen sinnvolle Voreinstellungen verwenden,
mit denen im Normalfall (aber was ist das?) auch sinnvoll gearbeitet werden kann. Aber die schönste Automatik ist lästig und unnütz, wenn sie nicht bei Bedarf auch abgeschaltet bzw. manuell beeinflusst werden kann. Hier geht es nicht um eine für die Softwareentwicklung einfache und schnelle Lösung sondern um eine Lösung, die auf einem Schlag allen (oder wenigstens den meisten) Anwendern zur Erfüllung ihrer Wünsche verhilft. Weil sie variabel ist.

Zitat:

---

Original erstellt von AndreasK:
Und die Anwender die über verschachtelte Menüs und viele Knöpfe motzen und behaupten
'Das muss doch alles viel einfacher klappen' haben doch völlig Recht!

---

...ignorieren aber tapfer das altbekannte Dilemma:
je mehr ein Programm kann, desto genauer muss der Benutzer spezifizieren, was davon es jetzt tatsächlich tun soll. Nur ein Programm das nur eine einzige Funktion ausführt kann auch mit nur einem Tastendruck bedient werden. Hier beschwert man sich wohl über die Qual der Wahl. Für die Steuerung eines Automobils würde auch ein einziger Steuerknüppel statt Lenkrad, Hebelei und Pedalerie ausreichen. Warum wohl wird sowas nicht gebaut? Nicht, weil's technisch nicht machbar wäre oder die Hersteller nicht in der Lage sind, sowas zu produzieren, sondern weil's in der Handhabung nicht präzise genug und damit praktikabel wäre. Und weil der Mensch ein Gewohnheitstier ist.

Zitat:

---

Original erstellt von AndreasK:
Wenn sich wirklich mal Anwender und Programmierer zusammensetzen...

---

...artet das regelmässig in langwierige Frage- und Antwortspielchen aus, denn die meisten Anwender wissen nicht was sie wollen, sondern nur was sie nicht wollen. Aber Softwareentwickler sind grundsätzlich nicht in der Lage, zu programmieren was das Programm nicht tun soll...

Zitat:

---

Original erstellt von AndreasK:
Die meisten Programmierer bekommen doch nur die Bug-Liste zu sehen und denen sind die Anwedner der eigenen Software dadurch doch letzlich nur ein notwendiges Übel.

---

Jeder Programmierer würde sich glücklich schätzen, wenn Anwender konkrete Beschreibungen ihrer Probleme geben würden. Meist bekommt man aber nur Bug-Listen mit dem Tenor "Das geht nicht!",
was üblicherweise nur als Fehlerlisten getarnte Wunschlisten sind. In typischer Konsumentendenkweise: "Ich hab' das Programm gekauft, also muss es genau das tun, was ich will! Und genau so, wie ich es will! Wenn's nicht so geht wie ich es will, kann ich es nicht anwenden, also geht's nicht. Und das ist dann ein Programmfehler!"

Woraufhin eifrig weitere Optionen in's Programm eingebaut werden, damit der eine sich das Verhalten des Programms wunschgemäss einstellen kann - woraufhin sich ein anderer darüber beschwert, dass man soviel einstellen muss...

Zitat:

---

Original erstellt von AndreasK:
Oder, der Programmierer versucht mal ein Teil zu konstruieren, dann entstehen auch sinnvolle Verbesserungen und Erleichterungen.

---

Bingo, das isses! Das Beste in puncto Software-Ergonomie entsteht beim Testen der Software aus der Faulheit des Programmierers bei häufigen Wiederholungen von Arbeitsschritten. Ein Programmierer würde aber auch die Möglichkeiten von Menüerstellung, Befehlsmakros, Scripts usw. rigoros nutzen um sich die Arbeit zu erleichtern. Ein Nichtprogrammierer mault nur über umständliche Programmbedienung...

Zitat:

---

Original erstellt von AndreasK:
Jedesmal wenn ein Anwender sagt: 'Was macht das Programm den jetzt schon wieder? Sieht der Rechner das denn nicht was ich hier will?', hat er sich darüber Gedanken gemacht!

---

Na fabelhaft! Niemand würde auf die Idee kommen, sich in's Auto zu setzen und sich zu wundern,
warum es nicht losfährt: "Ja weiss das Auto denn nicht, dass ich von A nach B fahren will?".
Selbstverständlich kann das Auto von A nach B fahren, aber lenken und gasgeben muss der Anwender schon selber. Oder Taxi fahren. Beim Auto ist das jedem klar, von Software und Computer wird aber
in Ermangelung grundlegenden Verständnisses einfach verlangt, gefälligst genau das zu tun,
was man als Anwender erwartet. Hat sich schonmal jemand bei einem Werkzeughersteller beschwert, weil der Hammer einen Nagel krummgeschlagen hat? Bei Computern wird sich die Betrachtung als Hilfsmittel oder Werkzeug, das nur so gut sein kann wie der Benutzer der damit umgeht, wohl nicht durchsetzen...

Zitat:

---

Original erstellt von AndreasK:
Leider haben Konstrukteure nicht die Zeit, sich ein oder zwei Wochen von der Konstruktion zurückzuziehen und ein Interface zu entwerfen.

---

Erst recht haben Softwareentwickler nicht die Zeit, wochenlang umfangreiche Konstruktionszeichnungen mit allem Drum und Dran zu erstellen um alle Ecken und Kanten der Benutzeroberfläche zu finden. Jedenfalls nicht, solange Softwareanwender nicht bereit sind, diesen Aufwand auch zu finanzieren.

Im Übrigen kann es sowas wie "Intuitive Programmbedienung" nicht geben.
Weil jedermann andere Intuitionen hat. Ein Paradebeispiel: Als mit der Wheelmouse das Rad neu erfunden wurde, glaubten Softwareentwickler mit wunderschön bequemen Zoomfunktionen
Anwender glücklich machen zu können. Weit gefehlt! Langwierige Diskussionen entbrannten zu der lebenswichtigen Frage, ob eine Vorwärtsdrehung des Rades den Zeichnungsinhalt vergrössern,
also den Zeichnungsausschnitt verkleinern sollte oder umgekehrt. Oder ob eine Vorwärtsdrehung den Zeichnungsausschnitt nach oben oder unten verschieben sollte. Der eine betrachtet das Zeichnungsfenster eben als eine Art Lupe oder Zoomobjektiv, das über die Zeichnung bewegt wird, der andere stellt sich vor, wie bei seinem Microfiche-Lesegerät die Zeichnung unter dem Bildschirm zu bewegen. "Wat dem eenen sin Uhl', is' dem anderen sin Nachtigall!". Seitdem gibt's wieder ein paar Optionen mehr, zu deren "Programmierung" die Anwender gezwungen werden...

Zitat:

---

Original erstellt von AndreasK:
Nur ist nicht der Blick aus der 'Küche' in das 'Restaurant' viel hilfreicher als der Blick zum 'Herd' wo alles gekocht wird?

---

Welcher Koch lässt sich schon gerne in die Töpfe schauen? Schlimm genug, wenn für den Koch (wie für den Programmierer) der Erfolg seiner Arbeit auf Gedeih und Verderb vom Geschmack des Gastes (Anwenders) anhängig ist. Da wird 'a la carte' bestellt (damit's billiger wird) und hinterher gemault wenn's nicht schmeckt. Der Koch kann es nunmal nicht (ohne individuelles Rezept - und Preis) jedem einzelnen recht machen sondern sich nur nach dem Geschmack der Mehrheit richten. Es liegt aber in der Natur der Sache, dass diejenigen, denen was nicht passt, intensiver ihre Interessen vertreten (lauter schreien) als diejenigen, die zufrieden sind - denn die haben ja was sie wollen und brauchen sich nicht mehr engagieren. Also betrachtet der Softwareentwickler so Unix-mässig eben "keine Rückmeldungen" als "gute Rückmeldungen". Denn ansonstenen ist die Kritik immer lauter als das Lob - aber leider nur selten konstruktiv...

------------------
jk
interCAD BOSS (blearyeyed, overnighted & stressed softwaredeveloper)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo Diskussionsrunde,
hier auch noch mein "Senf" zu diesem leidigen Thema. Ich bin zu meinem Glück kein Programmierer, kenne aber einige Leute dieser Spezies und möchte behaupten, wenn man als "User" an die Leute rankommt, dann machen sie vieles möglich.
Das Problem liegt meines erachtens schon beim Nutzer!
Ohne Fahrerlaubnis darf keiner auf den Straßenverkehr losgelassen werden. - Ohne Software-Schulung auf ein CAD-System schon!
Die Erfahrung zeigt, viele Firmen lassen ihre Mitarbeiter gar nicht oder nur in Crash-Kursen schulen und wundern sich warum dann nicht viel bei rauskommt.
Außerdem gibt es auch Schulungen, da wird IRGENDWER, der schon mal den Namen des CADsystems buchstabiert hat auf die Kursteilnehmer losgelassen und hinterher wissen die Teilnehmer immer noch nicht mit dem System umzugehen und dann heißt es gerne das System taugt nicht...
Ich hatte schon mehrfach die Chance Nutzer aus Crash-Kursen nach- oder umzuschulen - die waren dann so baff, was mit fundierten Kenntnissen alles noch so geht oder viel einfacher geht. Und mit Systemanpassung so viel wegfallen kann, was der Nutzer nicht alle Tage braucht....
Deshalb auch meine Bereitschaft hier ein Forum zu moderieren, denn meistens ist nicht die Software schlecht oder Programmierer zu "betriebsblind" oder der USER ein D(ümmster)A(nzunehmender) U(ser)- sondern es fehlt nur Sachkenntnis, die das Leben vereinfacht.
Zugegeben nicht alles liegt daran, manchmal hilft aber der richtige Trick um das (Arbeits-)Leben wieder lebenswert zu machen.
Murphy ist ja jedem Computernutzer inzwischen bekannt und der Bursche muß einfach hin und wieder ausgetrickst werden.
Schönes Wochenende wünscht
Angelika

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo,
habe mir mal nur diesen Teil rausgezogen:

Zitat:

Original erstellt von AndreasK:
Muss ein nicht-massstäbliches Mass nicht immer unterstrichen werden, auch wenn der Anwender dies nicht ausdrücklich über eine Option ge-'enabled' hat. Diese Art der Optionen und Einstellung sind sicherlich keine Anwenderwünsche. Anwender wollen sowas nicht, kriegen es aber als einzige (weil einfache und schnelle) Lösung 'aufs Auge gedrückt'.

von jk:
Garantiert finden sich für jede zwangsweise Normgerechtigkeit der Software auch Anwender,
denen genau das nicht passt und wenn es nur für einen einmaligen Sonderfall nicht passt.
Selbstverständlich muss ein Programm für alle Optionen sinnvolle Voreinstellungen verwenden, mit denen im Normalfall (aber was ist das?) auch sinnvoll gearbeitet werden kann. Aber die schönste Automatik ist lästig und unnütz, wenn sie nicht bei Bedarf auch abgeschaltet bzw. manuell beeinflusst werden kann. Hier geht es nicht um eine für die Softwareentwicklung einfache und schnelle Lösung sondern um eine Lösung, die auf einem Schlag allen (oder wenigstens den meisten) Anwendern zur Erfüllung ihrer Wünsche verhilft. Weil sie variabel ist.

Mein Kommentar dazu:
Da ich selber längere Zeit auf beiden Seiten war (SW-Entwickler und Anwender), mußte ich über die Aussage "finden sich auch Anwender denen daß nicht paßt" erst einmal schmunzeln. Zur Zeit muß ich mich aber über die (nicht nur aus meiner Sicht) nachlassende Professionalität der CAD/CAM-Softwareerstellung ärgern.

Konkret; es wundert mich, daß in der ganzen Diskussion über das "schwierige" Problem der "Options" der Begriff "praktikal default" nur beiläufig als "sinnvolle Voreinstellungen" vorkommt. "praktikal default" heißt: wenn bei einer zu lösenden Aufgabe 90% (Größe ist variabel aber >50%) der Weg "A" eingeschlagen wird, sollte "A" voreingestellt sein und beim Weitermachen angenommen werden, "B" ist zwar da, erfordert aber "Mehraufwandt".
Beispiel: Wenn in einem Text Editor mehrer Zeilen selektiert sind und ich "Drucken" sage soll die Selektion zum Drucken voreingestellt sein, so daß mit OK die Selektion gedruckt wird. ("Alles" muß man extra anwählen)

Nun zu CAD; da manche CAD-Software-Programmierer in ihrem Leben vielleicht gerade mal eine Zeichnung gesehen haben, aber kaum (eine Zeichnung) lesen können, geschweige die DIN oder ISO-Normen, wie soll er dann "praktikal defaults" festlegen? Somit hängt er von seinen "Vorarbeitern" ab und dort liegt das Problem. In diesen "marketing" getriebenen Positionen sind nur in Ausnahmen (und die sind dann erfolgreich) FACH-kompetente Mitarbeiter und Manager zu finden. Über das was mir im Laufe meiner 30 Jahre CAD/CAM-Anwendung dort begegnet ist könnte man Bücher schreiben.

AndreasK hat recht, Anwender sollten sich nicht mit solchen einfachen Lösungen zufrieden geben, nur weil manche Anbieter von Ihren Applikationen wenig Ahnung haben. Sie lassen Ihre Elektroinstallation auch nicht von einem Schreinermeister (vielleicht der Beste in der Gegend) machen; aber als Produktlinienverantwortliche bei CAD/CAM Anbietern finden wir oft mehr Physiker als Techniker. Die fragen halt nicht mal mehr was der "Normalfall" ist (üblicher Lösungsweg für eine gegene Aufgabe nach aktuellem Stand der FACH-Technik), Optionen sind ja leichter möglich. Praktical defaults (sinnvolle Voreinstellungen) sind eher die Ausnahme als die Regel.

Es wird gesagt " Selbstverständlich muss ein Programm für alle Optionen sinnvolle Voreinstellungen verwenden" nur hier klafft die Lücke zwischen dem was Anwender erwarten und Systemanbieter leisten noch weit auseinander.

Mit der Frage "(aber was ist das?)" (mit "das" ist der "Normalfall" gemeint) wird doch nur der Mangel an Fachkompetenz bestätigt.

Frage: In wieviel % der Fälle werden nicht-masstäbliche Masse unterstrichen?

Mit freundlichen Grüßen
Alfred Vieth

PS:
Lieber jk
(interCAD BOSS blearyeyed, overnighted & stressed softwaredeveloper)

Wie sieht es denn bei euch aus? Laßt Ihr auch mal Konstrukteure in eure Nähe, dürft Ihr auch mal raus in die Industrie vor Ort zum Anwender?
Bitte bewerte die "Variabilität" nicht höher als "sinnvolle Voreinstellungen".

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Zitat:

---

Original erstellt von Alfred Vieth:
Frage: In wieviel % der Fälle werden nicht-masstäbliche Masse unterstrichen?

---

Hallo Herr Vieth,

diese Frage in Zusammenhang mit den Stichworten DIN/ISO, CAD und Zeichnungserstellung zu stellen ist wirklich sehr gemein!
Aber vielleicht gibt es dennoch ein Paar 'kompetente' Antworten, die das Vertrauen der Softwareanwender in ihre Programme, falls verloren, wieder herstellen.
Wobei die Bemassung eines Bruchs natürlich nicht als unmassstäblich gilt, obwohl die Entfernung der bemassten Punkte eine andere als die Zahl auf der Masslinie ist.

Appropos Bemassung. Tipp für CAD Neulinge die sich für eine Software entscheiden müssen: Einfach eine neue (leere) Zeichnung beginnen, einen beliebigen Bemassungsbefehl ausführen und wild in der immer noch leeren Zeichnung klicken. Wenn jetzt Bemassungen 'in der Luft' erscheinen, dann ist hier sicherlich an der Problematik vorbei 'entwickelt' worden.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Dem ist nichts hinzuzufügen. Bravo für diesen Beitrag.

Oliver Wendlandt

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Dem ist Einiges hinzuzufügen:

Zitat:

---

Original erstellt von Alfred Vieth:
Zur Zeit muß ich mich aber über die (nicht nur aus meiner Sicht) nachlassende Professionalität der CAD/CAM-Softwareerstellung ärgern.

---

Klar, den schwarzen Peter kann man ja prima den Software-Herstellern in die Schuhe schieben, die gefälligst die nachlassende Professionalität der CAD/CAM-Anwender durch Fachkompetenz der Software zu kompensieren haben. Denn die Software braucht nur einmal bezahlt werden während teure Fachleute zur Anwendung derselben regelmässig bezahlt werden wollen. Also lässt sich bei denen mehr sparen wenn man die Professionalität nur von der Software verlangt.

Zitat:

---

Original erstellt von Alfred Vieth:
Über das was mir im Laufe meiner 30 Jahre CAD/CAM-Anwendung dort begegnet ist könnte man Bücher schreiben.

---

Bin beeindruckt, aber da kann ich über: Nur 15 Jahre CAD/CAM-Softwareentwicklung reichen schon für meterweise Bücherregale...

Zitat:

---

Original erstellt von Alfred Vieth:
Mit der Frage "(aber was ist das?)" (mit "das" ist der "Normalfall" gemeint) wird doch nur der Mangel an Fachkompetenz bestätigt.

---

Daneben getippt - damit wird die Vielfaltigkeit und Uneinigkeit von Anwendermeinungen moniert. "Normalsein" ist das Vorrecht der Mehrheit, also richten wir uns danach, auch wenn die nicht genormt ist. Aber die nicht normale Minderheit meckert nunmal lauter als die normale Mehrheit lobt.

Zitat:

---

Original erstellt von Alfred Vieth:
Die fragen halt nicht mal mehr was der "Normalfall" ist

---

Doch, selbstverständlich. Siehe oben!

Zitat:

---

Original erstellt von Alfred Vieth:
(üblicher Lösungsweg für eine gegene Aufgabe nach aktuellem Stand der FACH-Technik)

---

Wieder daneben getippt. Üblicherweise der Lösungsweg nach aktueller Meinung der Anwender. Und die sind
1. nicht notwendigerweise auf dem aktuellen Stand der Fach-Technik
2. verschiedener Meinung
3. König

Zitat:

---

Original erstellt von Alfred Vieth:
Praktical defaults (sinnvolle Voreinstellungen) sind eher die Ausnahme als die Regel.

---

Practical defaults sind immer die Regel, weil sich jeder Anwender seine individuellen Lieblings-Defaults selbst einstellen kann wenn ihm die defaults der Software nicht practical genug sind. Deswegen gibt's Einstellungen mindestens viermal:
die statischen Voreinstellungen, die das Programm verwendet solange der Anwender nichts anderes will - oder weiss
die variablen Voreinstellungen, die den Softwarentwickler von der Notwendigkeit befreien, jedem Anwender eigene Software stricken zu müssen
die temporären Einstellungen, die von Fall zu Fall in der Anwendung geändert und verwendet werden ohne die Voreinstellungen zu beeinflussen
die aktuellen Einstellungen, die mal temporäre Einstellungen waren aber je nach Laune des Anwenders dann doch wieder Voreinstellungen sein sollen
Das Ganze dann wohlgemerkt auch noch in hierarchischer Anordnung: firmenspezifisch, gruppenspezifisch, projektspezifisch, anwenderspezifisch, rechnerspezifisch. Und weil garantiert irgendwer mault dass soviel einzustellen ist und jede weitere Option die Chance auf fehlerhafte Einstellung verdoppelt, auch noch mit Voreinstellungen für die Berechtigung zum Ändern von Voreinstellungen. Damit nicht jeder dran rumfummelt und sich hinterher beschwert dass die Software Unfug macht. Und alles irgendwie sinnvoll und practical.

Zitat:

---

Original erstellt von Alfred Vieth:
Frage: In wieviel % der Fälle werden nicht-masstäbliche Masse unterstrichen?

---

In wieviel % der Fälle haben x Anwender weniger als x+n verschiedene Meinungen darüber, wobei sowohl x wie n als Zahl stets positiv, zumindest n in der Auswirkung aber negativ ist?

Zitat:

---

Original erstellt von Alfred Vieth:
da manche CAD-Software-Programmierer in ihrem Leben vielleicht gerade mal eine Zeichnung gesehen haben, aber kaum (eine Zeichnung) lesen können, geschweige die DIN oder ISO-Normen...

---

Ähm - schon mal einem Hochschulabgänger mit druckfrischem Maschinenbau-Ing.Diplom eine 2D-Werkstattzeichnung vor die Nase gehalten? Einem, der unheimlich stolz ist auf seine bunten 3D-Konstruktionen und der komplexe FEM-Analysen im Kopf rechnet aber verdeckte Körperkanten nicht von Mittellinien oder Wirklinien unterscheiden kann? Der mit Strichstärken nichts am Hut hat und Oberflächenbearbeitungszeichen für Hyroglyphen hält? Ist immer wieder ein ROTFL wert!

Zitat:

---

Original erstellt von Alfred Vieth:
...nur hier klafft die Lücke zwischen dem was Anwender erwarten und Systemanbieter leisten noch weit auseinander.

---

Und erstmal die Lücke zwischen dem was Anwender erwarten und dem was sie zu bezahlen bereit sind...

Zitat:

---

Original erstellt von Alfred Vieth:
Laßt Ihr auch mal Konstrukteure in eure Nähe, dürft Ihr auch mal raus in die Industrie vor Ort zum Anwender?

---

Ja, regelmässig. Zum Vorbeten des Anwenderhandbuchs.

Zitat:

---

Original erstellt von Alfred Vieth:
Bitte bewerte die "Variabilität" nicht höher als "sinnvolle Voreinstellungen".

---

Doch, unbedingt! Sonst müssten alle Anwender die nötige Fachkompetenz haben um sich zu einigen, was sie für sinnvoll halten...

------------------
jk
interCAD BOSS (blearyeyed, overnighted & stressed softwaredeveloper)

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Vielleicht sollte man den Begriff Fachkompetenz durch Fachautorität ersetzen. Dann wird einiges klarer. Mit der Kompetenz ist das so eine Sache, sie wird leicht 'überschritten': Erzählen doch die Hersteller (Programmierer) den Konstrukteuren wie sie zu arbeiten haben und umgekehrt erzählen die Konstrukteure den Herstellern etwas über Software-Entwicklung.

Das führt aber zu nichts. Zumindest zu nichts sinnvollem wie offensichtlich festgestellt wird. Entweder entwickelt sich die Software vom Anwender weg oder die Software wird so allgemein, dass sie einen bestimmten (ursprünglichen) Zweck nur noch mit Verrenkungen erledigt.

Nun reden wir hier aber über (so habe ich zumindest verstanden) CAD Software, die einem Konstrukteur an die Hand gegeben wird, damit dieser seine täglichen Arbeiten erledigen kann.
Wir reden ausdrücklich nicht über Textverarbeitung oder DTP!
Was macht den ein (klassischer) Konstrukteur? Er konstruiert, was sonst. Und wozu? Damit irgendwann 'hinten' eine Zeichnung abfällt, die er in die Fertigung geben kann (etwas idealisiert aber nicht grundsätzlich falsch).
Er gibt also eine Zeichnung weiter. Keine textliche Beschreibung.
Diese Zeichnung enthällt nun Symbole und verschiedenst geartete Linien und Beschriftungen. Die Leute in der Fertigung können diese Zeichnung lesen, da beide die gleiche Sprache verwenden. Ohne Rückfrage kann das abgebildete Etwas gefertigt werden und der Konstrukteur kann seine Idee jetzt auch anfassen.

Also ist es doch wichtig, dass das Werkzeug des Konstrukteurs 'weiss' (oder zumindest erahnen kann), wie was darzustellen ist. Werden Achslinien gezeichnet ist keine Diskussion über die Darstellung notwendig. Der Konstrukteur erkennt seine Achslinien und der in der Fertigung kann diese auch als solche erkennen.
Für jeden anderen mögen diese Dinge bedeuten was sie wollen, es tut nichts zur Sache.
Das bedeutet im Rückschluss für das Werkzeug, was immer der Anwender sich vorstellt wie eine Achslinie auszusehen hat: Es tut nichts zur Sache!
Nun hat Software den unbestereitbaren Vorteil, programmierbar zu sein. Also könnte doch die Menge der potentiellen Anwender dadurch erhöht werden, dass die Software auch Schrägstriche statt Pfeile für die Bemassung zulässt, diese also konfigurierbar macht.
Wenn dies geschieht, also zugelassen wird, ist es nicht nur die Bemassung die sich ändert (was brauchen wir den Abmasse im Bau, es kommt doch nicht darauf an ) sondern auch die Schraffur, Linientypen usw bedeuten plötzlich was ganz anderes! War es eben noch eine Achslinie, ist jetzt eine Wasserleitung oder ein Fluchtweg? Wer weiss es.

Und genau das ist doch das Problem:

Mit jeder Möglichkeit eine 'praktische Voreinstellung (die änderbar ist, sonst wäre es ja keine Voreinstellung)' auch nur in Erwägung zu ziehen, ändert sich die Sprache mit der eine Software mit dem Anwender kommuniziert.
Aus leeren Zeichnungsblättern werden Templates, aus Feldern im Schriftfeld sind plötzlich ATTRIBUTES und um den Regelfall der unterschiedlichen Massstäbe zur Darstellung von Details erstellen zu können, werden verschiedene Koordinatensysteme (xyz-spaces) eingeführt und es müssen Beschriftungen in 3500 mm Höhe abgesetzt werden.
Alles nur, weil den Erstellern solcher Software die nötige Fachautorität fehlt ein Werkzeug für einen bestimmten Zweck zu liefern. Und noch viel schlimmer: Das ist alles völliger Humbuck (aus der Sicht eines Konstrukteurs). Zumindest erscheint es dem Erstanwender einer Software als völliger Humbuck, auch wenn er mit der Zeit damit zu leben lernt. Nur hier gilt: Der erste Eindruck ist meist nicht ganz falsch!

Und was folgern wie daraus:

Statt Handbücher zur Software wird ab sofort der Hoischen mitgeliefert. Und wenn das CAD-System etwas 'anspruchsvoller' sein will, dann gibt es halt den Dubbel.

Und wenn dann was in der Software nicht klappt wie es soll, haben beide Seiten eine gemeinsame Diskussionsgrundlage und man weiss von was geredet.

Und die, die damit (Hoischen und Dubbel) nichts anfangen können, müssen eben ein anderes CAD - System einsetzen (das, hoffe ich, dann die entsprechenden Anwender-Handbücher ebenfalls mitliefert).

[Diese Nachricht wurde von AndreasK am 02. Februar 2001 editiert.]

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP

---

Hallo zusammen,
das eigentliche Problem sind doch nicht die vielen kleinen Schalterchen, von denen die meisten User gar nicht wissen, wofür sie gut sind (sei es wegen mangelnder Schulung oder mangelndem Interesse am System (nach IKEA: "Entdecke die Möglichkeiten").
Das eigentliche Problem ist, daß die Software oft fehlerhaft ist (Beispiel Catia).
Wenn z.B. bei Kreisen, die R=10 sind bei der Bemaßung mit R0.6 bemaßt werden,
wenn Schnitte nicht erzeugt werden können (tangent cutting-profile).
wenn Basisfunktionen (z.B. Spiegelung) fehlerhaft arbeiten (Flächennormale sind nach der Spiegelung grundsätzlich falsch orientiert => führt zu Fehlern beim update, wenn Split-planes und "keep assoziativity with plane" verwendet werden (Rechts-/Linksteile).
wenn sich Solids nicht skalieren lassen,
wenn sich Flächen nicht aufdicken lassen,
wenn sich Solids nicht mehr updaten lassen (z.B. neue PTF's),
wenn einfache bool'sche Operationen nicht ausführbar sind (impossible operation),
...,
wenn die Software einfach so "aufgiebt",
dann ist das das wahre Problem.
Dann muß man Zeit investieren um Fehler zu umschiffen, dann muß man seine Konstruktion an die Möglichkeiten des Systems anpassen.
Da kann man dann auch nicht mehr viel schulen, das lernt man dann nur durch den Umgang mit dem System. Dann die Ursachen zu finden und das Problem kostet Zeit und damit Geld.

Je mehr Möglichkeiten in die CAD-Programme integriert werden, desto größer werden auch die möglichen Software-Fehler und je mehr Möglichkeiten es für den Anwender gibt Einstellungen selbst vorzunehmen, desto mehr werden Anwender mit "falschen" Einstellungen arbeiten.

------------------
Gruß
Michael B.

Eine Antwort auf diesen Beitrag verfassen (mit Zitat/Zitat des Beitrags) IP