How can I learn more about using content from Share sheet?

Thus far, I haven’t really dabbled much with enabling Share Sheet shortcuts. Now I want to, but find myself confused. How can I learn more?

Let’s imagine the following scenario… I want the user to be able to add to a list of web URLs…

  • If they Share something from a browser/app (typically, a web page or similar), that should include both page title and URL.
  • But if the shortcut is not invoked by sharing, they should be prompted to specify the title text only, with no available URL used.

So let me assume for now that I only should enable sharing of three things: “Safari web pages”, “URLs”, “Articles”. How do these even differ? If I invoke the shortcut from a Safari share, what content type does it come in as?

And what are the usable components of each of these things? If I do “Set variable SomeContent to Shortcut Input” and click open the “Shortcut Input” part, I can see it defaults as type “Article”, with sub-types/elements of…

  • “Article”
  • “Title”
  • “Author”
  • “Published Date”
  • “Body”
  • “Excerpt”
  • “Number of Words”
  • “Main Image URL”
  • “URL”
  • “Name”

But some of these, when I attempt to “Quick Look” them, aren’t even present. And doesn’t this assume, rather strictly, that the passed-in content is of type Article? (It could be any of the three, right?).

Do I somehow need to be checking to identify the type of the inbound, shared content and then act accordingly, ie. three IF pathways just to get URL and Title? Tiresome.

How can I find out more about all this?

Thanks.

1 Like

Safari web pages are the web pages as loaded in the Safari browser (web view), with any properties that goes along with that.

A URL is a string of text that defines a location. However, it also includes a name in Shortcuts terms. An easy way to look at meta data associated with a type is to create some content of that type, then add a magic variable for it into, say a text field, open up the magic variable options to see what data is available.

2022-01-17-19.55.02

Articles are stripped down, content focused versions of a web page. Useful for picking out the content from a blog post rather than the navigation and advertising stuff that may surround it. There used to be services listed for this in the (workflow, then) Shortcuts About acknowledgements, but it looks like they have gone now.

As well as the magic variable options above, Shortcuts has something within it known as the content engine. This allows translations between different types of data object. Now, if you use the view content graph action, you can view the graph (though apparently it looks unusably zoomed with a set window size on the Mac when I checked just now) and drill down on the nodes to find out what data is held on a more technical level. Often these are acessible via magic variable options, but not all are. However, it may give you a deeper appreciation of the differences.

A data object that allows a system to store a variety of related items of data as a set. But just because the option is there, it does not always mean that it is populated.

Taking the article option for example. Let’s say you get the “article” for a blog post where the web page is clearly marked up with the name of the author and the publishing date as well as an excerpt for things like an RSS feed. The page has a nice title set, and an image that also gets included in the RSS feed. When you generate the article for this page, it gets lots of that lovely article meta data.

Now let’s say you try to do that on a page that displays a bus timetable. This time you only get some of the data. Perhaps the title and content - no author, no exceprt, no publishing date, no main image. You don’t get them because they were not defined for the page and so the article object was not populated with this data when it was generated.

Now let’s say we try another blog post on a different blog. This one is similar to the first, but has been marked up in a different way. While the author’s name is clearly present on the post when you view it on the web page, perhaps the blog’s HTML meta data does not have it specified. As a result, perhaps the service that generates the article does not recognise that an author has been specified - because it is specified in a way it has not been programmed to extract for. As a result, the article for this post has the author name blank because the article service did not identify that an author was specified.

As a general rule, no. For most people’s Shortcuts automation requirements you would not need to do that as in general if you have the URL, you could always retrieve/query for the other content based on knowledge of the type and whether that sort of data is always going to be populated. I would personally always expect title to be populated on Safari web pages and articles. I would always fetch the content of a URL to get that data and not just go with the name as that could be derived from a file.

Sometimes however, for more advanced or flexible cases, you could adopt a more conditional approach as you describe.

But if I am allowing multiple data types I would always take the lowest common denominator (e.g. the URL), and work from that. That’s why it is best to be as discrete as possible with your types and not just open it up.

Apps usually share one type of data structure from the share sheet, but some share multiple types (e.g. plain text AND rich text). The OS will allow you to coerce te data to an extent, and then the content graph engine in Shortcuts will allow you to do even more. So rather than blanket allowig lots of types, choose what you want to get and keep the number of selected options minimal. Consider building up things in Shortcuts to go out and get additional data, or coerce the existing data into the required format you need; but note that this conversion only dervices data, it does not create data.

Back when it was Workflow, we just used to experiment with it. It was like a game without a manual.

There are obviously guides and courses out there such as those created by @MacSparky and @RosemaryOrchard. I don’t believe Rosemary’s guide covers this sort of detail - but maybe the update will? I haven’t looked at David’s course, so I really don’t know if this depth is covered in it.

As for finding out more in general, hopefully this reply has helped explain some of it. I expect it may even throw up other questions. But, hopefully that’s where you can hone in on the points you would like to understand better and people here on the forum who have been through similar learning experiences can help with suggestions of the what’s why’s and how’s to help you improve your understanding.

Hope that helps.

1 Like

I appreciate your thoughtful response.

A URL is a string of text that defines a location. However, it also includes a name in Shortcuts terms.

Okay, I see how a “URL”, including “URLs” passed in by the Share sheet, carry both “URL” and “Name”. This seems useful, except…

“Name” only appears to be actually used by “URLs” shared out of Safari. In other circumstances, iOS stores a duplicate of “URL” in “Name”. And that isn’t just when you create a new “URL” in Shortcuts for test, it’s also the case when sharing something out of another app - eg. Chrome, Pocket Casts.

Okay, maybe no surprise here - a URL is a simply URL. Only surprising that they should add a “Name” to it, perhaps.

I would always fetch the content of a URL to get that data and not just go with the name as that could be derived from a file … Consider building up things in Shortcuts to go out and get additional data

I think you’re suggesting use “Get Article using Safari Reader” on a given “URL” to go and get the page title etc. I can understand that, and have tested it, but…

  1. It seems an inefficient way to get content that really is already visible right in the app being shared from.

  2. Under iOS 15, it seems like this involves a lot of permissions pop-ups, since I think it would want to confirm the request for each website you do this for. Since I’m aiming to make a shortcut for other users, I think that’s problematic.

I can’t believe that both “URL” and “Name” are not available for the content in a large number of apps. When I share out from apps like Chrome, Pocket Casts etc (and not just Safari), apps including Mail, Notion, Spark, Todoist and TickTick all evidently include both the “Name” and “URL” of the content, and this does not seem to be the result of all these apps going and making a remote call to parse the content. Why can’t I find a way to get both pieces as neatly in Shortcuts?

1 Like

Use the view content graph action to review all the data across translatable formats passed in from an app. That will help you understand what the app has shared to the OS.

I may have just cracked it…

If I scope down the shortcut to only accept “Article” types from the Share Sheet, it still channels through structured content from a variety of apps, eg. Chrome, Reddit, Pocket Casts.

The fields of Article can be used in the shortcut and they do show what I hoped for.

See this example of content shared out of a podcast episode in Pocket Casts.

In other words, “Article” may be poorly named. It’s a structured-content holder that appears to be able to parse certain content types other than what you would classically call an “article”.

Allowing sharing of “Safari web pages” and "URL"s in addition to “Articles” seemed to be interfering with it. From Safari, “Safari web pages” was taking precedence. From other apps, “URLs” was taking precedence. That was precluding both a) consistency and b) the ability to actually utilise “Article”. So I tried to make it the only usable type.

Supplementary question…
I noticed you suggested in an old thread that Article parsing (I guess, “Get Article Using Safari Reader” uses Diffbot. But I seem to have found a way to not need it - I don’t think any remote call is being made in sharing an “Article” from the to the shortcut… it’s all on-device, right?


1 Like

So that comes down to the apps prioritising what they send through, but again it comes back to my point of limiting what types your shortcut accepts in order to drive the data/results you want to work with.

Yeah, so as noted before, I know it used to use services - Diffbot was one, and there was another at one point; but they didn’t seem to list any now in the about acknowledgements from what I can see. It may well be that they have developed their own article processor that is now being used. As to whether that is all on device, I don’t know, but if you turn on Airplane mode, it would be an easy test to determine - Shortcuts will throw an error if it needs an Internet connection to do any backend processing or call outs to a web site. If you want to know which it is doing, then you would need to use WireShark or a similar tool similar to monitor the network traffic to and from. your device.

Interesting.
In Airplane mode…

  • Safari page still in browser when offline: The “Article” successfully shares to the shortcut and it’s parsed.
  • Other, third-party apps, content still in-view when offline: The “Article” does not even hit the shortcut.

So there may be an online component to the parsing, in some circumstances - but no permission request is made by Shortcuts for a connection.