bytes, kbytes, megabytes, and gigabytes

[Eli Cochran]

We've been talking here at Berkeley about how best to represent file  
sizes in the Uploader. Most OSs display the unit of measure for a file  
depending on the file size, similar to how we would measure a pickle  
in centimeters, a tree in meters and a football field in, well,  
football fields.

So a file that is 465 bytes would be represented as 465 bytes*, a  
40,650 byte file is shown as being 40 kb, and a 4020650 byte file as  
4MB (or maybe 3.8MB).

This works when all the files are similar sizes; big files compare  
well with other big files, small to small. But when you start having  
big and little files in the same list then the different units of  
measure are potentially confusing. Is a 465 byte file smaller or  
larger than a 40 kb file?

Many users understand this stuff because, rightly or wrongly, this is  
just the way computers work. But many users may never have noticed or  
never cared (and may still not care.)

So should we use one consistent measure? I think not.

There are a number of good arguments for following the OS scheme. But  
the one that tips it over the edge for me is consistency. And not the  
"let's be wrong for consistencies sake" consistency. But more because  
users need to map their files in the OS, with the files that they are  
uploading. And if a user loads up a 2.3MB file (by the OS measure) in  
the Uploader that is then displayed as being 2355.2kb, they might  
think we grabbed the wrong file.

My plan is to represent all files less than 1kb in bytes, between 1kb  
and 1024kb in kilobytes (kb) and those files 1024 kb and above in  
megabytes (MB). With 2 decimal places... seems fine.

Should I also display files over 1024MB (those very rare files that we  
would have a hard time handling anyway) in GB?

Thanks for reading through this long post.

- Eli


* 1k (or 4k) which is partly for clarity and partly because of the  
amount of space that small files take up on hard disks.

. . . . . . . . . . .  .  .   .    .      .         .              .                     .

Eli Cochran
user interaction developer
ETS, UC Berkeley