Hacker News new | past | comments | ask | show | jobs | submit login

I'm a huge fan of Readability Mode and use it often. It's proof that Web design isn't the solution, Web design is the problem.

For those who are using e-ink devices, or even just standard tablets, EInkBro is another immensely useful tool. Yes, it's a standalone browser, not a mode on Firefox, Safari, Vivalti, etc.

https://github.com/plateaukao/browser

(Available through Google Play, F-Droid and other sources. Android-only, sorry iOS fans.)

What it offers over standard browsers is that it's optimised for e-ink displays. That is, it favours pagination over scrolling, runs to full-screen, can easily adjust font size up or down (no more itsy-bitsy-teen-weenie-yellow-polka-dot HN fonts), bold text, and has its own reader mode as well.

Even on a standard tablet, some of these features are a huge step above and beyond the mainstream browsers.

The feature-set is limited, some of the UI is a bit rough, and a few things are just plain broken (if you need to edit entries in the JS or Cookie enabled/disabled sites ... you have to delete all data and start over again).

That said, my usage is evolving from sending individual pages to EInkBrow when I want to do long-form reading, to using it at least part-time as a primary browser. (Mozilla Fennec Fox is my first choice, still.) The browser is stable and very much usable despite this. The developer is responsive to requests and bug reports.

What's most refreshing is that the design principle is readability of Web content, as determined by the user, and not by the page author or publisher.




I wish somebody would create a DL/GAN/style-transfer tool to automatically change the style of any website into https://motherfuckingwebsite.com/

(regardless of how the website is structured, so deleting the CSS doesn't count)


On emissive / colour displays, this still is my preference:

https://codepen.io/dredmorbius/full/KpMqqB

On e-ink, the off-white / off-black colour palette is actually something of a probem, though the page otherwise remains highly readable.

From the original page, the lack of margins is a problem. Text running straight into the gutter is a readability problem.


This wouldn't be HN without some snark^H^H^H^H^Hconstructive feedback, so... it's perfect, except it's missing a fake quote at the end.

Also, I hate the yellow.

(Am I the odd one out here to prefer cold light to warm light? Warm light makes me seriously sleepy. But everyone I talk to, they all prefer to have warm lightning in their homes. And like with home lightning, I feel the same about webpages. On HN I got used to warm colors over the years; everywhere else I hate them.)

But seriously - great job!


Warm light doesn't make people sleepy, blue light keeps people awake. So basically: you are sleep deprived, the blue light is keeping you awake, and without realizing it you consider that a feature rather than a bug, whereas many other people conclude the opposite. Which is of course fine, you decide what's best for you.

Given how big of an impact good sleep (or lack thereof) has on my physical and mental health I am in the latter camp too, using a red filter on my screens even during day-time, but everyone's situation is different.


That's a possible explanation, but the same happens to me during the day, even when I'm well rested.

Cold light is much closer to natural sunlight than warm light. So working in a warm-lighted environment can be seen as being deprived of the blue parts of the spectrum that should be there. Blue light keeping you awake is a feature because the natural environment in which we evolved is saturated by it during the day.

I use blue light filters on my screens too, but they're timed to turn on around sunset. Ideally, everyone would have adequate access to raw sunlight during the day, but that's not the case for many (myself included) - whether because they live/work in a city, or because it's overcast weather, or both (like me, right now).


Right, makes sense. Sounds like that was the bit of context I was missing and also taking for granted: available natural sunlight. And I should have thought of that, honestly: I work next to a window with lots of light during summer, but in winter I use a high-power lamp to fake sunlight.

(plus I happen to treat blue light filters as an "default with opt-out possibility" kind of setting in general)


I do wonder if you might benefit more (during daytime) from a high-powered daylight lamp though, since light intensity also matters when regulating sleep cycles.


Quite likely. I'm considering it for my new location.

My current home office has a ceiling light fixture with three slots, adapted to low-wattage incandescents. I've plugged in three Hue bulbs I had sitting in a drawer, and tuned them to full intensity and color temperature as close to natural daylight as the bulbs can get. As a result, the lights almost always outshine the available daylight. I feel pretty comfortable with this temperature and intensity. Plus, my eyestrain reduced a bit, as the difference between room lightning and computer screen brightness isn't that big anymore.

On evenings, my color filters kick in on the screens, and I either kill two of the three bulbs, or bring their color temperature down.


Happy experimenting after the move then, I hope it works out!


If I may quote some motherfucker on the web:

And no, you don't have to fucking love all my shit

The background colour's the 2nd CSS rule (followed immediately by text). If I were to redo the page, I'd have a media query for colour depth and set those to #fff and #000 respectively for B&W screens anyway.


Love it. Would you mind putting it on Github and making the licence MIT so that I can use it and link back to you? I really like it, makes it so easy to read. Big like for the nice transition on hovering links as well.


Consider it MIT / BSD 2-phrase or more permissive.

(I don't have the login handy for that CodePen account presently.)


thank you!


I think that is very good (even though they say it is satire, it is good). (The end user should apply their own CSS if wanted; my idea of "meta-CSS" (not implemented or even properly defined yet) would allow the end user to conditionally apply CSS, so that for example it will only apply to those that don't have their own CSS (or whatever other criteria you might want); meta-CSS would also be the way for the user to configure media queries such as dark mode preference, etc.)

For some web pages, deleting the CSS can help, sometimes not. Perhaps the way to go about such a thing is to consider mainly HTML, also considering CSS and ARIA to fix the layout (some web pages have forms that don't work correctly when CSS is disabled, but I have seen them have ARIA; an implementation could use ARIA to fix up any forms that are broken by doing so). So, while the CSS can be deleted, it still might need to consider it for some purposes, such as checking if something should be removed or formatted differently (e.g. emphasis, fixpitch, etc; HTML can specify such things too but it is not always done properly).

(That web page does have Google Analytics, with the comment "yes, I know...wanna fight about it?" preceding it, but you can just disable JavaScripts to avoid it.)


> (The end user should apply their own CSS if wanted;

I still remember the time when user styles were a first class feature built into all browsers. Hell, that 'C' in CSS - "Cascading" - was always there to allow styles to enhance/override prior styles, including allowing the user to override website's styling. Back before web designers ruined everything by making every web page into its own special snowflake, people thought users would have one or two default CSS sheets to choose from and apply to any webpage, the way we today think about "dark mode".

These days, we have to resort to using browser extensions. A well-known one is Stylus [0][1]. In a way, it's much better than old built-in user styles. But then, it's not built in. Still, it's a nice way to fix up some of the frequently visited websites.

--

[0] - https://github.com/openstyles/stylus

[1] - Mind the name, it's "Stylus", not "Stylish" - the latter used to be popular, but then it sold out and become another peace of surveillance capitalism detritus. Stylus is a GPLv3 fork of Stylish with data collection removed.


userChrome.css and userContent.css still work just fine in Firefox (though you have to enable toolkit.legacyUserProfileCustomizations.stylesheets in about:config first). I'm using them to (re-)style both the Firefox UI as well as some specific sites.


> It's proof that Web design isn't the solution, Web design is the problem.

This is only true when your Web activity is limited to reading a static page of text, which is only one of many (albeit more common) use cases for the web.

I love reader mode too but the assertion that web design is never a solution to a problem is silly. Am I supposed to turn on reader mode on YouTube, Codepen, AudioNodes, an interactive tutorial, or a captivating experience website on Awaards.com? The modern web is so much more than text now.

Nonetheless, I agree... Most articles I read from HN would be intolerable or literally unusable without reader mode.


How can I implement my website such that it is optimally useful for browsers like this? Just avoid flashy stuff? Is there any way to list my blog somewhere as a friendly place to read? I'm spinning it up again after a year off for reasons that I will probably write about :)


I've just poked through both the GetPocket site (https://getpocket.com/publisher/) and Mozilla's Readability Library GitHub page (https://github.com/mozilla/readability) without seeing obvious guidelines.

My general suspicion is that adhering to a simple HTML5 documemnt structure, and possible use of microformats (https://microformats.io/) goes a long way.

Update: there's some discussion here: https://news.ycombinator.com/item?id=28301113


I haven't seen guidelines lately, but Readability.com, before it was shut down, did have a page that's archived here: http://web.archive.org/web/20160301180825/https://readabilit...


Thanks, yes I remember that page.


Adhere to the actual semantic meaning of HTML5 tags and browsers will handle the rest - honestly. So long as you're not using JS to swap in hidden content and CSS to arbitrarily reorder content flow then even aria hints are pretty unnecessary - but adding the relevant aria attributes will make sure that screen readers have an easier time.

Not abusing the tags solves pretty much everything at this point because the browsers can't trust anyone. Just read up on HTML5 and how tags should be used... then follow that.


For writers, that is a good idea (although I think there are a few things missing from most implementations, such as foot notes, and a table of contents window; I do have the idea of a "feature" attribute to handle such things, but it is not implemented either (although using it is harmless, since unrecognized attributes in HTML will be ignored)). CSS should mostly be not needed.

For readers, it will be necessary to fix the implementation to do the working better, since not everyone will write it properly.


I recently worked on implementing readability in my app and here's the resources I found most useful:

A very long read but this covers everything:

> How to Section Your HTML

https://css-tricks.com/how-to-section-your-html/

These are specifically important for accessibility users.

Another short read:

> HTML5 sectioning elements, headings, and document outlines

https://www.456bereastreet.com/archive/201103/html5_sectioni...

And you can use Markup Validation Service to validate and get tips:

https://validator.w3.org/#validate_by_input+with_options

Check out the excellent answer by Christian Kohlschütter on how readability works:

https://stackoverflow.com/questions/3652657/what-algorithm-d...


Thank you so much. I have been looking for a good browser for E-Ink devices for years.

I'll also take the opportunity to mention that AnkiDroid works perfectly fine on E-Ink devices such as Nook. You don't even need root anymore, just install a launcher via ADB. I literally spend an hour every day on my Nook with AnkiDroid.


Thanks for linking that, I'm going to try it on my reader when I get home. I like my boox for most things I try to use it for, but right now the pain point is all the royalroad webnovels I'm addicted to.


I have both Mozilla Pocket and EInkBro on the BOOX.

My preference is to read in EInkBro.

Pocket's craptastic pagination is endless frustration.

(I still use Pocket to save/tag content. But for what's supposed to be an enhanced readability tool, it's increasingly insufficient.)


I'm guessing this won't work with Remarkable.

Or what are some good e-ink devices for this I wonder?


Depending on how far you want to go, there are VNC clients[1], toltec has opkg-installable stuff including at least one browser[2] known to work, and there are full OS replacements that let you run a full linux GUI[3] which can almost certainly run a normal-ish desktop browser.

So while this one won't work, there are options.

[1] https://github.com/reHackable/awesome-reMarkable [2] https://toltec-dev.org/ [3] http://www.davisr.me/projects/parabola-rm/


Any Android-based device.

Potentially in future, Linux-based devices which can run Android apps.

I'm not a particular fan of Android. Its application ecosystem is a bonus though.

Again, this is installable through F-Droid.


Checking installing on an older tablet: EInkBro works, though having it display colour is ... slightly disconcerting.

But if you want to get a sense of the app, it's possible to do so.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: