I wonder if it might not be a good idea to have a new Category?
We already have tags to easily locate topics about each script language:
- jxa
- applescript
- javascript
- shellscript
- swift
- others?
The point is not to be able to sort out all the stuff about scripting (and by the way the list is missing Objective-C), but rather to move it all to another area of the site to avoid overwhelming the straightforward KM stuff.
3 Likes
Yeah, I was just thinking about the “clutter” mentioned earlier. Personally, I’m fine with it. 
Again, that is what tags are for.
We now have a good tag list, that, IMO, is better than any forum category could be. Have you checked out the list?
Easily available from the main top menu:
And from the Menu Dropdown button:
I must have a completely different conceptual framework for tagging, because my attempts to tag posts are successful probably less than 5% of the time. I posted many tags and added a few more later. I haven't checked, but I don't think many made it into the list.
I don't understand why you are insisting on tags for this. Tags are for filtering, categories are for separating. Why do we need categories at all? It's like the Finder — we could do without it and just use tags, and there certainly has been movement in that direction over the years in various contexts, not just the Finder. Categories help even in searching: it's hard enough constructing a search to find what you want on the forum, at least if you could limit it to an appropriate category your chances of success improve greatly.
The point is that many (most? nearly all? everyone except a few of us?) are probably not interested in anything to do with Objective-C, JXA, writing actions, or perhaps even much about AppleScript. If there is a purpose to categories, surely isolating these discussions would be an appropriate use.
Other Discourse forums I participate in, including the Discourse forum itself, have many more categories.
I suppose it's worth thinking about the ways one could take advantage of the separation categories provide other than just being able to add "category:macro" to a search.
1 Like
These need to be alphabetized. If there were a way to do it it would also be good to group them into related topics. (All scripting tags, all GUI tags, all Mac application tags, etc.)
Tags are more useful because more than one tag can be assigned to the same topic, whereas a topic can belong to only ONE forum category.
The way @peternlewis has designed the forum categories is for each category to represent a very broad classification.
So it is easy enough to search for what you want:
category:macro tag:jxa
will get you all of the JXA related macros.
I tend to agree with you on this, but the Discourse forum designers seem to think it is more important to present the tags most used first, and we have no way of changing that.
If you want an alphabetic list, go to the tags page, and click on sort by name.
The scripting discussed here has pretty much all been related to applying the many different scripting languages to automating processes of some sort, and hence it is appropriate on this forum.
And I do agree there is a risk that all the scripting discussion is overwhelming for users just wanting to solve some simple problem, and that risk is not mitigated by Tags. It would be reduced somewhat if there was a Scripting category and the scripting discussion was confined to that category, but I don't see how that would work since most scripting replies are replies to non-scripting specific questions of how to accomplish something. If I look at just the General category:
https://forum.keyboardmaestro.com/c/general
there are only a handful of topics that are really scripting-specific, the rest are topics asking how to do something that may or may not use a scripted solution.
As for a multitude of categories, I general find that more categories either requires significantly more maintenance in changing categories of incorrect choices, or significantly more education of the visitors (which I am not in favour of requiring) and tends towards problems of never quite being sure where things really belong.
For the most part, I think the value of the scripting knowledge shared on this forum outweighs the downside. And I presume novices looking at the forum a) won't be reading every post and thus will skip long drawn out debates on scripting, and b) will be scanning through the general or macro category looking for something interesting, or c) will use search to find what they are after, or d) failing that will post a question.
Oh, and in an ironic twist, this topic itself belongs in the meta category, not the general category… 
2 Likes
Y, meta & y ironic. Apologies.
Y, I forgot Swift
For my part, I am probably a happy KM user largely because I can't script. So when the solution to a question is a script I tend to feel we haven't advanced our ability to wrangle with KM.
I perfectly understand that scripting provides more elegant/quicker/shorter solutions but, to adapt an analogy I started elsewhere, it's like I'm taking a German class and people try to help out by making suggestions like "have you tried writing it in Spanish?" 
That said, I have been very happy copying mostly Apple-scripted solutions and hacking them about on my own (though JXA leaves me standing.)
I wouldn't want to see the scripting discussions disappear and I'd love to see more focus on KM-wrangling sometimes... Is that having my cake and eating it?
4 Likes
You would have both if scripting discussions were in a different category.
1 Like
This makes perfect sense. Access to scripting is key to complex automations, and it fills those gaps that Peter hasn’t thought of or isn’t interested in - such as very tight application integration. (We aren’t likely to see, say, a set of Evernote or TaskPaper actions.)
If you are uncomfortable with “just write this script”, please do feel free to ask if there’s a non-scripting approach that’s easier to manage, or if it’s possible to better “package” that script (some easy variables to fill out rather than editing a complex script).
2 Likes
I'm a scripter and I agree with you. When building a KM macro, or suggesting solutions to others, I first try to design it using native KM Actions (non-script actions). In fact, I have lots of KM macros that I could have done in script, but I found it easier/quicker to do just using KM Actions.
Interest in scripting here in the KM forum seems to go in cycles. We seem to currently be in a period of high interest, but I suspect that will die down after a while.
1 Like
Astute observation from @Rather.
True, some things only scripting can do, so a big "thank you" to scripters here.
But plenty of scripts, I think, "KM alone could do that, or most of that, and a lot easier to modify and maintain, too."
"To a hammer, every problem looks like a nail."
Here’s some reasons for script postings:
- To do something that KM can’t.
- KM could do it, but it would be either cumbersome, slow, or both.
- For an example of slow, try iterating through all the lines of a text file (after reading the file into a KM variable, of course). Watch how slow it gets as the number of lines in the file increases.
IMO, almost all of the scripts posted in this forum are because of those reasons.
Or at least the belief that those reasons are true - I know that for me, I’ve sometimes posted a script answer because I didn’t know KM could do it, and do it just fine. But that’s not the case most of the time.
1 Like
I agree with Dan.
Keyboard Maestro is an excellent instrument which can be used at varying levels in a wide range of contexts.
That means that this is a busy watering-hole, visited by a quite wide range of creatures, all with very different needs and skill sets. For any given problem, a script may provide the best solution for some (quicker to write), while a series of actions may provide the best solution for others (easier to write).
Unlikely to be any value I think, in trying to normalise the approach – the thing is to optimise it for each user. No one would really benefit if discussion of Execute Script actions was discouraged. Scripters would just go elsewhere.
( See under the tale of Procrustes – who ran a much less popular and successful business – not an approach to emulate … )
3 Likes