iOS dev update & RFC: New "End of workflow" behavior!

Actions For Obsidian
1

(RFC = request for comments)

So, no Shortcuts action has access to the whole workflow, and therefore can’t tell where it is located in that workflow, and what the current state of the workflow is. Which is a sensible choice made by Apple, but it’s a bit annoying to have AFO show up when it is the last action in a workflow, and that workflow has just finished. I think we can agree on that. :wink:

But. BUT. It looks like I figured out a way to make that last action in a workflow aware that the workflow has just ended, if that action is provided by AFO. :tada: (The app still has no idea what’s going on in that workflow, mind. Or what the most recent app is, because iOS doesn’t volunteer this information.)

So I’d like to introduce a global setting in AFO as to what to do at in this particular “end of workflow” situation:

  • do nothing (i.e., v1.3 current behavior)
  • go to Home screen
  • go to Obsidian

Any other options you’d like to see?

2

Currently, I have a Hide AFO shortcut and I include Run Shortcut at the end of AFO workflows to avoid showing the app. This seems to work well on both macOS and iOS.

It uses the Scripting action Get Device Details (Get the Device Model). If it’s Mac, then I use the Scripting action Hide App Actions for Obsidian; otherwise (on iOS) I use Go to Home Screen.

Perhaps you might offer an option for Run Shortcut. In fact, maybe you even include a Hide AFO shortcut along with AFO (or provide an equivalent action). Then I wouldn’t have to always remember to add that final action.

I don’t think Go to Obsidian is very useful. You already offer an option to open a note in several actions. And where would you go in Obsidian? The home note, daily note, last note affected by AFO, etc?

3

I agree with @doug78645. For the use case ending up in Obsidian, you already have options that ensure the creator of the shortcut can define a landing place. I haven’t checked how Doug’s proposal to hide AFO works on the Mac, but it sounds promising. Nevertheless, it seems to be a typical ‘it depends’ UX issue. I am only familiar with my use cases, where I create or add things to a note, and I always check to see if it works as intended. So open up the just created note or the note I added stuff is fine for me.

4

Thanks for the input, @doug78645 & @leif! Let me explain my thought process a bit more, maybe it clears up where I’m coming from.

Different people have different ideas of what their workflows should do once it’s done. Maybe a workflow should return to the home screen, maybe it should open the most recently active note in Obsidian, maybe it should start playing a podcast or something. :wink: But also it depends on the workflow, since not all workflows are alike.

So I figured I could offer a global setting which would kick in if an AFO action is the last block in a workflow. For your standard workflows, you could use AFO actions as you always would, knowing that even when it provides the last block, the workflow wouldn’t just end with you staring at the AFO app.

But in those cases where it isn’t the last block, nothing would change, e.g. when you add an explicit Open App action or something, it wouldn’t interfere with that.

Basically, I only want to offer a small selection of useful options which works for the majority of all customers’ cases. Trying to anticipate everything and all cases is futile, methinks.

As for your suggestions, @doug78645:

Perhaps you might offer an option for Run Shortcut.

You mean offering “Run shortcut X” as an additional option to the three sketched options from my original post?

In fact, maybe you even include a Hide AFO shortcut along with AFO (or provide an equivalent action). Then I wouldn’t have to always remember to add that final action.

But that’s the thing: I want to find a way so you don’t have to remember to add a specific action at the end of your workflows. :wink:

How about this: AFO could give you the option to do something at the end of a run if provides the last action of the workflow — but you can pick a different option on each device. Then, for example, you could select “Quit AFO” on macOS, and “Go to Home screen” on iOS, and the very same workflow would do just that, depending on the device its currently running on. And for any other, more specific case, you could configure your workflow accordingly.

Edit: I just remembered that due to the different app state handling on macOS, it’s way, way harder to reliably figure out if a workflow is done or not.

5

Yes, I meant include a “Run shortcut X” as a final action. You might show an example shortcut on the website that we could install, such as “Hide AFO” that I use. And that could easily used for that final shortcut, so the same workflow could work on both macOS and iOS.

I agree that it would be nice not to always have to remember to run my “Hide AFO” shortcut just to avoid me always seeing the AFO app after a last AFO action.

1 Like
6

That’s the challenge when I said ‘it depends’ :slight_smile: . Since I’m not an automation expert and a beginner in the world of shortcuts, my understanding of possible use cases is not very deep. In my experience, the workflow typically ends in Obsidian or at the screen where I trigger the workflow, especially in the case of AFO. However, there are generic actions to open apps, and apps that support shortcuts might provide additional functionality.

I think one of the strengths of the Shortcuts app is its openness to mashups from different libraries and scripting languages. So, why worry about catering to all the different uses? But maybe I’m still missing something.

As far as I understand, the ‘issue’ with AFO, at least on iOS, is the screen changing while executing a workflow (I haven’t yet checked Doug’s proposal) and that AFO doesn’t quit, right? But maybe I’m still not grasping the full picture. For me, currently, it seems more like a documentation issue and a lack of examples: ‘What you can do if the workflow completes successfully or in case of an error.’

I hope I’m not totally off the mark :wink:

7

However, there are generic actions to open apps, and apps that support shortcuts might provide additional functionality.

Yes, there are, but AFO behaves differently from other apps due to the interplay of iOS and the Obsidian API. Most customers are expecting to end up on the iOS screen where they started the workflow, and with AFO they simply don’t which is confusing and/or annoying. I advise them to use a “Go to Home screen” action, and while that works, it also means they have to remember to do that in every AFO-powered workflow which can be cumbersome.

Also, new customers who haven’t read the FAQ pages (yet) think it’s a bug or a nag screen related to purchasing or something, which isn’t ideal, either.

I think one of the strengths of the Shortcuts app is its openness to mashups from different libraries and scripting languages. So, why worry about catering to all the different uses? But maybe I’m still missing something.

I’m with you here. I don’t want to cater to all the use cases, just very few I know people are struggling with. And the question “Why is AFO showing up when the workflow is done?” is by far the most recurring. So I figure if I implement the few things that are most requested (open Home screen, open Obsidian), and maybe, as Doug suggested, triggering another workflow, I’d cover 80% of all the cases. For the other 20% the solution is still “You’ll have to add extra blocks to the workflow”.

As far as I understand, the ‘issue’ with AFO, at least on iOS, is the screen changing while executing a workflow (I haven’t yet checked Doug’s proposal) and that AFO doesn’t quit, right?

The latter, mostly. Workflow done, AFO pops up again.

But maybe I’m still not grasping the full picture. For me, currently, it seems more like a documentation issue and a lack of examples: ‘What you can do if the workflow completes successfully or in case of an error.’

There is, I’m copy/pasting that FAQ page link a lot: Why is AfO brought to the foreground when one of its actions is the last block in a workflow? - ActionsDotWork Knowledge Base :wink:

8

Little update before I close down the shop for the night: the current state of affairs in iOS. It’s a WIP but it works really well.

IMG_F54FEAC5C161-1
IMG_F54FEAC5C161-11125×2436 120 KB

Why the additional “Open Shortcuts”? Because during testing I noticed that it’s a useful option to have when I was editing my workflows. Afterwards, not so much, but while working on them workflows: very useful because it saved me a lot of manual app switching.

9

Ok, I think I understand the problem space now.

Your users expectations are different as ending up in AFO and instead of reading the documentation they contact you direct. I experienced similar challenges initially; however, after reading the FAQ, I realized the problem wasn’t on your end. Nonetheless I missed the part with the workarounds until I discover the “open note” action as a (natural) solution for this problem in my case by myself. You should add this as a workaround, too.

From what I can see, there are basically four ways out:

  1. Back to the app where the workflow was triggered
  2. Over to Obsidian, which has a bunch of AFO-supported entry points.
  3. To another app (like your podcast example) or maybe the Shortcuts app?
  4. Or just straight to the home screen.

For 2, 3 and 4 internal or external blocks already exists, the only missing piece is no. 1. There is no solution out there for that yet. If it’s feasible to add this to AFO would be great. And then make it to the default exit if there is not another block (2 to 4), though I get that might be tricky. The home screen or the Shortcuts app as defaults don’t really make sense for me.

Apart from that, it’s all down to the documentation and examples - and customer care.

1 Like
10

Impossible because to the best of my knowledge, the OS is not sharing that information.

11

That’s what I thought, but as always the most sensible solution is not possible. That’s life.

12

since I’ve been getting around this by executing the shortcut via another shortcut, simply by adding an app opening action on the screen I want to end up on as a terminal action, I’ve noticed that I have a success rate close to 100% of execution with the “do nothing” setting, whereas with “go to home screen” execution was interrupted almost 50% (in a specific case on ios-> see my example in another post).

image
image1125×477 53.7 KB

13

Thanks! I’m still trying to replicate the cause of the 50% success rate…