Bike Outliner & Shortcuts

Bike Outliner 1.11 (Preview) adds Shortcuts support.

I think I’ve created a flexible set of actions that cover much of the AppleScript functionality. I’m fairly new to using Shortcuts and would love for some people to try it out and let me know what needs improvement for the next release.

Bike’s automation features require a license, but Bike has a trial period where you can try out all feature for free. I’m also happy to give a free license to anyone that posts post a useful shortcut while Bike is still in preview. I expect to release this version on the 18th.

1 Like

Here’s a shortcut that I have a question on.

The shortcut saves all tab name/urls from Safari into Bike. I don’t think reading those values is possible using only shortcuts, so I used AppleScript for the reading tabs part.

My question: Is there a shorter way to get values out of the returned records and into values that Shortcuts can work with? For example the Shortcut has these actions:

The ApplesScript Result is a list of records. I want to get specific values from each record and use them as parameters to other actions. It seems that to do that I need to first get the value. Second save that value to a variable. And third use that variable as my actions parameter.

Is there some way to do the same thing with fewer actions?

Any reason the actions would not register? I’ve restarted Shortcuts, but still get unknown actions and no listing for Bike.

In terms of the shortcut, is it actually getting tab details for you? So far, I have never got lists of records to be returned by AppleScript in Shortcuts - as illustrated by the example. I tried stripping down the shortcut above and that also wasn’t giving me any output from the AppleScript.

And that one line does typically work.

These related discussions might be useful for people to scan through too. - they are about dictionaries in AppleScript, and passing data out of Shortcuts.

Given I can’t currently get the Bike app shortcuts action to work/appear, I have built a separate Bike-independent example to show some alternatives.

Here, I’ve written some AppleScript to build a JSON string (which can be read into a Shortcuts dictionary) of tab data of the following sort of format:

{
	"tabs" : [
		{
			"tabURL" : "https://www.taskpaper.com",
			"tabName" : "TaskPaper – Plain text to-do lists for Mac"
		},
		{
			"tabURL" : "https://www.hogbaysoftware.com/bike/",
			"tabName" : "Bike Outliner: Outline writing, lists, and notes app for Mac"
		},
	]
}

 
The shortcut explicitly transforms it into a dictionary.

The repeat loop operates not on the dictionary as a whole, but explicitly the values of the tabs key of the dictionary - i.e. the JSON array of the tab data.

The Text action is just illustrative to show how you can direct access the data elements of the JSON in each array element without having to get it in a separate action. In the screenshot below, you can see the Repeat Item variable is explicitly set to a type of Dictionary, and the key is set as tabURL. As such, in the original shortcut, you shjould indeed be able to slim things down in the repeat loop.

The repeat loop dumps out each Text action, so in the screenshot of this example, you can see I had 10 tabs open in my front most Safari window, and that the fourth tab was this topic.

Hope that helps clear things up, and do let me know if you have any ideas how to get the shortcuts for Bike to appear (happy to poke around and see what I can do with the shortcuts actions it provides). The only thing I haven’t tried yet is a reboot, but normally you don’t have to reboot to get Shortcuts actions for an app to show up.

Is it possible that you have multiple versions of Bike installed? The times that I’ve had Shortcuts not find Bike’s actions seem to have always been when it was finding an older version of Bike that didn’t support actions.

I guess the other thing (maybe, just guessing) is make sure to put Bike in a location where shortcuts is likely to find it. Desktop or Applications folder seems to work for me.

Yes, the shortcut is working for me. Here’s what I see for the AppleScript results:

I also see a count result of 1 when running your foo,baz example. Maybe a macOS version difference? I’m on 13.3.1 (22E261).

Ahh, this is the part that I was missing. I didn’t realize that I needed to explicitly set the type to Dictionary … now I can make my example much shorter and nicer looking. Thanks!

Do let me know your macOS version. I wonder if maybe I’ve done something in my Bike actions implementation that requires latest OS?

Installed Bike for the first time this morning to try this out. The application is in my root level Applications folder.

That’s very interesting. Maybe the Shortcuts team have addressed it in a recent update :sunglasses:

I’m hopeful this isn’t simply a local issue - Shortcuts has given me a few headaches in the pas, for example I’ve never got Siri to reliably and consistently trigger shortcuts by name.

I’m on 13.2.1 (22D68). I’ve just forced a software update check and I can see I can get an update to 13.3.1. I’ll hold off for now in case I can help with any further checks, but otherwise I’ll look to get that downloaded and installed within the next few days and see what difference it makes. I’m going to be heading out shortly (without my Mac), but I’ll be back later in the day and can carry out any additional checks or apply updates at that point.

No problem :slightly_smiling_face:

Looks like 13.3 added the AppleScript update for dictionaries from lists.

Run AppleScript can now produce dictionaries as output from AppleScript records

1 Like

I guess one thing you could do is:

  1. Delete Bike 125
  2. Open Shortcuts
  3. Open Console.app and start streaming events
  4. Filter to see only Shortcuts.app events
  5. Reopen Bike.dmg and copy to applications or desktop.
  6. Wait a bit, maybe click around in Shortcuts, and see if it prints any errors concerning loading Bike actions.

Do let me know if they show up after you upgrade. I know that I have at least a few users who are using Bike actions, so it does work off my computer. Not sure what version of macOS they are using.

Is anyone aware of reasons why shortcut actions wouldn’t be found depending on macOS version?

I’m building my actions via the AppIntents framework. So the metadata is being generated when I build. I’m not seeing any compiler warnings, except that I am using AttributedString which gives me @Sendable warnings… but I was told in AppIntents slack meeting that I could still use it.

Edit And maybe do try a computer restart too. I’ve talked to another developer with a Mac app that uses shortcuts, and they say these problems happened from time to type (especially earlier on), but seemed to resolve self a bit later (after restart, or just waiting a bit).

1 Like

Happy to report just uninstalling and reinstalling the app resolved the missing Shortcuts action issue :sunglasses:

This is pre-macOS update - I’m going to install that next now this Shortcuts appearance issue is sorted.

1 Like

One oddity I notice is that in your screenshot Bike’s actions aren’t sorted into categories such as “Rows”, “Outlines”, etc. Let me know if that’s fixed by update too.

Maybe you are thinking of when you select an app in the apps list vs. searching in the list of all apps and actions?

I’ve installed the OS update, have the app installed (showing 3 days of trial), the license entry in the settings indicates trial mode enables all the features … but trying to run the original shortcut, I get and error on the first action - “Create Row” (based on the info, though the wording on the action says “Find or Create” - which was a little confusing):

Error: To perform this action you need an active Bike license

I created a new shortcut and selected an action to create a new outline, and then another action to create some content. The first action completed okay (I gort a new blank outline), and the second action threw the license error.

Overall, there seems to be something strange going on with the Shortcuts actions and the trial license. :face_with_diagonal_mouth:

Sorry about that… something must be off with my validation code. I’ve sent you a Bike license. If anyone else here want to play with and test Bike shortcuts please message me and I’ll send you a license.

Bike: 1.11 (126)
macOS: 13.3.1

I have been having an experiment this evening by building a shortcut to put a folder & file structure into Bike via Shortcuts.

Here is the shortcut I created
https://www.icloud.com/shortcuts/ba92e4d9e58c4efca5ef01c59fb6aaa1

When it runs, it gets to 40 rows inserted into the Bike outline, then throws this error.

2023-04-19-22.13.22

That is twelve quintillion, one hundred fifty-seven quadrillion, six hundred sixty-five trillion, four hundred fifty-nine billion, fifty-six million, nine hundred and twenty-eight thousand, eight hundred one Finder items … :exploding_head:.

I am pretty sure that that is more than the actual listing - which was 2,794 folders/files when I piped the shell script action output to wc -l.

I tried running the shortcut on a much smaller listing of 90 folders/files and it failed at the same point after outputting exactly 40 rows. I then tried various others and it keeps erroring on what is presumably the 41st iteration in the repeat loop, completing successfully for smaller numbers.

I’m sure writing to file or copy and paste into the app would be more efficient, but as I say, it was just a convenient idea to try out, and something is obviously going awry with the action.

1 Like

Interesting. I’m not immediately able to reproduce that error. I ran the script on a directory that inserted 1000 rows, so there must be something different in our tests … I’m on same macOS and version of Bike that you are.

Few thoughts:

  1. What happens if you just remove Bike from the script… just run the shell part and repeat over the split lines?

  2. If that works what happens if you use Bike’s import command instead of importing each line separately. Something like this: Shortcuts

  3. Do you think it might be directory specific, instead of size specific. For example what happens if you try to import another directory structure from another location on your computer?

It runs just fine. I can add the lines to a variable in the repeat loop, join them back up, and display them.

As I noted above, I knew there would be other more efficient methods, but the point of me doing it this way was to push it a bit harder and check for any edge cases :wink:

Using the import works just fine on the results.

No. As noted above I ran this on various directories containing various numbers of files and folders. These were mainly subdirectories within my user directory, but also under shared. Very much from all over. Different content, different basis for permissions, etc.


I also tried …

  • Running from Shortcuts home page, from within the shortcut, or from the command line yielded the same result.
  • Putting in the add to variable in the loop alongside the Bike Find or Create action made no difference, and neither did adding a Wait action

However, I have now figured out the cause of the issue. Fundamentally, I think it is just a poor error message from Shortcuts as it had nothing to do with Finder, is related to sharing (but that is an ambiguous term in wsay sharing can occur from Shortcuts), and 2^20 … well, that’s just a fantastic computer science number and way too big here to be meaningful in terms of what is really happening.

I realised the message was similar in format to ones that I’ve seen several times referencing settings on i*OS under Settings > Shortcuts > Advanced. Only I didn’t remember touching them on the Mac (though I suspect I did to enable the running of scripts). They are in the Shortcuts app’s Settings (née Preferences) under Advanced rather than in the system settings app like on i*OS.

After enabling the “Allow Sharing Large Amounts of Data” setting on the Advanced tab, the original shortcut using the repeat loop and individual row insertions works. It looks like Shortcuts considers separately passing single items of data more than 40 times to Bike within a single shortcut run as “a large amout of data”; and consequently throws up the error above.

1 Like

I’m glad you noticed this, I wouldn’t have known where to start.

One oddity is that for whatever reason I don’t seem to be running into the same problem on my computer. I created a new user account for testing, and then ran the Shortcut on that account… I quit the Shortcut running after 5000+ rows being inserted.

The odd part is I never changed any of Shortcuts default settings for that new user account. In particular “Allow Sharing Large Amounts of Data” was left unchecked. I also tried running the shortcut on a few very large files, but that didn’t create issues either.

Anyway, good to know that sometimes “Allow Sharing Large Amounts of Data” can fix things. Hopefully I’ll remember that when this problem shows up again for some other user.

1 Like

Moving on, using the more succinct import approach on a set of, in this case 2,795 rows of data, the import rows hangs and did not seem to be completing.

https://www.icloud.com/shortcuts/2613dedf286e4770b57ab7f9ca57f990

The screenshot below shows it sitting and seemingly doing nothing.

The following actions (also shown as the separate shortcut on the right) collapse all rows then expand the first. This works fine standalone but is never reached. When I try just the shortcut up to the import, it gets to the same point and seems to pause execution - like it is waiting for me to click something, but nothing comes up.

Running it on a folder containing just two files, the Bike outline wass created rapidly (as expected) but then took an age to finish. Here’s a GIF of it happening so you can see what I mean

2023-04-20-17.52.24

A little while after this, I got this alert…

2023-04-20-17.56.51

I think there may be something leaking memory when dealing with larger data volumes. It apparently managed to get up to this within about 20 minutes of me doing various Shortcuts tests - I had closed the app several times in the last 90 minutes or so of testing.

After closing the app things were much snappier with the very small volume import of just the three rows. However, when I went back to the 2.7K row import, things slowed down again so I opened up Activity Monitor and watched the memory used by Bike rack up the gigabytes (again there’s a GIF of a screen recording below).

2023-04-20-18.03.48

I’m wondering if this can be reproduced by others.

This is a problem and I reproduce, understand, and will fix soon! :slight_smile:

The fix might require a breaking change. Right now each Row has an outline property, the outline that contains the row. The AppIntents framework that I’m using to implement my actions has a calculated “DisplayRepresentation” for all objects/entities. In the case of Outlines I am including an image of the outline file. I didn’t expect this display representation to get encoded along with the entity, but I guess that’s how it works… so that’s why all the memory is being used. And image along with each row.

I guess I will change things an just include outlineID along with each row instead of outline entity.

I think this problem is solved in latest Bike preview release:

1 Like

Thanks for the update. I am no longer seeing the memory utilisation, but I do see a lag in the shortcut action to Import Rows :+1:t2:


I have a few further observations from trying this that I’ll offer up for future consideration should it be worthwhile pursuing:

When running the previous shortcut to output less than 10 lines the Import Rows action finishes in a second or less. When it runs on a bigger set or 2.5K rows, the content takes less than 2 seconds to appear in Bike, but then a further 9-10 seconds in Shortcuts to finish, only then moving onto the next action in the shortcut. Meanwhile I can fully browse the content which is already in Bike. That is a hugely significant lag when the volumes rise to this level.

I guess that since the action returns details about the rows it is getting that information back from Bike, and that accounts for the additional processing time. In fact, if I run the Find action set to “All Rows” with no limit (or sorting), on an outline of that volume, then Shortcuts times out the execution entirely. I can’t even get a count of the rows from that. So if anything Import Rows is probably doing a sterling job in comparison.

Ideally a more performant return of data for both would be ideal. Importantly though, I have no real sense of how big an outline structure a typical or even a power user might expect to work with. Most of my outlining runs to fewer than 200 rows. Larger ones I’ve probably breached 500, but I can’t recall ever pushed things further without breaking things down into separate outlines. Circa 2.5K may well be so far beyond the norm as to be a true edge case and not worthy of pursuit. Of course other constraints may also make this a non-viable option.

Should an alternative consideration be on the cards, perhaps having a parameter in the Create Outline action to opt out of returning data (i.e. the action would could return Rows or Nothing) would workaround the lag post import?

After import I would imagine most people who did want to interact further might be looking at say focuing on the first or last row. To get the first row, a Find “All Rows” with a limit of 1 and no sort works fairly quickly even on large numbers of rows, but unless you have a sorted outline, the last row’s out of reach. An option to find “First Row” and “Last Row” might be useful additions to “All Rows” and Shortcuts’ inbuilt variable options for the Find Action to help with that, and potentially bring useful options in any case to the action.


Thanks again for the memory consumption change, and hopefully the observations are useful too - if nly to know where the practical limits start to creep in for Shortcuts use with Bike.