Jim Lipsey

SolidWorks recently unveiled beta 4 for the 2007 release. From the press releases, it appears we’re getting close to SP0. A lot of new features are bundled in this effort, and many, such as enhanced Curvature Continuous (C2) and spline editing capabilities are being well-received. I’m dubious about other new additions, such as the SWIFT SketchXpert and FeatureXpert. SolidWorks’ wizards have always been hit-or-miss. Props to the hole wizard, but Smart Fasteners require more trouble than they’re worth. From their descriptions, the Xperts strike me as akin to the Shape function — impressive for demos and used by novices, but of little value outside of CNC’d one-offs. This criticism is unfairly premature. I haven’t even tried the beta.

I have, however, worked extensively with every version going back to ‘98. Recent releases have made something increasingly apparent. It’s time to bite the bullet and rewrite the SW interface and file formats either in large pieces or whole cloth. And some aspects of forward compatibility must be broken to do so.

SolidWorks has a long-standing policy regarding file compatibility — each new major release will import files from previous releases, but only save to the current format. Every detail, from features, to assembly mates, to visual properties must be faithfully imported and result in a model in exactly the same state as the original, but compatible only with the current and future versions. Service packs within the same major release are always supposed to be inter-compatible with no import step, though there has been the occasional hiccup in this regard. Generally, this system works well, allowing SolidWorks to add capabilities while ensuring forward compatibility. Users sometimes gripe about the lack of backward compatibility, but it’s virtually impossible to add featuring tools and expect a part to be built, much less editable, in a prior release. However, nearly a decade of adding in new capabilities, as well as incorporating third-party addins in the core packages have resulted in a lot of cruft. The interface is showing signs of being over-ridden with confusing tool buttons, menus and interface dialogs that often seem at odds with one another.

Nowhere is this more evident than in specifying visual properties. Appearance properties can be defined at the face, feature, body, part and assembly levels (did I miss any?), with color, texture and transparency each specified with a plethora of options. But even then, visual properties are also impacted by material property specifications. If that weren’t enough, there are two display modes: standard and RealView, the latter being an eye-candy feature added a couple years ago to make demos more exciting. Things are more exciting at the assembly level, which starts with the the current set of display states for each component, then allows for part-level overrides for all of these properties as well as display mode (shaded, HLR, etc.) and visibility.

In 2006, SolidWorks added the Display Pane as a clunky flyout from the Feature Manager to help users make sense of all this, but it’s basically a band-aid solution and far from complete. To make sense of everything, we now decipher a two-dimensional array of colored triangles and icons. Set the transparency for a part to 1% (hardly noticeable relative to being opaque), and the tranparency icon is toggled in the Display Pane. Change the color of a face, and the Display Pane doesn’t register any change at all.

Competing property scopes and a confusing hierarchy of property settings aren’t limited to visual specifications. A material specified at the part level may or may not be the one that is actually used in COSMOSWorks, which has its own material manager. The same is true again of PhotoWorks.

The many material editors of SolidWorks.

I’d like to see SolidWorks start over with respect to visual and material properties that are independent from part geometry and assembly construction. We need to simplify the whole system. How about a single, unified XML schema for defining materials? Have it encompass all mechanical and visual properties. Give us a flexible property editor that allows materials to be dragged-and-dropped from one database to another. Allow users to apply properties to multiple materials simultaneously. Only define materials at the part level, have the material designation be configuration-specific and uniformly utilized by SolidWorks, COSMOSWorks, PhotoWorks, etc. This would be a terrific enhancement, but will almost certainly break forward compatibility in parts that have competing properties tied to different SolidWorks functions.

The SolidWorks development team has a tough job. Their user base is incredibly diverse — running the gamut from small machine shops to design houses that crank out large, complex assemblies intended for mass manufacture. To satisfy all these users, an incredible level of customization is demanded. However, the consequence of all this flexiblity is complexity, which eventually becomes an inconsistent and overlapping feature set. To create an elegant (but not necessarily simple) user interface and modeling system means features being demanded from some quarters will not be implemented. This is a tradeoff that is always present in software development and not unique to SolidWorks. If SW is willing to alienate a few customers in the process of producing a more consistent, usable product and continue to improve their modeling, surfacing, analysis and PDM capabilities, they can become the undisputed leader in the 3D CAD arena.