Review Request 128466: Rename Checksums tab to Integrity
Olivier Churlaud
olivier at churlaud.com
Tue Jul 19 15:23:00 UTC 2016
> 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."
> ```
>
> 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!
>
> Thomas Pfeiffer wrote:
> 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.
>
> Elvis Angelaccio wrote:
> I think that replacing the current groupbox with a collapsiblegroubox might be the best solution:
>
> * It keeps separated the two use cases, even more separated than the current design. This should avoid any possible confusion.
> * The verification stays at the top of the dialog, which is good because verifying is much more common than sharing.
> * We could remove the three "Calculate" buttons and start the computation as soon as the box is expanded (though I'm not 100% sure this can be done without reading the file three times).
>
> If there is consensus on this proposal, I'm going to discard this review and open a new one :)
>
> Ivan Čukić wrote:
> @Elvis
>
> Seems QCryptographicHash does not have the support for this, so without reimplementing the hash functions (or stealing the QCH implementation), all the buttons are needed >:|
>
> Sebastian Kügler wrote:
> So the checksums tab is located in the file properties dialog, which is primarily an informational display. This dialog also holds the size, which is costly to compute, just like the checksum. The checksums tab serves two purposes: verify and display the checksum.
>
> The verification can either be done manually (I read the checksum over the phone to the dude who has to work in IT support), or I compare it with a checksum on some website right after downloading the latest rebecca black OS iso.
>
> Logically, having the checksum is a pre-requisite for comparing it, so a lineedit to paste a checksum which is then compared makes sense, but it's a helper tool. First and foremost, I trust nothing and nobody and want to actually see the checksum. (Also, if a checksum is different, it shows in the first few latters in the vast majority of cases, so a quick verification can easily done with the naked eye.) For those lazy bastards, who copy the checksum off the website, the lineedit is a handy tool.
>
> A problem I see with the three button approach is that it provides little guidance for the user: Which checksum do I want? I think a combo box to pick the algorithm with md5 as default (as it's the most widely used) would make this a bit nicer and easier to use.
>
> As a result, to me, a logical user interface would offer the following:
>
> - display of current checksum (possibly a hint that it needs to be computed first for files larger than N?)
> - a chooser (in the current approach, three buttons, I think one button + a combo would be nicer here, see above)
> - a way to make comparing easier (the lineedit seems like a nice idea)
>
> To me, this UI can be very easy, if done right, it displays, allows to compute (and pick the algorithm) and allows to compare (in that order).
>
> I think groupboxes, collapsible widgets and advanced sections make this much harder than it really needs to be. Simplicity can be achieved quite easily here, and we should aim for that.
As it was clear both sides had different understanding I spoke with Sebas and Thomas separately to understand what the issue was.
So Sebas has another user case:
You can get a hashsum over the phone or on IRC but without copying, you can just compare yourself (while reading) the X first characters of the hash with your file. So hidding the 'calculate' part is not a good idea. Also it means that the shown hash *can* be part of the verification process. Therefore it makes not so much sense to have grouping boxes. Furthermore, it's too engineered or visually complex to surround 1 lineedit on the one side, and 3 buttons on the other side in boxes.
Finally all that is about verifying the checksum. Either you (compare in the line edit or visually) or someone else (the previously called "share" user case). They belong together.
# New proposition
The proposition I do is the following:
In the tab called "Checksum":
A line edit (with explaining labels, tooltips, whatever): you paste in it and it becomes either red or green, with a label explaining what happened in the same color ("the checksum do not match, your file might be corrupted"/ "the checksums match, your life is beautiful"). **It should also state the type of algorithm used (MD5, SHA1,...)!**
----------A separation line------------
A list with MD5/SHA1/SHA256 (and later others?). 2 options IMO:
- for small **local** files you compute directly and display the hash, for others go to option 2
- have the name of the algo, followed by a [calculate] button, when calculated, the button is hidden and replaced by the hash string
sha1: [Calculate] then sha1: sjdljpfiljezflsjls
# Why does it work for both types of users
Someone like me or who does not know anything about hashsums will see on top a field where to paste the hash. He does it, get a green/red response and everything can be over here.
Someone like Sebas, who has no trust in this evil code written by Elvis (:P) will see what algo is used and be able to compare himself, visually, with the calculated string below, by clicking on the right [calculate] button.
Someone like Sebas or Ivan, who know the technicall part and don't want to use the text field, will directly click on the [calculate] button they are interested in and do whatever they want with the outcome (share, compare, ...)
# Finally
In my personal opinion, all has been said. Several designs were proposed and discussed. I think it's time for Elvis to have his enlighted choice. If it's not mine, I will think it's suboptimal, but that is life. If it's the very first one, Sebas will think it's suboptimal, but that's life. Because I'm not sure more consensus can be found.
- 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20160719/8dd07a72/attachment-0001.html>
More information about the Kde-frameworks-devel
mailing list