IIRC "The Design of Everyday Things" makes a point that most devices have poorly explained errors (beeps, error codes etc) because nobody chooses what to buy based on how it acts when it's failing, so there's no incentive to spend money on it. For hardware, the cost is quite literal, as having a better display just to show error messages is a lot more expensive than a beeper.
With software, it's probably a matter of prioritization, why invest into explaining errors when you can work on preventing them? Not that this error prevention always works out, but still.
> But because neither audio server is interested in implementing functions for embedded displays, neither power supply daemon is interested in implementing audio routing, encoding, decoding and playing functionality, neither input layer software is going to process battery and power relayed functionality and also it is not up to the modem software to register input devices into kernel and process button press events, the only reasonable solution for this problem is to provide another software which would own HSP/HFP AT modem connection for remote Bluetooth devices and would forward commands, signals and requests
to appropriate application.
> The email client strips out the text/x-amp-html part of the MIME tree when a user replies to or forwards an AMP email message. This is why it is important that an email provide alternative content in the HTML part.
They can only hit a JSON endpoint in the same DNS zone (eTLD+1) as the sender's email, e.g. if the email is from [email protected], it can only hit endpoints on example.com and its subdomains.
Open in what sense? For example, there's no open standard (to the best of my knowledge) for the HTML used in emails right now and different email clients render HTML in emails differently.
On the other hand, the protocol itself is standardized, but AMP is not working on protocol level.
Regardless of whether you like the keyboard or not (or have no opinion), I strongly recommend you check out their blog: https://ultimatehackingkeyboard.com/blog
They gave a very thorough overview of the (many, many) challenges involved with "kickstarting" a hardware product - and how they overcame them (from issues with banks to FFC and CE certification). It's a great source of knowledge for anyone who considers doing the same.
I've been using it for a few months now. I didn't know how to touch-type before it arrived and I forced myself to learn. Without that, this keyboard is not very useful.
That said, after learning to touch type, I found some layout decisions surprisingly intuitive.
Most notably, it turned out that having arrow keys on my home row is a great idea. Only after I got used to that did I realize how annoying it is to leave the home row on a normal keyboard.
Still not sold on escape and fn keys. I believe that it would've been better if had an extra row for those, but I might learn to appreciate that too in the future.