Since you offered... I'm curious about the rendering technology behind it. I'm working on a web app with a spreadsheet interface, and I'm using a standard canvas-rendered grid.
You obviously have different design constraints, so it would be interesting to see how they shaped your solution.
Cool idea and onboarding experience. I spun up Chrome to demo it, and although its got the rough edges of a prototype, the potential is there.
I created a rule to remove thumbnails and shorts from YouTube, and after a few failed attempts, it succeeded! But there were massive tracts of empty space where the images were before. With polish and an accessible way to find and apply vetted addons so that you don't have to (fail at) making your own, I would consider using it.
My daily driver is Firefox, where I've set up custom uBlock Origin cosmetic rules to personalize YouTube by removing thumbnails, short, comments, images, grayscaling everything except the video, etc. My setup works great for me, but I can't easily share it with other people who would find it useful.
It works well and I like the overall design. Why'd you make it?
The default keyboard shortcuts are a little awkward; using tab or the up/down arrows to navigate the list would be more intuitive. Also, it would be easier to distinguish tabs if the title were displayed before the hostname.
It's really cool to see the applications made possible by the high quality, reasonably priced, and fairly licensed text-to-speech APIs offered by AWS, Azure, and Google Cloud.
The most fleshed out service of this type that I've found is narro.co, which offers web/pdf/epub/video/rss/email/text to audio conversions.
Keylogging is just the beginning. Any (and many) browser extensions have the ability to record everything you do on every page you visit. All it takes is specifying the <all_urls> permission in the extension’s manifest and adding some event listeners.
It has to work this way or browsers wouldn’t be truly extensible. Be mindful of which extensions you install.
Great work. It’s a pleasure to use. A few questions:
1. Have you heard of Narro (narro.co)? It does the same thing, but it’s been around longer and has many integrations.
2. Can you share the tech stack currently powering your voice synthesis? Since it’s called PollyPodcast, are you currently using AWS Polly for TTS?
3. Is this something you intend to monetize?
4. It seems like you offer unlimited readings for free. Do you have an abuse prevention strategy? This could become a hole in your wallet if you’re paying for a charged-per-character TTS service.
5. Creating custom voices is a great differentiator. What are some problems you have to solve to create them and how is this effort progressing? Do you have quality and performance goals?
I wonder if it will be possible to load scripts into the reader view document. Currently, it isn’t, so keybinding extensions, which rely on inserting Keyboard event listeners, don’t work in reader view. I had been prototyping a custom reader view in Saka Key using Mozilla’s Readability library to work around this issue.
The Content Security Policy fix is a lifesaver. Saka Key attaches hint elements to the DOM and attaches a script tag to load common styles/fonts. Sites with the policy style-src: self (like crates.io) block script tags, which breaks hint styling and positioning.
This is unfortunately true, though it doesn’t have to be. The problem with webapps generated with JavaScript is that it’s tempting to create a custom implementation of built-in functionality. Good old anchor tags are “visible” to screen readers that visually impaired people use to browse the web. Chances are your JavaScript Link hack isn’t because you forgot to include the role=“link” attribute. Keybinding extensions are similarly blind when developers write inaccessible markup.
The solution is for developers to spend a day learning about accessibility. A good starting point is https://webaim.org/intro/.
An extension overlay API would have saved me so much pain when building Saka (saka.io). There are two options for injecting UI today:
1. Inject UI directly into the document
2. Inject an iframe containing the UI into the document
Both rely on manipulating the document, which can be used to fingerprint users. Most developers opt for 1 because it requires no setup and lets the content script synchronously access the UI. 2 is needed when the injected UI containing sensitive information.
I'd like an extension overlay API that lets you inject:
1. UI local to the tab
2. UI that persists across all tabs
In a brief #webextensions IRC discussion, I was told an overlay API isn't viable for a number of reasons, one of which is multiple extensions may conflict.
Just wanted to mention, one of the unique features of Saka Key is that it lets you define keybinding profiles that are easy to switch between, and there are multiple profiles built in, including one that mimics Vimium.
The address bar autofocusing is annoying. Best advice I have is to replace your new tab page with a URL or a custom new tab extension.
Also, I devised the default keybindings with three goals in mind.
1. Common keys should be easy to reach.
2. Users unintentionally trigger dangerous commands (like close the current tab). To prevent this, I bind dangerous commands to 2 key sequences.
3. Users not being able to remember keybindings. To help users remember, I try to associate commands with an intuitive key, e.g. Zooming is mapped to z.
I think site-specific keyboard shortcuts are great. Do you have plans to release the source code? My chrome extension Saka Key [1] provides generic keyboard shortcuts, but my vision is to eventually integrate with other extensions like yours and Streamkeys [2].
I have an obfuscated closed-source extension that I accidentally released with source maps in early versions. Guess I'll have to be more careful next time.
Thanks! I was very surprised a half-decent in-window tab search extension didn't already exist. They all opened in the popup or a new window. So I made one myself.
My goal is to make a complete Omnibar/tabs replacement so I can browse in full-screen mode by default.
I've been building a keybinding Chrome extension like Vimium for about half a year now. It started when I struggled to add a feature to Vimium and figured I could do it better myself.
From my biased perspective, my extension is better. User uptake has been negligible, but I think the lessons I've learned have made it worth the time invested.
For my extension Saka Key (https://github.com/lusakasa/saka-key), I decided to use the browser.* APIs on both Chrome and Firefox using Mozilla's web extensions polyfill.
https://github.com/eejdoowad