Live Discussion?


(Mark Alldritt) #1

I am seeing other software developers doing a lot of live product demos and interactive discussions for their products using the live streaming features of FaceBook, and other social networks. For example, ScreenFlow does this regularly on YouTube and FaceBook (

Is there interest in such things for Script Debugger? If so, what kinds of topics do you think I should/could cover? Are there formats for this kind of thing you find more useful than others?

As you may know, I’ve done several video tutorials for Script Debugger 6. I would like to do more, but I’m not sore what kinds of information people need most.

(Ed Stockly) #2

I’ve been thinking that a series of 30 or 60-second videos, each illustrating a different SC feature/concept might be cool. Like little commercials. I don’t think a lot of scripters under stand the concept of step-debugging and observing variables.

Also, for years I’ve thought that SD could be a great learning tool for AppleScript. I could see a series of videos titled “Learning AppleScript with ScriptDebugger”

I’m not sure how interactive discussions would work. With appleScript people are all over the map in their skill levels, apps they script and technology they use (pure appleScript; OSAX; ASOBJC; shells; javascript) I’m not sure if there’s specific topics that would be of broad interest.

(Mark Alldritt) #3

Please make a list of the features you would like to see explained in short videos. Script Debugger feels like a comfy pair of old shoes for me. I cannot see the pain points any more.

As the for the Live Videos, I was thinking we could have a topic and focus on that. It does not even have to be about Script Debugger. For instance, we could talk about scripting Mail or scripting Safari, or using ASObjC to interact with Web Services.

(Ed Stockly) #4

SD Video topics:

  • Step-debugging while viewing variables
  • Debugging droplets
  • Using the SD dictionary to build commands and learn about applications
  • Using the SD Explorer to see what is available to script in a document/window/app
  • Searching multiple dictionaries
  • Inserting clippings with placeholders
  • Writing and customizing clips
  • Scripting ScriptDebugger and using the scripts menu
  • Using Open Quickly
  • Using Code Folding
  • Text substitution, auto pairs and key bindings
  • Using script templates
  • Responding to URLs in web pages

These are roughly in order of importance in my own subjective opinion.

I’m pretty sure that none of these are available in SE. (Not sure about any other editing environment. ) I would miss every one of them if I had to go back to SE, but appleScripters using SE may not know what they’re missing.

Plus, there just may be a few powerful features I haven’t used yet, so I may not know what I’m missing too)

–>Script Debugger 6.0.4 (6A198) on OSX 10.11.6

(Jim Underwood) #5

IMO, 30-60 seconds is way too short of time to show a newbie almost anything, especially anything associated with step-debugging. The fundamental mistake many very knowledgeable presenters make is moving much too quickly for a newbie. To be effective you must move slow, both showing and telling the audience what (and maybe why) you are doing.

By “newbie” I mean someone who is substantially less knowledgeable about your product than you are.

The main benefit of a live, interactive, presentation is allowing the audience to ask questions, without having to write out a protracted question (like in a forum post), and then have some back and forth with the presenter.

I think this is good for a participant who is new to the product, doesn’t understand the terms of the product, and thus does not know how to phrase a good question. The presenter can (hopefully) pull the real question from the participant.

The downsides of a live presentation are:

  1. The participants have to be available at the scheduled time.
  • This may be a big challenge for many.
  • I rarely do anything live anymore. I record all of the TV programs I want to watch, and do so later at my convenience/availability.
  1. It make take much more of your time to prepare for a live presentation.
  • Obviously, you can’t edit it like you could with a video recording.

So, the question you have to ask yourself is “Are the benefits worth the cost of a live presentation?”.

Finally, I have to ask what is your ultimate objective in doing this?
I have assumed marketing, but maybe not.

Frankly, I thought this (“S2 EP1 of ScreenFlowLive.”) video was terrible.
(although I only watched the first few minutes).

  • The presenter was looking all around instead of at the camera.
  • He was not prepared, and so stated – did not have a clear agenda or even an expected duration for the live event.
  • I really don’t like FaceBook or its UI. I could not find a link to the video to share here, or elsewhere.
  • He started out talking extensively about himself, rather than the product.
    (does anyone really care about the presenter, unless he/she is a top exec in the company?)
  • It felt like a real waste of time for me.
  • It did NOT in any way encourage me to further consider ScreenFlow.

I know many people rave about Facebook. But it is social media. Is it really a good tool, or the best tool, for discussing tech products??? I think not.

I really like the way these tutorials are done:
Snagit 4 Tutorials

The one key ingredient missing is a Comments/Questions section for each tutorial.

@alldritt, well, I don’t know if I answered the question you were asking, but I hope you find this feedback useful.

(Ed Stockly) #6

I would envision these almost as commercials for SD rather than tutorials.

You can do a lot in 30 seconds.

(Jim Underwood) #7

OK, you’re on. I challenge you to make a meaningful, compelling SD commercial video of only 30 seconds.

Too tough? Then develop a 30 second video that will convince a newbie to learn more about SD. Remember, the newbie doesn’t really know much about SD, maybe only saw the name referenced somewhere.

(Phil Stokes) #8

Precisely. The only way SD is ever going to grow is if AS grows.

(Phil Stokes) #9

There are a lot of very bad screencasts / video tutorials around. TechSmith make some of the best, not surprisingly since their main products - Camtasia and SnagIt - are for exactly that purpose. I think the latest version of Camtasia does have some interactive features.

YouTube is probably a better platform than FaceBook, but I’m not sure about the “live aspect”.

A YouTube channel with upwards of 50 1 to 2 minute videos showing off pretty much every aspect of AppleScript using SD would be the way to go. What you want is anyone typing in an AppleScript question getting a link to that channel high up in the results.

An example of what I mean is this guy’s cocoa programming channel - though his videos are awful ( tedious, lengthy and full of errors), the sheer volume of content he’s got drives views (and the content actually is pretty good, if you can bear listening to him taking forever to get to tell you what you want to know). Type in cocoa and almost any topic to google and you’ll likely see one of his videos near the top of the search results.

Now if typing in applescript and a topic or question ended up at Mark’s channel with the tutorial done in SD; well, I’d see that as a very good way to drive new interest in the product.

(Ed Stockly) #10

I would do some spots at 30 seconds, and some at 60.

Newbie is not the term I would use.

The target audience is someone who has experience with AppleScript using Script Editor, and well understands the limits and frustrations of SE, and would recognize the value of SD.

To make these work they’d have to be carefully scripted, rehearsed and edited.

I’d start with the first item on this list (added a few more topics) and it would definitely be a 60-second spot. The others would be as indicated.

  • Step-debugging while viewing variables – 60
  • Debugging droplets – 30
  • Using the SD dictionary to learn about applications and build commands – 60 (or break this up into 2 30-secs)
  • Using the SD Explorer to see what is available to script in a document/window/app – 60
  • Scripting Addition dictionary – 30
  • A tour of the Variables/Resources/Inspector panes – 60
  • Searching multiple dictionaries – 30
  • Inserting clippings with placeholders – 30
  • Writing and customizing clips – 60
  • Scripting ScriptDebugger and using the scripts menu – 60 (or break this up into 2 30-secs)
  • Live Debugging applets – 30
  • Using Open Quickly – 30
  • Using Code Folding – 30
  • Text substitution, auto pairs and key bindings – 60 (or break this up into 3 30-secs)
  • Using script templates – 30
  • Responding to URLs in web pages – 30

(Phil Stokes) #11

Incidentally, if you’re looking at attracting scripters who’ve toyed / toiled with script editor, I think the biggest attraction of SD has got to be the drag and drop feature of the dictionary viewer.

I was just pointing this out on another forum to a long-time SE user: how often do you use the dictionary viewer in SE? It’s about as much use as a match in a fire. If you’re scripting something new, you might as well just go hunting on ASU or MacScripter for the unlucky ones that went before you who wanted to do the same thing.

However, being able to just drag and drop commands (etc) from SD’s dictionary viewer and have all that obscure syntax plumped straight in the editor for you is one of the major obstacles of scripting a new/unknown app solved in an instant.

(Ed Stockly) #12

Step Debugging

This is a rough cut version of the kind of spot I’m talking about. Simple, direct and to the point. Think of it as an ad. It’s not a tutorial and it doesn’t mention every aspect of every feature. It simply shows an experienced scripter a single aspect of a powerful program.



For me writing an Applescript to handle all the mail rules directly in an script was a massive pain in the butt. It was well over a year to get anything to work. It was poorly documented all over the place and nearly all the examples I found on the internet didn’t work. A few months ago I tried coming back to it many years after my first experience and now I can’t get it to work to all once again. Just about every one I asked years ago didn’t know how to do it. I’ve given upon AppleMail for scripting because it is such a pain. So I think that would be a nice topic. But providing source code for the things discussed would be really nice.




What about ASObj-C examples? I’d even write the stuff for you. Some easy to use and useful stuff could be demoed and perhaps that would get people to try going a little farther. All the examples I see don’t show example that would create things most people are into. Most ASObj-C examples are about gaining more programming power. What I like about ASObj-C is not that it can do more powerful things. It’s the interface capabilities it offers. I just learned Foundation first because it is used in a lot in all kinds of things. But AppKit has amazing stuff in it.



I agree with Jim 100% on this, having taught many people AppleScript. Many people teach at the pace they feel comfortable with or that they think the learner are comfortable with. I taught people one on one and that taught me how wrong I was about how much time to spend on things.



I worked at one company that was big enough to have it’s own training staff. The guy running the department was good at hauling people into a demo class wether they want to or not. But he did interactive session on a test audience before ever making any kind of recorded lesson. He also went to where people were having trouble and asked them what they needed. I guess the question where does one find a group of clueless Mac users that are interested in AppleScript.



Search engine optimization is a difficult thing to pull off without putting in some work. Google actively tries to defeat cheap tricks to get to the top. Google constantly says if you want to get to the top have lots of high quality content. That is what google looks for in its algorithms. Following SEOs example means constantly changing with the newest tricks as opposed to just creating great content. That is an endless series of constant changes. Of course another thing is getting a lot of sites to link to the late night web site. That factors into Google algorithms. Reciprocal links are a common trick for that. If the late night website had links for some decent sites then late night could get links on other people’s sites.

Google does have active processes searching the web looking for sites that are faking good content. When Google finds one they lower the sites ranking.

One thing that would make Google more likely to rank late night higher is content on teaching AppleScript, links to places that do teach AppleScript, suggested links for scripters, …



The problem with all this is that the people successfully do these kind of things use market research. Discussing it like this involves a lot of opinions. Bigger companies do it all by market research in the beginning. They make plans in that stage. Then they make samples and try testing it in their chosen market with free samples. This is pretty well documented stuff for marketers. I worked with a lot of them being a technical liaison for marketing and sales. Marketers never guess. They find out because one bad campaign can get them fired.


(Phil Stokes) #19

No, you don’t want to go the SEO route. Good content does get to the top - I’ve done it myself and know many others that have, and so does raw views on (eg) youtube. just as you say, links from other sites is also a big, big factor.

The recipe is bascially those three things (and it is of course a feedback loop once you hit a certain threshhold), and it all starts with the content (both quality and quantity). The rest will take care of itself if the interest is there. Trying to game the system with SEO is neither necessary nor advisable.

(John Welch) #20

I’d love to see some things like this Mark. I think it would be a great addition to the overall community, especially sessions on things that seem obvious to the experienced but aren’t (like whose clauses) to the noob.

Even if you aren’t specifically talking about an SD feature, using SD to help explain things ends up being a great way to show off SD’s features and benefits in a more natural manner.