Counter in a corner of a button

I'm creating a user control which is essentially a wide tile-like button (think Windows 8 "wide" start menu tiles), but in the upper-right corner there's a darkened area which contains a counter. This number can range from 0 to 99999 (well, technically the number can be even larger, but real-life scenarios shouldn't see it go above 20000 which is 5 digits).

The buttons also have a white icon in the middle, which won't be visible in the following screenshots.

The problems are as follow:

a) If there's a small number, it looks... badly out of place. It can be scaled to take up more space, but then two tiles with different numbers (one with few digits, one with many digits) look strange, because the numbers are now of different display sizes

b) I've tried rotating the number inside the counter 45 degrees, which gives me more horizontal space to work with. This sort-of removes the display size issue, but, well, now the user has to read the number at a strange angle.

c) I've also tried setting up a max number limit (say, 999), and if that number if exceed display a + at the end (so it becomes a 999+ and doesn't grow any more). This limits the amount of information the user receives somewhat (albeit if the numbers DO grow to such values then the user doesn't really loose much information - they know the number if high, which is important), but I still need enough space to fit at least 4-characters...

All in all, this is a minor UX issue I'm facing, but one that's been bugging me for a while. I wonder what's the best way to tackle this.

EDIT: I might also add - buttons are displayed on a Windows Metro-like grid, so they are next to each other. Not all buttons have counters. Currently, if a button doesn't have a counter, the darkened area simply doesn't show at all.

EDIT 2: I should also note - the number displayed is... well, I'm having a bit of trouble judging how important it is to the user. The buttons represent tasks of varying types assigned to workers (users). The counter is to represent how many tasks of each type have been assigned. Some buttons are tasks not assigned in the system, so those don't have counters. Otherwise, to me, it seems the most important information is not really how many tasks are assigned, but:

• if there are any tasks assigned or not
• if the number of tasks has changed
• the general scope of assigned tasks - 10s? 100s? 1000s?

Thus I was willing to go with somewhat less readability for more aesthetics.

EDIT 3:

A friend of mine suggested the following:

• PS. This is my first question on UX.StackExchange - I'm not entirely sure I've selected the right tags for the question... – Shaamaan Apr 8 '16 at 7:18
• You might want to round the number to thousands. Instead of displaying 999+, make it 1.0k (like StackExchange does with rep counts) – Bergi Apr 8 '16 at 11:53
• @Bergi That's an awesome idea too! – Shaamaan Apr 8 '16 at 11:59
• I really your friend's idea. – martijnn2008 Apr 9 '16 at 9:26
• @martijnn2008 You really "like"? "Hate"? There's an adjective missing there. Also, feel free to turn it into an answer if you think this is a good idea. – Shaamaan Apr 9 '16 at 17:47

Are you restricted to using an angled corner?

If not, a box would be much more simple & sleek.

Otherwise if you are stuck using the angled corner, aligning to the top right rather then center is probably your best bet!

• I'm not at all stuck with an angled corner, but the non-angled solution looks far worse than the angled corner one, at least IMHO. It IS more readable, that much is true, but I'm trying to keep the whole experience as aesthetically pleasing as possible. – Shaamaan Apr 8 '16 at 9:49
• I will have disagree here. It does look better in my opinion but more importantly it removes the needs for shenanigans with angled corners that do not improve the experience. Clarity is priority, especially if it has arguably minimal impacts on the looks. Obviously, I have not seen your design specifications so it's really up to you. What is your thoughts about top-right alignment? – alexbouchard Apr 8 '16 at 9:51
• The top-right alignment is how it's been currently done (perhaps the margins were different on my part). It's readable, yes. The issue is that without automatic scaling, single-digit numbers look odd when surrounded by so much free space, especially when a nearby button has a number with more digits for comparison (while with scaling they look odd because they are of different size). – Shaamaan Apr 8 '16 at 10:01
• Right, it looked more vertically centered. It's true that it looks odd with less numbers which is why I'll stick with the box ;) Good luck! – alexbouchard Apr 8 '16 at 10:04
• Diagonally-slanted numbers is a certain no (IMO). Of the other options, including trailing zeroes serves no purpose other than adding cognitive load for a user to scan/parse numbers and determine what the number ACTUALLY is. I think your solution with the number in a box in the top right is pretty fine and functional; how do you feel about inverting the regular label colors, for your number label? That is, make the box containing your number a white background with bright-blue colored text on it for the # value? – HC_ Apr 9 '16 at 0:01

One option you may try is to make the dark area variable, depending from the number of digits. This way the dark area will also work as a visual cue, indicating the magnitude of the number.

• I think this is arguably the best solution. First of all, it requires the least changes to the existing design, secondly it is a solution that not only solves the original problem, it enhances the design as well. By varying the size of the angled section with the scale of the number, you create an implicit cue for relative proportion, should that be relevant. This means it requires less attention by the user to parse relative scale. Excellent +1. – mechalynx Apr 8 '16 at 19:03

Scaling of text according to the size of the sample, on comparable images, more often than not results badly. Lets try to work around that.

Small numbers (as in single digit numbers) might look too isolated and unaesthetic when appearing on a bigger canvas.

This can be avoided to an extent by making the ten's place hold a value by default (0 in our case). For example,

Let this pattern be followed by the numbers till '99', and then just go as one normally would, like,

If the number is relevant to the user (it shouldn't be there in the first place if its not, so I'm guessing it is), don't truncate it, unless you are planning it to display the whole number on hover/focus. As long as you manage to place it aesthetically, the size shouldn't matter.

On a side note, I suggest not to place any text at an angle to the viewpoint of the user, unless its in a totally informal setting. I assume the given canvas is not the finalized version, so it'd be worth to mention that the whole control might look more elegant if you reduce the font size by a bit and tweak it's placement. Like,

Good luck with the project.

• Reducing the font emphasizes the problem of smaller values (fewer digits), unless they are padded with 0s even more (like to 001)... – Shaamaan Apr 8 '16 at 9:53
• You have to find that sweet spot where the looks wont compromise the functionality. The amount of padding should be limited to 3 at the most in my opinion. – JaikGeorge Apr 8 '16 at 10:13
• Padding the number makes the magnitude of the value difficult/slower to parse at a glance (its no longer enough to just look at the width of the digit sequence). This might be important for user experience if there are many such values and if their magnitude is important. – Waterlimon Apr 8 '16 at 15:46

Have you tried shifting the values based on the number of digits?

In other words, set the vertical offset for the single-digit numbers to remove the empty space and then move the numbers upwards as the number of digits increases.

The plus side of this approach is that now, in addition to the visual- length-based sorting already present, height-based sorting will also be able to be used, since lower values will be lower on their icons.

• The buttons are displayed in a grid (again, think Windows 8 start menu). While the vertical offset might not be apparent when looking at two buttons (one underneath the other), it'll be very apparent when viewing two buttons side-by-side, causing a strange "this counter doesn't fit" effect - same as I had with the automatic scaling of the counters, where single-digit counters were larger and looked "weird" near other, larger counters. – Shaamaan Apr 9 '16 at 17:45