readulatorReadulator reads a page the way a person would and throws away the rest: the menus, the share buttons, the newsletter box, the cookie notice, the "you might also like" rail. It gets this right most of the time. When it doesn't, one report is usually enough to fix that site for everyone, because almost nothing here is a per-site rule. It's the same handful of heuristics reading every page on the web.
So a report about one article on one site is worth much more than it looks. The last several rounds of fixes each came from a single report.
Sending one.
- Open the item Tap it in the Stream, so you're looking at the captured text rather than the list.
- Mark the problem, if you can point at it Select the offending text and choose Highlight from the menu that appears, the same way you'd highlight a passage worth keeping. Highlights ride along with the report. This is the single most useful thing you can do, and the next section is entirely about it.
- Tap the ⋯ menu, then Report a Problem It's in the toolbar at the top of the item.
- Say what should have happened One line is fine. The URL, your highlights, and a full technical trace of how the page was fetched are all attached for you.
Reports are anonymous. There's no account, and nothing identifying you is attached. See the privacy page for what does get sent.
Highlighting is the report.
"The text is wrong" is a starting point. A highlight is an answer. There are two kinds worth sending, and they're opposites.
Something is in the article that shouldn't be
Highlight it. Anything that isn't the writer's words: a stray "Sign up for our newsletter," a photo credit, a share prompt, an author bio, a subscription pitch, a line of leftover JavaScript, the first paragraph of a completely different story.
Highlight only the intruding text, as tightly as you can. The exact wording is what gets matched, so a clean highlight of one junk sentence is more useful than a highlight that also swallows the real sentence next to it.
Especially worth reporting: junk at the very beginning. The first few lines become the item's summary in the Stream and the first thing you hear in the Listen Queue, so clutter there does the most damage.
Something is gone that should be there
This one you can't highlight, since it isn't there to select. Instead, say where it stopped and what's absent: "cuts off after the third paragraph," "the whole bulleted list is missing," "every subheading is gone," "only the picture captions came through," "this is the comments section, not the article."
If part of the article did survive, highlight the last sentence that made it in. That marks the exact spot where extraction gave up.
Content going missing is the more serious of the two problems and the harder one to notice, because a clean-looking article that's quietly half the length reads fine. If a piece felt strangely short, it's worth a look at the original.
Also worth reporting.
- A link that works in Safari but not here. Say so plainly: "works in browser." That's a real bug with a real cause every time, and the attached trace usually shows which step gave up.
- A wrong verdict. "This says it's behind a paywall, but it isn't." "This says it's blocked and I don't believe it." Trust that instinct; you've been right before.
- Something filed in the wrong place. A recipe that landed in the Stream instead of Recipes, a film that didn't come through as a film, a book or album that should have its own card. Say what you expected it to be.
- A stuck item. Anything still saying "Fetching…" long after you saved it. You can report from that state; the trace is the whole point.
- Text that sounds wrong read aloud. A URL read out character by character, a hashtag, a stray "undefined," a caption glued onto a sentence. Listening surfaces problems that reading right past them never does.
- Anything mangled in the title. A literal
'where an apostrophe belongs, a site name stuck on the end, a headline that's actually the site's slogan.
What happens next.
Every report gets read. Each one is reproduced against the live page, and if it's a real bug it gets a fix plus a test pinning that page's exact markup, so the same problem can't quietly come back later. Sometimes the answer is that the page really is that thin, or the site really is blocking us, and then nothing changes except that we know.
The fix usually arrives in the next build. You won't get a reply to a report, which is the trade for making them fifteen seconds long, but if you want to talk something through, mention it in TestFlight feedback instead.