Merge lp://staging/~mbp/launchpad/bug-width into lp://staging/launchpad

I thought about doing this through a feature flag; it seems like the kind of change that would be nice to be able to try gradually to see if anyone objects or if it breaks some browsers. It seems like it would be pretty easy to allow them to show up in CSS, but for this change, being so small and already tested through user style-sheets, it didn't quite seem worth while.

... as an example of further bugs, look at this mp page, where for no good reason the description wraps very narrowly but there's no apparent max-width on the comments.

Hi Martin,

I think this is the wrong solution for the problem. While this adds readability for tracebacks/code you lose readability for everything else.

As we discussed previously I think a better solution would be to add the ability to use markdown (or something similar). That way we can define code blocks and wrap them appropriately (it would give us several other benefits such as allowing us to not have a mono font for all our text, we could also add appropriate syntax highlighting etc).

I think markdown would be great, but it's a substantially bigger project, and this seemed like an incremental improvement.

I see your point about not regressing but on the whole this seemed like an improvement. Having some text slightly too wide is less bad than having other text mangled.

I think the majority of bugs in Launchpad do not include code/tracebacks in their descriptions, I wouldn't want to make it harder to read all of them for the sake of those that include code/tracebacks.

Another interim solution would be to have a toggle on the description that changes the text width to fluid (this would just be adding/removing the 'max-width' property).

@huw, I'm just curious - is 40em known to be optimal / a sweet spot
for readability here, or is it something we've inherited from one of
our many redesigns? Just trying to understand why 80em would diminish
readability for most of our bug reports (vs no limit at all which I
can certainly understand would make things harder to scan).

-Rob

@lifeless, there is a range of line lengths that are considered to be best for readability, usually this is about 1.5xalphabet (just to clarify or maybe complicate, there is some research that says that reading comprehension is slightly better with longer lines-about double the length-but users prefer to read shorter lines).

This roughly fits with what we have currently have. It looks to me like the width we have was implemented with this range in mind, not necessarily an arbitrary design decision (although it could have been and just gotten lucky with the length).

@huw thanks for the explanation!

Empirically, we have five votes on 435905 for a wider display, and no objections (yet) on that bug, and I can't find any bugs complaining that text that is _not_ wrapped, such as mp comments, is too wide to read.

For a technical audience, about 72-80 cells of monospace text is perhaps what people are used to.

Looking at bug 435905 and the following twenty bugs, 8 of them have computer output text and of those 6 suffer to some extent from bad wrapping. Some of them are trivial bugs (invalid or dupes of some other bug). In particular apport output which is present in many bugs can wrap. So, although it's not most bugs (and this is not a very exhaustive survey) I think some accommodation for terminal output could be worthwhile.

I thought about this a bit more, and I keep coming back to thinking we
ought to increase the maximum text width in Launchpad.

We also ought to make the width and the font family consistent across
different text elements - that's a separate bug, but being able to get
there depends on agreeing how they should look.

I'd like to eventually do markup in Launchpad, but it seems like a big
solution to the fairly small problem of code/tracebacks/etc being
wrapped poorly.

Launchpad is a technical tool and a lot of the information in it is
computer text, where readability is seriously harmed by being wrapped
too soon. I've attached a dump of 200 recent bugs from Launchpad and
you can see the majority of them do have machine output. If you view
this in a 45-character-wide text editor it is clearly less readable
than at 80 characters.

<https://bugs.launchpad.net/launchpad/+bug/435905/+attachment/2582319/+files/bugdump.txt>

On the other hand, English text with no line breaks will be unreadable
if it becomes extremely wide, but I think we have some room to go
before that becomes a problem.

Even within single descriptions (eg single reports from apport) there
is a mix of machine text and human language text. Adding markdown
support would give people a chance to get this precisely right when
they care, but we'd still have to have some kind of default, and
automatically inserted text will likely not be precisely marked up.

So we have to make a tradeoff but at the moment I don't think we're
getting a good balance.

Because Launchpad uses a monospace font, 80em is not as many words
across the page as it would normally be, and because there is a
moderate amount of leading we can sustain having lines be a bit
longer.

We could put this behind a feature flag but I do think we should land it.

abcdefghijklmnopqrstuvwxyzabcdefghijkl

My current proposal on this is to set the max-width to roughly (but no less than) 80 character cells. That would be enough for most machine output and code to be readable, but not so much that text becomes unreadable.

80em is substantially more than 80 columns because an em is the height, not the width, of a character.

Just to be clear, I'm pretty sure that's less than what we have now.

Actually you're right! It's 92 characters.

I don't know then, maybe i should just live with it.