> 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.
@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. - 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
