Interesting comment

We are losing those big companies to other products. Products that are not better just bigger. More familiar.
And Bentley please note this. The group here are the family. Like brothers and sisters, we don't pull our punches nor sugar coat our comments. it is "Tough Love" . As in many cases our livelihood is more dependent on your success than yours.

This article makes sense. Not in a negative way but is foundation to the next generation of BIM which Bentley could lead.

Note that Architecture is pretty wide in the things that can designed. But as we pour concrete and build with common material those concepts come to earth. This software need to do both and in a way disappears from out thoughts and NEVER becomes a factor or even a thought in developing the documents for creation.

KB:

"You could have the smartest technology with the coolest demo of the newest solution but if people say ‘that’s not the way I work and I’m not prepared to change the way I work” then you are wasting your time."

"The future happens to us rather than by us. There is no masterplan for the road map for the next 30 years. Every five years we look back and ask what is different today. The decisions we made five years ago were all based on the technology available and the problems that we wanted to address. Sometimes the right decisions of the time turn into the wrong ones for all sorts of reasons and so you have to keep revising the plan."

There will always be a mismatch between how people work and the lead-in time required to introduce and implement the tools that enable those workflows.

It's important to bear in mind that how people are prepared to work is also symbiotic with the tools that are available + a learning curve + eco-system. If you provide the tools and environment, workflows will change. I suppose that the published example of this is the way DS tries to market CATIA/Enovia etc. They sell a whole eco-system and tell the client that this will require change in work practices 're-engineering' style.

It's not always about asking users what they want. Most times they are backward looking and won't know what the future will be in 5 or 30 years etc.

Maybe its about identifying the 'timeless' or 'profound' functionality like speed, scalability, reliability, UX, longevity, compatibility, adaptability, composability, interoperability etc and focusing on that. It seems like a lot the problems are really to do with lack of follow through and 'profoundness' over time. Functionality that is brittle and perishable over time.

I think what gb was trying to describe is a situation where the people developing the code also use the code to design, coordinate etc like super users in their targeted audience.

By doing so, I think things like usability and predicting the way the tools can or should evolve would be ingrained.

 

developing for Mstn... circa 2000.

Unknown said:

The coders need to produce tools that they themselves find cool and powerful to use.

It's a fine hope but as outlined above, does not hit the mark.

For me, the 'developing' link produces an empty pdf?

Now I see it - like a glimpse into the Mind of God! - makes me realise how difficult it is that the two worlds-apart mindsets might more effectively meet.

Yea... and that was with JMDL (would have been replaced by dotNET) which is a managed language which shields the coder from all that resource management that compiled languages like C++ etc require. It also only about the 'upper level' UI interactions, and not all that 3d solids modeling kernel coding or the parametrics change management etc that will be needed for all that nice TF joins etc that we have been discussing. All of which would need to be coded using libraries provided by others, which are apparently are often 'take it or leave it'... or yea we know its a bug and its on our backlog for years (sound familiar?) And that's if the library publishers are still around and cooperating.

A more detailed version of the report below:-

Yea... and that was with JMDL (would have been replaced by dotNET) which is a managed language which shields the coder from all that resource management that compiled languages like C++ etc require. It also only about the 'upper level' UI interactions, and not all that 3d solids modeling kernel coding or the parametrics change management etc that will be needed for all that nice TF joins etc that we have been discussing. All of which would need to be coded using libraries provided by others, which are apparently are often 'take it or leave it'... or yea we know its a bug and its on our backlog for years (sound familiar?) And that's if the library publishers are still around and cooperating.

A more detailed version of the report below:-

That sounds alarming - surely Bentley have faced all that (whatever it means) recently during the ground-up (?) rebuild of MS, which must have gone deep into '3d solids modeling kernel coding or the parametrics change management etc' incl 'using libraries provided by others' as necessary?

Won't that updating of the groundwork suffice for similar overhaul of TF? Or is TF a whole different, old, possibly obscure/forgotten animal, modifiable only 'if the library publishers are still around and cooperating'?

All the more reason then to ditch the old BricsWork/TF foundations and reverse-engineer Forms as new-type MS (parametric) solids,

which really are MS (parametric)solids while running MS;

but while running BD, in addition (optionally, alternatively) also offer a differently-expressed way of parametrically defining the same solids, and some extra modification methods.

So while running BD, any solid could be modified with equal ease, at will,

displaying either its MS-type parametric definition system and using MS-type modification tools,

or displaying its TF-type parametric definition system and using TF-type modification tools

(although many tools e.g. PushPull would work equally seamlessly with either parametric definition system).

Of course, by indiscriminate use of MS modification tools you could screw up sophisticated TF things like implied Relationships. An informative message system would be needed - 'yes you can make this move but it'll screw up that - confirm or cancel?'; 'you can modify this solid's topography but it will no longer function as a TF Form - confirm or cancel?'

Across all the Verticals, such reverse-engineering of the plethora of specialised soild-types, into a common MS (parametric) solid-type, must surely be what must happen. Perhaps we'll have to wait for v9i for that full flowering of the new v9 potential.

Interesting take on why CAD dev is difficult. Reward.

'raise the tide'

Unknown said:

So while running BD, any solid could be modified with equal ease, at will,

displaying either its MS-type parametric definition system and using MS-type modification tools,

or displaying its TF-type parametric definition system and using TF-type modification tools

Where did I see - was it new BricsCad? - any solid can be Selected by one click or a double-click or a triple-click; the 3 different select-click 'gestures'(?) ea present the solid in a choice of 3 different formats - different handles, (different parametric definition system?), different modification possibilities.

Cool