Now that I am (momentarily) out of apps to post, I'd like to take some time to talk about this blog. What are the objectives? What is the plan for the future? That sort of thing.
The philosophy:
This blog is 100% meat. There is no filler for fluff. If it's not related to Vault, it's not getting posted. There will be no vacation photos, stories about my family, movie reviews and so on. Some other blogs do that, and that's fine, but it's just not my style.
A consistent level of posting is important too. The formula I use is 1 posting per week and 1 sample app per month. I've been able to keep that pace for over a year an a half, which is a decent accomplishment in my opinion. The downside to this approach is that there is an excess of content and certain times of the year (like now with the release of Vault 2012) and a lack of content at other times (like right before a release). The result is a slower release information so that it lasts for the whole year. Hopefully, you are not even aware that I'm doing this. Nevertheless, let me know if there is a topic you want me to hit sooner than later.
Programmers are my target audience, but I'm very aware that free apps is a big draw for all types of Vault users. The two groups are very different from each other, but I haven't heard any complaints. Regarding programmers, I want my blog to serve the whole spectrum. From professional software engineers to hobbyists that barely know how to code. Not every post will hit the entire range, but overall, the blog should have something for every type of programmer.
My blog is just part of a network of Autodesk online content. On the Vault side alone, there is a usage blog, support blog, wiki and discussion group. The hope is that all these pieces come together to form something positive and useful. I try my best to fill my own little niche while adding benefit to the overall network.
Future plans:
I don't have specifics or timetables or anything like that. But I do have some ideas bouncing around in my head that I would like to start acting on in the upcoming year.
- Quick start guide: If you are new to Vault programming, I imagine the whole thing can be overwhelming. So I will be creating a section geared specifically for getting someone coding on Vault as quickly as possible. It may just be a page that links to some of my old posts, or it may be something more experimental, like a video tutorial series. I'll probably start small and grow it over time.
- Developer community: Since my blog is the de facto place to go for Vault apps, I'd like to use it as a cornerstone for a development community that extends outside Autodesk. The trick is how to do that without sucking up too much of my time.
- Retroactive updates: As new Vault releases obsolete my older posts, I need to go back and add addendums indicating how things have changed.
Don't change what is working:
I have no intention of changing anything. Based on all the feedback I've received (both internal to Autodesk and external) this blog is on the right track and I should keep doing what I'm doing. I have no intention of changing my rate of posting, sample apps, webinars, level of technical detail and so on.
Final Notes:
I love what I do, and hopefully it shows with every post. Maybe one day this blogging stuff will seem like work, but I don't think that day will come anytime soon.
Subscribe
My Take-away from AU
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.
Posted at 08:09 AM in Commentary | Permalink | Comments (0) | TrackBack (0)