我正在进行一个关于进度指标的研究项目(我可能会扩展到GUI的更多元素)，我希望在图形设计方面(不寻找编码等)收集尽可能多的材料，以及它们在历史上的外观和今天的使用。
我正在寻求帮助，在过去找到任何进度指示器的例子，我相信施乐Parc是第一个GUI，所以假设这将是第一个在这种情况下找到进度指示器的地方。我也希望你能帮我找到关于他们的文章。基本上，任何你能想到的与进度指示器相关的东西，电脑，电子游戏，包括它们今天的使用情况(我将对pi的当前趋势和发展进行调查)。
任何有帮助的，提前感谢!
艾萨克老好人Robert Bell写了一篇关于这个主题的好文章。
http://chrisharrison.net/projects/progressbars/ProgBarHarrison.pdf我还听说有些软件实际上在进度条上延迟，好像用户认为软件已经安装或加载得非常快——这是一个问题，但我找不到任何可以进一步解释它的细节。
我刚读过的东西
http://developers.slashdot.org/story/13/02/13/0026234/ask-slashdot-why-is-it-so-hard-to-make-an-accurate-progress-bar进度条不应该基于时间，它们应该基于工作量。通常当他们做字幕式的进展时条(只显示动画，不显示实际进度)，它的意思是数量不详。这在很多情况下都会发生由于数据的原因，要处理的总步骤数未知，或者计算总数所需的时间
进度条也应该是与时间估算不同的主题因为它们不一样。我有100件事要处理，所以我的进度在1到100之间。这需要多长时间完全取决于我我处理。如果我在处理发票，那么需要多长时间这在很大程度上取决于发票所涉及的内容(行项目，计算，其他查询)。
仅仅因为花了10秒来处理最后一个并不意味着处理下一个需要10秒。为了…确定还剩多少时间，大多数人所做的就是把剩余的数量乘以到目前为止的平均时间。你可以对平均值应用平滑(这样它就不会在a周围跳跃Lot)，但除此之外，你还怎么估计时间呢?如果处理项目所需的时间是相当均匀的，你的估计将非常准确，如果他们之间有很大的不同项目，那么你的估计就会到处乱跳，然后非常不准确的。