> On July 18, 2016, 2: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." > ```
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 - Olivier ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128466/#review97521 ----------------------------------------------------------- On July 16, 2016, 2: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, 2: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
