Setting up custom, app-specific keyboard shortcuts

[lucaben]

I was referring to the "Automation" section of the app, which is a much simpler one. I am not that familiar with the shortcuts section as I never used it, it's an interesting one. From what I can see, it packs all conditions under "scripting", but then if I pick "all actions" I cannot find them. A bit confusing…

Anyway if you look at some of the examples in the link that I've shared, and in the screenshot above, you'll see that there's a bespoke call to action to create a condition, and I think that's a better approach. I don't have a problem with how KM represents actions and conditions in the same space after they are selected, I have a problem with them not being clearly differentiated from one another in the actions picker, because as I said, logically they are quite distinct. And in fact I did not notice them until you pointed out that they are available… which is the proof of what I am saying. A better approach would be to have an "Add condition" button next to "Add action", which is what the wiki page that you've pointed to seems to suggests, when it says "Add a new condition by clicking the green + button beside New Condition to select from a list of available conditions" — except I cannot locate any green button, so I am not sure what they meant by that.

[Nige_S]

I think, perhaps, I'm starting to see where you are coming from...

Sometimes, especially in no-/low-code systems, you'll see a conditional statement represented as "Do this thing if..." -- especially if the "if" is optional. This can make sense in many situations, most commonly when there is no "else". And you can (sort of) see this construct in KM's Group and Trigger settings -- "Enable this macro if Figma is active", "Trigger this macro if ⌥⌘A is pressed".

But the more common structure is "If a condition is met then do this thing" and, by extension, "If a condition is met then do this thing, otherwise do this other thing". That's what KM uses for its "If Then Else" Action -- this is externally consistent with common practice and, importantly, internally consistent with other Actions which can all be easily read from top to bottom. The "If" we've already covered, so consider the "While" Action:

"While these conditions are true, do some stuff".

Same with the "Until" action:

"Do some stuff until these conditions are true". (And this natural approach should make the difference between "While" and "Until" abundantly clear.)

If you can flip your thinking and see a "decision" as an "If" Action containing conditions and conclusions, rather than it being a conclusion that you decide whether or not to follow, I think you'll find KM a lot less frustrating.

@lucaben

except I cannot locate any green button, so I am not sure what they meant by that.

If there's no green button it probably isn't an Action that can take Conditions. Here's a newly-added "If" Action with "Add Condition" highlighted:

...and, as with other areas of the KM interface, once you've added something (in this case a "Calculation" condition) you then get a "+" button to add another after the last and "-" buttons to remove their associated conditions:

[lucaben]

I am not sure you've looked at the links that I provided, it looks like we are talking about different things. As I mentioned in my previous comment, what you are showing here makes perfect sense to me. I just don't think that hiding conditions away and mixing them up with actions is the best approach. See examples in the provided link. Below is a possible solution to that.

[Airy]

I would love to understand what you are saying. What do you want the KM Editor to do when the user pressed on the "+ New condition" button?

[lucaben]

@Airy

I would love to understand what you are saying. What do you want the KM Editor to do when the user pressed on the "+ New condition" button?

Get access to the "Control flow" actions, or a subset of it. The wording may be different

[Nige_S]

@lucaben

I just don't think that hiding conditions away and mixing them up with actions is the best approach.

They aren't "hidden away" or "mixed up" -- conditions are part of conditional Actions. What would your "New condition" button do in the screen shot above?

A KM Condition is something like Local_savedTime + 60 < NOW() or The application Safari is at the front -- statements that can be evaluated to either true of false. They are meaningless unless used within a Conditional Action such as "If Then Else" or "While".

If you mean "this button adds from a subset of Actions" -- that seems like unnecessary separation. Conditional Actions are Actions like all the others -- why special case them? If you want to special case them -- add them as "Favorites".

[lucaben]

@Nige_S

They are meaningless unless used within a Conditional Action such as "If Then Else" or "While".

Well of course, so what? Aren't the UIs in the examples above not going to work? Again, check the examples, and you 'll see that rules/conditions have a bespoke UI.

@Nige_S

Conditional Actions are Actions like all the others

Yes, you can see it that way and a UI that reflects that mental model would still work, but actions and conditions ARE NOT the same thing. A condition adds conditions for actions to apply, an action doesn't imply any logic, it's just executed. Controlling the flow is one thing, adding actions is another. Once you add a logical operator, of course you have to add specific conditions for the logic to apply, and actions, so it does what it's supposed to do. You are stating the obvious.

[Nige_S]

@lucaben

@Nige_S

Conditional Actions are Actions like all the others

Yes, you can see it that way...

I am, quite deliberately, referring to Actions. So it isn't a question of my seeing it that way -- it is that way.

"If Then Else" is an Action. It contains zero, one or more Conditions. The evaluation of those Conditions determines the branch taken and what further Actions are executed.

"While" is an Action. It contains zero, one or more Conditions. The evaluation of those Conditions determines whether the Actions within the "While" action are executed and control then returned to the beginning of the "loop", or the "loop" is exited with execution proceeding to the next Action in the macro.

And so on...

You can see this structure in the XML representation of macros and Actions -- just right-click something, "Copy as XML", and paste into your favourite text editor.

[Airy]

@lucaben

Get access to the "Control flow" actions, or a subset of it. The wording may be different

I don't know how that differs from what KM already gives you. You already have access to those actions using the "+ New Action" button.

If you explain what you actually want to see on the screen, maybe I could understand. Or don't worry about it.

[lucaben]

I've already explained it above, it's a different mental model. Of course it won't give you anything you don't have already, it's just a slightly different workflow, better than the existing one. Please no more questions on this, I've invested enough time and keep repeating things that I've already explained clearly.

[lucaben]

I am very busy and I don't see the point in continuing this discussion. It seems like you are only interested in proving that you are right rather than trying to understand the point that I've been making, which has been expressed very clearly and has no logical contradictions in it. I am not going to try hard and convince you. I've given my contribution and the KM team can improve the software based on the feedback that I've provided, if they want to. They can also look at similar tools out there, that follow the approach that I am advocating for: making a clear distinction between actions and conditions, since there is an obvious difference between the two, and because exposing conditions upfront is the best way to make sure that people notice them. I think what might still a source of misunderstanding is that I am using the words "action" and "condition" in their general meaning, I am not referring to actions and conditions in the KM UI. That's also been stated very clearly above, and should not need been repeated over and over.

[Airy]

I'm truly flattered that you would call me part of the KM team, but KM isn't developed by a team, and not by any of us. The person who develops KM reads some of these threads, but I have no idea if he has read this one. If you want to contribute your ideas for KM, you could submit your ideas to the developer of KM.

[lucaben]

I actually never assumed that people in this threat are part of the KM team, I am fully aware that it's just KM users helping one another. I did reach out to a guy called Peter, who read part of this thread already. If what you say is true, then he may be the developer you are referring to, I guess. So he will decide what to do with my piece of advice. Thanks for the suggestion anyway.

[Nige_S]

@lucaben

It seems like you are only interested in proving that you are right rather than trying to understand the point that I've been making...

I can only apologise -- that certainly wasn't my intent, but I do get rather carried away when it's an interesting discussion!

What I was hoping (and obviously failing) to show is that that the UI is a representation of the underlying structure of KM itself, and that structure is built on a design philosophy of "Macros contain Actions which contain...".

This is a common structure across procedural programming, although different terms may be used -- for example, "programs contain statements which contain...". And in almost all of these systems an "If" is considered to be a "block", just like "set variable to..." or "print..." -- except that an "If" block also contains conditions to be evaluated.

Your example from Axure RP is a good alternative way of doing things. But (and I'm sure you guessed there was a "but" coming ) Axure is a UX prototyper. It is, in the modern UX way, object oriented -- and when you are dealing with objects it makes perfect sense to apply conditions to the objects themselves. The UI reflects that, and it is "obvious" to the user because it's the obvious thing to do -- "this button should only be active if..." is a condition "belonging" to the button object.

Both KM and Axure are "correct" in how they do things, because both honour their own underlying paradigms. But trying to shoehorn Axure's OOP way of doing things onto KM (or vice versa) would be very difficult.

But maybe, right now, Peter is working on a complete rewrite of KM -- perhaps as part of a wholesale conversion to Swift/SwiftUI and all sorts of other new Appley goodness -- and you'll get conditions that can be applied to actions in the way that Axure does. Now that would be interesting!

[lucaben]

Thanks I much appreciate your comment, it was obvious to me that you had no bad intent, the conversation has just become a bit exhausting, as I am in the middle of a very demanding project and can't devote too much time to this. But this is definitely a very interesting use case and a challenging one. As a UX designer, I can say that UIs for devs/tech people are some of the most challenging. I am currently working on consolidating UX patterns for several types of UIs and in this area, one can find some complex patterns, the likes of command palettes, rule builders… these are all special-purpose UIs that require lots of pondering, design thinking, and testing with real users. I've been in touch with Peter in regards to this, he will read this thread so hopefully it will bring some insights on any coming UI revamp, if that's the case. And thanks again for your helpful suggestions on getting this issue resolved.