> 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 > > Thomas Pfeiffer wrote: > I fully agree with everything Olivier said. > > Gregor Mi wrote: > ``` > Checksum > -------- > > If you downloaded this file e.g. from a website which > also provides the expected checksum, then you can verify > if the data you received is valid. > > [ Paste the expected checksum here ] (?)_1 > > ( the initially hidden verification result ) > > (+) Advanced (initially collapsed) ---------------------------- > | | > | There are different algorithms to calculate a checksum: | > | | > | MD5: [Calculate] | > | SHA1: [Calculate] | > | SHA256: [Calculate] | > | | > ---------------------------------------------------------------- > > (?)_1 (What's this link): > A checksum provides a means to detect errors in a file which > may have been introduced during its transmission or storage. > > When text is pasted here, at first the correct checksum algorithm > is determined (currently MD5, SHA1 and SHA256 are supported), > 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. > ``` > > Jaime Torres Amate wrote: > This is totally offtopic (but related to this tab). > I think the user should be informed about the colision problems of MD5: > https://en.wikipedia.org/wiki/MD5 and SHA1: > https://en.wikipedia.org/wiki/SHA-1. i.e. they do not provide, by themselfs, > proof of non modification from http or ftp sites. It is a little bit better > from an https or sftp site if the site has not been compromised. > > Olivier Churlaud wrote: > I think it's not our role to tell them this. Maybe a line in the tooltip > that say SHA256 is recommanded? But not more: we already have a lot of text > here > > Elvis Angelaccio wrote: > > I think the user should be informed about the colision problems of MD5 > > Please let's keep this thread on topic. By the way, there are no > computationally feasible second preimage attacks against MD5 and SHA1, which > means that both algorithms are still fine for file integrity purposes. > > @all: thanks for the impressive amount of feedback, I'm still trying to > read all the replies :p > > Ivan Čukić wrote: > @Olivier > > > 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? > > I haven't checked the API so I can't comment on that. As for scalability, > hashsums need to work on input/forward-only streams (would be quite > problematic if they required random-access) so I'd say it would be > scalable to have one button. > > @Gregor > > I'm not sold on the collapsing thing to be honest. > > @Olivier > > > Collapsable area make more sense being below > > And this is the reason why I'm not sold (though I do like the collapsed > version better than the original one). The fact that it is more logical for > collapsable part of the UI to go below the normal UI does not necessarily > mean that something should be moved below, but that maybe a collapsing UI is > not the right way to go. > > @Jaime > > These hashsums are not meant to be used as tampering-elimination > verification (even if a lot of people do use them for this) but for transfer > verification. > > --- > > Anyhow, *if* collapsing is the way to go, there is no need for any > buttons at all. Paste the hashsum, and during the file hashsum calculation, > the insides of the collapsed part would be filled and shown when the user > un-collapses. > > Alternatively, if the user uncollapses, then it can automatically start > the calculation of the hashes. It has the required pre-action so that it does > not happen every time somebody opens this tab. > > The reason why I like the collapsed version better than the original > proposal is that it removes the initial confusion of 'what is what' when > someone opens the dialogue. > > As for the verbosity of text, I'm not against it. We can expect that the > users who have no idea about checksums will switch to this tab, and a > paste-textbox is not really all they would need to understand what the hell > it is. > > @Elvis > > Sorry for spamming you this much. :) > > Olivier Churlaud wrote: > I agree 100% with what is below the ruler, and I think it brings much: no > more buttons, everything is smooth. > > However I don't understand what is the problem with the proposed design, > if the user knows what is what. For example, I don't see why I, as a user, > would need to explicitely calculate the hashsums. > > I do not see why you would paste the hash AND show the calculated ones. > If you paste, you just say 'your hash is wrong'. No need to show strings that > are worthless: the user won't be able to use this result, and he doesn't need > to compare the strings, as he would be already told that it does not match. > > Gregor Mi wrote: > Jaime: > > I think the user should be informed about the colision problems of MD5 > > Oliver: > > I think it's not our role to tell them this. Maybe a line in the > tooltip that say SHA256 is recommanded? But not more: we already have a lot > of text here > > Ivan: > > These hashsums are not meant to be used as tampering-elimination > verification (even if a lot of people do use them for this) but for transfer > verification. > > If we put the website download example on the dialog, I think it is > important to at least give a hint that there might be security problems of > all kinds. Something like "Please be aware that the security and > trustworthiness in the Internet is a complex matter. Please inform youself > about potential issues when downloading files from the Internet and that > checksums do not provide data authenticity." > > > Ivan: > > Alternatively, if the user uncollapses, then it can automatically start > the calculation of the hashes. It has the required pre-action so that it does > not happen every time somebody opens this tab. > > Good idea. I still wonder how performance will be affected if all three > checksums are calculated at once on a large file (e.g. a DVD image on old > hardware). But maybe one could add "Stop" buttons to each algorithm (similar > to the folder size calculation in the General tab). > > > Oliver: > > I do not see why you would paste the hash AND show the calculated ones. > If you paste, you just say 'your hash is wrong'. > > +1 > > Ivan Čukić wrote: > > I do not see why you would paste the hash AND show the > > calculated ones. If you paste, you just say 'your hash is wrong'. > > One of the mentioned use-cases is 'sharing the checksum' for which you > need to have it shown. > > > Good idea. I still wonder how performance will be affected if all three > checksum [...] > > If they are done with a single pass (single file read), it should be > almost as fast as calculating one of them. I haven't benchmarked, but basing > this on the fact that hash sums require rather simple calculations. > > > "Please be aware that the security and trustworthiness in the Internet > is > > a complex matter. Please inform youself about potential issues when > downloading > > files from the Internet and that checksums do not provide data > authenticity." > > This might be a good solution. What do others think? > > Thomas Pfeiffer wrote: > > One of the mentioned use-cases is 'sharing the checksum' for which you > need to have it shown. > > Yes, but when you want to share the checksum, you don't want to verify > with it. That's the thing: The verification and the "calculate and show > checksums" feature serve different usecases. Either you already have a > checksum from somewhere anduse that to verify the file, then you only need > the paste box and the line below telling you whether it matches or not. If > you want to share checksums, you can safely ignore the paste box. > > Therefore it's fine if the collapsible area is below the paste box, as > there is no two-step process of first showing the calculated checksum and > then verifying with it. > > >> "Please be aware that the security and trustworthiness in the Internet > is a complex matter. Please inform youself about potential issues when > downloading files from the Internet and that checksums do not provide data > authenticity." > > >This might be a good solution. What do others think? > > Makes sense to me!
Oh btw, now that we're discussing the whole UI in this review request, anyway: Is there any feedback given while the checksum is being calculated when you paste a checksum intop the field? It should say "Comparing checksums..." in the line where then the result is shown, so that the user knows that they triggered a process by pasting the checksum, in case the calculation takes a while. - 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 > >
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
