[meta] Followups for API change nodes

Perhaps a silly question, but who is going to manually convert all the old data in http://drupal.org/update/modules/6/7http://drupal.org/update/modules/6/7 to the new format?

jhodgdon, have you unchecked "Promoted to front page" ? :)

Change nodes appearing in News tab in Front page.

I unchecked the promoted boxes. Looks like features doersn't manage those for us.

I'll give you a hearty +1 to not showing the block if it's empty. It was pretty disconcerting to suddenly lose a third of the page all the way down an issue to a block that was providing no meaningful information. Even if it does have data in it, the fact that it needs a grid-4 sidebar region down the length of the page is going to be annoying... I guess I really settled into having a full width issue page and miss it now.

Do you think there'd be some way to put this in the content region floated right so it doesn't affect comment width? (Edit: just realized that might not be so easy.)

Non-full width is not actually a bad thing, some discussion on this landed at http://drupal.org/node/1036132#comment-4726874. Summary: easier to read, try putting more meta-data in the column.

Ahh, sorry to rehash the topic. I'm familiar with studies on the readability of smaller width columns, but I liked the extra space when posting code / images at the very least. I don't often hang out in issues with hundreds of comments, though, so maybe the nature of Commerce's issues is less conversation dense and more technical at this point.

subscribing

sub

I totally agree with rszrama in #4. Losing a third of the screen for all issue information for a tiny block is a colossal waste of space, and I've gotten accustomed to having the full width for issues.

I also agree with rszrama in #4 and merlin in #10. Seriously missing full width issues.

I am a bit confused by this move as well. It adds way to much visual prominence to something, that has little importance to most people. The fact that we are not using all of the page, is not the point - if that improves readability, that's fine.

I find the argument that this is done to improve readability a bit vague though. The idea behind it is that the readers eyes become fatigued after a certain line-length - and thus often a rule of thumb applied that the ideal line-length is between 52-78 characters. Although this is done correctly in this case, there are more factors at play such as the font(especially width), letter spacing, word spacing, and even alignment which is very different in the issue queue than on long body's of text.

I am not sure with the change we have accounted for all the other variables, also considering mark boulton put a lot of thought into the design of these pages - I am hesitant to say, that this should be considered an improvement.

Can a typographer (purist) chime in?

Everyone I've talked to really dislikes the sidebar block. Personally, it makes me feel almost claustrophobic. I am not sure if this is just because we are habituated to the full width, or because at this point it is not yet useful. However, I know the plan is to add more metadata to this column, which would be helpful for issue scan-ability in general.

A couple of thoughts:

1. Could we make the sidebar column skinnier, maybe 1/4 instead of 1/3 width?
2. Could we move the "Jump to" links to the top of the sidebar so there's less visual clutter?
3. Could we even, possibly, move the issue metadata into the sidebar to make it feel more useful?
4. Could we add a few Issue summary/lated revision diff quicklinks out there as well?

Sorry, crosspost because of d.o barf.

Committed. Will be deploying soon.

Hardly the expert here, but some considerations:

Drupal code wraps at 80 chars, people will want to post code snippets and see that not break in here

Readability, fontsize, line length, line height and friends, yes they all relate. For line length alone, the take-away is that *comprehension* seems to drop with shorter line lengths. The ball park is 70 to 110 chars per line, anything above or below is likely to hamper comprehension and retention.

Line-length preference is very much an individual preference. Enjoy this reasonable informed bikeshed discussion in the comments here so we don't have to: http://www.viget.com/advance/the-line-length-misconception/ As per usual, skim the post, then start reading at the bottom :-)

I checked this page with firebug, and an optimal line of text in this here layout, with the block showing, hits 90 characters per line. A line with word lenghts that cause the line to wrap sooner doesn't easily drop below 85 chars per line. So it seems doable and wouldn't necessarily break the design but also comes really close to what is the absolute minimum necessary here.

Just closed #1218166: Why do I (and others?) see revision info on issues? as dup.

Send general layout and design stuff over to our theme, http://drupal.org/project/bluecheese. It isn't this issue's problem.

(Since there was some talk about it here, I'd like to summarize the current situation. *.Drupal.org is ours. We did have Mark Boulton design a redesign, but that was well over a year or two ago. It is ours to evolve now. We need to do that, so there isn't a need for another monolithic redesign project.

We already are doing that, the body font size was bumped up from the original, without changing the columns. That certainly changed the character counts. Different fonts on different systems will give you different counts too.

Issue pages are especially ours to make our own, Mark didn't spend any time on them. We have the advantage of being users of issue pages. We don't have to worry about the old "you are not the user" advice as much, but do keep it in mind.

Sorry for the rant.)

You're right drumm, but we also have to have these design discussions in the context of where it actually happens and people are thinking about it. Thanks for the summary on who's to own this. Also: #1218230: Design for issue pages with more information :-)

New work on this can happen at docs_infra-drupal.redesign.devdrupal.org, when it finished in about 5 minutes. The D.o snapshot was taken before the deployment today, so head over to .../admin/build/features and revert to what is in code. As always, info on the setup is at http://drupal.org/node/1018084.

It is possible to create change notification records that are attached to issues for contributed modules.

Would it be possible to create a view that gathers the change notifications associated with a given project, and link to that view from the project page?

EDIT: Dave Reid said in IRC that this has already happened; I'm going to go and test it out now.

Yup; I added a change notice for one of my projects, and I saw it listed in the resources on the project page.

Posted #1327980: Change notices should default to revisions on which is a quickie if someone has a d.o sandbox.

My two cents on the "undecided" points:

• I think (j) is something we should do.
• (g) seems like it might actually negatively impact the UX to me.
• (f) will be redundant once commits are back-linked. :) It's probably sufficient to just link the issue (as we already do) at that point.
• For (d) I think a "N/A" option is probably a good idea. That section confuses a lot of people, in my experience.

add all the stuff discussed here, with status, to the summary

I would like to re-examine "(g) some sort of taxonomy or component list for filtering change notices -- I don't think we need it, as we have quite a bit of filtering available... we also need to keep in mind that change notices apply to all projects, so we can't just use the core component list here."

The reason is that you can neither filter by keywords or taxonomy. So there is no way at this point to get an overview of changes by category similar to what we had for earlier versions.

There is also no way to get a view that gives you an overview of the actual text of the changes without clicking into every single issue. There is also no way to get an rss feed that has anything other than the most recent changes. Together these make the new list somewhat less useful than the old page that you could scan to see what has changed at a glance. You can see people complaining about this at http://drupal.org/update/modules/7/8, and I personally don't think this is as useful as it could be.

I've asked for access to a development environment where I could try to create some more useful views like this. I'd like a view that displays the text of the change for a way to scan without clicking into each issue, and it would be nice to have a way to create such a scan that is categorized, too. It would also be nice, and probably not too hard, to have the rss feed respond to values in the url so you could see a rss feed for a time period (or for all time), not just the most recent changes.

I'm open to suggestions if people disagree, but I know that for me at least the current view is less useful than the old page was.

So here's one simple improvement. I've altered the view so the original view works exactly as it does now and it is accessible both from the original url and also from list-changes/summary as a default tab.

Then I added a new display that has all the same filters and arguments but instead of displaying as a table, it displays the complete nodes as a detailed display. This makes it easy to filter the changes and read the results without clicking through to each node. This view shows up as another tab at list-changes/detail.

Screenshots and the exported view are attached.

Please go ahead and export the whole feature at admin/build/features when this is ready to deploy. Be sure to call out any config changes not managed by features if they happen.

(I don't have a comment on the actual changes. I shouldn't have any problems with basic views changes, as long as people like them.)

OK the output of fd and the new feature are included below.

The keywords do work here, I was having trouble somewhere but can't re-create that now.

You can see this in the screenshots and at http://changenotice-drupal.redesign.devdrupal.org/list-changes/ and http://changenotice-drupal.redesign.devdrupal.org/list-changes/detail.

The list-changes/summary and list-changes/detail are the right way to configure paths that are tabs (list-changes is the base path, and the other two are the tabs). If I change it to list-changes-detail it's a completely different path and the tab can't work. There are no 'links' to the different views, there are tabs. You can see both tabs from both views. If you want to see a project page it should be list-changes/detail/example or list-changes/summary/example, since the project name is an argument that drops in after the base view path.

I limited it to 30 items rather than 50. Yes it's long, but if you shorten it too much you lose the benefit. I think 30 is a fair compromise.

Added issues:
#1762540: Include revision date in display of API change nodes
#1762568: Add options for update status of API change nodes

Update status of tasks

Here's another one, which hopefully should be pretty easy: #1785334: Add "Distribution developers" as an option under "Impacts" for change notices

add some new ideas to the summary

So can this be closed? Still some undecided issues, but.

That's fine. Partly it's just a reminder that this issue has stalled. Can we decide on the undecided elements?

Thanks!

Added #2302003: Change records tabs for contrib projects link to Drupal core's change records.

#1785334: Add "Distribution developers" as an option under "Impacts" for change notices is done.

That leaves only:

• #1762568: Add options for update status of API change nodes
• #1762540: Include revision date in display of API change nodes

Which I think can stand on their own without this issue tracking them. Especially since the first one looks like it might need some decisions.