It will give you a more accurate insight into my ranting if I prologue this with the fact that Pro/E-Creo Parametric is the only PTC product I am addressing in this writing. I don’t use Windchill or any other data management program with Pro/E-Creo.
I have used Pro/E since the early 90’s. At the time it was so far ahead of AutoCad that there was no comparison. Suddenly I was able to model and update drawings for pressure vessels and structures, calculate minimum thicknesses, accurately detail and dynamically (“parametrically”) represent geometry. The amount of fabrication time and errors this saved is almost immeasurable. For years, I found the challenge of fulfilling client’s design challenges easier with Pro/E than with anything else available in the CAD market. I have even obtained patent’s based on designs with 3D geometry developed in Pro/E that (at the time) no other modeling program was capable of (except by archaic triangulation methods that were not as accurate as they needed to be).
As challenges increased (as they inevitably do) I was always running into limitations. But I could always discuss issues with a US based knowledgeable PTC user/engineer and develop a process or number of steps to get to a workable solution. This has changed. This has been my first level of disillusionment and my primary concern with PTC. Although the Knowledge Base access and Help files have improved, other CAD providers have left Creo Parametric in the dust with their truly dynamic hint and usage pop-ups and windows, and complete and illustrative explanations of how to use each capability.
In college I took a class in Assembly Language Programming. In terms of computer programs, I could eventually accomplish anything. It was not intuitive, nor elegant, but it could always (one way or another) get the job done. For years, Pro/E was the “Assembler Language Programming” of CAD… not intuitive, nor elegant, but it could always (with a little finesse) get the job done, and usually better than anything else. Just as Assembler Language Programming has given way to many more intuitive and easier to implement methods of programming, Pro/E has been challenged by other more intuitive and (questionably ) capable CAD packages. The field of various 3D kernels (the 3D component underlying all CAD programs) has expanded and somewhat equalized, and each has their benefits (usually accuracy, methodology, and implementation)…and limitations (usually error recovery). The real issue is the rate by which a design challenge can be met. The real implementation of meeting that challenge is in the intuitive and efficient (efficient in this case means the clear knowledge of how accurate and appropriate the result is) interface of the user with the software. If the software you are using does not have an intuitive, practical, efficient and useable interface…then you must customize it.
For as long as there have been computers with QWERTY keyboards for an interface, there has been an inherent limitation to interfacing with software. The QWERTY key layout was supposedly developed specifically to slow down the typing process to account for the limitations in mechanical typewriters. The Dvorak Simplified keyboard layout can potentially be much more efficient, quicker, and reduce strain. Yet we are virtually stuck with the QWERTY keyboard – being supplied with every new computer. Early word processors, spreadsheets, and CAD programs had various means (e.g. function keys F1-F12) of accessing menus (access to the series of steps needed to accomplish any given task). Microsoft, as well as others, resorted to the “Ribbon” to provide a reasonable and more intuitive interface with word processing and spreadsheets. For these programs, the Ribbon has served adequately…if not well. It was inevitable that CAD programs would resort to the same attempt at an intuitive interface. We are virtually stuck with the Ribbon interface, just like the arguably archaic QWERTY keyboard.
Well, you can customize your keyboard (if you really want to), and guess what, you can customize your interface with CAD software as well. But doing this does not mean customizing (only) the Ribbon. Macros bypass most of the need for Ribbons in CAD software. In the case of Pro/E-Creo, the tool to do this is Mapkeys. Getting proficient at creating Mapkeys is a skill, and is unfortunately underutilized by most. My rule is…if I find myself doing the same series of steps 3 times each time I get into Creo…create a Mapkey. Mapkeys are also the foundation of customizing the Ribbon. For a series of steps I use once-in-a-while (assign a material, change number of decimal points, change between fractional and decimal dimensions, etc.) – create a button in the Ribbon to execute a Mapkey. For a series of steps that I use frequently (view shaded, view hidden, etc.) – create a Mapkey for two or three button keyboard execution. For those steps that I perform repeatedly (turn datum on or off, points on or off, change view orientation, save file, etc.) – create mapkeys that are triggered by a button on my multi-button mouse. This is how you tap into the functionality of interfacing with your CAD software…and into real gains in productivity…by customizing the interface to be intuitive for YOU.
If you are going to complain about the Ribbon interface, and you have not really tried Mapkeys, you might as well go get a job that does not involve Pro/E-Creo. You can complain about the trials of implementing mapkeys (and the lack of support for continuity of mapkeys between version upgrades). But once you have properly incorporated Mapkeys into your routine use of Pro/E-Creo, the irritations of the Ribbon interface become inconsequential and not worth mentioning.
Yes…Mapkeys are the path to intuitive productivity in any version of Pro/E-Creo…but they are not without their quirks. I have a list of over 100 Mapkeys . I had occasion years ago to attend a presentation by James Heppelmann – who stated at the time that the transition from Wildfire to Creo was designed to be seamless and trouble-free. I wanted to stand up and tell him it wasn’t quite so. I had just spent over two (unanticipated) weeks re-creating about half of the Mapkeys I had developed and used for the previous two years. They had become ‘functionless” as a result of the changes in some of the Mapkey commands. Seamless…and trouble-free…bull----! But once I had re-created and edited my collection of mapkeys, productivity was in fact, even better than before.
The path to increased productivity is not always without its hurdles. There was a similar hurdle in transitioning from Creo 1 to Creo 2. Sometimes it is best to get into Pro/E-Creo, execute the steps you want in your Mapkey, then exit the program. Locate and extract the desired steps from the trail file and edit them into a Mapkey. Even a “normally” created Mapkey will often have unnecessary commands – which can be edited out to speed it up. And why (in this world, in its current level of technology) would anyone put Mapkeys (macros) in the same file that now contains hundreds of configuration setting? – Here’s a legitimate item to add to the list of “MOST ANNOYING THINGS WITH CREO”
Mapkey implementation needs work, but regardless of the irritations – it’s worth it. Once you embrace this approach, for the first few days you will create 1 to 5 macros a day, then 1 to 5 macros a month, then 1 to 5 macros a year. If I spend a whole day on one Mapkey (creating, editing, testing, refining), if well implemented, it always reaps benefits in the time it saves in the future (at least till the next version upgrade). You will usually use a few minutes each time you create a Mapkey that will save you accumulated weeks over-all. There are a few series of steps that are difficult to Mapkey, and even a few that are impossible. My approach has always been to assume that it can be done until I prove that it can’t (as opposed to assuming it’s just too difficult to try).
So as I read (almost every day) the entries in MOST ANNOYING THINGS WITH CREO concerning the Ribbon and some other dysfunctional areas of Pro/E-Creo, I always fight the urge to respond with “either go use the other software – or create yourself a Mapkey!”
3D modeling can be the backbone of any project. I have never seen the failure of a project (a client design challenge) based on too much accurate 3D modeling. I have witnessed many times, broken (and failed) projects, as a result of inadequate or inaccurate 3D modeling. However, the necessity of 3D modeling is no longer limited to geometry. Customize your start part and start assemblies with the parameters you know you will need (remember I’m not using Windchill). Create parameters that have an origin date, revision and revision date, drawing note(s), etc., that you will use at any stage (design, refinement, detailing, identification, fabrication, destination, etc.).
The curve is less and less diverse in terms of ease and accuracy of 3D model geometry among the various CAD packages. Now that the challenges of 3D geometry has seemingly been met, everyone is addressing the fact that they already knew…there is a lot more than geometry that needs to be incorporated into the model. Thus the attention has shifted…from the geometry of the 3D model…to all the information that can be incorporated into, and extracted from it. There have been databases since before the inception of the electronic computer. Nowadays 3D models are what relate all that numerical data to the real world (until the 80’s it was either the scale model or prototype). They are what eventually becomes tangible and physically functional. Much has been created in recent years that could not before, because it has been able to be imagined, and then created with a mathematical model inside the computer.
PTC was once the most powerful and capable (compared to anything else) 3D modeler (let alone parametric) available (it possibly still is – it just lacks a competitive innovative interface). Now that there has been a shift towards managing all the related data (PTC’s Windchill wishes to be the best example) there seems to be less motivation to further develop a truly innovative and intuitive interface for 3D modeling, or even to address issues with the existing interface and capabilities. The number of entries and subjects under just one discussion “MOST ANNOYING THINGS WITH CREO “ reveals this.
It used to be that our sales people would impress clients with the fact that we use Pro-Engineer (and not even mention that we also use Autocad, SolidWorks, and Tekla). Now, SolidWorks is mentioned – mostly because everyone at least knows of it. We seldom mention that we use Creo – because we have to further explain that Creo used to be Pro/E…and what was Pro/E? – compared to Solidworks?
For us die-hards… I will continue to use Creo, endure the taunts of SolidWorks users, continue to refine my Mapkeys, and resist the urge to respond to many “MOST ANNOYING THINGS WITH CREO “ entries with “either go use the other software – or create yourself a Mapkey!”.
I finally quit submitting anything to PTC’s “Product Ideas”. What’s the point when it takes years for PTC to even indicate if it is something they will or will not consider…how long should one be hopeful, or finally know that you will always have to do a “workaround”. I subscribe to PTC Technical Support Subscriptions. It is often a source of hints, cures and techniques to deal with software quirks, and sometimes to find helpful but otherwise “hidden” config.pro options. It has also become a discouragement that as a line item in some articles addressing submitted issues, under “Resolution” there is the entry “Kindly log an idea at Product Ideas @ PTC Community”. Why would you log an idea if it takes over a year to know if it is ever going to be considered (let alone knowing if it is not going to be considered, or when it might be available if it is).
In the early years, PTC seemed anxious to jump on and implement any reasonable ideas – it kept them ahead of their competitors. Now it seems more important to PTC to simply offer workarounds, and submitted “Product Ideas” must apparently win a popularity contest (rather than be considered on merits as a productivity enhancement or practical aid).
There are also some very legitimate issues brought up in “MOST ANNOYING THINGS WITH CREO “. For these issues, and the many good points suggested under “Product Ideas” that have been there for years without any indication from PTC as to their possible dispositions, I pray that PTC will not completely lose touch with the foundation that enabled them the opportunity for their clients to have a need for Windchill. Creo is still at the top in the list under Product Families on PTC’s website, but it seems to have taken a back seat in terms of client fulfillment.
I'll throw in that I keep mapkeys out of the config files. ProE/WF/Creo is just as happy reading a text file with the mapkeys in it, so I create one mapkey for the config that loads all the other mapkeys I use by default. And I have several files so infrequently used and ad hoc mapkeys don't pollute the main group. This means when I click on mapkeys.txt it opens Notepad and not Creo.
I agree on the name change. It was not helpful. It doesn't stand out in web searches and dilutes brand recognition. They should have just used PTC as a prefix, like GM does for its main line of cars.
Finally - upper end users of Microsoft products are also unhappy about the ribbon interface, which came from the same mill that produced Clippy and Bob. It is based on the flawed concept that what is helpful to a user with no training on day one will be productive to the user when they gain experience. This would be explicable if road race bicyclists were still sporting coaster brakes and training wheels.
I've got a similar urge to reply while reading that thread. That is "Go hardcore or go elsewhere".
Stay and die hard. That's how it's gonna be. Yay.
Thank you for writing this. We too make extensive use of mapkeys. Prior to our jump to Creo Parametric 3 we migrated over 200 company wide mapkeys. Some of them kept working fine from earlier versions. Many had to be recreated. Some of them we have been completely unable to recreate. In fact I've spent all day today just trying to recreate a mapkey to enter text into a table cell and format it without crashing Creo. There are definitely some serious issues with mapkeys and the new text entry method (in place vs. separate window) and related dialogs.
That's epic!! My usage of mapkeys over the years has "ebbed and flowed" but I completely agree it is a good solution to many of the problems with productivity and it is completely within the power of the user!!! No waiting on tech support or product development to fix things.
I agree with all of this but the mapkeys. Like Tom Uminn I have created hundreds of mapkeys over the years and have edited the mapkeys directly in the file many times. Mapkeys are just as much of a kludge as many other parts of the software. As the main way that experienced users actually satisfy their need for efficiency with the software... to break most of the mapkeys on each release and to spitefully or lazily choose not to release the documentation for the mapkey api is just plain disrespectful. Every release I fix less and less of my mapkeys because I too have found that I can no longer make many of them work at all much less consistently. One day I expect they will just remove the mapkeys from the menu in order to "focus" their efforts more on the UI or something. The programmers clearly don't have a mandate to make the mapkey functionality work smoothly and consistently.
The sad part is that mapkeys are really the only resource for productive customization by the average user (without the challenge of resorting to programming languages). The versions of Pro-E/Creo have only complicated the issue - potentially more capable software with less capable mapkey support. Mapkeys, scripts, macros...whatever you want to call them, become a necessary evil if you're going to reap potential benefits of customizing the software to meet your particular methods and directives. Mapkeys by themselves are ineffective macros. Even when mapkeys work (per the documented methods of creation), they are full of unnecessary junk unless manually edited.
I use a Razer Naga mouse with a total of 19 programmable (assignable to a macro) buttons. I keep my Creo mapkeys relatively simple and then augment and implement them with macros within Razer Synapse. This is very effective, but it is also a testament to the fact the Creo mapkeys alone are inadequate.
Besides the fact that help/support for Creo has improved somewhat(?), it is based solely on successful empirical instances ('performs to product specifications'), and never volunteers or explains what cannot be done, or has any practical examples. Thus developing good functional mapkeys becomes a time consuming experience in trial-and-error, breaks down at each new version, and pushes patience to an extreme level of frustration.
Yet I persevere, only because some new (version) software capability usually provides better gains in productivity than the battle encountered in re-stablishing broken mapkeys - guess that's why I'm a Die-Hard. There's nothing about the mapkeys that I can defend. I just know that I have to use them, one way or the other, in order to exploit productivity in Creo.
It is really a shame that they don't make their VBA API more accessible. I use Autohotkey to automate AutoCAD and it is incredible the stuff I can do with that even on top of what AutoCAD already offers. I tried to get it to work with Creo and I think the convoluted way they have it set up was either broken or blocked by our enterprise software. Autohotkey executable scripts/mapkeys in combination with my G900 programmable mouse I don't think can be beat for efficiency . You can check out my blog for my Autohotkey/AutoCAD tips.
The software as a whole is still worth using if you are already committed to it as a business but I don't think the new functionality is more significant than the new bugs and broken mapkeys. I think they are about the same roughly. Simulate has gotten better but aside from that I would rather have Wildfire 4 still. I even like the ribbon mostly . The problem is the ribbon is what limits the usefulness of the mapkeys.
I am impressed with your optimistic attitude though Aaron!