如何直观地表示文件大小
恐怕这有点主观，但我很重视集体的建议。
我们的网络应用程序列出了用户可以下载的文档；标准文件导航器内容：
Type Name Created Size ----------------------------------- PDF Doc 1 01/04/2010 15 KB PDF Doc 2 01/04/2010 15 MB
目前我们将文件大小列为文本，但我想通过某种方式直观显示文件是小、正常还是大来改进这一点。
这样做的原因是，用户可以快速扫描列表并发现可能需要很长时间下载的文件。
我目前的选择是：
- 较大的文件使用较大的字体（缺点：布局可能会变得杂乱）
- 图标（如 wi-fi 信号强度指示器；缺点：难以扫描）
- 将所有大小保留为 KB，以便零的数量表示大小（缺点：用户必须在头脑中计算“友好”尺寸）
我知道这是一件小事，但我很感激任何人对此事的想法！
编辑：感谢您的回答！
从您所说的来看，我认为：
- 我真的很喜欢罗伯特的想法，即告诉用户下载文件大约需要多长时间
- 正如有人指出的那样，如果我使用条形或“信号强度”图标，给人一种“最大”文件大小的印象
- 我喜欢对文本进行阴影处理 - 对于较大的文件更强
我将采用组合方法：
- 统一字体大小
- 对于较大的文件使用较暗的文本
- 一个工具提示，告诉用户下载大约需要多长时间
- 大小后面的一小段文字，放在括号中，描述它有多大，例如：
15 KB (tiny) 2 MB (small) 20 MB (big) 300 MB (huge)
我会看看是否可以在此处放一个屏幕截图，显示它的外观我有一个原型。再次感谢您的反馈！
This will be a bit subjective, I'm afraid, but I'd value the advice of the Collective.
Our web application lists documents that users can download; standard file navigator stuff:
Type Name Created Size ----------------------------------- PDF Doc 1 01/04/2010 15 KB PDF Doc 2 01/04/2010 15 MB
Currently we list the file size as text, but I'd like to improve this by having some way of showing visually whether the file is tiny, normal or huge.
The reason for this is so that users can scan the list quickly and spot files that are likely to take a long time downloading.
My options currently are:
- Bigger font sizes for bigger files (drawback: the layout can become untidy)
- Icons (like a wi-fi signal strength indicator; drawback: harder to scan)
- Keep all sizes in KB so the number of zeroes indicates size (drawback: users have to calculate the "friendly" size in their heads)
I know this is quite a minor thing, but I'd appreciate anyone's thoughts on the matter!
Edit: Thanks for the answers!
From what you've said, I think that:
- I really like Robert's idea of telling users roughly how long it will take to download the file
- As someone pointed out, if I use a bar or "signal strength" icon, that gives the impression of a "maximum" file size
- I like shading the text - stronger for larger files
I'm going to go with a combination approach:
- Uniform font size
- Darker text for larger files
- A tooltip telling users roughly how long it will take to download
- A tiny piece of text, in brackets, after the size, describing how big it is, e.g.:
15 KB (tiny) 2 MB (small) 20 MB (big) 300 MB (huge)
I'll see if I can put a screenshot on here of how it looks when I've got a prototype. Again, thanks for the feedback!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
如果是我，我会以通常的方式显示文件的大小，但也会显示估计的下载时间（假设您的计算为 1.5 MBit DSL）。
If it were me, I would show the size of the file in the usual way, but also display an estimated time to download (Assume 1.5 MBit DSL for your calculations).
长度取决于尺寸的条怎么样？这类似于 Wi-Fi 信号图标的想法，但扫描会更容易。
随着长度的增加，颜色将从绿色开始逐渐变为红色。
How about a bar whose length depends on the size. This is similar to wi-fi signal icon idea but scanning would be easier.
The colors would start out at green and go to red as the length increases.
如果您有空间，我会同意您的想法，将所有文件大小保持为恒定单位，因此数量级由消耗的位置数表示。使用右对齐的数字，可以很容易地扫描特定的数量级。
请记住，通过这种方法您可以获得大约三个位置的空间，因为您消除了单位列，而是将单位放入文件大小列标题中，因此这不会占用太多空间。要节省更多空间，请考虑将大小（以 MB 为单位）显示为 0.1 MB。对于当今宽带的下载持续时间，一旦考虑到服务器响应时间和变化，任何低于 0.1 MB 的内容似乎都具有大致相同的持续时间。它所花费的时间不会超过加载新网页的时间，并且用户不期望/不需要对此进行持续时间估计。对于小于 50kB 的文件，您可以将其写为“under 0.1”。如果您确实需要空间，也许解析为 1 MB 就足够了。
文件大小的线性图形表示（例如条形图）更适合评估相对下载时间。但是，当您的下载持续时间跨越三个或更多数量级时，我认为它无法正常工作。用户可能希望区分 5 分钟和 10 分钟的下载，因此您需要大约 2 MB 的视觉上明显的差异。我想说，对于 2 MB 的条形图，您至少需要 3 个像素，这几乎排除了表示 1 GB 或更大的文件的可能性。
您可以尝试用单独的图形线性表示 GB、MB 和 kB，但众所周知，此类显示很难读取且难以扫描（例如，由于读取错误，多指针高度计已在飞机上很大程度上被放弃）。除非您的用户接受过培训或拥有丰富的经验，否则我不会尝试类似的操作。
尝试使用图标、颜色、字体大小或符号数量对文件大小进行排名或分类是有问题的，除非您知道适合用户的断点。但是，您可能无法知道，因为可接受的持续时间阈值将根据用户、他们的设备和他们的情况（他们有多少时间）而变化。我不会对任何文件大小使用红色，除非您希望某些用户认为该文件太大以至于下载可能会损坏他们的计算机或导致其他一些技术问题。
有利于排名的代码（例如字体大小和符号数量）也可能存在问题，因为当您可能需要使用对数变换时，用户可能会认为它们与时间线性相关。以恒定单位写出大小不会出现此问题，因为很明显位数与大小呈对数关系，即使对于不知道什么是对数的用户也是如此。如果您想尝试某种排名符号，我建议用 3-D 实体的体积（例如，各种尺寸的立方体）来表示尺寸。这可能有助于用户理解一步意味着尺寸的非线性增加。当然，任何使用多个维度的图形编码都可能在表中出现行间距问题。
如果您无法使用常数单位，那么以图形方式区分 kB、MB、GB 符号是一个不错的选择。我会考虑使用字体粗细。它在某种程度上是可扫描的，但其真正的功能是增加用户注意到不同单位的机会，而不是帮助扫描特定大小范围的文件。如果用户无论如何都要下载文件，但只是希望能够计划下载时间，那么这很好。
实际上，如果任务确实是关于用户查找特定大小范围的文件，则按文件大小对列表进行排序或过滤（默认情况下或作为用户选项）可能是最好的解决方案。
If you have the space, I’d go with your idea of keeping all file sizes in constant units so the order of magnitude is indicated by the number of places consumed. With right-aligned numbers, that will make it easy enough to scan for a particular order of magnitude.
Keep in mind you gain about three places of space with this approach because you eliminate the units column, instead putting the units in the file size column header, so this won't be that much of a space hog. To save a little more space, consider showing sizes in MB resolved to 0.1 MB. For downloading duration with today’s broadband, once you account for server response time and variation, anything under 0.1 MB is going to seem to have about the same duration. It'll take no longer than loading a new web page, and users don't expect/need duration estimates for that. You can write it as “under 0.1” for files less than 50kB. Maybe even resolving to 1 MB is good enough if you really need the space.
A linear graphical representation of file size (e.g., a bar graph) is better for assessing relative download times. However, I can’t see it working well when your download durations span three or more orders of magnitude. Users will likely want to distinguish a 5 versus 10 minute download, so you need a visually noticeable difference of about 2 MB. I'd say you need at least 3 pixels for 2 MB for a bar graph, which pretty much rules out representing files of a GB or more.
You could try to linearly represent GB, MB, and kB with separate graphics, but such displays can be notoriously hard to read and harder to scan (e.g., multi-hand altimeters have been largely abandoned in aircraft because of reading errors). I wouldn’t try something like that unless your users get training or a lot of experience with it.
Trying to rank or categorize files sizes with icons, colors, font size, or number of symbols is problematic unless you know the proper breakpoints for your users. However, you probably can’t know because the threshold of acceptable duration is going to vary by the user, their equipment, and their situation (how much time they have). I wouldn’t use red for any file size unless you want some users thinking the file is so large that downloading might damage their computer or cause some other technical problem.
Codes good for ranking, like font size and number of symbols, may also be problematic because users might assume they are linearly related to time, when you’d probably need to use a logarithmic transform. Writing out the sizes in constant units doesn’t have this issue because it’s clear the number of places is logarithmically related to size, even for users who don't know what a logarithm is. If you want to try some sort of ranking symbol, I suggest representing size by the volume of 3-D solids (e.g., various sizes of cubes). This may help users understand that one step means a nonlinear increase in size. Of course, any graphic coding using more than one dimension can have row spacing issues in your table.
If you can’t use constant units, then graphically distinguishing the kB, MB, GB symbols is a good alternative. I’d consider using font weight for that. It’s somewhat scanable, but its real function is to increase the chance of users noticing the different units, not to help scan for files of a particular size range. This is fine if users are going to download the file anyway, but just want to be able to plan for the download time.
Actually, if the task really is about users finding files of a particular size range, sorting or filtering the list by file size (by default or as a user option) is probably the best solution.
如果您只有一个范围步骤（即只有 kb 或 mb，或者只有 mb 或 gb），那么我会使用大小 + 最低单位。例如。 15000kb，15kb。如果你必须这样做，kb，mb，gb 那么这是行不通的。
在大小后面加上简单的 + ++ +++ 或 $ $$ $$$ 来显示 kb、mb、gb 怎么样？
If you only have a single range step (ie only kb or mb, or only mb or gb) then I would use size + the lowest unit. eg. 15000kb, 15kb. If you have to do, kb, mb, gb then that isn't going to work.
What about a simple + ++ +++ or $ $$ $$$ after the size to show kb, mb, gb?
进度条样式的大小指示器怎么样？
另一种方法是灰度缩放：小文件为浅灰色，大文件为黑色。
What about a size indicator in the style of a progress bar?
Another way would be gray-scaling: Tiny files light-gray, big ones black.
使用颜色怎么样？类似于：
，或者适合您必须处理的文件类型的任何其他规模...
您可以将这些颜色放在描述文件的行的背景或文本颜色上，或者放在接近大小的图标上...
What about using colors ? Something like :
or any other scale that fits the kind of files you have to deal with...
You could put those colors either on the background or text color of the line describing your file, or on an icon near the size...
尽管对数标度肯定是必要的，但有很多很多方法可以做到这一点。我建议使用一个字段，该字段的字符更大，并且对于 1000 或 1024 的每个幂重复次数更多。如下所示：
There are lots and lots of ways of doing it, although a logarithmic scale is definitely going to be necessary. I suggest using a field which has a character which is larger and repeated more for each power of 1000 or 1024. Like this:
我喜欢 KB 的想法 b/c 更大的数字会脱颖而出。然后设置限制，并可能使用 css 颜色来突出显示...绿色表示时间较短，红色越深，时间越长，等等。
I like the KB idea b/c bigger numbers will stand out. Then set limits and possibly use css colors to highlight... green is shorter times, the darker the red, the longer, etc.