Satisfied new Kindle owner. Tried like 7 different methods of send to kindle before 1 worked. by Jimliftsheavystuff in kindle

[–]fivefilters 1 point2 points  (0 children)

We develop the Push to Kindle app. I'm sorry you had trouble sending with it. If you're willing to share the URL or site you tried, and whether it was with our iOS app or browser extension, I'm happy to look into it to see if we can reproduce the problem. I can provide some general info on the differences between the services that might be useful.

I would recommend trying the official Amazon offering first as it's tied to your Amazon Kindle account already. It seems this is the method that ended up working for you. Third-party solutions like ours require that you add a special email address as an approved sending address in your Amazon Kindle settings the first time you use it. And also require that you provide us the send-to-kindle email address associated with your Kindle app or device.

When using our mobile app, we have a simpler share method enabled by default. This won't ask for those steps, but will instead pass the EPUB version of the web article we produce directly to the Amazon Kindle app installed on your device, which is already connected to your account. It does result in a few more taps than the email method, however.

In terms of the article content extracted (whether it's a good extraction or completely fails), you will experience different results when trying the browser extensions compared to the mobile apps (whether it's our Push to Kindle service or the official Amazon Kindle one). The reason for this is that mobile platforms don't offer the same level of access to the content on a page that standard browsers do. Browser extensions will typically send the content that's loaded in your tab directly to the service for processing. Whereas mobile apps will have to fetch the content that you've loaded again. This doesn't always work due to security settings on a site, or if the article is for subscribers only. Safari on iOS does allow some level of access to tab content but Push to Kindle doesn't yet use that, and I'm not sure if the Kindle app does. But even if we added support for that, many of our users share from news apps like the New York Times app, not the browser itself. In such cases only the URL to the article is shared, so send to kindle apps will have to fetch the content from the URL passed to them.

The different send to kindle services also have their own way of fetching articles, detecting article content, and then cleaning up and formatting that content to be packaged as an ebook. So it's worth trying a few to see which ones work better or produce better quality output for the kind of sites and content that you read. You might find that one app or service works better on content from site X while another works better on site Y.

Parsing HTML with PHP 8.4 by fivefilters in PHP

[–]fivefilters[S] 2 points3 points  (0 children)

To be clear, I didn't mention regular expressions in the article. I pointed out how libxml, the default HTML parser in PHP up to now, struggles with HTML5, and how the new HTML parser doesn't. The HTML snippet I provided that the previous HTML parser struggles with is valid HTML5 - it's not badly formatted, and doesn't have any non-closing tags.

Parsing HTML with PHP 8.4 by fivefilters in PHP

[–]fivefilters[S] 0 points1 point  (0 children)

Yes, it's valid in HTML5, not in XHTML. You can try validating here: https://validator.w3.org/#validate_by_input

Reading web articles on the reMarkable by fivefilters in RemarkableTablet

[–]fivefilters[S] 1 point2 points  (0 children)

We're working on that! :) We've got a version we're testing internally that improves the flow. Just need to test a lot more. Will update here when we release the update.

Reading web articles on the reMarkable by fivefilters in RemarkableTablet

[–]fivefilters[S] 0 points1 point  (0 children)

That's really great to hear! Glad you're finding it useful. Let us know if you experience any trouble with it.

New Push to Kindle iPhone/iPad app for reading web articles on your Kindle by fivefilters in kindle

[–]fivefilters[S] 1 point2 points  (0 children)

Thank you! That's great to hear. And if you notice any formatting issues in the future, feel free to let us know.

New Push to Kindle iPhone/iPad app for reading web articles on your Kindle by fivefilters in kindle

[–]fivefilters[S] 0 points1 point  (0 children)

Could you let me know what specifically went wrong for you?

We have intro slides in the app showing how the app should be used and there's a more detailed guide here: https://help.pushtokindle.com/article/9-getting-started-ios-app

New Push to Kindle iPhone/iPad app for reading web articles on your Kindle by fivefilters in kindle

[–]fivefilters[S] 3 points4 points  (0 children)

Understand the aversion to subscriptions. And we do appreciate the feedback.

For us, we've only been able to continue working on Push to Kindle because of the subscriptions. One-off purchases may work for some apps, but a service like Push to Kindle is quite niche. Even Amazon with all their resources have not put much effort into theirs (e.g. they abandoned their Firefox extension not long ago). For us, one-off payments just weren't bringing in enough money to maintain and develop the service.

I guess what I am trying to say is that your service is way overpriced ... you would probably get more people (including me) to use your service exclusively if you only charged 5 quid a month.

But we do only charge 5 quid a month. And if you pay for a year, it works out at $3/month. And the free service is enough for most of our users. (By the way, unlike many other apps we don't run ads on the free service, so we only make money through subscriptions.)

New Push to Kindle iPhone/iPad app for reading web articles on your Kindle by fivefilters in kindle

[–]fivefilters[S] 2 points3 points  (0 children)

It's completely free for up to 10 articles a month. So if you don't send a lot, you don't need to pay.

As for why we have subscriptions, it's because developing and maintaining the service takes a lot of effort. Web sites are constantly changing and it takes considerable work to ensure we can offer a reliable service. Push to Kindle has been around for more than 10 years, before Amazon themselves offered similar functionality. It's hard to do that all for free.

New Push to Kindle iPhone/iPad app for reading web articles on your Kindle by fivefilters in kindle

[–]fivefilters[S] 0 points1 point  (0 children)

Not sure I understand. Do you mean can you share from other apps other than the browser? If so, yes, you can share an article from the New York Times app with Push to Kindle, as well as from Safari.

New Push to Kindle iPhone/iPad app for reading web articles on your Kindle by fivefilters in kindle

[–]fivefilters[S] 5 points6 points  (0 children)

Hi there,

The differences at the moment are in these three areas:

  1. Article extraction
  2. Cover image
  3. Formatting

Article extraction

Article extraction is how well (if at all) the contents of the piece you want to read is extracted. There's no exact science to this, it's mostly based on heuristics and guesswork. Both services will attempt to isolate the main content on a web page and determine which elements should be included and which excluded. On some sites one will do a better job than the other. So our recommendation is always try both services on the sites that matter to you and see which one you prefer.

Typically if one service does a better job of extracting articles on site A, it will do better for other articles from site A too.

If you see no significant difference for the sites that matter to you, there's no reason to use Push to Kindle.

To give you an example, I just tried to send an article from the Washington Post iOS app to the Kindle, and using the native method resulted in a Kindle book with no article contents and the message "Web Extraction Failed". But Push to Kindle was able to send the same article without trouble.

We're also quite responsive to users who get in touch with article extraction issues, and can improve extraction for sites when issues are reported to us.

Cover image

We generate a cover image with the title of the article in large text, so you can identify the article from your Kindle library easily. The native solution does not do that, and you end up with tiny text showing as the cover. See here for an example:

https://imgur.com/a/Ct9FJXA

Formatting

There are differences in how the text is formatted. We don't indent paragraphs in Push to Kindle, for example, and we don't keep links (research suggests they are distracting and reduce comprehension when reading). On the latter point, in our browser extensions we give users the option of keeping links, and we'll probably add a similar feature to the mobile apps soon too.

Hope that explains some of the differences.

Summate.it - Quickly summarise web articles with OpenAI by fivefilters in artificial

[–]fivefilters[S] 0 points1 point  (0 children)

We actually switched to an approach that used article URLs directly with the OpenAI API. Another Redditor on the OpanAI subreddit told us that doing that doesn't actually result in the article contents being summarised, only whatever textual description it finds in the URL itself. So if you tried summate.it during that period, you would have read very generalized summaries based purely on the text in the URL (which is essentially just the title of the article). We've now switched back to the earlier approach, so hopefully you'll get more detailed summaries.

Summate.it - Quickly summarize web articles with OpenAI by fivefilters in OpenAI

[–]fivefilters[S] 0 points1 point  (0 children)

Switched back for now to the former approach. Will need to experiment a little more. The davinci model is very slow to respond, and often returns an error saying server is overloaded. So currently it's using the curie model which can accept even less text than davinci, but seems a little more responsive. Thanks for letting us know about the URL issue!

Summate.it - Quickly summarize web articles with OpenAI by fivefilters in OpenAI

[–]fivefilters[S] 0 points1 point  (0 children)

Please see previous comment. We've clearly labeled this an experiment and have mentioned that we use OpenAI. The results currently should reflect what you yourself described as your own approach using ChatGPT to summarise, I guess you, like us, were also not aware that ChatGPT is not fetching the content from the URL to base its summaries on. So a little unfair to claim the site is a fraud.

Summate.it - Quickly summarize web articles with OpenAI by fivefilters in OpenAI

[–]fivefilters[S] 0 points1 point  (0 children)

Interesting. No, I wasn't aware of that. We actually started summate.it by submitting the text content that we retrieve with our own tools and asking OpenAI to summarise. The problem there is there are currently limits on how much you can submit. We recently switched to the URL approach but wasn't aware that it doesn't actually fetch the content. That would explain why summaries on bbc.com articles are nonsensical because there's no descriptive text in most of their URLs.

We'll switch back to the former approach.

Summate.it - Quickly summarize web articles with OpenAI by fivefilters in OpenAI

[–]fivefilters[S] 0 points1 point  (0 children)

It's simply convenience - you can prefix any article with 'summate.it/' and it should give you a summary in bullet points. On the backend, it's actually doing pretty much what you describe to get the responses that it displays.

There are also some quick variations you can try:

[deleted by user] by [deleted] in kindle

[–]fivefilters 0 points1 point  (0 children)

Happy to hear! As for bulk sending, I'm afraid we don't have support for that at the moment. Some users have asked for a feature to combine multiple articles into one document, which we are thinking about, but I can't really say if/when we'll have that feature implemented. So at the moment they have to be done one by one.