Changes in STAAD.Pro Connect edition interface.

I'm surprised that more people aren't voicing this sentiment. I too am very unhappy with new version of STAAD. I have never liked the way they do physical members so I don't use them. I used another program several years ago that did physical member "right" in that a physical member and analytical member weren't consider separate. A member is a member is a member. So anyway, one of the major changes to the program is they now have a slick new interface for physical modeling but I don't use it.

That brings us to analytical modeling. One of the things I liked about the older versions of STAAD is the easy user interface. I can fly in that thing. Now they have went to the ribbon which slowed me down to a crawl. As a matter of fact, I just finished a fairly large and complex model that I decided to revert back to the last version before the Connect edition. My hours spent on a project are being watched closely and I just couldn't afford to spend the extra time when there is no extra benefit. I have the same model and the same results either route I go so I went the fastest route.

Actually that's not quite true. By using the older version I still have access to the SQL Query as you mentioned. Now, in full disclosure, I didn't use it for this job but I have in the past and it comes in very handy when you need it.

The folks at Bentley will argue that I just need to use the new interface more to get used to it. I'm a big believer in "If it ain't broke, don't fix it." I am thoroughly convinced that I will never be faster at building a model in the new version than I am in the older version, so even though I'm sure I would get better in the new system than I am now, why would I spend time getting better just so I can come back to my old speed of modeling at best? Which, as I said, I don't think is possible, because I've found a lot of things that take more than one mouse click that only used to take one.

STAAD.Pro CE is an application for today, but built looking to the future. One of the biggest drivers for the development of STAAD.Pro CONNECT Edition has come from engineers who have felt that STAAD.Pro does not change from release to release, however their operating system has undergone generational changes. These engineers are looking to leverage the power they have available with the newer operating systems and want to use the techniques that are fundamental to the tools their daily work such as Word and Excel.  MS Office updated to 365, built around a ribbon style interface with context based functions. Also how much has engineering itself changed? When STAAD.Pro was first developed, there was no 'Cloud', there was no BIM, but now these are becoming the cornerstone of any construction project.  

As organizations develop their teams with new engineers from graduates or engineers who simply don't have the wealth of experience, we want to make the learning process as simple as possible.  Keeping an interface based on an abandoned methodology does not do that.  I appreciate that it is difficult migrating to any new system when feeling comfortable in the older system.  In order to move from Windows 3 to Windows 95, XP, 7, 8 or 10, there was always some hurdle to climb to get the benefits that the new system provided. It also meant there were some capabilities that had to be retired as a newer offering or approach provided an overall better solution.

I agree the first introduction of a physical construct as an aggregation object in STAAD.Pro's analytical data structure was a too simplistic and difficult to manage.  That is the why we have invested so much time and effort producing the Physical Workflow in STAAD.Pro CONNECT Edition.  A fully managed physical interface that means that the beams, columns and surfaces in the model are handled as engineering objects, The deconstruction into the finite element analytical components has become an internal, automatic process.  This system will continue to evolve as we provide a more complete loading interface, analysis, post processing and ultimate design interface for the physical entities. However, as we want to get engineers used to the experience, we need to roll out updates with extra capabilities with an increased regular release heartbeat.

I am not saying that STAAD.Pro is now complete and will not change, but as engineering has changed so has STAAD.Pro, and we have taken the road that engineers have asked us to take.  We have already taken on board some early feedback regarding the selection and loading ribbons and revised the GUI accordingly. We will still continue to develop and provide the capabilities that deliver the most value to our loyal users.  We do listen to all the voices who use the program around the world, from simple frames to some of the most amazing projects being built today or being designed for tomorrow and we do try to provide everyone the best tool for use on all these projects. 

We do want to hear of any frustration and also when you have suggestions to further develop the program and help us continue in the evolution of a program that has grown since its original conception and will continue to so to be the best tool it can be.

Carlos, I’ll embrace the ribbon, although it will be kicking and screaming, when you do two things. First, get rid of the limitations on re-specification of supports after a CHANGE command. Namely, that releases before the CHANGE command must be greater than or equal to the number of releases after CHANGE and that supports must be specified in the same order before and after the CHANGE command.

I’ve submitted this as an SR but have been told it is not possible at this time. Given your words about the new architecture, I find this utterly amazing.

Second, and I know this will not be easy, make all members physical members and let the program worry about what you call analytical members internally. Right now, you have a separate interface for physical and analytical members. There should only be one interface. I’ve used other programs that pull this off quite nicely, so it can be done.

You’ve stated that we should not keep an interface based on “an abandoned technology” yet you want to hang on to the constructs of MEMBER and PMEMBER from the STAAD.Pro of yesteryear. I’ve used STAAD for many years and used to work at a very large engineering firm (where I met you when you were getting feedback on STAAD(X)) and I’ve never met anyone that used physical members in STAAD.

Obviously, your experience is different. I’m just giving you another data point to add to your research. Hope I don’t sound too critical because I know a lot of hard work has went into the new version of STAAD but you did say you want to hear our frustrations.

Carlos, I’ll embrace the ribbon, although it will be kicking and screaming, when you do two things. First, get rid of the limitations on re-specification of supports after a CHANGE command. Namely, that releases before the CHANGE command must be greater than or equal to the number of releases after CHANGE and that supports must be specified in the same order before and after the CHANGE command.

I’ve submitted this as an SR but have been told it is not possible at this time. Given your words about the new architecture, I find this utterly amazing.

Second, and I know this will not be easy, make all members physical members and let the program worry about what you call analytical members internally. Right now, you have a separate interface for physical and analytical members. There should only be one interface. I’ve used other programs that pull this off quite nicely, so it can be done.

You’ve stated that we should not keep an interface based on “an abandoned technology” yet you want to hang on to the constructs of MEMBER and PMEMBER from the STAAD.Pro of yesteryear. I’ve used STAAD for many years and used to work at a very large engineering firm (where I met you when you were getting feedback on STAAD(X)) and I’ve never met anyone that used physical members in STAAD.

Obviously, your experience is different. I’m just giving you another data point to add to your research. Hope I don’t sound too critical because I know a lot of hard work has went into the new version of STAAD but you did say you want to hear our frustrations.

Tank,

There are some nice new pieces of the STAAD CE.  The search box in the upper right hand corner of the interface is very useful. Right click options are also much more useful.  The overal interface change is pretty drastic, but I think that experienced users will pick it up fairly quickly.

I'm going to guess that a large portion of the difficulty with the handling of physical modeling is due to the insistence of many users that STAAD keep the text based input file rather than a more modern database.  I have quite a few co-workers who were very irate at the proposition of STAAD losing the ability to directly edit the input file.  The STAAD CE implementation is kind of a one foot in/one foot out solution.  It's certainly better than the old implementation of physical members. I also agree that many other programs have a better implementation of physical modeling, but I blame a user base that's unwilling to embrace change rather than the developers.  I'm hoping that the developers are able to smooth out the implementation as time goes on. 

I agree with your frustration on some of STAAD's quirks.  I again think it's probably a limitation of a text based input file.  Maybe Carlos can chime in on that.  It's actually pretty amazing what they're able to do with a simple text file, although the text file for the physical modeling isn't quite so simple anymore (which I'm OK with).  

Maybe, someday, they'll be able to ditch the input file.