"We cannot accomodate with plan[sic] text"? It's the simple version. It's standard. What are they, a garage operation using webmail to handle customer service? Maybe I shouldn't trust them to reliably provide my dial tone after all. Sodding amateurs.
I complained about part of their web site being broken. They responded with a mostly-canned message full of weaselwords and marketing speak, in a [expletive]ing PITA to read format. At the start of my reply to their response, where I called them out on the weaseling (for one thing, don't say you did things a certain way "to provide an enhanced experience" if there's NO EVIDENCE THAT IT ENHANCES ANYTHING -- if you don't give me a reason to believe that the thing that breaks in my browers is actually an enhancement, I'm going to hear that as placebo buzzwords and be offended), I requested that further email be sent in plaintext.
Apparently they're so newfangled that they can't send plaintext, but not so newfangled that they have a spellchecker. Or perhaps what they write is just as hard to read on their own screen as it is on mine?
<HTML>Dear Memer,<BR><BR>Thank you for your recent e-mail regarding The Talk Ame ricaá Local and Long Distance Service.<BR><BR>If you have difficulty with our e- mail or are unable to use an alternate MUA, we recommend that you correspond via telephone or U.S. mail as we cannot accomodate with plan text.<BR><BR>If you ha ve any additional questions, please visit us online at www.talk.com. You can als o call us toll free at 1-877-536-7968.<BR><BR>Our hours are:<BR> <BR>Weekdays:< BR>Eastern 7 A.M. - 6 P.M.<BR>Central 6 A.M. - 6 P.M.<BR>Mountain 5 A.M. - 6 P.M.<BR>Pacific 4 A.M. - 5 P.M. <BR> <BR>Saturday:<BR>8 A.M. - 5 P.M. Eastern Standard Time <BR> <BR>Sunday:<BR>Closed<BR> <BR>Talk America, We Put Customers First.<BR><BR>Sincerely,<BR><BR>Talk America<BR>Customer Care<BR>< BR><BR><BR><BR><BR>Date: Mon, 8 Nov 2004 21:30:00 -0500 (EST)<BR>From: "D. Glenn Arthur Jr." <dglenn@radix.net><BR>To: cs@talk.com<BR><BR>Please send me mail in plaintext, as is the standard for email<BR>acc! ording to the relevant RFCs, not in poorly formatted HTML.<BR><BR>At the very l east, please insert actual carriage returns into<BR>the code after the BR tags t o make it easier for someone using<BR>a plaintext MUA to read. (Yes, I am aware [...]
I'm not getting warm fuzzies here. I'm having serious second thoughts about having switched my dial tone to TalkAmerica. Unless I get clues that they know their asses from their elbows, I'm certainly not going to suggest that anybody else use them.
(They also gave me a "tell the customer what he wants to hear" answer instead of the truth (which was probably "we don't know") when I was first signing up, when I asked whether their "turbo Internet" access worked with Linux. Once the CD arrived and I saw that it had only Windows files on it, I called and asked, and they explained that no, there was no Linux version, but that Linux is "so much faster" than Windows that I should see the same speedup anyhow. (Okay, Linux is faster than Windows ... I'll buy that, especially since I'm not running an X server on most of my Linux machines -- and certainly not on the box with the modem attached. But 500% faster at serial I/O than a Windows box? Windows really can't keep a 56K modem busy?) Uh, riiight ... But if I'm already using Linux to connect to a different provider and the speedup I'll see is because I'm using Linux, won't I see the same speed that I already get with my old provider? Fortunately I wasn't expecting actual results from that "feature" but took the freebie as an experiment.)
They've earned a public mocking. Plaintext is easy, and they're a $%*#ing telecommunications company. They can write RFC-compliant email if they want a shred of cred with a techie. I don't like being lied to (even in a "say yes instead of 'I don't know'" manner), and I really don't like being told to "just get a different MUA" because somebody else can't be bothered to send plaintext. There are reasons I use the mail client I use.
(And yes, I'm aware the HTML could have been worse -- it could have been that abominable Microsoft cruft with a separate <DIV> tag for each line and gratuitous font-change commands that wind up not doing anything. Small favours and all that...)
(no subject)
(no subject)
Contemplating appropriate rewrites, but still uncertain.
Res Ipso Loquitor
Re: Res Ipso Loquitor
Re: Res Ipso Loquitor
I dunno, I don't think I'd trust a company whose form letters weren't even spell-checked. Ugh.
(no subject)
(no subject)
Windows unable to keep a 56K modem busy?
on TV for $369). It only runs Windows 98. And we'll make the modem a Winmodem
(CPU does all the DSP). Tip in a really inefficient, top-heavy web browser (IE, since
it comes with W98). And a stripped-down frame-buffer style graphics card (hey,
you don't get a $400 GeForce card in a $369 computer). Slow dynamic RAM, with
CPU refresh. 50MHz frontside bus. 13 clocks/instruction, average. A very register-
poor CPU. You know, it's quite possible that a brand-new Dell computer would, in
fact, be unable to max out a 56K modem.
Re: Windows unable to keep a 56K modem busy?
I wonder what their "turbo Internet" software actually does, and whether it has any effect if there's a real modem instead of a Winmodem.
Re: Windows unable to keep a 56K modem busy?
part of the IP stack, b) caching, and c) compression. There could also be
static content (known ads, backgrounds, scripts, etc.) that is accessed
locally instead of fetched over the modem, and perhaps some sort of
filtering. Also, there could be some user experience management going
on, where it loads the stuff you can see, and gets the rest of it while
you're reading the first part (something real browsers have been doing
for a long time).
Re: Windows unable to keep a 56K modem busy?