By "actual code" I meant the assembly that the application logic compiles down to, not the entire executable. But as far as the entire package goes, compiling it using clang with some flags I can get down to 19.5k without any effort. If I wanted to waste time on this, ripping out the CRT entirely and getting it to 16k would probably take less than an hour.
Yes, it is technically possible, but it is occult knowledge. I don't know how. I know the one Kindle with ads I had, they somehow disappeared and never returned after I reset it, possibly because I did not connect it to any Amazon account or Wifi. You won't get any help with that aspect from any mainstream Kindle jailbreak devs or on MobileRead, as they follow a general policy of live and let live with Amazon. They don't get DMCAs on jailbreaks, they don't help people "pirate".
They don't do that anymore, at least not for me. I tried contacting two different support agents and both mentioned that the functionality has been removed for them by the higher-ups.
Aside from having to have something to parse out the submission as the response isn’t that human readable, I think the biggest problem is that users need a mail client and requires them to hit send. This disorients people so even if they have a mail client, you end up with people not hitting submit.
There’s also the bigger issue your directly exposing an email address to web scrapers like it’s not the 90s using mailto forms is a shocking take as acceptable
This isn’t really a concern for me. I’ve had my gmail exposed to web scrapers for decades without making me regret it.
For this purpose though it’s a non-issue as I also have a contact email published on my site so people can email me. And I would create a separate mailbox just for the form.
I’m not sure why people are concerned about their email being scraped as it’s comical that any email address isn’t already on a million spam lists.
You can. It is actually relatively hard to do though unless you are extremely motivated.
Where you have to find a setting in mac / windows as well as configure your browser (chrome) for it, by using an obscure icon in the address bar etc.. and then you can have some apps fighting for you to change the setting. And then it depends on which browser profile is currently active. It is pretty messy to say the least
1. For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem. From Windows or Mac, this FTP account could be accessed through built-in software.
2. It doesn't actually replace a USB drive. Most people I know e-mail files to themselves or host them somewhere online to be able to perform presentations, but they still carry a USB drive in case there are connectivity problems. This does not solve the connectivity issue.
3. It does not seem very "viral" or income-generating. I know this is premature at this point, but without charging users for the service, is it reasonable to expect to make money off of this?
I don't understand why people don't understand why making users do this weird shit (and yes, mailto: is weird although not as weird as SVN/CVS vs Dropbox) isn't going to work.
I would guess that mailto will be great for deliverability. Since the user has already emailed you before your emails are more likely to go through to them and not get filtered as spam or promotion.
I think if my mom was trying to submit a form, and it opened her email client with a body consisting of URL encoded data she’d probably just close the email client thinking that something went wrong. Then she’d try again and the same thing would happen again. Then she might call me, and I’d probably tell her to just forget about it and try to call them on the phone instead or give up and try another company instead.
The e-mail client decodes the URL encoded data. So you actually see plain text. The encoding is only done for the purpose of passing the data from the browser to the e-mail client.
I created a form with a dropdown and a some other inputs.
The result when using enctype=application/x-www-form-urlencoded and method=post in the form html is that the body that is shown in my email client is URL encoded.
They have a different enc type that you could use to specifically make it plain text. That one is not recommended because then you're gonna have a bad time parsing out the fields that were submitted from the form.
One variant that seemed interesting was method=get with enctype=application/x-www-form-urlencoded
In this case the values from the form get added as headers in the email so they are not directly visible to the user
I thought that I could still add user-visible subject and body by adding ?subject=foo&body=bar to the mailto: url
For example I could then have the subject say "Web form submission", and have the body of the mail contain a description that tells the user to send the email and that the data they filled into the form will be sent along with the email.
Even that is not great UX imo, but could still be interesting.
However from my testing with Brave web browser and Apple Mail, the subject and body are not filled in for the user in this case.
You see that in the "email" forms of for example most "contact" sites.
Like, for example, here on HN, in the right end of the site's footer (on desktop), by clicking "Contact" (but this isn't a form, just a "mailto:..." link).
Sadly the best way to use this stopped working years ago. I vaguely recall in some browsers (maybe IE6 or earlier?) it actually send the submission to email directly without opening the user's email program at all.
Having to send an email with the fields prepopulated feels rather archaic by comparison, and leaves me using form scripts as a rule now.
> An Impressum is a statement of ownership and authorship for online and print media. An Impressum helps combat spam and disinformation by holding creators responsible for their content. An Impressum is legally required for commercial sites operating in Germany, Austria, and Switzerland.
If I hit "submit" on a form and I saw it start to open a new Gmail tab in my browser, I'm going to close the new Gmail tab before it even has time to finish loading. (Or same if I saw it opening Mail.app.)
I'd just assume the site was trying to trigger some kind of spam e-mail or something.
The idea that I'd fill out a form on a site, then submitting it would open my mail program, and I'd then have to hit send there, and then close my mail tab/window (not to mention exposing my e-mail address to the site when maybe I wouldn't want to), is some of the worst UX I've ever heard of.
I have a Pavlovian annoyance response to noticing that I have inadvertently clicked a mailto link, because back in ~2005 firefox would try to start Evolution. I usually only noticed the click because of the sound of my spinning disk thrashing to try to lift into memory hundreds of MB of dependencies from their rust platter slumber. Evolution generally didn't even load enough to so much as show its splash screen before I found a terminal and killed the process tree.
I believe the last time I've sent an e-mail was in July 2017, when I was finishing my Master degree thesis, and I was glad I'd probably never have to do it again. Please don't ruin my dream?
that email from 2017 will still be in that sent folder, waiting for you, readable and accessible on all possible platforms and form factors, when all the latest owners of the slacks, teams, whatsapps and telegrams of the world ratshit onto their users into oblivion. Ask the ex-twitterati.
Genuinely curious: what is so bad about writing an email? Do you really prefer/expect that every interaction with someone online is better to be had via an app or automated form?
Easily yes. Especially when you interact with companies the email is just a shitty gateway to their actual CRM/Ticketing Software.
Ignoring the general shittyness of email itself being plaintext or bastardized html that's destroyed the moment someone replies -- Different reply and quoting styles, emails |||||||| of every previous email in the thread. A haphazard mix of fonts, font sizes depending on the client, obnoxious signatures on every message. No one understands threads where threads in chat are immediately groked.
Ignoring all that. Unsolicited communication mediums can go die in the hell from whence they came. All communication that allows someone to message me without asking, where new identities can be minted like candy so they're impossible to block permanently. Awful. My inbox is just for password resets and spam now. Same with SMS, it's the messaging of last resort.
Being able to close your DMs to just actual humans you want to talk to is goated. Email, SMS, and my mailbox are just junk drawers ever since the marketing people got ahold of them.
While a good rant is always appreciated, I don't see how forcing people to install an app or having an online form (which will very probably ask for your email anyway) is any better. And to avoid abuse, email masking services work quite well.
It's just funny that with Communick I have a whole Discourse site setup because I was anticipating people weary of giving out email addresses, but in the end the majority of my customers just prefer to solve issues by email.
One could dream of a world where XMPP is relevant and that most clients support its HTML submission capabilities, but this is also not the timeline we're in.
