[tahoe-lafs-trac-stream] [tahoe-lafs] #964: show sizes in unambiguous way that doesn't get mistaken for different units

[tahoe-lafs]

#964: show sizes in unambiguous way that doesn't get mistaken for different units
------------------------------+-----------------------
     Reporter:  USSJoin       |      Owner:  zooko
         Type:  defect        |     Status:  assigned
     Priority:  minor         |  Milestone:  undecided
    Component:  code-storage  |    Version:  1.6.0
   Resolution:                |   Keywords:  usability
Launchpad Bug:                |
------------------------------+-----------------------

Comment (by Zancas):

 Replying to [comment:8 zooko]:
 > This is what people call
 [http://en.wikipedia.org/wiki/Parkinson%27s_Law_of_Triviality "a bike
 shed"]. The theory goes that few people are willing to contribute their
 opinions about designing nuclear power plants, because that is very
 complex and requires high expertise, but many people are willing to
 contribute their opinions about designing a bike shed, because it is
 simple enough that they can see how they would like it to be.
 >
 > ''(Aside: I don't really like that metaphor of a "bike shed" because it
 belittles the concerns of the contributors. I actually agree with USSJoin,
 davidsarah, and kmarkley86 that user interface issues are important,
 including this one. Don't forget that the original post by USSJoin
 explained how he actually lost some of his time due to confusion. Wasting
 user time is not okay! Also, a design being simple and easy to understand
 doesn't mean that it doesn't matter how it is done!)''
 >
 > However, this issue has now distracted both David-Sarah and Brian from
 [http://allmydata.org/trac/tahoe-lafs/milestone/2.0.0 building nuclear
 power plants]. Let's put a stop to the discussion. Our policy will be to
 express numbers in units that are as unambiguous as possible so that a
 user who assumes that "GB" means 2^20^ and a user who assume that "GB"
 means 10^9^ will both have a minimal chance of wasting their time with
 confusion. Specifically, the suggestions that Brian made in comment:7
 about redundantly listing the same value in different units would probably
 help.
 >
 > That's the main idea -- to make the user interface sufficiently clear
 (even at the cost of redundancy) that nobody wastes their time mistaking
 the units. I believe this policy will
 [http://en.wikipedia.org/wiki/Satisficing satisfice].
 >
 > We will continue to use {{{KiB}}} to mean 10^3^, {{{MiB}}} to mean
 10^6^, {{{GiB}}} to mean 10^9^, {{{TiB}}} to mean 10^12^ etc. as per
 http://en.wikipedia.org/wiki/Binary_prefix , and never use {{{KB}}} to
 mean 2^10^ etc.. However, as per the ''main idea'', above, we will
 probably try to reduce the use of {{{KB}}} at all in favor of less
 ambiguous designations.

   Oops....   isn't it {{{KiB}}} means 2^10^...  et cetera?   If I
 Understand Correctly the infixed "i" means base 2, and exponent increments
 of 10.

-- 
Ticket URL: <https://tahoe-lafs.org/trac/tahoe-lafs/ticket/964#comment:14>
tahoe-lafs <https://tahoe-lafs.org>
secure decentralized storage