4 ms·

I've tried Beeline multiple times and I every time I come out with varying experiences. For example it's pretty much useless for reading code stuff as it colors

I've tried Beeline multiple times and I every time I come out with varying experiences. For example it's pretty much useless for reading code stuff as it colors in code blocks with no way to disable that. Also I'm certain it actually makes well formatted text harder to read. As in 60-70 character lines with healthy paragraphing and imagery. I'm kinda perplexed that they are charging 2$/month for this extension when it could be replicated in javascript bookmarklet or grease monkey script. All it does is blindly apply gradient to text. Not a fan of accessibility innovations like this being made propriatory like this either.

gnicholas 6y ago
You're right about code blocks! We offer a domain blacklist feature so that folks can prevent it from running on sites they read that have a lot of code, and we are working on a smarter way to detect code blocks and not color them. If you're certain that BeeLine "makes well formatted text harder to read", then I'm pretty sure we're not for you! I'd be curious to know where you find it helpful? Just for text that is displayed too densely? We're doing a bit more than blindly applying gradients to text! The first thing to figure out is where the body text is on a page. It's not easy to avoid overcoloring (accidentally coloring captions or text that is on a different-colored background) and undercoloring (not coloring all of the main blocks of text). It's easy to do these tasks on a handful of websites, but it's hard to come up with algorithms that work across the entire internet (in many languages). But yes, what we do is something that is proprietary, and that makes it different than some accessibility techniques. There are other aspects of accessibility that are proprietary, for example high-quality TTS voices like Amazon Polly. But my goal is to have the technique that I invented, tested, and refined adopted into products so that users do not have to pay for plugins and such. There's good progress on this front, with major e-textbook platforms and big newspapers looking to integrate the tech. Once we get a couple of these larger licensees on board, there's a good chance we'll make the consumer tools free for individuals.
- kabacha 6y ago
  sorry to put you on the spot but what makes it difficult to simply ignore `\<pre>` blocks? As to answer your question - beeline is great for _badly_ formatted texts. Many articles are in whooping 120 character long lines or absurdly long, bland paragraphs. In those cases the benefit of beeline is definitely noticable! Finally for technical bits, it seems that that beeline extension colors each letter individually, however modern css already offers horizontal gradient[1] which might be prettier and somewhat preserve the original document better. https://stackoverflow.com/questions/39884260 https://stackoverflow.com/questions/39884260
  - gnicholas 6y ago
    Thanks for the advice! The last item is the most important I think, and the reason we didn't originally do this is because the plugin has been cross-platform since launch in 2013. I believe at that time the CSS technique only worked on certain browsers. We have been talking about updating the coloring technique to use CSS, but it hasn't been a top priority compared to everything else we've been doing (both on the browser plugin and on the rest of the business). I'm going to talk with the team about your suggestion regarding \<pre> blocks. We're early in the process of addressing this issue, which has come up recently. Hope it's a quick fix!

gnicholas 6y ago

You're right about code blocks! We offer a domain blacklist feature so that folks can prevent it from running on sites they read that have a lot of code, and we are working on a smarter way to detect code blocks and not color them. If you're certain that BeeLine "makes well formatted text harder to read", then I'm pretty sure we're not for you! I'd be curious to know where you find it helpful? Just for text that is displayed too densely? We're doing a bit more than blindly applying gradients to text! The first thing to figure out is where the body text is on a page. It's not easy to avoid overcoloring (accidentally coloring captions or text that is on a different-colored background) and undercoloring (not coloring all of the main blocks of text). It's easy to do these tasks on a handful of websites, but it's hard to come up with algorithms that work across the entire internet (in many languages). But yes, what we do is something that is proprietary, and that makes it different than some accessibility techniques. There are other aspects of accessibility that are proprietary, for example high-quality TTS voices like Amazon Polly. But my goal is to have the technique that I invented, tested, and refined adopted into products so that users do not have to pay for plugins and such. There's good progress on this front, with major e-textbook platforms and big newspapers looking to integrate the tech. Once we get a couple of these larger licensees on board, there's a good chance we'll make the consumer tools free for individuals.

kabacha 6y ago
sorry to put you on the spot but what makes it difficult to simply ignore `\<pre>` blocks? As to answer your question - beeline is great for _badly_ formatted texts. Many articles are in whooping 120 character long lines or absurdly long, bland paragraphs. In those cases the benefit of beeline is definitely noticable! Finally for technical bits, it seems that that beeline extension colors each letter individually, however modern css already offers horizontal gradient[1] which might be prettier and somewhat preserve the original document better. https://stackoverflow.com/questions/39884260 https://stackoverflow.com/questions/39884260
- gnicholas 6y ago
  Thanks for the advice! The last item is the most important I think, and the reason we didn't originally do this is because the plugin has been cross-platform since launch in 2013. I believe at that time the CSS technique only worked on certain browsers. We have been talking about updating the coloring technique to use CSS, but it hasn't been a top priority compared to everything else we've been doing (both on the browser plugin and on the rest of the business). I'm going to talk with the team about your suggestion regarding \<pre> blocks. We're early in the process of addressing this issue, which has come up recently. Hope it's a quick fix!