When even screenshots fail

My best weapon for handling user queries is the screenshot.

User: Hey Vincent, I’ve got an error when doing X.
Me: Send me a screenshot.

User: Hi Vincent, sorry to disturb you. The application Y doesn’t work.
Me: Send me a screenshot.

User: Dear Sir, I cannot log in to application Z. Please advise.
Me: Send me a screenshot.

I’ve been fortunate in that I don’t have to educate my users on how to create a screenshot. Imagine the conversation with me describing where the PrintScreen button is…

User: Uh, how do I send you a screenshot?
Me: Just do a PrintScreen.
User: How do I do a PrintScreen?
Me: Just press the PrintScreen button.
User: What PrintScreen button?
Me: It’s a button on the top right corner of your keyboard, beside the Scroll Lock button.
User: Ok, I’ve pressed the PrintScreen button. Now what?
Me: Now send me the screenshot.
User: How do I do that?

I’d probably slam the phone down and throw it halfway across the hall.

PDFs, Word documents and bitmap files

Anyway, even with the absence of the kind of inane conversation above, I still receive some interesting emails. I might receive an email with a PDF file. I open the PDF file and lo and behold, there’s a screenshot inside, all shiny and black and white and kinda fuzzy and grainy due to the warping from the PDF writing software.

Yes, there are users who are more adept at creating PDFs than Word documents.

Then there are screenshots where the user diligently took a capture of the screen. With the actual error obscured by another window.

Then there are the emails with a file size of 2 megabytes. Think bitmap file attachments with a resolution of 1024 by 768 pixels.

Then there are the clever users who took a screenshot, and to compress the file size, they dumped the contents into a Word document. Word automatically compresses the bitmap. I can’t blame them for not knowing how to use an image editor, even one as simple as Windows Paint. Didn’t get any fancy meta-screenshots, though I’ve gotten a screenshot in a PowerPoint file before.

Then there are the ultra-clever users who know how to take a screenshot, use an image editor to crop it, and *exclaim* save it as JPG or PNG. Even then there are problems. Let me first show you this:

Yellow screen of death

If you’re familiar with ASP.NET, that’s everybody’s favourite error screen. It has useful data such as the general error message, the line of code where the error occurred and the stack trace. The stack trace contains information such as what events were triggered so you know for example, which button was clicked.

Now I have this web application with a loading screen, played out with an animated GIF image. And when there’s an error, something like this shows up:

ASP.NET error with Now Loading

I’m terrible at drawing stick figures… It’s supposed to be a stick figure searching for files in a file cabinet, and throwing any useless files behind him.

Well, my user sent me that. Most of the useful information was below the screen. So I asked her to scroll down so I could see them.

Me: Can you scroll down and resend the screenshot?
User: How to scroll down?
Me: Just use the scrollbar and scroll down.
User: What scrollbar?

That’s the compressed version of a few emails back and forth. I didn’t quite throw my phone across the hall, but I did take a deep breath and drink some water.

Then I took her screenshot and added some comments in it.

ASP.NET error screen with comments

I accompanied that modified screenshot with more comments in my email. I can’t remember what I typed, so here’s the closest version:


I’m sure the man throwing files all over the place is all very nice, but I can’t see the actual error below him. Please scroll down so I can see more of the error message.


Sometimes, you’re not just debugging code. You’re debugging human behaviour.

Cannot open an Adobe FDF file

This was an actual problem faced by my users. The problem might be phrased as

  • cannot export pdf
  • cannot see pdf file
  • nothing happened when I click on the button
  • or some such variant

So here’s the back story. I maintained these web applications which generated Adobe PDF report files, which were designed using Crystal Reports in Visual Studio.

The reports were generated on the fly, and there were no problems from my users… Until one of them said she couldn’t see the PDF file. She only said there’s an error. This was where my user querying skills came into play, and I finally convinced her to send me a screenshot of the error (it was fortunate I didn’t have to teach her how to use the PrintScreen button…).

And it looked something like this:

Adobe FDF error

The error message reads something like:

Acrobat could not open ‘pa123456.fdf’ because it is either not a supported file type or because the file has been corrupted

And the solution? Fire up the Microsoft Internet Explorer (IE) browser. In the browser, click on “Tools” menu, then “Internet Options”.

On the “General” tab, click on “Settings” button in the Browsing history section.
If you’re using IE6, then it’s under Temporary Internet files section.

Make sure the radio button under “Check for newer versions of stored pages” is checked at “Automatic”.
The user with the error probably set it at “Every time I visit the webpage”.

Note that my users are in an internal corporate network, so the only browser they know and use is IE. I’m not sure if this happens on other browsers.

I’m writing this because it took me a long time before I finally found the answer. That answer was probably here (yes, mjurrius, it helped. Thanks!).