[Sharing] Share Extension: Improve text import from other apps

[frosty]

When sharing text to our share extension from other apps (I tested Bear and Ulysses), one of two things happens:

1. The share extension is launched with the shared text inserted as a block quote
2. The share extension is launched with an empty editor

In Bear, to reproduce number 1, simply tap the system share icon in the top right of a note. To reproduce number 2, tap the (i) icon in the top right of a note, tap TXT at the bottom, and attempt to share the text version of the note.

There are two issues here:

Text inserted as a blockquote

This is a conscious choice we made when we first built the share extension. If only text is being shared to the extension, we insert it as a blockquote. One use case for this is for example sharing snippets of text from a web page (highlight the text in Safari, and choose Share from the popup menu). It seems that we have no way to detect whether a user is sharing selected text or an entire document.

I think we have a couple of options here, and I'd be interested to get input from @wordpress-mobile/automattic-design:

• Revisit this decision, and perhaps never auto-quote shared text
• Auto-quote text only if it's below a certain character / word count (but how do you decide the limit?)
• Allow the user to choose whether imported text is quoted or not. How would we surface this? A setting in the main app's App Settings?

No text inserted

I saw the same behaviour from both Ulysses and Bear, and it looks like it's a bug on our end. In this situation, the NSItemProviders sent to the share extension contain two types of content: public.file-url (a URL for a local file containing the shared content), and (in Bear's case, but not Ulysses') the shared content as public.plain-text.

When we attempt to extract shared content (in ShareExtractor.swift), we iterate through a number of different extractors that we've written. When we reach an extractor that can extract valid content, we stop checking the other extractors.

In this case, the URL extractor says it can extract the URL content, so we never look at the text. However, the URL extractor bails out later if it detects that the URL is a file URL. So we end up with no content.

There are a couple of solutions here:

• Make the parsing / extracting more robust, and perhaps prefer text content over URL content if it's available.
• Add the ability for the URL extractor to copy content from a file URL

On top of each of these fixes, we could also look at supporting other content types in the share extension, such as JSON or TextBundle – but we can open separate issues for that.

cc @nheagy @matteorattotti

[folletto]

Text inserted as a blockquote

I wouldn't revisit this as long as there are other options. The reason is that in most scenarios (at least, that we are aware currently) people don't share entire content.

Maybe I'm mistaken and I'm not evaluating all the implications, but can't we just provide an API explicitly for apps that want to publish to WordPress? Something simple so they don't have to create an entirely new codepath just for WordPress, but at the same time something explicit so when present we can manipulate it knowing WHY it's coming that way.

[frosty]

Thanks for the input, @folletto!

Maybe I'm mistaken and I'm not evaluating all the implications, but can't we just provide an API explicitly for apps that want to publish to WordPress?

That's essentially what #11223 is about – we can offer TextBundle as an alternative format accepted by the share extension. When a TextBundle is shared to us, we can extract the text and any images and use them to populate the editor as-is.

[nheagy]

Allow the user to choose whether imported text is quoted or not

This would be my preference, fwiw. At the very least, I'd like to see us explore what kind of UI we could provide to allow users to decide if they want the text quoted or not.

[folletto]

When a TextBundle is shared to us, we can extract the text and any images and use them to populate the editor as-is.

So once that's done, will this be still a problem?

This would be my preference, fwiw. At the very least, I'd like to see us explore what kind of UI we could provide to allow users to decide if they want the text quoted or not.

I understand why this might seem a good option but note: there's already an UI to do that, and it's... the editor! Tap anywhere inside the quote, tap "Quote" and the text is immediately unquoted. :)

I'd rather choose to not quote anymore if that's the case (as I can again select and re-apply Quote).

[nheagy]

Tap anywhere inside the quote, tap "Quote" and the text is immediately unquoted. :)

This may be a separate issue, but atm it takes one tap per paragraph to unquote. When the source is a lengthy post from another app, this can be a real pain.

[matteorattotti]

I wouldn't revisit this as long as there are other options. The reason is that in most scenarios (at least, that we are aware currently) people don't share entire content.

That depends from where they're sharing, for example if you share from a notes taking app the quoted content can be not ideal. If you already have a quote button it should be easy for the user to quote some part of the text instead of having the app to assume what the user want.

Maybe I'm mistaken and I'm not evaluating all the implications, but can't we just provide an API explicitly for apps that want to publish to WordPress? Something simple so they don't have to create an entirely new codepath just for WordPress, but at the same time something explicit so when present we can manipulate it knowing WHY it's coming that way.

On iOS the share panel is already very nice "API" to support, it allows other apps to just share a specific format without adding custom code only for WordPress. Also it's super nice because it skip all the login/authorization part leaving it to the WordPress app (more secure, more trustworthy).

[folletto]

That depends from where they're sharing

Unfortunately the answer is always "it depends". Our current primary scenario is sharing URLs/Quotes, which is why that's the current default. Afaik we didn't have any indication that the balance has shifted, and I feel that companies that want to publish to WordPress explicitly have a desire to provide extra data to mark it properly instead of having both sides guessing it.

On iOS the share panel is already very nice "API" to support

Yep I agree, if that allows for the degree of control we need with a lightweight API, it works.

[megsfulton]

I recently did a walkthrough of the current experience and my thoughts on the expected behavior largely aligned with what was reported in #10955.

I feel that companies that want to publish to WordPress explicitly have a desire to provide extra data to mark it properly instead of having both sides guessing it.

Does this mean that the experience of sharing to WordPress could vary from app to app? I could see that being somewhat disorienting and hard to understand from the user's perspective.

[folletto]

I feel there's some context lost, so let me take a step back.

1. The sharing feature has been built and designed to share content from elsewhere: photos, text, URLs, etc. That's the core use of it on mobile. In that scenario we are quoting the text to avoid being mixed to what the person will actually write below it.
2. Also note that iOS share API doesn't differentiate partial quotes from full pages. It's just text being passed.

This being discussed here is a different case scenario from Bear developers. Share wasn't designed nor built for that scenario, as it wasn't the problem share was trying to solve. Now we can surely change our approach if we believe that more people will use share to post entire articles from a specialized app... but I find that secondary (how many people even have a specialized app to write entire posts before pasting it in the already existing WordPress app they have?) — thus I'd make that change carefully.

Which is why I suggest for an explicit declaration from any specialized app that doesn't just want to share something with WordPress, but an entire article, with full formatting.

[frosty]

Thanks for the clear explanation @folletto – that's really useful. I think in this case, for now, we should simply implement this as a bugfix to fix the case where the editor is displayed with no content.

If apps want to share full content via the share extension, that would be a case for the TextBundle support.

[folletto]

After a chat with Megs and a night of sleep I thought of an alternative approach — alternative not intended "in substitution of the above" but "an extra option to provide" — that might be easy to build and try.

If I recall correctly we can have multiple quick actions, like "Save as Draft". So maybe we can add "Post Full Article" or something similar and then measure which one of the two gets used the most, so we can use that to adjust the default?

[nheagy]

I have made a first pass at improving this issue: #11288

In this case, when the shared item is a text file we assume it is from an app and don't quote it, but text shared directly (not within a file) is assumed to be a snippet and is quoted. This isn't perfect, because some apps (such as Bear) default to sharing the text directly and must be instructed to instead share a file. However, it works.

Ideally we can take some of these ideas further in the future, but this seems to be a reasonable starting point?