开发者

How to visually represent file size

开发者 https://www.devze.com 2022-12-26 09:52 出处:网络
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:

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!


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).


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.


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.


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 :

  • green if the file is less than 1MB
  • yellow if the file is between 1MB and 10MB
  • red if the file is more than 10MB

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...


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:

Type   Name     Created       Size
-------------------------------------
PDF    Doc 0    01/04/2010    15  B 
PDF    Doc 1    01/04/2010    15 KB .
PDF    Doc 2    01/04/2010    15 MB ::
PDF    Doc 3    01/04/2010    15 GB |||
PDF    Doc 4    01/04/2010    15 TB TTTT
PDF    Doc 5    01/04/2010    15 PB PPPPP
PDF    Doc 6    01/04/2010    15 EB EEEEEE


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消