It's not clear what "Size" in Upgrade summary means

[Templayer]

In this example, we have three Debian packs. One with a positive Size, one with a negative one, and one with a zero.

This is confusing as heck.

I think those are actually "Size differences" and not "Sizes". Unless it's a proper bug.

If I'm correct, the best solution (at least in my opinion) would be to use the string "Size difference" if the pack in question is already installed and it's an update. If it is a new piece of software, use "Size" (because that makes more sense for new software, I think).

Now that I look at it, it is an update screen, so in that case, use "Size difference". Same for the line starting with "Will be upgraded". The line "Update size" at the start should probably be "Update resulting size"? Because it is negative in this case. EDIT: Nah, it should be "Update resulting size difference". :P

[vinifmor]

I believe just adding the "+" sign for positive sizes would help the users to understand that is a size difference (since for negative values the sign is already present)

[Templayer]

Oh, yeah, that would work too.

[vinifmor]

It would look like this:

[Templayer]

Two things - something I should have noticed previously but didn't - why are you using bits instead of Bytes? (eg. Mb versus MB)

"It's easy to confuse the two, but bits are much smaller than bytes, so the symbol "b" should be used when referring to "bits" and an uppercase "B" when referring to "bytes"." Source / more info: https://simple.wikipedia.org/wiki/Byte

Second - the things in parenthesis should probably be separated by a comma, a ";", or a "|" (probably the last symbol because that is what you have been using up until now, for the sake of cohesity).

That means that "(Amount: 26. Size: +374.90 KB. Download: 52.46 MB)" would become "(Amount: 26 | Size: +374.90 KB | Download: 52.46 MB)"

It's even more complex for kilobytes (the first link contains info about the "kilo" prefix, while the other states the various ways those can exist for bits and bytes and such AND it also states the reasoning behind it all)

• https://physics.stackexchange.com/questions/579853/kg-or-kg-notation
• https://ux.stackexchange.com/questions/13815/files-size-units-kib-vs-kb-vs-kb

Spoiler: KB (and MB, etc.) should be used by default, with KiB (and MiB) should be an option in the settings (for server users).

From the second link: "Enterprise or technical users are a special case. If your app is measuring disk or database usage on a server farm, that 8% difference for a GB is huge, and you should allow the user to specify how you display kilobytes, even including a KiB option. These are probably your only users who would care enough to differentiate."

While not strictly necessary (the ...iB stuff), it would make the application look quite professional.

And also I'm not sure how are you currently solving language-dependent decimal separators. For example, in the Czech language, the line "(Amount: 26 | Size: +374.90 KB | Download: 52.46 MB)" would become "(Počet: 26 | Velikost: +374,90 KB | Ke stažení: 52,46 MB)" - notice the commas in values instead of dots. In projects, we would usually have a method called something like formatToString(Float float, ...) or formatToString(Double double, ...) that would take a float or double and some additional parameters (like the number of needed decimal spaces and if trailing decimal zeroes should be removed, etc.) and format it, getting the current Locale. In Java, any Locale object has a decimal separator declared, so that can be used to build the string. In C#, things can be even more streamlined by using extension methods.

I work as a programmer in corporate, so I have to deal with this bullshit pretty much every day. :D

[vinifmor]

The changes you proposed were welcome and now available on the staging branch (except the bit based sizes, that should be opened as a separate feature suggestion)

[Templayer]

True enough, that's pretty much a "cherry on top" feature.