[quote=“Gorgeousity, post:8, topic:15080”]
The USP is really simplicity, it’s designed to be very easy and (hopefully) fun to set up tiggers
[quote]
That’s a solid answer: a good core to your product pitch. “[A]mazing simplicity”, if you’re feeling ambitious—and why not? iPod conquered its own market by leading with the same. Less is more.
I wouldn’t use the word “triggers” (or tiggers). “Actions” is how Siri Shortcuts describes the behaviors to perform, so find a word like “Events” which really complements that[1].
I do like the surrounding framing: “When X then Y.” That works well.
I would advise radically simplifying the Actions your app can perform. That side of your app bring nothing new or novel; all it does is duplicate (weakly) what Shortcuts already supplies as standard. Instead, have your app run just Siri Shortcuts: strip out that entire list of custom behaviors (System Notification, Speak, etc) and just list the names of workflows already defined in Shortcuts.app. Let the user put a tick mark besides one (or more) of those names so that, when the event fires, your app runs that shortcut.
…
The bit that you do want to put all your energy is your list of supported events, and the UI for configuring trigger conditions. Your current list of events is painfully sparse, very focused on “nerd features” and lacking in “general lifestyle” events. The motivation for adding trigger types should not be “Is it trivial for me to implement?” so much as “How much do my target audience need and want it?” Else you end up with lots of low-cost but low-value clutter no-one really needs while the high-value features they do want is swamped or left out.
Focus on this event detection and notification UI+UX you’ve built, because that’s a step in automating your automation that’s a PITA for most users. Incoherent, inconsistent; if apps support it at all, they rarely do so the same way. Hide all that mess, pain, and complexity behind your single clean unified UI, and you’re rolling.
Music.app track change notifications are an absolute no-brainer; and trivially easy to hook:
let dnc = DistributedNotificationCenter.default()
dnc.addObserver(self, selector:#selector(AppDelegate.myTrackChangedMethod),
name:NSNotification.Name(rawValue:"com.apple.iTunes.playerInfo"), object:nil)
Sniff to see what other DNs are flying around; most will be crap (DN is criminally undervalued and underused) but there might be the odd good one worth adding while you’re on that. Me, I’d implement the track change detector widget so its code is trivially reusable for detecting other DNs. Put your Music track change widget in “Lifestyle” catefory (née Environment) and put a generic reusable version with a text field for typing the notification ID under your “macOS” (née System”) category so techies can play around with it.
Calendar alarms should be another essential “Lifestyle” event; and even a single social media event (e.g. Facebook or Instagram post notification) will prove to your audience that your app can expand to those too. Don’t spend long on this (you wanna get to market) but look around for a day to see what low-hanging fruit there is, and grab a couple tasty bit to put in v1.0.
If your app finds its market, I’m sure your market will tell you which to add for v2.
…
It might be worth adding an “AppleScript[ed] Event” trigger, as a generic catchall for those willing to do the work to set it up. Define a very simple AppleScript dictionary with a single command, do event, that takes an arbitrary string. Define an “AppleScript” event widget that has a text field for entering a matching string. That allows an external AppleScript to trigger an event in your app. Technically an AppleScript can already send a run shortcut "NAME" command directly to Shortcuts, but that tightly couples the two (the script has to know a workflow’s name, and a workflow with that exact name has to exist).
Or skip past AppleScript and install a little shell command, like macOS’s notifyutil except it messages your app, which all scripting languages can use.
Adding this hook provides a low-cost route for both you and users to define new event behaviors where there isn’t an existing macOS API (e.g. Distributed Notifications) to hook into. You could write a full-blown Apple Mail extension which listens for incoming/outgoing emails and sends your app the notifications; but is that worth the effort for something already doable by “Run AppleScript” Mail Rule. This same approach can be equally applied to other email apps that have similar Mail Rule capabilities (as well as other apps and scripts in general).
With luck you can automate away the tedium and specialized knowledge of installing and configuring these “event scripts” too, so the user only has to click an “Enable This Event” button in your GUI, and that triggers’s ready to use. As you say, simplicity’s your goal. If you can achieve zero-config “don’t-make-me-think” UX, you’re there.
…
One more thing: it is entirely possible that Apple will finally pull its finger out at WWDC23 and add the same trigger support directly into Shortcuts. (iOS Shortcuts already has this; there’s no good reason Mac Shortcuts doesn’t except Apple are complacent and slooooow.) Or, if not this year, then next. So it’s possible your implementation may have a fairly short lifetime.[3]
–
[1] My first thought was the obvious “Reactions”, but, oops, that just replaced my mental image of a gun with a bout of the flu, so nope. Honestly, I wouldn’t over-clever it: “Events” might well be the best name for it. Annoyingly, iOS shortcuts label this “Automation”, which is blindingly stupid: ALL of it is automation; what distinguishes is whether it’s proactive (the user manually, explicitly, presses Run) or reactive (automatically in response to something of interest happening in the system).
[2] You might have to keep “special” options, like “Pause this trigger” and other development/troubleshooting features, in your UI; Shortcuts is rather monolithic and lacks fine-grained hooks into its interaction as it runs, so users will probably need a way to temporarily pause/cancel events being dispatched to actions.
[3] Honestly, you could do worse than tap @AriX and co, on offchance they might take it off you. Easy win for both parties if they haven’t begun internal development, assuming vast Apple bureacracy and inertia is navigable.
Please?