Review Request 128466: Rename Checksums tab to Integrity
Thomas Pfeiffer
thomas.pfeiffer at kde.org
Mon Jul 18 15:23:31 UTC 2016
> On July 18, 2016, 12:05 p.m., Sebastian Kügler wrote:
> > Please don't ship it, yet.
> >
> >
> > I find the UI illogical. There's a groupbox grouping the checksum buttons, but then you can input the checksum above, so essentially, the groupbox is unnecessary and confusing.
> >
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" and removing the groupbox altogether, as it's not providing any semantic value.
> >
> > A usability reviewer should have a look.
>
> Kai Uwe Broulik wrote:
> This dialog has been created in Review 128283 and Usability has been involved from the beginning...
>
> Sebastian Kügler wrote:
> It has changed in a significant way, though, making it illogical.
>
> (Not that I understand the "Share" title in the original review, but that's another matter.)
>
> This needs more work.
>
> Elvis Angelaccio wrote:
> > Perhaps the whole thing could be simplified by naming the tab "Checksums" and removing the groupbox altogether, as it's not providing any semantic value.
>
> Preview here: https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF
>
> Sebastian Kügler wrote:
> This looks logical to me, and it's simpler: Very good!
>
> (Take that as "sebas withdraws his objection" :))
>
> Thomas Pfeiffer wrote:
> Clear -1 to removing the group box.
>
> Here is tha rationale:
> For most "regular" users, only the lineedit at the top is relevant. The calculate stuff is just distraction and - worse - potential confusion. If we remove any visual distinction between the two, we just make the situation worse for them.
>
> I agree that calling the tab "Checksums" is still better, though, because "Integrity" is too vague.
>
> For the "average user" I just re-tested this with, what would actually help her is creating a second box around the verification part, calling the top one "Verify checksum" and the bottom "Calculate checksums".
> That way if she was told e.g. by a website to verify a checksum, she'd knew she could simply ignore the whole calculation part.
>
> Overall simplicity should not be the top priority here: The priority should be to make it clear to users who just want to check whether a download went okay which part they should care about and which they can ignore, while still providing the calculation part for advanced users who want to do that.
>
> Of course another option would be to split it in two tabs, but that might make the tab bar quite long especially in languages like German.
>
> Sebastian Kügler wrote:
> The latter part seems redundant then. How can you verify a checksum without calculating it?
>
> Thomas Pfeiffer wrote:
> See _that_ is why the bottom box was originally called "Share". Of course the verification part also does calculation, but it does so without you telling it to. You paste in the checksum, and it tells you whether it matches or not.
> The manual calculation at the bottom is for people who share a file with others and want to accompany it with a checksum for _them_ to verify it.
>
> I think we might get away with "Calculate" anyway because those who don#t know much about checksums don't need to know that the verify part calculates as well, and those who know it should still be able to use the thing correctly.
>
> Sebastian Kügler wrote:
> That 'Share' title completely puzzled me, and I think I'm the kind of user this dialog should work for very well. (I need to verify checksums all the time.)
>
> To be quite honest, from getting it explained, I get the strong impression that you're overthinking it.
>
> To me, the most logical would be:
>
> * Calculate checksums at the top
> * Under that, the input field so I can c/p or type my checksum in there to have it compared automatically.
>
> That's both, the order of the workflow as well as the logical order of operation. 'Calculate' underneath would raise exactly the same question as I put above: "...but but but ... it could not verify it without calculating it, yet I have to hit a button to calculate ... maybe I should try again and maybe I should just use the commandline to be sure".
>
> Point in case: for this kind of stuff, simplicity trumps since it makes it easier to TRUST the dialog. I can't trust anything I don't fully understand or have doubts about, and that's what the groupbox design and the share title cause: doubts.
>
> Ivan Čukić wrote:
> > See that is why the bottom box was originally called "Share".
>
> When I saw the UI, it did not even occur to me that it behaves like this comment suggested. I'd say that is a wrong thing to happen with an UI.
>
> > To me, the most logical would be:
> >
> > Calculate checksums at the top
> > Under that, the input field so I can c/p or type my checksum in there to have it compared automatically.
>
> +1
>
> Additionally, whe are there 3 buttons for calculating the check-sums. All those can be calculated in-parallel without any noticeable performance impact. All of them (IIRC) read the file in 512-bit chunks and perform some computations. Computations are insignificant compared to file-reads, performance-wise.
Sebas, Ivan, please read the discussion here: https://git.reviewboard.kde.org/r/128283/ None of the things you're commenting on here fell from the sky, there were reasons for them.
As for what is "logical": Yes, this is the logical progression for _you_, who know how this whole checksum business works. You, however, can also just use [whatever]sum from the command line. This dialog was designed with users in mind who don't know how checksum verification works (the vast majority of "regular" computer users, I can assure you). They don't and need not know that a checksum has to be calculated first.
All they should need to know is what they should do, and the instruction at the very top of the dialog explains exactly that. And if they follow those instructions, they get a result.
In the first iteration, the dialog just threw three checksums at you, which leaves ordinary users utterly puzzled (I tried it with one). Plus, David Faure advised against calculating them automatically, and since he has a certain reputation of knowing what he's talking about, we followed his advice.
Of course we could just use one "Calculate" button.
Still, I don't see a point in making the vast majority of users who just want to verify a checksum they found a website calculate the checksum first.
I'm open for ideas on how to separate the two usecases (verifying the integrity of a file and getting checksums to do whatever with them) better, but I strongly oppose bothering users who know nothing about checksums with any information they don't need (and yes, that includes the calculated checksum, as that is 100% irrelevant to them).
- Thomas
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128466/#review97521
-----------------------------------------------------------
On July 16, 2016, 12:35 p.m., Elvis Angelaccio wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128466/
> -----------------------------------------------------------
>
> (Updated July 16, 2016, 12:35 p.m.)
>
>
> Review request for KDE Frameworks, KDE Usability and Dominik Haumann.
>
>
> Repository: kio
>
>
> Description
> -------
>
> Dominik suggested to rename the `Checksums` tab to `Integrity`, so that we can "free" the Checksums string and use it as the title of the groupbox below (in place of the current `Share` string, which can be confusing).
>
> Preview in the attached screenshot.
>
>
> Diffs
> -----
>
> src/widgets/checksumswidget.ui 03c64db
> src/widgets/kpropertiesdialog.cpp 808765c
>
> Diff: https://git.reviewboard.kde.org/r/128466/diff/
>
>
> Testing
> -------
>
>
> File Attachments
> ----------------
>
> Before
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/6771ed06-c803-4d18-abe3-91e4f97c8c76__checksums-tab.png
> After
> https://git.reviewboard.kde.org/media/uploaded/files/2016/07/16/b2cd12c8-6bbf-4123-9e8e-59cb0c29cbdb__Spectacle.TJ7614.png
>
>
> Thanks,
>
> Elvis Angelaccio
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160718/9eaa9d8a/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list