So, something isn’t working on your website, and you need an expert to tell you what’s wrong. To get the best support possible, you need to allow them to view your website so they can investigate.
I frequently receive support requests from customers asking me to diagnose issues based on just a description or a screenshot. As someone who deals with troubleshooting customer site issues a lot, I can tell you that access to the site itself is almost always a prerequisite to providing assistance. While it seems obvious to a developer that this is a necessity, it doesn’t occur to some customers, so I thought I’d explain why access to the actual site is so critical when troubleshooting.
Vague symptom reports and screenshots don’t tell the whole story
Unfortunately, customer reports of site issues are rarely reliable, simply due to lack of expertise. Just like I can’t give a mechanic a useful diagnosis of issues with my carburetor, non-developer analyses of website issues are similarly unhelpful (or at least incomplete) for troubleshooting the problem (customers with the skills to provide a complete analysis have already solved their own problem in 99% of cases). In the best case, the report is but one piece of the puzzle; in the worst case, the report is misleading as the user has misinterpreted the issue (that’s not a z-index issue, it’s a hidden overflow problem).
Screenshots are little better for troubleshooting – though they can certainly be useful in drawing attention to the location of the problem. The visual output of an issue is only a small fraction of the information available to an expert attempting to diagnose a problem. In my experience, guessing based on a screenshot is essentially pointless.
Analogy time.
Accessing your site in a browser is like getting under the hood of your car
When you’ve got automobile problems, you need to bring your car into the shop. They can run diagnostics, test the battery, check the oil level, and see the engine firsthand. In short, the mechanic needs to get under the hood to investigate the source of the problem.
The same thing is true with websites. The customer only sees the symptoms on the surface – the end result. The developer, with specific browser tools, can look at the underlying HTML, CSS, JS, and DOM structure, view javascript error logs, investigate the loading of resources over the network, troubleshoot CSS selector specificities, debug javascript execution, and even test solutions.
Firsthand access to the website is absolutely critical to the accurate diagnosis of any non-trivial site issue.
Luckily, providing access to a website is a lot cheaper than a tow truck.
Just the tip of the iceberg
Keep in mind that symptoms and diagnoses are not 1:1 relationships. There could be multiple causes for the same symptom, so a developer can rarely offer a definitive solution based on a symptom report alone. For example, let’s say a custom CSS style isn’t working on a website (a common support request: “I added some CSS but it didn’t work – why?”). Here’s a partial list of why that might occur:
- The stylesheet didn’t load (this in and of itself could have several different causes)
- The stylesheet loaded, but a syntax error prior to the style in question prevented the style from being processed by the browser
- The custom CSS selector did not properly target the intended element
- The custom CSS selector targeted the element properly, but did not have a high enough specificity and was overridden by another style.
- The custom CSS was properly applied but was missing the prefix for the desired browser.
- A caching plugin is in use and the cache was not cleared, so the site is still serving up old stylesheets without the new custom CSS
- An HTML syntax error caused a DOM error that prevents style rendering in Internet Explorer
- A bad doctype has sent IE into quirks mode, altering the rendering of the DOM elements
A single symptom might be the indicator for a number of underlying causes
A report that “the CSS doesn’t work” or a screenshot showing a lack of styling gets us no closer to a resolution because it gives us no information to troubleshoot. As soon as the URL is provided and the developer can get “under the hood,” the cause behind the symptom can be diagnosed, and a solution can be provided.
Imagine calling your mechanic and saying “my car won’t start, what is wrong?”
Well,
- Your battery might be dead
- The spark plugs might be worn out
- The ignition timing might be off
- The distributor cap might be cracked
- The car might be out of gas
- Maybe the engine is flooded from that time you drove through that puddle the size of Lake Michigan
- Maybe you didn’t turn the key or have your foot on the break when you pressed the keyless ignition start button
(or probably 50 other reasons – I’m not a mechanic, and I don’t play one on TV)
You’ll need to bring it into the shop, because your mechanic can’t tell the source of the issue without looking under the hood. Neither can your web developer.
But I’m still in development!
So, what do you do if your site isn’t public, so your expert/developer can’t see it? You have a few options:
1. Try to debug it yourself with the resources at your disposal. In the case of UberMenu for example, I’ve provided a Troubleshooter that will walk you through troubleshooting common symptoms.
2. If your site is on a public server but requires credentials, provide credentials to the expert troubleshooting your site.
3. If your site is not on a public server, and you don’t know how to troubleshoot it yourself, you’ll either need to hire someone to come over and view the site on your local network, or put the site up on a public server temporarily so the expert can troubleshoot it remotely. I recommend the latter.
4. If it’s a code problem that isn’t site-specific, create a demonstration of the issue that others can troubleshoot. CodePen and JS Fiddle are excellent resources. As CodePen states: Demo or it didn’t happen.
Demo or it didn’t happen
If you want help from a developer, it’s up to you to provide the requisite access. Your doctor needs to X-ray your arm to see if it’s broken, your mechanic needs to check your car’s oil to tell if it needs replacing, and web developers need to see your website in a browser in order to troubleshoot it. Expecting a developer to be able to diagnose and provide a solution for a problem that they can’t investigate simply isn’t reasonable.
Want good support? The most important thing to do is to make it as easy as possible for the developer to troubleshoot your site by providing them all the resources they need. That and be polite – the friendly customer is going to get a better response than the belligerent customer any day of the week 🙂
Happy troubleshooting!
