Super Editor prototype for article rendering and interaction

[matthew-carroll]

This PR is a prototype that demonstrates that Super Editor can be used to render articles in the News Toolkit.

Super Editor benefits:

• Explicit document structure representation, which better reflects existing industry practices for document modeling
• Stylesheet support, which better reflects existing industry document styling practices
• Deep support for inline styling and metadata, e.g., bold, italics, links, font changes, all within a single block of text
• Mobile-style content selection, including selection highlights, drag handles, a magnifier, and auto-scrolling
• Alignment with the community on a package that was initiated by Chris Sells, that's funded by multiple companies, managed by the Flutter Bounty Hunters, and receives contributions from other community members

PR notes:

• This PR is a prototype. Nothing is optimized. Some minor features are missing. Lots of lint complaints.
• This PR uses the existing News Toolkit document structure.
• This PR uses the existing widget implementations for non-standard content, e.g., banner ads, videos, newsletters.
• Super Editor might lack some needed features. As those are located, our team is dedicated to quickly providing solutions.

Video of the original article implementation

https://user-images.githubusercontent.com/7259036/204066968-4337d3ab-29c8-4d98-a2b1-dcea9412166d.mov

Video of the Super Editor implementation

https://user-images.githubusercontent.com/7259036/204066990-c15a6ba0-e841-4a39-a500-f53170fb9a5d.mov

[kaiceyd]

Hi @matthew-carroll, thanks for pulling this draft together!

We've discussed the benefits of using super_editor internally and have struggled to justify a nontrivial refactor at this moment in time.

That said, we may be missing some perspective and would like to ask you what benefits, specifically for the news industry, does this package offer when it comes to displaying text to readers. Can you shed some light on how super_editor can improve a reader's experience over the current implementation (flutter_html) + vanilla Flutter?

Thanks!

[matthew-carroll]

Hi @kaiceyd can you please elaborate on what you mean by "non-trivial refactor"? The introduction of Super Editor took less than a day, the code is very well quarantined from the rest of the app, which minimizes cascading issues, and we have Flutter Bounty Hunters who can take over any such workload to complete the integration. It seems simple and low risk to me.

As to your question about benefits, can you please check the PR description and let me know why the currently listed benefits wouldn't be relevant for news organizations?

[kaiceyd]

Hey @matthew-carroll, I understand the benefits for the package itself, but wanted to make sure we weren’t missing industry-specific use cases for news readers beyond what vanilla Flutter already provides.

Given that this project is meant to be a template, we’ve been collectively cautious when selecting packages to include in this codebase. By default, we’ve only included packages that are necessary to meet the requirements of publishers. Of the packages we used, we relied upon “Flutter Favorites” or packages that have excellent test coverage, popularity, and pub points that have been vetted by the Google product team.

We were able to add text selection support using the SelectionArea widget and it seems to work quite well. We were also able to add hyperlink support to the HtmlBlock by implementing the onLinkTap callback and using package:url_launcher to launch the url in an external browser.

The caveat is that hyperlink support (and other inline styling such as bold, italics, underline, etc.) for non-HTML blocks will be more difficult to adopt because we don’t have nested support for inline styles. This is where super_editor could provide additional value over the current solution in our opinion. If a large portion of publishers want to support nested inline styling without the HtmlBlock, then super_editor would be beneficial; however, given our current feedback from customer interviews and implementations, we suspect most publishers with inline styles will likely prefer to use the HtmlBlock since their content will likely already be HTML.

It’s possible this PR can be revisited after we obtain real market data from the industry after GA launch. If we receive feedback that inline style support for non-HTML blocks is needed, we can revisit the potential to support super_editor here.

[justinmc]

+1 to everything that @kaiceyd said, but @matthew-carroll I wanted to jump in and say that we should all probably keep an eye on this repo, super_editor, and the framework itself to make sure we're not diverging in terms of how we all go about representing documents etc. Currently with a quick glance at the code in this repo I'm not worried and it doesn't seem too opinionated or entrenched about that kind of stuff, but it might be relevant for future work.

In the framework as you know we don't have much/any support for multiple "paragraphs" or large documents either. Nor do we have any specific plans for it. If we do start moving in that direction though, I hope it can align with super_editor and news_toolkit and be useful all around.

[matthew-carroll]

@justinmc don't forget about attributed_text and super_text_layout as well. Those are the somewhat hidden workhorses in super_editor. super_text_layout is mostly useful from an editor perspective, but attributed_text is a great tool for defining any text with styles and metadata. Way easier to use than TextSpans.

[justinmc]

Thanks, I wasn't very aware of those, will check them out.

[zoeyfan]

Based on the previous discussion, we do not plan to merge this request in the near future. Hence I am closing this PR now. But we will be more than happy to revisit when we hear customer feedback. Thank you.