Tag Info

Hot answers tagged

63

Best solution will be to increase the size of the box. If you can do it without changing the layout, it is good. For reducing the font size, I would suggest use a single size rather than going descending. It is easier to read. And, if you want to do 'k' representations, make sure the user has some way of accessing the actual number, via a tooltip or some ...


36

Your layout should support your content. First content, then appropriate layout. You can not easily break the physical constraints (like small screen), but maybe even your biggest number could be placed as separate line at smallest screen. Also I would recommend to keep in mind three stages concerning software: Useful (Functionality) Usable (Usability) ...


32

Something which is done here in stackexchange is using colors in combination with k's to display weight (and I'm guessing m's as well). Look at how different colors represent different weight, in combination with the k's, you're receiving something which is unmistakably usable & understandable Reading further: Have you considered adding a ...


9

Make the box big enough to contain any likely price. If your app has prices that might go up to six figures, make the price box big enough to take a six figure price. Do this even if you have to change the layout, even if real estate is limited and you have to sacrifice something else to make room for it. Don't use "K" or any other abbreviation to try to ...


9

As a programmer, I prefer the line breaking to happen at the boundaries of words (assuming your assessment that line breaking is needed is correct). However, I would change the way you break. Instead of continuing at column 0, I think you should continue at the same column as the line you are breaking, and you should indicate somehow that it is not a real ...


7

Wrap the data with an elipsis at the end. What this does is, it uses known vocabulary to show there is more than what is visible. AAAAAAAAAAAAAAAAAAAAAA becomes AAAAAA... then you can use a tooltip to show the entire content, use hyperlink or the column can be expanded, depending on your design.


6

Breaking up words/names is a bad idea for the simple reason that it's hard to tell where the function name begins and where it ends. Names can be abstract which makes them even more difficult for the brain to stitch back together. The first just feels more natural and although still difficult to read, you quickly can understand that text is wrapping and ...


6

Is the size of the box a limitation as was asked? The only reason I ask this is due to the fact that you can probably change the size of the box to the width of the largest price you have and set it as a fixed width for the box. Then center the price inside the box and you'll know that no other prices can exceed the width because you've buffered it using the ...


6

You could compromise on a mouse over for all digits (if that's an option), or you could make the trailing digits smaller / slimmer (if you have the resolution). I tried with Calibri + Arial narrow, this doesn't buy you much: (FWIW when using 'k' I'd use a small one, it distinguishes better from the digits and is SI-Correct. no such luck with 'M for ...


4

There is a third approach, text-overflow: .shorten { white-space: nowrap; overflow: hidden; -o-text-overflow: ellipsis; -ms-text-overflow: ellipsis; text-overflow: ellipsis; /* or "clip" */ } See dev.w3.org for more information.


3

One option is to set a minimum width on the code container and let the user scroll horizontally. Code that wraps unexpectedly is confusing at best, and in languages like Python it will appear completely broken. (This would be overflow-x: auto or scroll on the code element's parent in CSS.) 80 monospaced characters is often the default line length.


3

I have never heard of any wrapping algorithm that would break up words on anything but syllables (or soft hyphens). So breaking up a words at any arbitrary character is certainly not advisable. For programmers words in code are identifiers or operators etc. They only have meaning as a whole. So in this contexts even breaking up on syllables is ill-advised.


2

Make a toggle: Linebreak [yes] or [no]. Depending on the programming language being displayed, inserted linebreaks will alter the execution of the code. Once you do break the code onto a new line, indicate this by adding the linebreak character at the end of the line. With a toggle you will be able to give the user of your application the option of making ...


2

I know the good way of wrapping for humans, including developers. The first way. You don't break words. If you do break words, they are not readable anymore. When reaching the wrap point, you may make it clearer that the line continues, by putting at the right a symbol like an arrow ⤶. Nice text editors do that.


1

Scientific notation would have you display this as: 1.23e5, it's more 'correct' when it comes to units: 1.23e5 m is right, whereas 123k m isn't (it should be 123 km). However if your users aren't comfortable with the 'k' postfix then I doubt they'd like this much, I merely mention it for completeness. Other possibilities might be to have something like: ...


1

It's hard to say without knowing more, but here are some possible options: Make all boxes resize so they are all as large as the one containing the biggest number Reduce the padding to the left/right of larger numbers so they fit in the box Make the number text smaller Keep the 123K, and have the option of showing the full amount by some sort of toggle ...


1

Boy is this a rock and a hard place. Definitely keep words intact. No programmer is going to like this (as is already clear), too much info is being removed by the indentation being mucked up. Breaking words doesn't solve this and it does add other problems. To make the best of a bad situation you need to clearly delineate lines. Your examples use zebra ...



Only top voted, non community-wiki answers of a minimum length are eligible