> but the important information the engineer needed was what was actually right outside the boundary of the screenshot I took
Ah ah. At one gig we had trained the users to always send a screenshot of the entire screen. People reviewing the tickets would dump them if the screenshot was cropped and the user warned: "No full screenshot, no ticket".
Why? The most important info was the time at which the error happened (which, for users who were on Windows, was in the bottom right of the screen).
With the time we could look in the logs and the error/bug was usually obvious.
This seems like it would only work if the applications in question didn't contain any PII - as soon as you get into applications or flows within an application that contain some form of PII, either displayed or the user entering it, having them send a screenshot of the entire screen is asking for the user to accidentally leak their PII to the person reviewing the ticket.
Where I work (in which the above would be a problem), we make sure to log enough information that given a relative timeframe of when the user had the issue, we can usually narrow down to where the issue was using context and some querying of the logs (splunk is incredibly helpful for this)
Indeed, that's a great rule. Another one is "What URL was the browser on?" which is rarely ever in cropped screenshots but is visible in full screenshot
Oh maybe, I do remember hearing about that. Mine don't (Firefox & Chrome on Fedora) but maybe that's a default setting (on Linux) or maybe I changed the setting and forgot about it?
I think you changed it immediately when you first saw it and never thought about it again. I’d doubt Chrome binaries on any platform would change that only on one platform.
URL, totally. I was talking to a PM recently where their customers self-host their product so without knowing the url, they have no idea where on the internet to start looking for the bug.
For us it's not the time but the id of the thing they're working on, but users tend to like to crop to just the dialog or subsection they're having issues with.
It's infinitely easier to help the customer when we can take our own look at things.
Good tip, will pass it along to support and see what they say.
Seems nice but I hate sharing my whole browser window with anyone. I don't care to let other people see which plugins I use or my bookmarks toolbar etc.
oooh. you got them.
Like figuring out which timezone the user was in is impossible.
What if the user intentionally set their clock wrong to mess with support.
No, the people requiring a screenshot to include the time instead of just asking the user for an ID and time of error are the ones being silly. Have you ever heard of log filtering?
Users that might customise their system a bit by digging into the settings are usually more inclined to give a detailed report in case they encounter a bug or have a general knowledge of what to look for when requested for some information in my team's experience. Sounds much more like an edge case.
Most users don't customize anything, even something as trivial as that. Most corporate users may not be allowed to. I bet they never had to deal with any of these supposed gotchas.
The user not being in the time zone we expected has been exactly the information we were missing to debug something more than once. “The logs say it was 10am but the screenshot says 11… what if we were mishandling timezones?”
Ah ah. At one gig we had trained the users to always send a screenshot of the entire screen. People reviewing the tickets would dump them if the screenshot was cropped and the user warned: "No full screenshot, no ticket".
Why? The most important info was the time at which the error happened (which, for users who were on Windows, was in the bottom right of the screen).
With the time we could look in the logs and the error/bug was usually obvious.