fluid-work Digest, Vol 16, Issue 9

[Daphne Ogle]

I think you've got the right idea Eli.

It seems to me that users that don't understand the measurement  
probably wouldn't understand the measurement even if we used the same  
scale.  Those users, as you say likely ignore the measurement  
indication and  are probably more interested in how long it will take  
to upload.  They get great feedback with our progress indicator about  
that.

My 2 cents...

-Daphne

On Jun 4, 2008, at 8:57 PM, Eli Cochran wrote:

> Well, the 0K files were really a rounding error. Adding the decimals  
> would have fixed that problem.
>
> But thanks for the vote of confidence.
>
> - Eli
>
> On Jun 4, 2008, at 8:25 PM, Justin Obara wrote:
>
>> I would agree with that. This would also solve the issue of why
>> four 0KB files might equal 2KB in the total section.
>> Justin
>> ----- Original Message ----
>> Date: Wed, 4 Jun 2008 13:51:38 -0700
>> From: Eli Cochran <eli at media.berkeley.edu>
>> Subject: bytes, kbytes, megabytes, and gigabytes
>> To: fluid-work <fluid-work at fluidproject.org>
>> Message-ID: <F4A27F75-0BDC-4302-99C3-C119A2D7FDAA at media.berkeley.edu>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> 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
>>
>>
>>
>>
>
> . . . . . . . . . . .  .  .   .    .      .         .              .                     .
>
> Eli Cochran
> user interaction developer
> ETS, UC Berkeley
>
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work

Daphne Ogle
Senior Interaction Designer
University of California, Berkeley
Educational Technology Services
daphne at media.berkeley.edu
cell (510)847-0308



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.idrc.ocad.ca/pipermail/fluid-work/attachments/20080605/2ca9b798/attachment.htm>