5

Is there any established standard or research about what the cut-off point should be for moving to the next unit prefix e.g. moving from "kilo" to "mega"?

I assume it may depend on the unit itself, so I'm specifically asking about bytes (or bits), for example when displaying download progress / remaining.

One approach I've seen is moving as soon as it goes above 1000 (or 1024), e.g. 1000 kbit becomes 1 Mbit. However, it's not uncommon to cut off before that: I've seen e.g. camera manuals say "0.8 MB" rather than "800 KB" for the size of a photo.

7

Recommendation: Don't change units based on the progress of the download

However, it's not uncommon to cut off before that: I've seen e.g. camera manuals say "0.8 MB" rather than "800 KB" for the size of a photo.

Well, the thing with documentation is you should be consistent and not change between units. Hence the use of 0.8 MB in the camera manual (chosen because MB is currently the most common unit when taking about photo size). You don't want a user to think 800 KB in bigger than 80 MB just because they lost track of which unit you had changed to using.

One key thing though is to make sure you don't mix and match units when providing comparisons. For example, don't say "800 KB / 11 MB". That same rule applies when displaying a table of available downloads, don't say:

  • File 1 = 800 KB
  • File 2 = 80 MB
  • File 3 = 0.8 GB

Instead pick the most common unit, and use that for all:

  • File 1 = 0.8 MB
  • File 2 = 80 MB
  • File 3 = 800 MB

Basically: If it is easy for the user to visually compare 2 or more values, than make sure they are the same unit.


for example when displaying download progress / remaining

So, with regards to your example. If we agree you can't mix and match units then the obvious question is: should the "total download size" ever change units? (E.g. 800 KB / 8000 KB later becomes 1 MB / 8 MB as the download progresses)

I would say the answer to that should be no. The total download size should be constant through the whole process. Therefore, you should also fix the unit for the progress size too.

Determine the most appropriate unit for your "total size" value and then fix your "progress value" to use the same unit. Don't change it part way through.


Direct Answer: Switch at 1000 (or 1024)

If after all that then you still want to change units as the value progresses, then I would suggest doing it once it gets to 1000 of them (or 1024 if more appropriate). The reason for this is because it shows a more accurate and useful value for longer.

For example, consider the transition of MB to GB. If the user has a speed of 1 MB/s then this:

799... 800... 801... 802... 803

is more useful to the user than:

799... 0.8... [insert 100 second wait]... 0.9

6
  • Good point on consistency, I guess this doesn't really answer if 0.8 MB is preferred over 800 KB if consistency is not a factor, but seems the vast majority of existing tools just cut off at 1000. – fstanis Jun 17 '20 at 15:36
  • @fstanis: There you go, I added an explicit answer to the question you asked. – musefan Jun 18 '20 at 5:33
  • “Switch at 1000 (or 1024)” No, never switch at 1024! 800, 900, 0.9, 1.0, 1.1 is better than 800, 900, 1000, 1.0, 1.1. – Crissov Jun 18 '20 at 11:38
  • @Crissov: I am not saying you are wrong. However, what if the download is 1010 bytes in total, for example? (let's say in a situation where data transfers at 1 byte per second) Displaying 1MB at any point could be seen as inaccurate. NOTE: I would use a better example of MB > GB but it's too early to open my calculator :D – musefan Jun 19 '20 at 6:33
  • 1
    @musefan My point was that one should never switch to four digits for what is usually a very brief moment before returning to (max.) three digits. – Crissov Jun 19 '20 at 6:38
0

As far as I can tell, there's no official established standard, but there are some good examples being used by countless people worldwide. If we were to use some operating systems and command line utilities commonly used by many as an example to learn from, the behavior varies a fair amount.

In terms of bytes to kilobytes, Mac OSX, as well as the commonly used command line program, ls (with -lh options added), will display up to "999 bytes". It changes to "1 KB" when the size of the file is 1000 bytes or more. On Windows, it will display "1 KB" even before 1000 bytes.

While the behavior here varies, I think it's most common to round up to 1 KB when at 1000 bytes or more.

When going beyond 1 KB, ls will display the kilobytes rounded to the nearest tenth, accurate to the full byte value (e.g. 1.5 KB is equal 1536 bytes not 1500 bytes). Mac OSX does the same rounding but only displays the whole numbers.

This seems like a good convention to follow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.