Poking around in the Wiki, I discovered that when I search for the @actions namespace, I get nine resutls. Eight of them are action groups or categories and one is the "Wait For Browser to Finish Loading" action, described on its page as a single action while all the others in the namespace describe sets of actions.
Is this intentional or a glitch? While I can edit WIki pages, I don't think I can reorganize files, and even if I could, I would want to check first.
Any ideas?
actions:Wait For Browser to Finish Loading is not one action, it's a set of actions:
Thanks.
Thanks. I think I see the pattern now, at least for some of the @actions namespace pages. Others I'm confused about.
There are six pages in the @actions namespace that are all about browsers:
Browser_Actions
Browser_Form_Actions
Browser_Window_Actions
Click_Browser_Link
Execute_a_JavaScript_in_Browser
Wait_For_Browser_to_Finish_Loading
Some of them look like "individual" actions and may even have singular-mode grammar, but they all say something like, "Chrome, Safari, or whichever was last foremost".
It makes sense that the "Wait For Browser to Finish Loading" page is among those. That was my original question.
But the more I look, the more I find other seeming inconsistencies.
There are three more pages in the @actions namespace:
Redirect Control Flow is very clear that it has a bunch of actions that do different things. Definititely it belongs in the @actions namespace.
Send_Message includes Send SMS and Send iMessage. Those have identical Action entries and it makes sense for them to have the same Wiki page. Why are they not one action with a scroll menu?
The Send MIDI actions do have a scroll menu to choose the action, and picking any of the four in the Actions menu will still let you change the scroll menu choice to one of the others.
I don't see any distinction between the Send Message and Send MIDI action groups and the single action in the @action namespace, "Display Text".
Display Text includes:
In the Editor's Actions menu, it has four entries:
It has one Wiki page and it is in the singular @action namespace.
The MIDI actions are similarly switched between by a scroll menu, yet they are in the plural @actions namespace. The Send Message (SMS or iMessage) actions are nearly identical, are in the @actions namespace, but don't have a scroll menu.
Maybe I'm putting too much meaning onto the namespace names, but it seems to me to be a primary organizational level and I'm confused trying to find rhyme or reason for the inconsistencies.
My best guess at a reason is "historical accident that has never been a priority to clean up", which is one of the most common reasons for many things in software (and one of things that has meant there was a budget for my former job as a Technical Editor/Writer). If that's the case, what kind of cleanup would be the desired outcome? I think it depends on what the @actions namespace is meant to mean and how it should be used in the long run.
Is @actions meant for broad action groups like Browser Tools and Control Flow? Then move the Send Message and MIDI pages to where they are classified as single actions, the way Display/Insert Text and other scroll-menu determined action are. (This seems a pretty simple cleanup path.)
Or is @actions meant to collect all action groups of related actions, even those distinguished by a scroll menu, like the MIDI actions? Then move Display/Insert there along with any other actions that have very different meanings according to a scroll menu. (That seems like a lot of work for little result except confusion.)
In either case, I recommend combining the two Send Message actions (Send SMS and Send iMessage) into a single action with a scroll menu (like Display/Insert Text) and move its Wiki page to the @action namespace.
It's in the Gear menu.
There is no particular reason it's done one way or the other.
Generally, the pages in the actions namespace is for groups of related but different actions, with actions in the action namespace have have multiple options,
It's a gray area as to where the case of related actions are just options of a single action.
Certainly the argument could be made that Click_Browser_Link, Execute_a_JavaScript_in_Browser, Wait_For_Browser_to_Finish_Loading just have options as to which browser they target and should be described as single actions, with variants. Same for Send_Message and Send_MIDI.
But some of it depends on point of view. If you consider the grouping of actions to be “Chrome Actions”, then those actions are not variants of each other, but members of different groups.
Just be extremely careful with any such changes that the Help in Keyboard Maestro continues to work.
There is also the consideration of naming. Because you only want actions that are actual actions in the action namespace, because they show up on the Actions page.
So the Actions page, for example, lists the four MIDI actions. Each of those four are redirects to the actions page. The alternative, they could all redirect to one of those pages (maybe Packet?).
What about Send SMS and Send iMessage - which would be the redirect and which would be the actual page, and how would they be titled?
Similarly for the Execute_a_JavaScript_in_Front_Browser, Execute_a_JavaScript_in_Google_Chrome, and Execute_a_JavaScript_in_Safari pages. Which should be the page (maybe the Front Browser one?), and which should be the redirects? As it is they are all redirects, which means the page cannot appear in the action namespace. Hence its in the actions namespace as documentation for a collection of actions.
Which I guess really nails down the difference in the two namespaces. The action namespace is for actual individual actions, perhaps with options, and the actions namespace is for collections of related actions, but which is not itself an action.
I see the two Send Message actions in the Actions page, the four MIDI actions, and out of the six Insert/Display Text actions there is one Display Text action listed. The three Insert actions are there plus an extra "Insert Text" that looks more like an @actions namespace page because it isn't an action itself, it just references the other three Insert actons and also has a link to Type Keystroke, which is not in the Insert/Display menu.
So again, more inconsistencies.
Thanks for the overview. I am not going to attempt any changes at this level until I am a lot more familiar with how it all works and how it's all organized, especially how the Editor Help system links to all this.
Meanwhile, in response to Peter's comment in another thread ...
... I'm going to work on at least putting titles into pages that are missing them.
That would be excellent.
Getting a consistent sized title, ensuring consistent See Also sections (including adding any extra references that are appropriate), removing most horizontal lines, all would be great.
This is not a trivial task and has a lot in common with creating a good index. The real issue is the connections that are important but not obvious because they use different terminology or approach the problem from a different direction.
Perhaps "crowd sourcing" would be useful. Here's a couple of ideas.
Is there a mechanism for adding comments to a Wiki page, where people with sufficient "reputation" could make suggestions for what would be useful in the See Also section, including especially Forum posts, for later editing and inclusion in the full public pages?
Or maybe we could add a request for input to the bottom of each undeveloped See Also section, asking users to make comments here in the Wiki section of the Forum, puting the page title (which by then would be in place) in the title of Forum post.
Just ideas.
Are there others with this design? Is there an advantage over the scroll menu as used in Insert/Display Text?
It seems to me the Gear Menu is generally used for things other than setting the application context of an action. If we could explain the resoning behind having the different designs, even if it's just historical and a low priority to clean up, it might help people remember how to find the settings they need when they need them.
It's less clutter.
And you are unlikely to choose to use one and then decide you really meant the other.
Where as changing your mind between styled and unstyled text to paste is definitely a possibility.
Also, there are only two options, so the Gear menu does not get overly cluttered, where there are multiple with the Display Text options.
But everything is a choice as far as what does and does not go in the gear menu.