|
|
|
|
$200 Leica BP-SCL6 Lithium-Ion Battery (8.4V, 2200mAh) BACK IN STOCK in Accessories: Batteries and Power
|
|
An Experience With Software Technical Support
I was so incensed by a September 2006 experience with Macromedia Dreamweaver technical support that I decided to record it in all its amusing glory.
The preparation of pages for diglloyd.com is done using Macromedia DreamWeaver 8 on Mac OS X (newest version is now used in 2010). It is a full-featured software package, but rife with bugs. On of the worst bugs causes a blank display as shown below, making it impossible to edit the page (Digital Infrared) except as source code.
The markup validates, and web browsers render it properly. My Digital Infrared article is one page that is having this problem; scroll down about 3/4 of the way in DreamWeaver 8 and it starts drawing a blank or partial page. Other pages manifest the same symptoms.
NOTE: this was the situation when this article was written, but the pages might have changed since then.
Glossary
FUD — Fear, Uncertainty, Doubt.
The first response (Sept 7 2006)
Thank you for writing to Adobe Technical Support. I understand that you're having an issue rendering your page in Dreamweaver 8.
I've checked on your code using your page on the web site and when I ran a validation test (Window > Result > Validation), I noticed that there are some errors on your page.
When I loaded your page in Dreamweaver using Windows, it renders fine there. However, when I loaded your page using Macintosh, I got the same result as yours. The workaround that I did to load up your page entirely in Macintosh is to set the magnification (Zoom tool) to 99% instead of 100%.
FUD
I've checked on your code using your page on the web site and when I ran a validation test (Window > Result > Validation), I noticed that there are some errors on your page.
So I fixed the page so that it validated with zero (0) validation errors using XHTML 1.0 transitional. But the page still won’t draw correctly in DreamWeaver. And it’s DreamWeaver itself which inserts some of these attributes when you use its Properties window (eg <table bordercolor="#808080">). In other words, I used their crappy program, and it complains about its own bugs.
Works on Windows
When I loaded your page in Dreamweaver using Windows, it renders fine there. However, when I loaded your page using Macintosh, I got the same result as yours. The workaround that I did to load up your page entirely in Macintosh is to set the magnification (Zoom tool) to 99% instead of 100%.
The problem doesn’t occur in the Windows version. So obviously the Mac version has a bug.
A suggested work-around
The suggestion is to use a View of 99%. There’s only one problem—the menu doesn’t offer a “99%” view:
and offer only coarse control, and all magnifications offer very poor display quality. Here is an example:
The second response
Later in the day, Macromedia support responded again. This time, the response really managed to combine FUD, a useless suggestion, and arrogance in one package.
Did you use Dreamweaver 8 to create this page?
Please enter 99% on the selection and press return to set the magnification to 99%.
This is just a rendering issue in Dreamweaver 8 and this was not filed as a bug. I noticed that you have lots of images on this particular page and it's too long. The best practice with this is to sub-divide your page so that Dreamweaver can render this properly.
More FUD
Did you use Dreamweaver 8 to create this page?
Maybe it’s my fault that I didn’t create the page in DreamWeaver, even though it passes all XHTML 1.0 validation tests. Never mind that DreamWeaver is supposed to be a general-purpose editor for web pages. Still, I did create the page in DreamWeaver.
Tech support could just look at the code of the page and see that it’s basic XHTML; it’s not a big a file (56KB) and it obviously wasn’t created in Microsoft Word or some such program.
Please use a command that isn’t there:
Please enter 99% on the selection and press return to set the magnification to 99%.
Since I don’t see any “99%” choice in the View menu (or any “” choice that would allow me to type “99”, I was baffled by this suggestion.
High capacity, high-performance fault-tolerant storage for photography and video.
Non-RAID or RAID-0/1/4/5/10.
Capacities up to 72 Terabytes!
Not a bug
Next, I learned that this isn’t really a bug, and actually isn’t very important:
This is just a rendering issue in Dreamweaver 8 and this was not filed as a bug.
The Mac version fails, the Windows version works, but it’s not a bug. Go figure.
Other than making it impossible to edit my pages (except as raw code, which I can do without DreamWeaver), technical support is correct that it’s not very important—to Macromedia. If a blank page is not a bug, I don’t know what is. Does it have to crash or erase my hard disk to be a bug?
It’s really my own fault
I noticed that you have lots of images on this particular page and it's too long. The best practice with this is to sub-divide your page so that Dreamweaver can render this properly.
My page is too long, it was all my fault to begin for wanting to actually use their shitty software to make a real web page. I wonder why 5 or 6 other pages aren’t displaying correctly in Dreamweaver either—some of them much shorter. And it’s now become my problem to work around the bug in Dreamweaver.
Patient: “Doctor, it hurts when I do that!”
Doctor: “Don’t do that.”
I am not going to design my web pages to work around a bug in Dreamweaver. Oops—I forget—it’s not a bug.
I paid $400 for a general-purpose software program for editing web pages (Dreamweaver 4 MX), plus another $200 for an upgrade to Dreamweaver 8. That’s $600 into Macromedia coffers. I expect a more helpful response to a legitimate bug report that precludes using it on some pages.
The third response—referral to 2nd-level support
Thank you for writing back. I will forward all that we have discussed to a Senior Technical Support Engineer and they will be the one following up on this incident. We appreciate your patience regarding this matter.
The 2nd-level tech support response (Sept 8 2006)
The next day, 2nd-level technical support responded. This time, the response was what it should have been in the first place, but can be summarized as “ We acknowledge the bug, we’re working on it, here’s how to use our workaround”. Other positive aspects of the response:
- it was acknowledged as a bug, and a bug number was created for it;
- instructions were given as to where to input the “99%” view;
- no FUD was used;
- no suggestion that the page should have to be rewritten as multiple pages.
I reviewed the notes and exchange of emails that you had with the previous TechSupport Engineer handling this issue and found the issue that you have is related to how Dreamweaver 8 renders your page in Design view. You have mentioned in your email that on the Design view, only two thirds of the page appears on screen.
This has been reported to our developers and the bug ID for this is #201845. At present, we do not have an updater available to fix this issue but we do have a workaround which is to set the magnification from 100% to 99%. To do that, with your HTML page open, look at the bottom of the page and beside the Zoom tool is the magnification which at default is set to 100%. You can enter an arbitrary value and change that to 99% or 101%. The page will then refresh and you should now be able to view the whole content of the page.
I understand that this is inconvenient on your end but rest assured that our Developers are working on this. I hope that this information helps and should you have other questions, feel free to contact us again.
The workaround isn’t really acceptable, because the text becomes jagged and unattractive, so I hope this bug actually gets fixed. However, my experience with software companies is that any visual bugs usually get rather low priority.
Conclusions
Having personally done tech support for more than a year over the phone many years ago (DiskDoubler at my own company, Salient Software), I know the ins-and-outs of supporting sometimes clueless, sometimes frustrated, sometimes angry customers. But in the end, if the job is done right, those same customers go on to tell everyone they know how great it is to do business with you. Few companies these days seem to realize that good support is their absolute best use of marketing dollars—for that is what good support really is.
After spending $400 on Dreamweaver MX 4 and its $200 upgrade to Dreamweaver 8, a bug prevented use of the software for its intended purpose. First-level technical support suggested changing my web page to accommodate the software bug, trivialized the issue (“not a bug”), and in general sought every avenue to place blame other than where it belonged—in the software.
Sadly, Macromedia (now Adobe) is not the worst offender. I spent hours on the phone with Epson about 3 years ago—explaining their own driver software to first-level support. This is not to single these two companies out—I’ve had similar experiences elsewhere. My best experience in the past several years was with Apple Computer, which took my issue seriously right away (a hardware one of my own making).
This type of 1st-level “support” really is the bouncer at the door—the more customers that can be discouraged from seeking help the better, so as to minimize costs and/or to force customers into the paid support program. It’s the same immoral behavior that health care companies use to deny paying for claims. They do it because it works, plenty of people will give up or accept the lies fed to them.
Update: November 23, 2006, January 10, 2010. Absolutely nothing has happened. I have not been contacted, no bug fix is available, etc. This is what you can expect from most vendors—you are worth nothing to them except at software-upgrade time, where they’ll ply you with buggy, useless “improvements” for 50% of your original purchase price. This is the common industry practice.
Your smart move
Before purchasing software, make a tech support call (or email), and see what kind of response you get. If a demo version is available, you might try that, and probably even find a real bug.
See how the company responds:
- timeliness;
- accuracy;
- accepting responsibility;
- suggested workaround;
- expected fix date;
