In the application I am designing we are currently just displaying a circle that rotates clockwise from gray to green. Inside the circle is a number indicating where in the process it is (20, 50, 90). Is it breaking usability if we do not display to the user that it is a percentage?
7 Answers
Yes, always show your units. As my maths teacher used to say:
Ninety what?...Elephants?
The problem is that people are used to seeing the percentage symbol with percentages. Therefore, it is in fact conspicuous by it's absence. That makes people think and the point is to make a UI where people don't have to think - at least not where they really don't need to.
This example simply makes users think: "I'm expecting a percentage here. I mean it makes sense to be a percentage. It looks like a percentage, but there's no percentage symbol, so maybe it's not really a percentage after all. Maybe it's a mistake. I'm really not sure, so how can I tell. I guess I'll wait and see if it goes up to a hundred. OK it got to a hundred, but was that a coincidence? What will it do next time? Will it be a different number?
Avoid all these questions and include the symbol. Don't think of the symbol as an embarrassment to the design. It adds value to the communication of the value to the user, and that's what counts. Don't fall victim to form over function.
When including the percentage sign, I would include it at the same size as the font used for the numbers. It seems the percentage sign should typically be aligned with the font baseline and not extend above the ascender line of the numerals to which it relates:
As to whether you need a space between the number and the sign - that's another question, and may vary between geographical location!
-
3Oh, all the time I saw 50 on progress bar I thought they were potatoes. And I thought "%" was a symbol of two potatoes on branch... Commented Apr 4, 2013 at 13:25
-
1Just to be pedantic, a percent is not a unit, it simply means a value "out of 100". Percentages tend to be unitless because the unit is removed by division. E.g. 8 potatoes / 10 potatoes = 0.8 because the units cancel out.– devios1Commented Apr 4, 2013 at 22:29
-
In some languages they consider it a unit - eg French (including French Canadian), but fair point, it's not really a unit. Commented Apr 5, 2013 at 7:16
If you are displaying a percentage, it's best to label it as a percentage. The %
doesn't have to be the same size or as dark even as the main number, but is gives a lot more clarity at a low cost. In fact, any number without units is meaningless unless it actually has no units.
Example:
Yes, always mention the unit. Your design should be as clear and as unambiguous as possible. If you do not wish to "spoil" your graphics with the % symbol, you can always add a note beneath the circle '% value' or 'Percent value' or something along this line.
Consider a color-blind user. By having both number (and I agree with showing the units) and the graphic, you increase the usability of the data visualization piece.
Yes, but what about counting down from 100 to 0? That I think is something which will not be misunderstood as unbounded or arbitrary - after all, who would expect it to ever go below 0?
-
I see your thinking, but this would imply that there are N items left to load/process when that isn't what's happening at all. In some situations the difference may not matter, but in some it will make a difference. Commented Apr 5, 2013 at 11:31
If you're going to show a number, you need to add its unit. Especially in applications where it might be that a number of tasks share a progress bar. It appears we're in agreement on that.
However, my experience, I guess like that of chaiguy, is that it's impossible to be accurate in representing progress. I've you've completed 5 tasks out of 10 that doesn't mean you're halfway done: tasks #8 might take twice as long as task #3. If your application can guess that its spent 2 minutes out of an expected 4, we still can't be sure we're halfway done for that same reason. Something may come up (and always does).
So, numerical counters indicate an accuracy that isn't there. It's like in science where you can't say that 2 + 2 = 4.0 because you can't have that extra digit of accuracy. If your prediction of progress is not accurate enough to support a scale from 0 to 100, don't show percentages.
Users know to mistrust progress-bars, because they've always been wrong. Experienced users will use their own experience to create an estimate of how long it will take. Give them information that helps build this estimate. Tell them that you are moving 5 gigs of data, or that you're doing 10 tasks. But don't bluff on your accuracy for predicting progress because you don't want to show information to a user that the user knows he or she cannot trust.
I'm really surprised that all of the answers to this so far have been "yes". I have to disagree that there's a significant benefit to displaying the percentage value numerically over simply representing the progress graphically.
Let's first of all agree that the real purpose of a progress bar (in most cases) is to show the progress of an operation that takes a certain amount of time to complete, and therefore its intention is to give the user enough information to gauge roughly how much longer the operation is going to take.
Therefore, displaying the percentage of progress with numerical accuracy has no significant advantage, since the end purpose (gauging time) is still at best a rough approximation.
I would argue that it is in fact much more valuable to display a computed estimate of time remaining than to display the progress numerically. After all, does the end user really care whether an operation is 49.5 percent complete versus 50.1 percent complete? Either way it's "roughly half done".
100
so that users are cued in to the idea that the number shown is X out of 100.