In the past I’ve made a few of my apps AppleScriptable, but I doubt anyone has ever used that functionality (I’ve certainly not received any feedback saying so).
I’ve recently released a new app and am thinking about adding AppleScript support. The app is written in Swift, and I found a great tutorial for how to do that on the RayWenderlich site here:
The problem is this: my users are fairly polarized: they’re either quite technically illiterate or they’re network admins. The former won’t use AS because it’s too hard, and the latter won’t use AS because they do everything through Jamf, Munki and the command line.
So, when I consider whether there is any point in me going to the time and trouble (as well as the possibility of creating bugs) of adding AS support, this is what I wonder:
As an AS user, when you come across an app that doesn’t support AS, do you just raise a weary eyebrow and then jump into System Events and try to GUI script it, or do you contact the developer and ask them to add AS support?
I’d love to hear from someone who wanted me to add AS support to my app; just one person would be enough to make me do it. But without the slightest encouragement, why would I (or any other developer) bother?
The point is this: if you want AS support in apps don’t forget to PESTER developers for it.
If I seen an application that supported AppleScript and another Application that did not support AppleScript and they both did roughly the same things I would purchase the application that does support AppleScript even if the one that supported AppleScript cost more. The only way I would pick the one with no AppleScript support is if that application had a lot more functionality that I would actually use. Even if I don’t see an immediate use for scripting in that application I like knowing that the support is there if I need it.
I have seen many examples of polar users you described. Posting AS functional examples on your site can help with some of the users that are less technical and more technical. More advanced users who knows many ways to solve a problem is not going to pick AS if they have a learning curve and they have other solutions without a learning curve. The less technical might try it with examples.
I get a lot of less experienced AS people asking me for help and giving them a few examples that target commonly encountered problems gets maybe over half of them to start trying it. It just depends if the user trying AS is someone who get in and play around with things or not. Some users that need to figure out things in a scripting language just don’t bother to try figuring it out.
But you as a developer need to figure out if the development time cost you too much time. Development is a livelihood. If it cost you too much to develop AppleScripting that don’t do it. In the end revenue drives a lot, if not all the decisions, made about what to implement.
I may be an odd case, but generally if it doesn’t support AS, I give up. That doesn’t mean I won’t use the app, but it does mean I won’t bother trying GUI scripting (unless for the simplest of things). That essentially means I’m always keeping an eye out for a scriptable equivalent, so I can change apps.
As Bill wrote. I try to find an equivalent application that does support AS. But if I find free software that has no AS support and still does the thing I might consider using that instead. That was my problem with FTP recently. I’d rather use the command line from AS than pay for an elegant AS supporting FTP client that does thousands of things I will never need.
As Shane, I don’t think I want to investigate GUI scripting for native apps, unless it is for trivial things. For non native apps like Java apps, using GUI scripting is an interesting way to solve some problems and they can’t have AS support anyway.
Also, I think it is important for developers to show examples of scripting if they want users to use that function. Dictionaries are not enough.
Last but not least, there are some FOSS applications that have limited AS support. I’d love be one day able to contribute there. I’m thinking of nvALT for ex, where we have a search function but now way to access the note contents.
Absolutely agree, and I do have a Scripting Examples page on my website (and I include examples within the sdef) for my other apps.
The app I’m talking about here (and I’ve deliberately not mentioned it or linked to it as this isn’t an exercise in self-promotion) has a command line tool (for the network admin guys), but that functionality requires a commercial-type license. I think I can (and will) add AS support for the other functions though. I doubt it will get used, but at least doing it in Swift will be a fun challenge for me, and might be something I can help others with in the future. Plus, I feel bad as a scripter not having scripting support in my own app!!
Thanks for the feedback. Y’all kind of helped me make my mind up!
I’m as Shane with a silent “Cheap!” crossing my mind. Unless I really need a particular application, I will choose a paid one with AS support over a free one without it because I want to be able to control everything I have on my disk even if I don’t do it right away.
I am late to the party here, but anyway; I have scripted many applications, but never made any of the authors aware of the fact.
I would never pester a developer for applescript-support. I guess they mostly think of applescript as a dying technology and the ones who don’t already make their applications scriptable. As long as there is some command line available it makes a lot more sense to just use that than asking a developer to add applescript support.
I’m curious, why does it make sense to use whatever is in the app as apposed to asking for AppleScript support. Developers are business people as well as developers, although I have met developers who aren’t happy about the businessman part Developers are always interested in things people would want in their program. They might not have time to get to what is asked for but they would be interested. Lots of people make feature request to developers. I’ve seen developers who make whole new versions from just feature requests. Pierre Bernard, who does Houdah, does that and has a wonderful program.
I’m not saying anything bad about your remarks. I’m just curious.
I agree, although it would depend on your definition of pester.
Certainly as a developer, I want to hear what customers want. It all goes on a list, and then I choose which to implement at any given time based on a bunch of factors, so any given thing may never be implemented, but it is always better to know.
On the other hand, if by pester you mean (as the definition states) “annoy with frequent requests”, then I’d also agree that is not appropriate. I imagine most developers are far more amenable to a single well reasoned argument that a sequence of repetitive “I want” emails.
Also, speaking for myself, the number of people requesting a feature alone is not decisive of what I will implement, it is a balance between how many people it will help, how much it will help them, how well it integrates with the rest of the program, how much effort it takes to implement and maintain, etc.
That is a good point. I was assuming pester meant let the developer know, not go on and on about it. It is also true the poorly articulated request can be close to useless if not totally useless. Thanks for your response It helped me see things from a different perspective.
Ten years ago I did ask developers for AS support. I cannot recall if that resulted in anything, but at that time I thought it was worth a try. Now I do not expect any developer to be interested. I am probably wrong.
If I plan to use an application in a workflow that would be suited for scripting I would rather search for another app or solution that is scriptable than try to get a spesific developer to – maybe sometime in the future – provide som half-baked script support. At that point in time I have probably found some other solution.
No, you didn’t sound negative. I was just curious about why you felt that way. I thought I might learn something and I did. AppleScript has had times it was on life support and not expected to survive. I have worked with it since it was first developed at Apple. It’s had a number of times it rose up and a number of times it dropped down. After a few decades I have learned not to call it dead yet.
However with the addition of ASObj-C the possibilities for AppleScript have grown considerably. Enjoy the site and have a great day
I do have to admit I did give up on Quark Express ever doing anything to fix bugs. That wasn’t a scriptable word processor, it was a beast looking for a victim to maul.
Developers are always interested in things people would want in their program. They might not have time to get to what is asked for but they would be interested. Lots of people make feature request to developers. I’ve seen developers who make whole new versions from just feature requests. Pierre Bernard, who does Houdah, does that and has a wonderful program.