Letter from the President - October 2017
This theme for this month’s AUGIWORLD is customization, and as I was thinking about that, it naturally led me to its close cousin, personalization. It seems to me that, more and more, we expect to be able to personalize the things we interact with. Forget Henry Ford’s philosophy of “the customers can have any color they want as long as it’s black.” If I’m using an app on my phone and find something I don’t like, I immediately look for a Preferences menu to see if I can change it. (And if I don’t find one, I get annoyed.)
What’s the difference between customization and personalization? The way I define it, at least as far as software, personalization involves changing built-in settings. Customization goes beyond that and either adds functionality or changes how the program operates. To use an example from AutoCAD®, choosing the background color is personalization, and building a ribbon tab with panels to store your firm’s in-house tools is customization.
Autodesk’s history with customization and personalization goes a long way back. AutoCAD has been customizable almost from Day 1. I couldn’t find when the PGP file was introduced (does anybody know?), but scripting was added in 1.4 (1983) and AutoLISP came in with AutoCAD 2.18, in 1986. The Revit API (application programming interface) started with Revit Building 8 and became a more central part of the development process with Revit 2009. Of course, I have to mention Dynamo, which uses a visual programming concept to help those of us who aren’t as comfortable with “code” create and run our very own scripts. And now there’s Autodesk Forge, which is an entire platform of APIs and SDKs (software development kits) designed to extend the functionality of all kinds of data and models. (And of course, it’s not just Autodesk: MacNeel has Rhino and Grasshopper, Microsoft has Power BI, and Google has Flux, just to name a few.)
But are we losing something in our race for complete customization? Is there still some value to a universal experience? (Anybody who has sat down at a new machine and realized the keyboard shortcuts are different—or worse, that your favorite add-in isn’t installed—will know what I mean.) Sometimes the ubiquity of customization and personalization capabilities makes me feel like I’m living in If You Give A Mouse A Cookie—once you start changing things to meet your preferences, where does it stop?
At Autodesk University last year, I saw a board that the Research team was using to ask people how certain types of settings should be stored: by individual, by project, or by company. Settings dialogs aren’t necessarily laid out that way (or if they are, they don’t use that nomenclature), but I thought it was a useful concept. For example: each person can have his or her own set of keyboard shortcuts, but a title block belongs to a project, and plot settings belong to the firm (or at least, to an office).
If you work with people who don’t quite understand why they just can’t change a particular setting, maybe this will be a helpful framework to deploy. If you can explain what personalization and customization they are allowed to do, it might help them accept the ones they can’t change.
I’ll conclude with these thoughts: Personalization, used wisely, can strengthen our connection to the tools we use and make our interactions with them more comfortable. Customization, leveraged strategically, can expand our technical abilities beyond what a program’s creator ever imagined. And both, if taken too far, can sow chaos and confusion within a user base.
The ability to personalize and customize our software is an extremely powerful one. But I’m sure you know that with great power comes great responsibility. (Thank you, Spider-Man.)
So until next time... customize responsibly!
