Kindle 3 support coming
The new Kindle model (“Kindle 3”) has a number of changes and new capabilities, and I’m planning first-class support for it just like I implemented for the Kindle 2 and Kindle DX.
Unfortunately, I don’t have one yet (mine ships “in September”), and therefore cannot test or develop anything for it.
As far as I know:
- Instapaper’s current Kindle functionality already works on the Kindle 3.
- The Kindle 3 might make better use of the @free.kindle.com email addresses such that Instapaper may actually be able to use them.
- The Kindle 3’s web browser is much better and may allow better web functionality.
I’ll be investigating all of these as soon as possible. I’m sorry for the delay.
Based on the email volume about this over the last few days, Amazon must be selling a ton of Kindle 3 units.
How Technology Is Renewing Attention to Long-form Journalism
When we’re constantly inundated with information via e-mail, text messages, push alerts, tweets and Facebook updates, it’s hard to make time for that 5,000-word New Yorker essay we bookmarked or the serial narrative we keep telling ourselves we’ll read but never do.
Barron's: Seven Great Apps
By Jay Palmer:
Instapaper: You can save a few trees, and a lot of time at the printer, by firing up this app. It lets you save Web pages (news or otherwise) on your device for later offline reading.
Thanks, Jay.
MediaPost: The 100 Most Important Online Publishers
#24 Instapaper
In the spirit of Time magazine’s infamous “You” person of the year cover, we are going to go out on a limb here and say, that for many of you, the best editor is probably you. Instapaper is really just a technology that allows you to save anything you want to read online in one place until you have the time to read it. And it lets you read it anywhere, even offline later on your mobile device.
Thanks, OMMA Editors.
Instapaper. Reinventing long-form reading…
Great article By Milind Alvares at Smoking Apples.
When I was reading the exact same article he was in the third photo, I passed “aluminosilicate” and thought, “I wonder if my dictionary has that.” And then I immediately dismissed the thought without trying it, thinking, “Nah, that’s far too specialized. There’s no chance it’ll have that.”
Instapaper 2.2.5 for iPhone and iPad now available
Note: 2.2.4 and 2.2.5 were only a week apart, so I’ve combined their notes into this post.
First, I’ve renamed “Instapaper Pro” to simply “Instapaper” for a few reasons:
- It’s easier to find, less confusing, and more welcoming to new users who heard of “Instapaper” from somewhere and want to get the app.
- I don’t want anyone not buying Pro because they think they aren’t serious enough users to need it.
- It’s shorter and can fit entirely under the icon on the iOS home screen. Since the icon has always said “Instapaper”, it’s better to simply call the app that.
Now, onto the new features.
Pagination
- Added swipe-left/swipe-right for page-turning (iOS 4 and iPad only). This helps when you’re holding the device one-handed and can only comfortably reach one part of the screen.
- Added a subtle sideways-motion animation to indicate the direction of each page-turn.
- Improved page-turn speed, especially under iOS 4.
iPhone 4 and iOS 4
- Added background completion if you leave Instapaper while an update is running (iPhone 4 and 3GS only). It will continue downloading as much as it can until you lose internet connectivity, another app needs its memory footprint, or about 10 minutes elapse.
- Icons have been updated for the iPhone 4’s Retina Display.
Rotation and position-saving
This is a big one. I’ve completely overhauled rotations and position-saving in articles. As a result:
- Rotations are much faster and more accurately keep you in the same place.
- Fixed iPad position-restoring when launched in landscape.
- Fixed minor interface bugs when rotating.
And one more thing:
- Now synchronizes your position in partially-read articles between multiple iOS devices, such as an iPhone and an iPad.
Positions are synchronized on every update, and it even uses background task completion on multitasking-capable iOS 4 devices to sync your position when you quit the app mid-article.
Other improvements
- Added “Email Full Text” option to Share panel. This is especially useful for integration with other services that I don’t support yet, such as Evernote, that have email-in features. (By the way, did you know that Instapaper has an email-in feature? Check the bottom of the Extras page.)
- Switched to OAuth for Twitter. You’ll need to log into Twitter in the app again. (Note: There’s a problem with this in 2.2.4 and 2.2.5 that fails if your Twitter password contains certain special characters. I’m working on this and will have a fix ready for 2.2.6. I’m sorry about this.)
- Fixed password-dialog problems on iOS 4.
- Improved tilt-scrolling performance on iOS 4.
- Fixed minor interface bugs related to the action menu, the folder list, and zooming text.
Instapaper Free
I’ll be updating Instapaper Free in the next few weeks (hopefully) to modernize its codebase and fix some bugs. In the process, like the formerly-“Pro” paid version, Graphical Mode will be removed. It’s just slaughtering the server, and it’s a terrible experience for people to try Free, think Graphical Mode is part of the product, and then buy the paid version, where it isn’t.
To make up for this removal, I’m adding position-saving and automatic updating to Instapaper Free, two of the biggest and most compelling features that it formerly lacked. I think this is a more-than-worthwhile trade.
More coming soon
As always, more features and improvements are coming in future updates. 2.2.6 will be a very minor bugfix update for the Twitter password issue, but I have a lot of great improvements planned for the version after that.
Thanks for your support, everyone.
Preview: Community text-parser configuration
I get questions almost every day from publishers asking how they can improve the way Instapaper parses their sites. And I get almost as many emails from web programmers among Instapaper’s userbase asking if they can contribute custom-parsing instructions for their favorite sites.
Well, I’ve been working on a solution to this for a while, and it’s almost done.
Part 1: Customized parsing
The Instapaper text parser has a complex “automatic” mode in which it tries to make its best guess on which element in any given page is the “body” container that will include all article text with minimal clutter from non-text elements (e.g. navigation, headers, comment forms, share-this widgets, etc.) and which additional elements inside the body container should be removed.
In addition to the automatic behavior, I can custom-configure the parser’s behavior for specific sites. So, for example, if a popular site such as Los Angeles Times parses poorly under the automatic behavior, I can customize the parsing of all latimes.com stories with fine-tuned directives:
body_node = //div[@id = 'story']
strip_id_or_class_substring: 'related'
strip_id_or_class_substring: 'tools'
But I have very little time to keep this list updated, and if a site’s not a major Instapaper source, I’ll probably never get around to it. This, obviously, sucks. But there’s a better way.
Starting very soon, I’ll open these up for public contributions. If you know a bit of XPath, you’ll be able to test and submit custom parsing instructions for any site. They’ll go through admin approval before going live, to prevent abuse, and then they’ll improve the text parser for everyone.
And, recognizing that your efforts could be useful to a wide range of other tools and services, I’ll make the list of all of these site-specific configurations available to the public, free, with no strings attached.
Sure, someone could make a pretty great competitor to my text parser with this list, but I’d rather have a better common parsing database at the expense of exclusivity instead of trying to keep this one component to myself at the expense of its quality.
Part 2: Special class names
Additionally, the Instapaper text parser will support some standard CSS class names to instruct it:
instapaper_body: This element is the body container.instapaper_ignore: These elements, when inside the body container, should be removed from the text parser’s output.
If the instapaper_body class name is present, the automatic selection and automatic stripping processes are disabled, leaving full control to the site’s author.
Coming soon
The back-end work for this is almost entirely done, and the interface is about half-done. (The submissions mechanism needs a lot of interface work.)
I expect this to be live within a few weeks. Until then, if you have any feedback or would like to see any other special class names added, I’d love to hear from you: email instapaper@marco.org. Thanks.
Instapaper Beyond for Safari
This is pretty incredible.
Fair warning: I am, of course, working on an official Instapaper extension for Safari 5. But it’s likely to focus on a smaller set of features.
Website update
Text view on website, Mobilizer, Text Bookmarklet:
- Added font controls. You can now change the font, font size, line height, and margin (margin not available on iPhone due to impracticality). Settings are saved in a cookie so they stick even when you aren’t logged in, like when using the Mobilizer in other applications.
API:
- By default, all URLs added will be crawled synchronously to find the final URL after redirects have been followed. Other normalization may also be applied. This should prevent URLs from being saved with URL-shortener hosts (like bit.ly) and RSS redirects (like feedproxy.google.com). Duplicate-checking applies to the final URL, not the originally submitted URL, when they differ.
- The
auto-titlefunctionality, in which Instapaper crawls the target URL to detect its title, is now used automatically if you do not specify atitleparameter, or if thetitleparameter is an empty string. Previously, it was off unless specified. As a result,auto-title=1is now redundant and deprecated, and it has been removed from the documentation. - Added HTTP Basic Auth as an alternative to the
usernameandpasswordPOST parameters. Please use Basic Auth whenever possible. - The
Content-Locationheader in the output previously used theinstapaper.com/go/(ID)URLs. It now uses the item’s target URL after redirects and normalization.
Page compatibility:
- Added to “save full contents” login-requiring-site list: livejournal.com, stratfor.com, soundonsound.com. Raised saved-HTML size limit to accommodate more sites on the list.
- Fixed a bug that prevented americansuburbx.com and a few other sites from working in the text parser.
- Fixed a filter that occasionally caused a stray “<” symbol to remain at the end of text versions of certain pages.
- Fixed a bug in which IDN conversion was incorrectly applied to WordPress slugs with extended characters.
Some overdue site cleanup:
- Removed “Automatically move articles to the Archive when I read them” option and behavior. Its convenience was outweighed by its poor usability and resulting confusion among users. The /go URLs will start to be removed where they’re no longer necessary to improve link-clickthrough speed and prevent user errors.
- Removed option to select the old text parser. Only the new text parser is used from this point forward.
Please let me know if you see anything that isn’t working as it should be. Thanks.
Instapaper Pro 2.2.3 now available
Changes:
iPad, iPhone, and iPod touch:
- Added left/right pagination tap zones
- Fonts now scale after rotation
- Improved pagination scroll indicator’s accuracy
iPad:
- Redesigned reading screen with controls moved to the top
- Added Hoefler Text, Baskerville, Palatino fonts
- Added brightness control
- Added dark-mode toggle in font popover
- Increased size of inline images
- Fixed landscape orientation bugs after moving items to folders
- Fixed login, “No internet connection” issues
iPhone, iPod touch:
- Restored OS 3.0 compatibility
- Fixed “Clear pending posts” text alignment
Some rationale for the major changes, since I got a lot of positive feedback when I last discussed the design process:
The iPad reading interface
…has been completely redesigned:

All controls are now at the top. I’m following Apple’s lead again: I’m not completely satisfied with control placement yet, but this is how most other iPad apps do it, and I think it’s at least better than having them at the bottom.
The Star and Archive buttons are on the left for a few reasons:
- Archive needed its own button because it’s conceptually strange to select the “delete” action from the Actions/Send-To menu (the swoop-arrow icon). There’s not enough room on the iPhone toolbar, but on the iPad, I found a spot.
- I really wanted to fit the article title in the middle, and it looks ridiculous if it’s not centered. With too many controls on the right, there wasn’t enough room for a centered title label.
- It made sense to put Star and Archive on the left, next to the Back button, because those are the actions you’re most likely to take after reading an article when you’re ready to go back.
The scroll indicator on the right side is now much thicker and more noticeable, and it has also been made much more accurate, although there’s still room for improvement.
The huge margins
The iPad screen is actually too large for comfortable text reading spanning the entire width unless you move to multiple columns, which is a technical challenge that I’m not ready to tackle yet (especially since I don’t particularly like multi-column reading).
In 2.2.3, the minimum and default margins are both much thicker, and I’ve added a slight gradient around the edges (thanks to the Kindle app designers who came up with that) to help frame the content area and draw your eyes in.
Brightness adjustments
This was an easy decision to include: the iPad is far too bright to comfortably read text with a white background in a dark room, even at its lowest brightness setting.
I wish I could do it the way iBooks does, with actual hardware backlight-level control, but that’s not available to app developers. So mine’s done by putting a giant translucent overlay on the main reading and list areas. It’s a hack, but it’s the best that app developers can do for now. (Amazon’s Kindle app does the same thing.)

The darkest and brightest settings in Light mode.
I can’t dim the popovers easily (or well), so for now, they remain un-adjusted. (Sorry about that.)
I find that I now rarely use Dark mode, preferring instead to keep it in Light mode at very low brightness when reading in bed.
Pagination tap zones
After more usage, I’ve changed my mind about these (previous zones) and decided that left/right zones made sense in addition to top/bottom zones.
The new zone arrangement is a hybrid of both. (I’ll do a lot to avoid making yet another preference in the Settings panel.)
The goals on the iPhone were to provide as much tappable area as possible, and accommodate casual thumb taps on the mid-right section when holding it in your left hand. Furthermore, the larger the pagination area, the easier it is to tap while avoiding linked items in the page.

Red is previous page, green is next page.
On the iPad, the usage is very different: it’s usually held two-handed by its sides, and the margins are so thick that there’s no need to avoid hitting linked elements (because there aren’t any in the margins).

Additionally, the top zone didn’t make sense the way most people hold the iPad, and would be too likely to cause conflicts with the controls, so it was removed.
The way I most often hold the iPad, I tap the middle of the left margin for “previous page”, and the bottom-right corner area for “next page”.
Fonts, Dark mode in articles
The font panel has been significantly expanded:

In addition to the aforementioned brightness control, there are now three new fonts (Hoefler Text, Baskerville, and Palatino), and you can now toggle Light/Dark mode without leaving the article or opening the Settings panel. In a future version, I’ll probably remove the Dark-mode toggle from the Settings panel, as it’s now redundant.
While the in-article Dark-mode toggle isn’t on the iPhone version yet, I’ve laid the groundwork for it with this, so I’ll try to fit it into a future update. Unfortunately, I can’t add the new fonts to the iPhone, as they’re only available on the iPad. And I don’t think the brightness control is necessary on the iPhone since it does much better job of regulating its own brightness.
The future
One major addition coming soon is recognition of swipe gestures for page-turning. On the iPad, this is essential, because it’s how all other page-turning apps behave.
I have a lot of ideas for interface designs and improvements that didn’t make it into this release, plus the usual amount of feature ideas that are slowly getting implemented.
Stay tuned.