I was busy at AU last week, which is why there wasn't much activity from me online. I'm not going to repeat AU news that has already been posted elsewhere (PLM, Autodesk 360, etc), that's not what this blog is about. I'll keep things focused on the Vault API and share some things I learned.
Yes, I learn things at AU. Not things about the Vault API, but how people perceive and use the Vault API. The more I understand my users, the better I can distribute information.
I've known for some time that the API consumers fall into two camps, the professional programmers and the non-professional "scripters". Since I'm a professional programmer myself, I'm good at providing information targeted at the first group. The second group is where I rely heavily on feedback.
The Scripter persona
Let me take a crack at describing the Scripter (feel free to let me know if I missed something). This person wants to customize the Vault but doesn't want to spend days learning the entire Vault API. Usually they want to write tools tailored to their own environment. There is a task that they do over and over and they want to automate the process or reduce mouse clicks. The best-case scenario for them is to find a similar tool that they can tailor to their own needs. Having to start from scratch is a big pain and sometimes a show stopper.
Cost of entry is also a big factor. It's very important that a scripter can get something working early on, even if its just a Hello World example. Spending hours figuring out how to get a command to load is not acceptable.
Feedback
Most of the feedback I get from scripters is positive so I'd like to share that with you. I don't get much feedback on things that aren't working, but I do get questions like "Do you have an app that does X?"
The good: SDK Samples
These examples are easy to read and easy for scripters to modify.
How to make it better: More samples in the same style. In other words, samples that illustrate one useful concept in a clear and simple way.
The good: .NET
It's an easy-to-use and powerful programming platform. It's free and supports VB.
How to make it better: Get rid of the "compile" step. This goes back to reducing cost-of-entry. The less steps equals lower cost-of-entry. And, technically, scripting means that the code does not need to be compiled. There are a couple of techniques that can help with this goal, such as PowerShell and run-time compilation. I haven't yet taken a serious look at these techniques, but it's on my agenda.
Leave a Reply