[Request]: make the verification page clearer

[RedAuburn]

Describe the request

The verification page is quite unclear, i'm unsure if the checksum is red because it wasn't recognised as a checksum, or if it doesn't match the file. The file being green is also unclear.

ideally, the colours of those segments would only represent if the input was accepted or not, and there should be an explicit separate cell that goes green or red and has the text "{hash function} checksum matches" or "{hash function} does not match"

something roughly like this (although further design needed):

Implementation Details

• [X] This follows the GNOME HIG.

[GeopJr]

Thanks for raising this issue!

Not opposed to it but I'd rather get to the bottom of the confusion first before finding the optimal solution.

i'm unsure if the checksum is red because it wasn't recognised as a checksum, or if it doesn't match the file. The file being green is also unclear.

They are meant to represent a binary result: whether their value matches the open file. So for the first one, the hash does not match any of the calculated hashes in the 'Hash' view. There's no hash function validation (the app does some cleaning up behind the scenes (lower casing, removing whitespace etc.)).

The second one, the inputed file's sha1 hash matches the sha1 hash calculated in the 'Hash' view, aka they are the same file. (It also does check the content in the case of checksum files, but that's pretty much it)

This feedback is also represented in the tooltips when hovering over them ('they match' vs ' they don't match')

ideally, the colours of those segments would only represent if the input was accepted or not, and there should be an explicit separate cell that goes green or red and has the text "{hash function} checksum matches" or "{hash function} does not match"

This sounds, to me at least, a bit excessive. What input is not accepted? and if 99% of inputs are accepted then what's the point of even showing that they got accepted successfully instead of just showing a toast when they don't?

Since this is a 'glorified string comparison', showing whether they match or not instantly sounds more appropriate to me, but I'd love to hear your take on it!

(what I'm trying to say is that usually you only care if they match, whether what you inputed is a valid hash function for example, doesn't matter, because it doesn't match anyway)

---

An early design mockup would use toasts but we never went with it, I could bring it back :shrug:

[RedAuburn]

Thank you for the detailed response!

They are meant to represent a binary result: whether their value matches the open file. So for the first one, the hash does not match any of the calculated hashes in the 'Hash' view. There's no hash function validation (the app does some cleaning up behind the scenes (lower casing, removing whitespace etc.)).

The second one, the inputed file's sha1 hash matches the sha1 hash calculated in the 'Hash' view, aka they are the same file. (It also does check the content in the case of checksum files, but that's pretty much it)

ahh! I see how it works now. I was on very little sleep when trying Collision out, so maybe it's obvious, but I didn't think there was any connection between the hash & verify views.

I thought you'd put a hash into the Checksum side, then a file into the file side, and it would compare them. Maybe an explicit subtitle over the filename in the verify view saying something like "file to compare" might help clarify?

This sounds, to me at least, a bit excessive. What input is not accepted? and if 99% of inputs are accepted then what's the point of even showing that they got accepted successfully instead of just showing a toast when they don't?

Since this is a 'glorified string comparison', showing whether they match or not instantly sounds more appropriate to me, but I'd love to hear your take on it!

I fully agree with how it's done now, now that I understand it 😅

[GeopJr]

ahh! I see how it works now. I was on very little sleep when trying Collision out, so maybe it's obvious, but I didn't think there was any connection between the hash & verify views.

No worries! It's an actual problem that has been brought up before but we never decide on a solution :/

Maybe an explicit subtitle over the filename in the verify view saying something like "file to compare" might help clarify?

Generally the tooltips contain hints but they still sound unclear

to check against what? the open file? or the checksum next to it?

It will sound a bit silly but I partially feel that because the subtitle is not visible in the sandboxed* app, users sometimes forget that they even have a main file open or that the title is the open file name:

(notice that the above screenshot shows the subtitle while the ones uploaded in previous comments don't)

* this is because, in the sandbox, the app doesn't know the real file path, all it has is /run/user/$UID/doc/$FILENAME. Showing that to the user would raise more questions, 'that's not where the file is' etc

---

Another option is using the 'help pages' feature to document it, but I don't think anyone will read it

---

Last option I have in mind is an :information_source: icon that informs the user about the context when clicked