Blocks in sidebar on issue pages forces the rest of the page to 2/3 width

Totally agree. Wanted to write an issue about it too:

Moving the issue metadata block to the sidebar (instead of floating it) makes the page unbalanced. I mean that you scroll down and see only the comments (the issue and the metadata is out of your viewport) and realize that the content (the comments in the #main div) has a much bigger white space on the right than on the left. This makes me feel unconfortable, I feel that "something is wrong". (It is good to mention that the with of main div correlate to font size is nice – in default state – cause there are about 80 characters in one line which is ideal for reading.)

I would like to have the block always in the viewport even if we scrolled down (I don't know if this is possible though), that would help a lot with long threads, that's the only reason for me to maintain this new layout.

If this is not possible / useful, I agree with the previous posts, it would be better to float right and restore full comments width.

Hope this helps ;)

The design for the entire issue page has been in the works for awhile. It is intentional, not a regression.

Thanks to a volunteer, we will have even more information in the sidebar, see "3. Bonus: Issue relations" at https://association.drupal.org/node/17983. I think more information there will fill out the pages and make them look more natural.

A taller sidebar would make both having the blocks follow with scrolling, and wide comments problematic. If the sidebar blocks are taller than the browser, and following with scrolling, the blocks themselves would have to scroll too. Just sticking the top of the blocks to the top of the browser wouldn't work. Something clever would have to be done to make it work okay. Alternatively, wide comments would make a whitespace "hole" under a short issue summary.

As thamas found, 8 of the 12 grid columns is designed to be a comfortable line width for reading blocks of text.

Leaving open for more feedback, but changing the title to be more accurate.

And now the D7 upgrade is changing it back just because

I understand you're frustrated, but please don't denigrate the work people have already done:

#1545922: [META] Issue page redesign
#1545952: [META] UI for updating an issue in D7

You (and others) are free to disagree with designs and reasoning, but it's not okay to pretend there is no reason at all. This is the only part of the D7 upgrade where we're actually changing the UI in any way, we're trying extremely hard to *not* change anything unless we "have to", and we're trying to provide lots of explanation about what we decided to change and why. We wrote an entire blog post about why we were changing anything at all.

There's no reason that the node body cannot be a two column layout, and the comments stay as they are today.

That seems like a pretty great compromise! There will be cases where the node body is short and there's not enough summary and the sidebar gets out of balance a bit, but that's not the end of the world. Probably a lesser evil than having more narrow comments on the mega threads with 50+ updates. I suspect we tend to have more long issues than short ones. It would be interesting to run some queries for the lengths of issue bodies vs. the number of comments and visualize it, but I don't have time to do that myself (at least not this week).

If that's an acceptable solution, I'll write it myself.

I'm in favor of trying it, but:
- it's not (just) up to me to decide
- it might get vetoed and not end up being deployed
- tvn has been the one driving this particular aspect of the UI and I'd want to hear her thoughts
- might be worth doing some mockups before coding it
- might be worth doing the queries and data visualization I mentioned to see what kinds of compromises we want to make to cover the majority of the issues on d.o
- the paid staff working on the upgrade can't really justify spending more time on this while the D7 port is not feature-complete

SO... knowing all that, if you still want to run with this idea, please do! My gut reaction is that 2 column body and 1 column comments makes a ton of sense, and will make "everyone" happy. ;)

Thanks!
-Derek

I think it would be great to use whitespace on the right for something useful. E.g. issue metadata block always in your view or 'jump to' links. However if we are not planning to do that anytime soon, we can let comments have it.

Sidebar can get quite busy now indeed (3 types of issue relations, change records). And sometimes it will be longer than issue summary, causing white space issues. I have a feeling though (not based on any data ofc) that issues with busy sidebars will mostly be core ones and they won't have one sentence issue summaries. If whitespaces appear too often, we might think of ways how to fix that, e.g. collapse 'related/child issues' by default.
Some real data from queries Derek mentioned would be helpful.

+1 letting the comments expand full page width! It would be a shame to have a right side block cause the entire remaining page use only ~ 2/3 of the page width (and would really bug me too). Code samples and images would benefit in particular, besides a more polished layout.

The other changes to the issue page are great, nice work, and will be well appreciated!

I think we are thinking about this in the wrong way, we shouldn't "fill" the sidebar. There should be clear argumentation for it being there. And there simply isn't. I see no arguments that support that this is better for legibility. The Drupal.org queue is not a blog post or article.

Issue queues are a highly engaged discussion, that is often many scrolls long. Legibility on column width, has to do with the characters 50-70 is ideal - so other factors weigh in; code comments, font size, blockquotes, listed items - considering that are we still improving legibility?

I'd also like to note that this is a different format. Papers are two, three, sometimes four columns because they are lengthy (and orientation needs to remain) - not saying that we should do that here. But merely looking at legibility from a design perspective on column width, and not taking into account the context is a wrong approach.

I still advocate for changing it to be full width. I see no clear gains from this change, if we don't also change font-size, line height and more. It now just seems like cramping loads of text in a small column.

#10 Agreed. The current sidebar "box" can still stand out keeping background colors, buttons etc., but displayed within, and designed for the single column.

I think the main reasons to keep the column 2/3 width are:

1) Consistency with the rest of the site. e.g. the handbooks https://drupal.org/developing/api, project pages https://drupal.org/project/drupal, g.d.o https://groups.drupal.org/, etc. While the main landing pages of d.o tend to be 100% width, the actual content inside of them tends to be 2/3 width. Presumably because...

2) There's general UX research to back up the fact that shorter lines in the content area are easier for people to comprehend than lines that stretch all the way to the edges. http://ux.stackexchange.com/questions/3618/ideal-column-width-for-paragr... has some references and some examples, I'm sure I could find other ones if I bothered to search more.

However, I will concede that it does look rather strange for the content to be condensed and then not to have any stuff in the sidebar to fill the space on 100+ comment issues. My idea to work around that (make the status block floating/scrolling) was rejected, but we could probably put some other stuff there like the "contributor links" block like there used to be.

@webchick the post you cite, explicitly states:

Additionally, you may want to be very conscious of your content size. For longer content prefer longer lines; with short content prefer shorter lines. Typically take the size of paragraphs and sections in your content as variable to how long the line should be—you don't want 1-line paragraphs, but equally you don't want 30-line paragraphs. Choose a happy average that makes the content easy to visualize.

The research shown (where only A. Dawn Shaikh his paper) primarily goes into articles and news, its not about extremely long pages. Papers like (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.108.4346&rep=re... - The influence of reading speed and line length
on the effectiveness of reading from screen) shows how comprehension is affected by longer pages. I am not arguing against the idea of a shorter line length being beneficial.

I am only saying, you shouldn't look at research like that as black and white. Especially because 99% of the research done on this, as far as I know - doesn't go into its performance on 30 scroll long pages. So we really don't know how well it performances, so what we are doing is acting on a principle. There is a swath of data that shows that a bigger font is beneficial for reading, we don't do that either.

I just don't see the point of "filler" content, because it will run out after like 1 scroll. If we are set on this improvement for legibility, why don't we just center it (and probably tweak the line height?). I don't understand why this is really part of the upgrade, it's not critical to the concept - nor is it likely desired by many contributors. Can't we just push this off till after, and have some good design and research behind it?

I don't understand why this is really part of the upgrade

I think most involved would agree that this is definitely out of scope for the upgrade itself. Any major layout adjustments would be post-launch follow-ups at best.

For now, I'm in favour of leaving the two column layout as is, as the extra space will give us an initial default location for new tools and features as they are developed (e.g. commit backlinks, change request backlinks, etc.) ... otherwise I fear that a one-column layout will result in a new issue page layout/design bikeshed for every new block/feature/piece of metadata we try to add to the issue page, and thus delay new feature deployments.

For now, I'm in favour of leaving the two column layout as is, as the extra space will give us an initial default location for new tools and features as they are developed…

Leaving space for possibly future features is a bad idea IMHO. We will add space when we need it. But untill that an unbalanced whitespace on the two sides is simply wrong.

(Just read #1 comment from me…)

Put a bit more emphasis on the "For now" portion of my comment ... don't confuse it with "For ever".

We've been in a holding pattern waiting for a new release for a long time. I'm saying that this doesn't need to happen *now*, as it would unnecessarily delay the upgrade release. I'm also suggesting that there are some benefits to sticking with the two column layout for a while ... allowing us to incrementally enhance the functionality of the issue pages without every new increment requiring a redesign of the overall layout. We know there is at least one 'official' item on the roadmap (commit backlinks), and I think it's fair to expect there would be at least a couple others. In order to compensate for the holding pattern, let's put a strong focus on building extra functionality for the next 3-6 months ... and *then* tackle the page layout restructuring.

During D7 team call today we made a decision to postpone this discussion post-launch. Initial launch will happen with the current issue page layout. We can't be spending more time on this discussion right now and delay D7 launch even longer.

I dont get what the decision here is? To go with a broken design, or restore it the current issue queue design?

Strongly against this new change (comments not full width). This will irritate me… every day.

What about adding a background color to the "sidebar"? It could stop the feeling that the page is unbalanced. And we could do it everywhere where there is no content in the sidebar (for example module listing pages).

(I know that the sidebar not as high as the main content but we can find a simple trick resolve this – at least visually…)

See the attached image!

Upgrade is live, so what about resolving this issue?

Since the d.o team seems unwilling to change this, I made a style at http://userstyles.org/styles/94685/bojhan-s-drupal-org-style

I think it's fair to assume that "the d.o team" is focused on slightly more critical issues right now ... this can't justifiably be considered much more than an 'annoyance', while there are other issues (complete *breaks* of functionality) which rightfully deserve attention first.

Moving my comments from a duplicate issue here: Agreed on reversion. All I needed was one issue with an exported View to remind me why I liked the full width tracker; I'm sure that will be doubly true for code snippets.

claudiu.cristea made some valuable points on the closed issue, so copying them here (with permission from Claudiu)

Given:

1. The new issue top-right block (or set of blocks) is/are a very nice addition.
2. The block activates a sidebar region that is not used for other purposes.
3. The whole big list of comments is now reduced to 620px, most of them without having something filled at their level in the right sidebar.
4. Code blocks are now very hard to read because the lines are wrapping.
5. We are losing valuable horizontal space in comments where we need to paste long readable lines.

Proposal:

Embed the top-right block(s) in the issue description area (keep top-right positioning). Drop right sidebar.

This is a tough one.
I *LIKE* seeing the metadata in the sidebar, and I would really like to be able to reference it no matter where I am scrolled.... thus the other issue I filed: #2125589: Keep issue right sidebar visible.

But, I also understand the desire to keep the full page width available for the body & comments. (On the other hand, how does this work on the limited space of mobile devices anyway?)

Here is a thought:
What if we would placed the metadata block as a full width, short block at the top of the page. Also make the metadata block sticky at the top of the page so it is visible even when scrolled way down...
I admit that thought has a few drawbacks....

The theme is not responsive yet, so mobile devices aren't (yet) a target. I don't know what a good approach would be for a responsive version of the theme.

@jthorson My comment wasn't about capability, but willingness. I fully understand that functionality breaking bugs should be resolved first, however keep in mind that all these issue queue annoyances add up, and in their whole could influence the rate that people are involved. Given that we have had this discussion several times before launch, even in 2012 and the d.o team seemed adamant on the 2/3 layout. I still don't see the value.

Thanks @Bojhan for the userstyle which is a nice band aid for now.

@Bojhan, #29: ++ and thanx for the userstyle indeed ;)

...also +1 for #2125589: Keep issue right sidebar visible

I think that people will eventually become accustomed to having the sidebar there, and I like being able to scan quickly for the most critical issue data. #2125589: Keep issue right sidebar visible will make it even more useful. If we wanted to be really fancy we could allow people to toggle the location of the sidebar on a per-user basis client-side, like the D8 toolbar. :)

I think we can also reduce the forever-scrollingness of the current issue view in a few other ways:

1. Remove the wasted space. E.g., the comment number and "posted by" data would be more scannable on the same line.
2. Collapse "updated issue summary" comments into a single comment for a sequence of changes by the same user on the same day, or something.
3. Assume there will be fewer comments in the long run if the new issue design meets its goal of making updating the issue summary the primary mechanism for adding to an issue.

There are probably issues for some but not all of those things already?

Even if we fix the page length, 2/3 width still sucks more for reading code or exported configuration.

I like the width when I read comment text 'cause lines are not too long now. And we could use a solution to make code blocks wider when they are active… (or build drueditor into drupal.org ;))

However I do NOT like, that the page feels unbalanced! (See my earlier comments.)

Right now, the comment width is sufficient for 80 characters, which meets our Drupal code style guide (although the styling of a code block might affect that).

Also, an exported view, or any other relatively large code snippet, should NOT be pasted directly into an issue summary or comment body. Something like that should be attached as a text file to maintain the overall readability of the issue queue comment list.

So, count me as opposed to making the comment list full width. Instead, the sidebar white space could be better utilized with something like #2125589: Keep issue right sidebar visible.

Style guides and shoulds just don't cut it for how people use the queue. When you write a CMS whose function names and array addresses can exceed 80 characters, you gotta be forgiving on column widths. It's not like we haven't conditioned our community / contributors / maintainers to be pasting snippets / Views / Rules / etc. into issues for the last 7+ years. : P

The better proposal, if we must keep the smaller column width, was in #34 - let's use a tool to actually expand these code blocks beyond the width of the left column. You can see an example of one such tool (not a recommendation for use) on the Lullablog: https://www.lullabot.com/blog/article/move-logic-front-end-angularjs

Re: expanding the code blocks, it's easy enough to do that for yourself by putting some CSS like the following into Stylish or any of the other browser plugins that allow you to define custom site-specific styles.

.node-type-project-issue .codeblock:hover {
  width: 940px;
}
.node-type-project-issue #aside-region {
  z-index: -1;
}

Obviously this is a terrible long-term solution, but it works well enough in the meantime.

@xjm, #32:

...
2. Collapse "updated issue summary" comments into a single comment for a sequence of changes by the same user on the same day, or something.
...

What a great idea! ...and here's an issue for it: #2136389: Consolidate successive comments from the same user that update the issue summary and/or its metadata into a single comment (credits to you of course)

Now that we have avatars displayed by each comment this has further reduced the usable space. We now have blank white space on the left of the comments. Does anyone know where the implementation and theming of avatars was discussed? I wonder if there was any consideration of putting it in a comment top bar along with name and date etc but leave the usable comment width as it was before?

I haven't really weighed in on this yet. I completely agree with @jthorson in #14 that changing the layout was indeed "out of scope" for an "upgrade".

I have attached the related issues (which introduced the user pics). It's introduction has been discussed in the issues (briefly) and mostly in IRC. From my conversation with @Bojhan, I would surmise that issue comments should indeed span the full width of the page. It isn't hard to just float the sidebar to the right (like it was before) as it would simply push content/comments over when it's appropriate.

Also, there is a possibility that adding responsiveness may increase the max width of the main container? (need @lewisnyman to verify) This, in theory, could go a long way for larger screens so the comments don't appear so squished.

The current responsive bluecheese sets the max-width at 960 to reduce any "regressions" with the desktop layout. I don't see a reason why we can't override this max width for "power user" pages like issues, to make the most of the work space. The current unresponsive bluecheese is actually set up pretty well to accommodate this, as all the columns are already fluid because to the work we did to lay the responsive foundations in the D7 upgrade.