Cigar Aficionado is a magazine for cigar lovers and aims for the upscale market. The website (www.cigaraficionado.com) comes off a little shaky, IMHO. Not sure if their CMS software is to blame (Vignette 6) or their developers (the js seems pretty fugly with three functions to read a cookie — getCookie, getCookie2, readCookie — checks for cookie names which don’t exist, js code for 2005 christmas popups still in place, etc.).
The issue I’m having is that a single page will not load, it sends me to the “Access Denied” page. So, I did what I rarely do, and contacted them about their site issues. I received an email back telling me it was probably a cookie issue and to clear my browser’s cookies. Being the anal retentive person that I am, I had already cleared my cookies, my cache, manually deleted cookies, attempted to login on different browsers, under different profiles on one machine and on three different machines. I like to check things like that before I raise a red flag and then look like an idiot when I just needed to clear my cookies. Then they sent me links to pages on their site to clear my cookies and perform a cookie writing/reading test. I passed! Woo! That was the last I heard from their customer support.
A few days later (a week?), assuming my issue had been ignored, I contacted them again via their forums. Surprisingly, I immediately received a reply from an editor. Soon after that I received an email from the same person in customer support who I had interfaced with previously. The developer geek in me came out. I ensured the problem existed on multiple computers, profiles and browsers, created a quick script to do some cookie read/write tests, logged cookie additions across requests, took screen shots, and sent them off the information along with details on how to recreate my issue. I hate javascript, but I take pleasure in getting it to work.
One of their developers contacts me regarding doing a Copilot session. I wanted to check out Fog Creek’s Copilot anyways, so off we went. Turns out Copilot is useless over a high-latency, low-bandwidth satellite connection. Said developer was disconnected (disconnects?) and informs me that he really couldn’t do much because Copilot was unresponsive. That was it. No next steps, no follow up. I have no idea if anything else is being done on my issue, my follow up emails/questions haven’t yet been answered.
So I dug some more and analyzed the request/response information and it turns out the single page that I’m having issues with is returning a 301 status code. I’m not sure why their server would be returning a 301, but it would explain my issue. I’ve asked them to analyze their Apache logs.
From a customer support perspective (which I get stuck doing on occasions remotely supporting my web application) I guess the takeaways (the things that annoyed me) are:
- Be responsive. Let the user know you’re working on their issue. Don’t leave them in limbo for days or weeks as to the status of their support request.
- Ask the user to do some troubleshooting for you. While most users are idiots, the ones who aren’t idiots get annoyed when you assume they are idiots and treat them like idiots. In other words, assume the best about the end user and not the worst.
- For tricky issues, have a customer support representative coordinate the communications, but get a developer on board immediately. It will probably save time and frustration in the end.
My wife thinks I’m an idiot for spending my free hours diagnosing this stuff (”let them fix their own website”), but I’m a geek and I like it. It’s what made me an Experts-Exchange Master. (Even I draw the line at becoming a Guru.)
UPDATE: 11-NOV-2007
They asked if I could get a better network connection so they could see about checking for an error from me. If only. If only.
I replied that I had sent cookies and HTTP header information and asked what other information they were looking for.
Their response was that no one else was having these problems, so the thing to do would be to test my machine. There is nothing alarming on their servers.
I don’t know what other machine testing I can do, but some specific “we’re looking for x,y,z” would be helpful. My non-specific requests for “what information are you looking for” were never answered so I asked them to specifically tell me what data they’re trying to gather and what tests they want to run to gather it, and I’ll do my best to do it.
Personally I think their server is issuing a 301 (perm redirect) when the restricted page is accessed without being logged in. Really a 307 (temp redirect) would be more appropriate. Somewhere along the line that “access denied” URL is being cached and returned (as expected according to the HTTP 1.1 specs) instead of the page that I want. This is supported by being able to access the page via a secured connection (SSL requests are not cached IIRC) and being able to access the page if I append a useless query string
to the URL (new non-cached request). We’ll see where this leads.
UPDATE: 13-DEC-2007
I had a phone troubleshooting session with one of their developers. It was more disturbing than helpful, but I appreciate the effort they went through. The end result was nothing has changed although I got some additional insight into their coding practices — which I emailed the editor, David Savona, about and will follow-up with another blog post when I get some time.