Futher to my previous post… it struck me that a lot of people’s problems would suddenly become much clearer if they could upload a screenshot. However, taking and uploading screenshots is currently a reasonably complex process, especially on XP (where it involves Microsoft Paint).
Here’s today’s usability challenge: can we enhance Firefox in some way to make this easier? For example, it would be great if we could give users instructions like:
- Right click on the “Browse” button of this file upload control and select “Upload Screenshot”
- See the timer start to count down from 10 in the top right of your screen
- Bring the relevant window or tab you want to take a screenshot of to the front
- Wait for the timer to expire
- Hit “submit” on the form
What about allowing pasting multimedia contents in a <input type=”file”/>?
Take a screenshot by pressing the Print Screen key, then bring up the form and hit ctrl+v (or context-menu > paste) on the file input.
Firefox should then do The Right Thing and encode the contents of the clipboard to a suitable format (something along what TB does when pasting images in a mail compose window).
The next step would then be accepting also other content types. And, obviously, providing some reasonable feedback to the user.
I would rather go with:
* Bring the relevant window or tab into foreground
* Press Alt+PrtScr (or simply PrtScr if you want to capture the entire screen rather than a single window)
* Now go to the file upload page and right click the “Browse” button of the file upload control, select “Upload from Clipboard”
* Hit “Submit” button of the form
This would help a lot already – and is much easier to implement (no platform-dependent code necessary, makes a pretty trivial extension with the new File API). It seems that ImageBot add-on already has this as part of its functionality, it only uploads to image hosting services however.
CAFxX: Sadly, you can no longer focus the “text input” box of an <input type=file> without it popping up a confusing and often OS-provided file dialog. Pressing Ctrl-V on that would not do what you want. :-(
Wladimir: I like that – it’s better than my workflow. And “Upload from Clipboard” would only appear on the menu (or only appear enabled) if the clipboard contained contents that Firefox could understand.
There doesn’t quite seem to be an extension for this, but I’m sure it could be written as one. Anyone want to try?
Screengrab goes a rather long way, doesn’t it?
https://addons.mozilla.org/en-US/firefox/addon/1146
Or do you mean “whole-screen” (not just what’s in the browser?)? Then maybe something like this (which is GPL2)?
http://code.google.com/p/zscreen/
I completely agree. Fortunately I am dealing with semi-technical people who have no problem with creating screenshots. Unfortunately clients seem to be so advanced that they like to crop the screenshot to contain only visible browser content area or even fragment of the page having the problem. They think it is self-explanatory so they don’t attach much information to it.
Can you imagine huge CMS with 50 modules and getting screenshot 200x100px of distorted menu somewhere deep in the system with description “It does not work.”? :-) Not much help.
I am always asking for full-screen screenshot with proper description. There are at least 4 important things you can notice – the URL bar content, the exact time on the OS tray (to be able to dig server-side logs), ability to guess what browser is being used, and possibly the Internet connection status (the strength of the WiFi signal).
I’ve built also the AJAX bug reporting tool directly into every admin page that brings up the simple form and upon submit it grabs the whole HTML content of the page including all vital information (referer, cookies, plugins, …) and sends it to the tech support for analysis… I am sure that in modern browsers it will be possible to make screenshots of rendered content from within the page…
@ Elixon
I use my task bar hidden by default. So do a few people. Relying on system clock and other stuff like that isn’t a good policy. Plus, the time of screenshot may not be the same as the time of page loading, and there’s timezones and whatnot.
I still think we should include a field to let the user say how experienced he is. THAT would save a load of time, and we wouldn’t require no APIs or anything like that.
Good idea. Currently, with XP, the problem is finding a program that will accept pasting from the clipboard and then save just the screenshot as an image file. The struggle is finding the right application. I think the essence of your suggestion, or at least the most useful part of it, is that Fx can be that program. One nice thing is that this would be a multi-platform solution.
I think it should be able to upload ANY screen shot, not just a browser window or tab. A good screen grabber will take a the whole screen, a selected area, or a single window with or without menus, mouse cursor, etc. then copy it into the clipboard. In different environments that’s usually accomplished either a keystroke or a separate, graphical program.
So why not just provide a special tab/window, and allow pasting the buffer into it. Then allow saving as a file or uploading in whatever format. I think that’s what CAFxX was suggesting. From the user point of view, that’s about as simple as it gets. In principle, it could allow the user to upload without saving the file, allow this would not be an essential feature.
While we’re on the topic of input type=file…
“you can no longer focus the “text input” box of an without it popping up a confusing and often OS-provided file dialog.”
Let’s say I have to fill out a form with 20 fields. 6 of those fields are input type=file. I’m supposed to upload photos A,B,C,D,E, and F. which are thumbnails of larger original photos.
I quickly go through the 6 file inputs and when I’m done I realize I’m not sure if I chose F for #6 or if I accidentally chose E twice. I used to be able to focus the text area and use the arrows or end key to jumt to the end of the path to see the file name. I can’t do this anymore.
More importantly my co-workers who are less graceful with the use of a mouse can’t do this anymore.
_I_ can still click+drag in the text area until i see the end of the path without triggering the dialog. Why doesn’t it just right-align that text box so we can always see the filename?
Moving along…. so I check the filename of file field #6 and see that I did indeed choose E.jpg instead of F.jpg. I click the browse button again and choose F.jpg. But I notice that F.jpg is 17.8 megabytes in size. “That’s not a thumbnail!” I say to myself.
I don’t have time to make a thumbnail for it right-now. I’d like to just upload the first 5 files and deal with F.jpg later. But how do I clear the 6th file input???
I vaguely remember in the past I could select the text and delete it (I think). But I can’t do that now. Touching the input in any way triggers the dialog!
It seems my only option is to intentionally upload E.jpg (a much smaller file than F) then find it in the admin system and delete it. So many needless steps :( I may as well actually make the thumbnail for F.
Wait, I just got a call from upstairs… Seems they aren’t sure if they want to show photos the blue products on the site today since we won’t have any blue in stock for another week. That means I don’t need to upload photos F, B, or C.
Hmm… there is a “reset” button on this form, that should clear all the file inputs BUT it would also clear my 14 other fields! Which means I have to type them all over again, unless I copy and paste them out first!
In the end what I wound up doing was search my temporary internet files for a 2kb transparent.gif and place that in the file input fields.
Was there a better way to handle this scenario?
“I am sure that in modern browsers it will be possible to make screenshots of rendered content from within the page… ”
Doesn’t the canvas have a feature sort of like that? I remember it being used in some drag/drop demos.
“So why not just provide a special tab/window, and allow pasting the buffer into it.” In OS X it seems all screenshots are temporarily saved as a png somewhere on disk then if you cmd+v in mail.app it’s like you attach the file that was saved in the temporary folder (or on the desktop).
Maybe we could have the screenshot saved somewhere on disk temporarily and the path to that file placed on the clipboard. Then the user could paste the path into the text box of the file input… if it became possible again to interact with that text box.
I think there should be an attribute that makes the file input act like it does now, or like it used to when you could touch the text box, or like it works in safari/chrome where you only see the file name and icon.
I’d vote for that (your version or Wladimir’s, either way) provided it works more or less the same (from the user’s perspective) on all three major platforms (Win32, X11, OS X).
> I still think we should include a field to
> let the user say how experienced he is.
It’s very hard to word that sort of question in a way that gives you any kind of useful answer. Normally users answer based on whether they are more or less experienced than the people they know (family and friends), which isn’t very useful. “Expert” can mean “I can usually remember how to copy and paste”, and on the other hand “Novice” can mean “I have barely scratched the surface of learning how the codebase of this application all fits together.” Short of offering what basically amounts to a standardized assessment test, I don’t know of any reliable way to get a *meaningful* answer that the “how experienced are you” question.
> A good screen grabber will take a the whole screen, a selected
> area, or a single window with or without menus, mouse cursor, etc.
If the user wants to get *fancy*, they can learn how to use image editing software. (Even something extremely basic, like MS Paint, can crop a rectangle out of a larger screenshot.) Or they can upgrade to an operating environment that includes such facilities in the stock screenshot utility, or they can download a third-party screenshot utility for the OS they do use. Lots of options.
For Firefox purposes, it’s probably enough to just do whole-screen grabs. The main point, you see, was that end users typically don’t want to learn new skills just to submit a bug report. They want to just click a button, type a vague description of the problem, and hit submit. Hence the proposal.
And incidentally, I think that implies that implementing it as an extension won’t really solve the problem, because people who don’t want to learn how to take screenshots probably also don’t want to install extensions (especially in the middle of trying to file their first bug report). It could be implemented initially as an extension for testing or whatever, but to really have much impact on the problem it probably needs to be a built-in feature.