Project

General

Profile

Feature #8660

Add an option to attach screenshots to WhisperBack reports

Added by bluewater almost 4 years ago. Updated 4 months ago.

Status:
Confirmed
Priority:
Normal
Category:
-
Target version:
-
Start date:
Due date:
% Done:

50%

QA Check:
Dev Needed
Feature Branch:
Type of work:
User interface design
Blueprint:
Starter:
Affected tool:
WhisperBack

Description

there is no option to upload a screenshot when sending an error report via whisperback. Whereas a picture can sometimes describe a troubled and confusing situtation much more clearly than words, said option is much needed in whisperback.

Bildschirmfoto von »2018-06-20 17-41-12«.png View (121 KB) sascha.markus@gmail.com, 06/20/2018 03:45 PM

whisperback_screenshots.ui (37.1 KB) sascha.markus@gmail.com, 06/20/2018 03:46 PM

screenshots.png View (31.1 KB) sajolida, 07/19/2018 01:53 PM


Subtasks

Feature #8666: Explain how to take screenshots in TailsConfirmed


Related issues

Related to Tails - Feature #15486: Ask users to send smaller images to frontdesk Rejected 04/02/2018
Duplicated by Tails - Feature #7159: Allow to take screenshots from inside WhisperBack Duplicate

History

#1 Updated by intrigeri almost 4 years ago

  • Assignee set to bluewater
  • QA Check set to Info Needed

It looks like a good idea to me. Indeed, as you indicated with Type of work = UX, it need design. What screenshot would you want to attach? One that you've taken previously (yourself, manually), or one that WhisperBack would take? If the latter, what to do with the WhisperBack window?

#2 Updated by intrigeri almost 4 years ago

  • Tracker changed from Bug to Feature
  • Subject changed from add an option to upload screenshot to whisperback to Add an option to upload screenshot to WhisperBack

#3 Updated by bluewater almost 4 years ago

intrigeri wrote:

It looks like a good idea to me. Indeed, as you indicated with Type of work = UX, it need design. What screenshot would you want to attach? One that you've taken previously (yourself, manually), or one that WhisperBack would take? If the latter, what to do with the WhisperBack window?

TAILS already has an app to take a screenshot, so I'd say the option should be for whisperback to upload a screenshot previously taken instead of a one to take by whisperback.

#4 Updated by intrigeri almost 4 years ago

TAILS already has an app to take a screenshot, so I'd say the option should be for
whisperback to upload a screenshot previously taken instead of a one to take
by whisperback.

OK, makes sense. Then, how about making this feature request more generic, and allowing users to attach any arbitrary file to a bug report? (BTW, would a limitation to one single fine be good enough, at least for a first iteration?)

#5 Updated by sajolida almost 4 years ago

  • Related to Feature #8666: Explain how to take screenshots in Tails added

#6 Updated by bluewater almost 4 years ago

intrigeri wrote:

OK, makes sense. Then, how about making this feature request more generic, and allowing users to attach any arbitrary file to a bug report? (BTW, would a limitation to one single fine be good enough, at least for a first iteration?)

this would pose a security risk. A few days ago I read about an Egyptian security researcher who hacked facebook servers by infecting a pdf file with malware and uploading it to the facebook jobs websites as his cv. So any file uploaded via whisperback carries the risk of being infected. Whereas a text based report does not carry this risk. Please take this in consideration.
I think limiting the upload to 3 files is better. 1 might not get the whole picture. But making it unlimited opens the servers for DoS attacks by flooding it with files. So I think 3 files limitation is good.

#7 Updated by intrigeri almost 4 years ago

wrote (13 Jan 2015 17:00:21 GMT) :

this would pose a security risk. A few days ago I read about an Egyptian security researcher who hacked facebook servers by infecting a pdf file with malware and uploading it to the facebook jobs websites as his cv. So any file uploaded via whisperback carries the risk of being infected. Whereas a text based report does not carry this risk. Please take this in consideration.

Sure. That will need to be conveyed to Tails frontdesk people, who are handling these incoming bug reports.

I think limiting the upload to 3 files is better. 1 might not get the whole picture. But making it unlimited opens the servers for DoS attacks by flooding it with files. So I think 3 files limitation is good.

It seems to me that a size limit would better address this problem than limiting the number of attached files. OTOH, the SMTP relay that's forwarding these bug reports supposedly has Postfix' default size limit for messages, so most likely we don't need to enforce this on the client side.

#8 Updated by sajolida almost 4 years ago

so most likely we don't need to enforce this on the client side.

We should for UX reasons: we don't want the user to try to upload 10MB
of attachments and then only get an error back from Postfix on the
server. I think that this should be checked upfront.

Regarding the number of files, I admit that when people attach
screenshots to their non-WhisperBack reports they tend to attach various.

#9 Updated by intrigeri almost 4 years ago

We should for UX reasons: we don't want the user to try to upload 10MB
of attachments and then only get an error back from Postfix on the
server. I think that this should be checked upfront.

Ah, right, good catch!

#10 Updated by BitingBird over 3 years ago

  • Status changed from New to Confirmed

#11 Updated by BitingBird over 3 years ago

  • Assignee deleted (bluewater)
  • QA Check deleted (Info Needed)

#12 Updated by sajolida over 2 years ago

  • Subject changed from Add an option to upload screenshot to WhisperBack to Add an option to attach screenshots to WhisperBack reports

#13 Updated by sajolida over 2 years ago

  • Duplicated by Feature #7159: Allow to take screenshots from inside WhisperBack added

#14 Updated by sajolida about 2 years ago

  • Related to deleted (Feature #8666: Explain how to take screenshots in Tails)

#15 Updated by sascha.markus@gmail.com 5 months ago

Here is a first simple suggestion.
It's based on the changes for Feature #7180: Remove the right pane of WhisperBack

The Label "Screenshot" might also have additional information about the allowed size (in total).
In this case we should also check the size and need an additional window for the feedback.

#16 Updated by sajolida 4 months ago

  • Assignee set to sajolida
  • QA Check set to Ready for QA

#17 Updated by sajolida 4 months ago

  • Related to Feature #15486: Ask users to send smaller images to frontdesk added

#18 Updated by sajolida 4 months ago

  • File screenshots.png added
  • Assignee changed from sajolida to sascha.markus@gmail.com
  • QA Check changed from Ready for QA to Dev Needed

Hi Sascha, thanks a lot for working on WhisperBack again!

I couldn't download your screenshot from Redmine this time. Maybe the '»' characters in the file name were not handled properly by Redmine... Then I tried to copy the .ui file into the source code (based on master) and got some error messages. So I opened the .ui file in Glade and I think I got the idea!

In such cases, what I find easier to review are Git branches, but take it easy if that's complicated for you.

I'm attaching my proposal for the interface and here is my rationale:

  • Since we want to limit the size of the attachments, as you said, we should display the size of each file, the total size, and the maximum. From my experience, users have a very hard time dealing with file sizes, so every bit of help will be helpful.
    • When the user adds a file that goes beyond the maximum file size, we could display the following error message:
    • I also considered adding a notification below the [Browse...] button but I thought that it would be harder to implement and get right.
*Screenshot to big (193 kB of 78 kB maximum)*

The screenshots are limited to 1000 kB in total.

Please add a smaller image or remove other screenshots.
  • I'm displaying the max size in kB as well. I bet than screenshots at least will always be in kB and that our limit will always be below 10 MB, so writable with 4 digits which is not too long. This way we avoid people having to switch mentally between kB and MB.
  • I'm adding a button to take a screenshot. The button would start GNOME Screenshots as people might otherwise not know how to do that (and it's a useful shortcut anyway). Do you think it will be possible to get back automatically the filename of the screenshot once GNOME Screenshots exits? Otherwise no problem, but the button will still be useful.
  • I went straight for an expandable list of screenshots (and not a fixed list of 3 screenshots) because I guessed that this might not be the hardest part of the code. An interface for a fixed list of screenshots would also look quite different (with different error messages, etc.) and we might have to recode a lot of stuff if we start with a fixed list. But if that's quite complicated, I can adapt my proposal to a fixed list.
  • In the list of screenshots we need something to remove screenshots (as a way of providing an "undo"). I was doubting whether to use a trash icon (/usr/share/icons/HighContrast/16x16/places/user-trash.png) or a cross icon (/usr/share/icons/HighContrast/16x16/stock/gtk-cancel.png) but I thought that the cross icon might not look enough like a button if the list is a simple list of text on a gray background. On the other hand a trash icon could be interpreted as "putting the screenshot in the trash" which is not the case. If you think that the cross icon looks good, please try that.

And stuff you could skip for a first implementation:

  • The paperclip icon (/usr/share/icons/HighContrast/16x16/status/mail-attachment.png) on the left of the list is bonus if that's easy :)
  • For now, it sounds safer to limit ourselves to screenshots only. So the file chooser when clicking [Browse...] should filter images only (PNG, JPG, anything else?). I also thought it could default to ~/Pictures which is where GNOME Screenshots stores its files by default.
  • I'd like the file name of the screenshot to be clickable and open GNOME Image Viewer, as a way of helping people check the content of what they are submitting. I don't think that we need to put anything visible to allow that and making the file name clickable should be enough (black on gray with no underline).

#19 Updated by sajolida 4 months ago

  • File deleted (screenshots.png)

#20 Updated by sajolida 4 months ago

#21 Updated by sascha.markus@gmail.com 4 months ago

sajolida wrote:

Hi Sascha, thanks a lot for working on WhisperBack again!

I couldn't download your screenshot from Redmine this time. Maybe the '»' characters in the file name were not handled properly by Redmine...

This is an good hint. This char is part of the default filename pattern if you create a screenshot in debian with the german language.
So for the we might do some ascii folding to make sure the files can be opens be the helpdesk people.

Then I tried to copy the .ui file into the source code (based on master) and got some error messages. So I opened the .ui file in Glade and I think I got the idea!

In such cases, what I find easier to review are Git branches, but take it easy if that's complicated for you.

Sorry. Just opening Glade was the idea but missed to explain it in the comments.

I'm attaching my proposal for the interface and here is my rationale:

  • Since we want to limit the size of the attachments, as you said, we should display the size of each file, the total size, and the maximum. From my experience, users have a very hard time dealing with file sizes, so every bit of help will be helpful.
    • When the user adds a file that goes beyond the maximum file size, we could display the following error message:
    • I also considered adding a notification below the [Browse...] button but I thought that it would be harder to implement and get right.

[...]

  • I'm displaying the max size in kB as well. I bet than screenshots at least will always be in kB and that our limit will always be below 10 MB, so writable with 4 digits which is not too long. This way we avoid people having to switch mentally between kB and MB.
  • I'm adding a button to take a screenshot. The button would start GNOME Screenshots as people might otherwise not know how to do that (and it's a useful shortcut anyway). Do you think it will be possible to get back automatically the filename of the screenshot once GNOME Screenshots exits? Otherwise no problem, but the button will still be useful.

I tried a bit. I didn't find a way to get the filename.

  • I went straight for an expandable list of screenshots (and not a fixed list of 3 screenshots) because I guessed that this might not be the hardest part of the code. An interface for a fixed list of screenshots would also look quite different (with different error messages, etc.) and we might have to recode a lot of stuff if we start with a fixed list. But if that's quite complicated, I can adapt my proposal to a fixed list.
  • In the list of screenshots we need something to remove screenshots (as a way of providing an "undo"). I was doubting whether to use a trash icon (/usr/share/icons/HighContrast/16x16/places/user-trash.png) or a cross icon (/usr/share/icons/HighContrast/16x16/stock/gtk-cancel.png) but I thought that the cross icon might not look enough like a button if the list is a simple list of text on a gray background. On the other hand a trash icon could be interpreted as "putting the screenshot in the trash" which is not the case. If you think that the cross icon looks good, please try that.

And stuff you could skip for a first implementation:

  • The paperclip icon (/usr/share/icons/HighContrast/16x16/status/mail-attachment.png) on the left of the list is bonus if that's easy :)

Should this just tell the user "This will be attached"? In this case I'd rather not add it. It just takes away space to display the filename smaller. And in the same row we have an icon which performs an action.

  • For now, it sounds safer to limit ourselves to screenshots only. So the file chooser when clicking [Browse...] should filter images only (PNG, JPG, anything else?). I also thought it could default to ~/Pictures which is where GNOME Screenshots stores its files by default.
  • I'd like the file name of the screenshot to be clickable and open GNOME Image Viewer, as a way of helping people check the content of what they are submitting. I don't think that we need to put anything visible to allow that and making the file name clickable should be enough (black on gray with no underline).

I had a look at the filechooser when I created my prototype. We can filter be filetype image/*.
For the Gnome Viewer: what about a magnifying glass next to the undo?

I'm rather busy these days so I won't make it in time for the 3.9 schedule.

#22 Updated by sajolida 4 months ago

This is an good hint. This char is part of the default filename pattern if you create a screenshot in debian with the german language.
So for the we might do some ascii folding to make sure the files can be opens be the helpdesk people.

Good point!

  • I'm adding a button to take a screenshot. The button would start GNOME Screenshots as people might otherwise not know how to do that (and it's a useful shortcut anyway). Do you think it will be possible to get back automatically the filename of the screenshot once GNOME Screenshots exits? Otherwise no problem, but the button will still be useful.

I tried a bit. I didn't find a way to get the filename.

Then forget about that. A button that only opens GNOME Screenshots will
be helpful already.

  • The paperclip icon (/usr/share/icons/HighContrast/16x16/status/mail-attachment.png) on the left of the list is bonus if that's easy :)

Should this just tell the user "This will be attached"? In this case I'd rather not add it. It just takes away space to display the filename smaller. And in the same row we have an icon which performs an action.

Ok, fair enough!

  • I'd like the file name of the screenshot to be clickable and open GNOME Image Viewer, as a way of helping people check the content of what they are submitting. I don't think that we need to put anything visible to allow that and making the file name clickable should be enough (black on gray with no underline).

I had a look at the filechooser when I created my prototype. We can filter be filetype image/*.

That's great!

For the Gnome Viewer: what about a magnifying glass next to the undo?

I thought that making the file name clickable would provide a bigger
clickable target and avoid adding one more visible element while still
being easy to discover.

But I'm not against the magnifying glass, then in addition to making the
file name clickable (which doesn't hurt).

I'm rather busy these days so I won't make it in time for the 3.9 schedule.

No problem!!!

Also available in: Atom PDF