Review Request 128466: Rename Checksums tab to Integrity
Thomas Pfeiffer
thomas.pfeiffer at kde.org
Mon Jul 18 19:33:30 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.
>
> Thomas Pfeiffer wrote:
> 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).
>
> Sebastian Kügler wrote:
> So you're saying that I'm too advanced a user for this dialog to make sense? I'm at a loss for words here. Maybe you can view Ivan and me as the kind of user this dialog should be used by and should work for well, and not try to conveniently place us outside of the target group by just telling us that the target user is dumber, but still not dumb enough to not need checksums. This way a bad design doesn't get fixed.
>
> As to my actual issue, it's not addressed in the review you link, it rather leaves me more puzzled:
> - the checksum must not be calculated automatically (I completely agree, I don't want my disk to be thrashed once I open this dialog or tab; it's unrelated to my comment, however)
> - so I paste the checksum in there, and then hit calculate (which button, btw, how do I tell?)
> - When I just need the checksum (for example when handing it out with a file, or to verify a file with a user), I hit calculate, and I can copy the resulting string?
>
> For me, calculating the checksum and showing me is what this dialog really should do. Comparing it to something typed or copy/pasted is an extra, which can only happen once the checksum has been calculated. Calculating is clearly the first, necessary step. Why the paste box is above it ... I simply don't understand. Why a groupbox for the primary function that distinguishes it from the copy/paste part (which, without calculating is entirely useless) -- I don't know. It serves no purpose (and none is given in the link you post).
>
> I rest my case, the design of this dialog doesn't make a lot of sense as it is, it can be done simpler, easier to understand and thus, better.
>
> Ivan Čukić wrote:
> Thomas, I have read the discussion before commenting here, although it is strange to call a mostly one-way conversation (you as the UI expert advising on the UI) a discussion :)
>
> I don't see 'we already had a discussion' as a valid answer for users' confusion with the UI (not only Sebas and me, which is also mentioned in Rangar's comment in the review #128283)
>
> I do agree that the two work-flows are separate. Still, the UI does not make that obvious to me. The UI does not make it obvious that it *has* two work-flows.
>
> So, from my point of view, these are the problems:
>
> - Even if the group says 'Sharing', it does not have any sharing mechanisms. It would be similar to having the file metadata under a share tab because somebody would want to share the song name and the artist with someone;
> - If the group is named 'Checksums', it implies that the thing outside is not a checksum;
> - The 'share' workflow is unfortunately a part of the verification workflow since it needs to calculate the sums;
>
>
> p.s. sharing a checksum is also for advanced users - users that could do it from CLI.
>
> Thomas Pfeiffer wrote:
> Do whatever you want, I'm outta here.
>
> Ivan Čukić wrote:
> I'm sorry if you are offended, but you need to be open to discuss potential problems of your work just like everybody else here.
>
> Olivier Churlaud wrote:
> @sebas: the way I understood it (but maybe I'm wrong) is:
>
> First user case: Check a file. You paste your checksum, and without clicking anything it goes red or green (or with a small message) and tells you if it's the good checksum. This mean that you don't need to hit any [calculate] button.
>
> Second user case: Share the checksums. You calculate, and copy/paste the output.
>
> IMHO they don't need to be in separate tabs but separated with meaningful titles in the "checksum" tab.
>
> Thomas Pfeiffer wrote:
> > I'm sorry if you are offended, but you need to be open to discuss potential problems of your work just like everybody else here.
>
> I do discuss problems with my designs, all the time. But not the way you (and especially sebas) barged in here, weeks after the original design was agreed upon with everyone involved in that review request, and telling me that because it doesn't conform to your logic, it must be wrong.
>
> I never said it was perfect, there surely are things that can still be improved, but this discussion is not worth my time.
>
> Let Elvis decide what to do with his feature.
>
> Gregor Mi wrote:
> I followed this thread closely. I tried to combine
>
> - the latest screenshot (https://share.kde.org/index.php/s/RUs9gAhIQqpFIqF)
> - with the approach to have the Calculate buttons on the top (although the primary use case is to "verify a checksum", for me it also makes more sense that calculation part comes first, because verifing is the second step and even optional if some just wants to calculate it without verifying against another checksum)
> - more explanatory text (the intro sentenced comes from Wikipedia) to inform the user
>
> This is the result:
>
> ```
> Checksum
> --------
>
> A checksum provides a means to detect errors in a file which
> may have been introduced during its transmission or storage.
>
> There are different methods to calculate a checksum:
>
> MD5: [Calculate]
> SHA1: [Calculate]
> SHA256: [Calculate]
>
>
> If you downloaded this file from a website, it is common that
> a checksum is provided so you can verify that the data you
> received is valid.
>
> Paste the given checksum in the field below:
>
> [Expected checksum (...)]
> ```
>
> It is more verbose than the original designs and does not tell the user in advance that if he pastes a checksum that the correct checksum method will be used and auto-calculated. I assume that he/she will find out when using it (or a tooltip could be added).
>
> Olivier Churlaud wrote:
> The problem here is that the user must do
>
> 1) which type of checksum do I want
> 2) explicitely calculate
> 3) paste the checksum he has.
>
> The current design makes this better I think: most of the time you only want to compare 2 checksums, but doing steps that can be automatized (choose type + calculate)? This is faster, and easier. Then if the user wants to know the checksum he has, he could explicitely calculate them, but most of them won't.
>
> Olivier Churlaud wrote:
> Proposition to make things more obvious:
>
> Can't you hide the [calculate part] so that there is only the option to paste a string that will be controled, with a "[] More option" check box that would show the other options (which are "only calculate the checksum"). With this it is just simple by design. The complexity is only there if the user needs it.
>
> This way, the problem raised by Sebas and Ivan would disappear.
>
> Ivan Čukić wrote:
> @Gregor
>
> +1 (though, like in my previous comment, I don't think we actually need three separate 'Calculate' buttons)
>
> Gregor Mi wrote:
> @Oliver:
>
> > The problem here is that the user must do
>
> > 1) which type of checksum do I want
> > 2) explicitely calculate
> > 3) paste the checksum he has.
>
> My suggestion was not to change the functionality when the user pastes the checksum (the checksum type is automatically detected). So the user _may not_ do those three steps (but he might think he has to, yes).
>
> Olivier Churlaud wrote:
> > (but he might think he has to, yes).
>
> This is a usability problem.
>
> Gregor Mi wrote:
> @Ivan: I understand that technically the parallel computation is possible but does the API allow for it without reading the file again? (I did not look into the current code) And is this scalable if more methods are added later?
>
> Gregor Mi wrote:
> ```
> Checksum
> --------
>
> A checksum provides a means to detect errors in a file which
> may have been introduced during its transmission or storage.
>
> There are different methods to calculate a checksum:
>
> (+) Show -----------------
> | MD5: [Calculate] |
> | SHA1: [Calculate] |
> | SHA256: [Calculate] |
> --------------------------
>
> If you downloaded this file from a website, it is common to
> provide a checksum so you can verify that the data you
> received is valid.
>
> Paste the given checksum in the field below to trigger
> calculation of the file's checksum and verification against
> the expected one:
>
> [Expected checksum (...)]
> ```
>
> - The "Show" box is initially collapsed (@Ivan: the three Calculate buttons could be replace with one, but now that they are hidden, it might matter less)
> - The only prompting widget is the "Expected checksum" text box. So, maybe the user will see it despite the fact that it is at the bottom of the dialog? (The first time the user would have to read much text but then he/she knows how the dialog works)
>
> Thomas Pfeiffer wrote:
> >> (but he might think he has to, yes).
>
> > This is a usability problem.
>
> Exactly. Again: Users who know little about checksums should not have to know that technically, a checksum has to be computed first. That's an implementation detail which is of no concern to users. They paste the checksum they have in there (like the text tells them to), they get a response, done. They never have to touch the "calculate" button.
>
> Gregor Mi wrote:
> ```
> Checksum
> --------
>
> A checksum provides a means to detect errors in a file which
> may have been introduced during its transmission or storage.
>
> (+) Advanced (initially collapsed) -----------------------
> | |
> | There are different algorithms to calculate a checksum: |
> | |
> | MD5: [Calculate] |
> | SHA1: [Calculate] |
> | SHA256: [Calculate] |
> | |
> ----------------------------------------------------------
>
> If you downloaded this file from a website, it is common to
> provide a checksum so you can verify that the data you
> received is valid.
>
> Paste the provided checksum in the field below:
>
> [Expected checksum (...)] *)
>
>
>
> *) Tooltip: "Advanced information: When the checksum is pasted,
> at first the correct checksum algorithm is determined,
> then the file's checksum is calculated with this algorithm
> (if not already done) which then will be verified against the
> pasted checksum and finally the result is displayed to you."
> ```
>
> Olivier Churlaud wrote:
> Collapsable area make more sense being below, don't they? At the end you provide the exact same design in more verbose (too much I think: once you have read it twice, it must really being nerving). However it's interesting: Maybe all your text could be in a "What is it for?" tooltip or link.
>
> I think that having a collapsed advanced menu would solve the issue. It would be intersting to hear Ivan and Sebas on this.
>
> And Thomas, what about the usability side of this tooltip/advanced options?
>
> I think Elvis has his word to :P
I fully agree with everything Olivier said.
- 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/1552ae65/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list