Originally published at: https://latenightsw.com/script-debugger-7-press-release/
Late Night Software Ltd. Contact: Mark Alldritt Email: sales@latenightsw.com Tel.: (250)-380-1725 Website: http://latenightsw.com FOR IMMEDIATE RELEASE Late Night Software Launches Script Debugger 7 VICTORIA, CANADA, March 2, 2018 – Late Night Software Ltd. has released Script Debugger 7, the latest version of its award-winning AppleScript development software. The upgrade introduces Script Debugger Lite, several new…
Mark, do you have a short, compelling video about why a user should at least try SD7?
I’m updating my standard YouTube description that includes key apps, videos, and links, and I’d like to include a video about SD7. I already have the LNS link.
I just had an idea. What do you think about adding at the end of such a intro video, short interviews/comments by selected SD7 users, perhaps some who are well-known, and at least one “normal” user who just discovered SD7.
I don’t really havingthing like that at present. I have plans to try and distill all of Matt’s Script Debugger 5 videos into a series of around three videos introducing and explaining Script Debugger. The best I can offer at right now is the Viewing Variables And Values video:
Mark, to be blunt, that is not at all what I was thinking about. It jumps in the middle of a very focused SD task, without any intro about SD itself.
I watch a lot of tutorial videos, and I have found that TechSmith produces some of the best videos, like about their product SnagIT 2018.
But in particular, you may want to look at the first two videos as excellent examples of introducing a product:
For a longer, more in-depth video see
TechSmith Snagit 2018 REVEAL
IMO, to help sell SD to those new to AppleScript (or infrequent users of it) you need to identify the “pain points”, the issues, that an AppleScript coder encounters, and then show how SD easily and quickly addresses those.
Like in the first SnagIT video, start high-level, briefly stating a problem, and then showing briefly how SD solves it, just showing a brief portion of how it is done, focusing on the results.
IMO, the biggest benefit of SD to new AppleScript users is in helping them understand and use the object model of the apps they are interested in. So, I would start with stating some problem with some app, maybe Safari or Pages or Keynote, and show the user how they can quickly explore and identify the objects and commands they need. Try to limit the detail – this is NOT a tutorial – it is a sales demo. At the end of the demo, you can provide specific tutorial videos that go into detail.
One key thought: just like with writing, often the hardest part of writing a new AppleScript is getting started. So share your experience with getting started with AppleScript projects, and then show how SD helps you do that.
Just had another idea – how about creating a contest for users to submit, in detail, their biggest challenges in using, and getting starting with, AppleScript.
The winners (you decide how many) get a free license to SD7, AND someone (ask for volunteers here) will help them develop their first major AppleScript. Maybe you limit the last to the top winner, or the top 3 – that’s up to you. There are already a number of long-time AppleScript users here that love to help people – maybe they would be willing to help with this contest.
Another idea – build a page of the top positive comments you are getting from the SD7 reviews. If they are in a podcast (or verbal only), then transcribe, maybe with a link to that portion of the audio.
Good luck with all of the above. I wish you much success. Let me know if there is any way I can help.
Jim, there are things in what you describe that LNS should do, and I fully agree with what you wrote about pain points, and there are some other things that the “community” could do.
Mark,
What would impress me as a perspective buyer is actual working examples of things that can be done in Script Debugger. Before I got into AppleScript I looked at what could be done with AppleScript. Then I moved into part time, and really learned what it could do. Then I went into it full time.
SD is great for helping people who are new to AppleScript to learn quickly. It’s also good for helping more advanced users to accomplish more with the same amount of effort. When it comes down to things like this it’s more about what the person wants to accomplish and what the product can provide.
Advertising how great and empowering Script Debugger is one thing, but providing them with something they can do great things with right away is another. I would be impressed with a paid program that came with a “wide” variety of useful scripts that helped people become highly productive very quickly. That is a tangible thing. I would be willing to give you some script you could include in a free give away. I’d bet other would as well. This is more then just talk.
Also talking about how active the SD group is and how helpful it can be is also a very tangible thing. It sounds like something that would lead a perspective buyers to become a lot more capable with AppleScript. The fact that you do “very” regular updates on Script Debugger impresses me to this day.
So many get into AppleScript and just don’t know what to do with it beyond very simple things that they could get by without. I would think seeing real, impressive things done entirely on Script Debugger would attack paying customers.
People getting the free version is a start, but the actual goal is to sell the product. Until people start to create great things with Script Debugger it’s much harder to see the value. Once people can see the value they would tell other how great it is.
I know the talk (spoken and written) in advertising is important, but it is the businesses that go beyond the talk that stick out to potential customers. Customers that would buy Script Debugger have certain things they want and helping people see that Script Debugger is a way to reach those goals is really what advertising and marketing is all about.
Bill
Some 18 months ago or so, I ended my review of SD6 by asking “how about an SD lite guys?” - and I honestly think this is the best thing that you could have done for AppleScript, and hopefully for yourselves, too.
Now, I’m just wondering what SD7 can do for me. While I will be endorsing and recommending SD7 to everybody that doesn’t currently have it as a replacement for SE, I’d like somebody to give me a compelling reason why current SD6 users should upgrade.
None of the features I requested in my review of SD6 have been implemented - no search in Prefs, no themes, no ability to view two different scripts in horizontal split view mode – yes, just my personal wish list, but since SD6 is already feature-rich, I’m not sure what SD7 offers me that I need.
Versions is nice, but not essential - I have other ways of doing that myself - I don’t care about adding Sparkle as I don’t build apps in SD. Have I missed something else to get excited about? Someone please tell me that it’s so!
Phil, it is certainly not an overwhelming set of new features. I’m working my way through some of them, and that takes time.
Since I distribute script apps, one of the most useful improvements is in the Resources tab. I’ve already taken advantage of the ability to specify code-signing only when a run-only export is created, even though code-signing itself seems faster in SD7. I like the clear-cut interface in this panel of being able to include used libraries, or set an applet to background only.
Also, the ability to filter dropped files based on extensions and/or UTIs is great, since a droplet is the type of script I make for most clients (and still one of the best interfaces ever). No more trapping by code needed!
I have not used the enhanced applet yet on a client job, but I’m sure I will. It’s the first interface improvement to script applications in years (decades?) so it is very much welcome.
$50 upgrade cost for an app I use every day to make money? Even considering the Resource features alone, that is a no-brainer for me.
Thanks for pointing those out Ray, and how they’re useful. I will be writing a review of SD7 when I get the chance (pretty snowed under with other stuff at the mo!), and that’s useful info I’ll be sure to include.
It does sound like a lot of those features hit a sweet spot for your use case.
For me, not so much. I mostly use SD now in one of two ways:
i. building scripts to automate tasks in apps like BBEdit, Coda, Numbers and Xcode, or to automate the system via FastScripts and Hammerspoon; and
ii. to prototype things I’ll end up doing in my Cocoa apps natively in objective-c or (more so nowadays) Swift. Sometimes it’s just quicker and easier to get a feel for how to do something by banging out an AppleScript (and on some occasions, it can actually be easier to use that code in the app directly with NSAppleScript)
I don’t see anything much that targets my use case; I was really really hoping for split-view to allow loading different scripts, but aside from that, SD6 has me pretty well covered.
I will update eventually, both for future compatibility and to support continued development of the app, but I can’t see any urgent reason to do so, atm.
Ray and Phil both make very valid points.
I have a lot of strong feelings in favor of SD because it did so much to change my life for the better. Being a scripter was so much better than being a software developer. It’s a completely different type of job. So I literally would buy a version of SD even if I didn’t need it.
But when I look at SD 7 I see things that makes working with AppleScript better. Some tedious things I used to deal with are now handled better in SD 7 and that is nice. But if this product wasn’t written by Mark and Shane I don’t if I would spend the money on it. SD 7 is really great for first time new users. But for long time users of AppleScript the things SD 7 “helps the user” with have probably long since been circumvented, or a better way was found. This is the case for me.
But I haven’t met many long time scripters who didn’t care about learning new things. The discourse web site is one thing that would totally draw me into script debugger had I just found out about Script Debugger and the group. I’ve had many times I posted something I came up with and someone suggested something better. Sometimes people point out the flaws I didn’t see with my implementation, add ideas to what I was thinking about, … I assume a person has to have bought bought some version of Script Debugger to get on the site. That would push me toward buying it.
Having tutorials for ASObj-C is of value for people who have been in AppleScript a long time. Shane helps and teaches that all the time on the discourse site. I’m making the ASObj-C database free to anyone who wants it and that is found in the site. The point I’m trying to make is the way you draw in new users and long time users is different. People start at one, move to a mix of both, then move into the other.
If script debugger could run scripts in a separate process and survive working with ASObj-C even if I was stepping through the script I would totally buy it. Even at a higher price because it’s worth the money. The increased power justifies the cost. ASObj-C is so powerful but is a pain to work with in an editor the runs in the same process. Stepping through ASObj-C code when using AppKit is rather suicidal.
ASObj-C’s capability in a stable editor is what those in the business work would say allows them to leverage their current resources far more effectively and the “output” to “man hours” ratio would rise noticeably. As a businessman once said to me I want the solution to make me more money then it cost me. The better it is at that the more I will use it. That’s pretty much how businesses see it.
Right now AppleScript links applications and resources together to produce useful end products but because of AppleScript limits in what it can do beyond linking things together is limited. To have something as powerful as ASObj-C and still be able to control workflows through automation has a real market.
When facespan was around customers readily accepted the use of facespan for solutions because of how robust the solutions could be. But solutions can now be robust again because of ASObj-C if someone can figure it out how to use it and share that knowledge with others. That’s why I do the ASObj-C database. I’m getting farther along with having interactive (non-modal) ASObj-C windows with a more advanced interfaces without requiring a “modal” dialog. I think this is something that can be taught to others. I think this is totally amazing stuff.
This is what I think after many years with AppleScript and when I met other long time users of AppleScript many of them get excited about the idea. But these grand ideas are too advanced for someone new to AppleScript. I don’t think the same approach will work for both types of users.
Bill
Thank you for your ongoing support. I’m very pleased to hear that supporting future development is part of your thinking. I’m sorry we didn’t provide the features you asked for. I understand that an upgrade needs to justify its self.
The move from SD6 to SD7 offers fewer new features then previous upgrades have. However, SD7 is vastly more stable and there are hundreds of refinements that make it better. Nothing earth shaking, but just “better” in undefinable ways. This is the nature of a mature piece of software.
When Shane and I decided to drop SD6’s price by 1/2 to $99, we also decided to ship paid releases with fewer new features more frequently. Our goal was a paid upgrade every 12 months, but it took us 19 months to get SD7 done. We hope that, over time, more frequent paid upgrades (which also saw a 50% price reduction) will generate income to compensate for the losses in full-version sales. The sad truth is that the 50% price drop did not generate twice as many SD6 sales, far from it. Despite this, we are sticking with this approach and we’ve made the bet that SDLite will, in the long run, result in more customers.
Obviously, nobody is compelled to pay for an upgrade they don’t feel has value. However, each upgrade helps keep Shane and I working on SD which includes maintenance releases, our presence on this forum, and ongoing work for future SD versions.
2 Likes
Let me add that most of the small refinements added were the result of user requests, so don’t be shy. Off the top of my head, I think the Merge All Windows command and the ability to copy error messages in the Event Log were both requests @sphil made. Similarly the (* and *) auto-pairing, formatting improvements, and changes to find/change were among changes requested in this forum.
2 Likes
Thanks for pointing those out (and adding them), especially this one, which is something I frequently have a need for (so almost an upgrade reason in and of itself!). 
1 Like